Dan Dennedy [Sun, 30 Jan 2011 19:57:05 +0000 (11:57 -0800)]
Be pessimistic about the duration (kdenlive-1962).
Some clip formats give a slightly longer duration estimate, and MLT does
not handle that well especially in some non-interactive use cases like
transcoding and automated processing.
Dan Dennedy [Tue, 5 Oct 2010 03:39:17 +0000 (20:39 -0700)]
Use a single queue for parallel workers.
This is a major change from the previous model of moving work items
(frames) from one queue to another. This new model improves the behavior
of realtime mode and performance overall. In the new model, a single
queue is used along with an is_processed flag on the frame. Also, there
is an index into the queue (process_head) that indicates from which
point should a worker consider fetching the next unprocessed frame.
There are situations in realtime mode where the processing of a frame
takes longer than the queue (or from head to its fetch index). Over
extended periods of this heavy processing, the video frame in the
consumer may never be updated (rendered=1)! To remedy this, the consumer
detects this and automatically moves the process_head towards the tail,
but even this may not be good enough. The only real remedy is to
increase buffers and suffer with poor latency. If lower latency is
preferred, then it may be better to not use realtime mode and permit
audio discontinuity.
Dan Dennedy [Wed, 16 Jun 2010 04:52:30 +0000 (21:52 -0700)]
Remove audio processing from the worker threads.
This has a bad interaction with the avformat producer, which contains a
buffer of unused decoded samples. This shifts audio processing to the
main consumer thread, which is often light anyways. I recommend to set
the threads property to 2 or more on the avformat consumer to offload
video encoding to separate threads from the audio processing and
encoding.
Dan Dennedy [Fri, 5 Mar 2010 05:24:02 +0000 (21:24 -0800)]
Add parallelism to mlt_consumer.
To use set real_time greater than 1 for frame-dropping or less than -1
for no frame-dropping. It works better with a liberal buffer size. You
can still set prefill less than buffer size, but it must be at least the
same number as real_time, preferably a little higher to help with frame
ordering.
The standard says the post-increment can have effect at any point
between the previous and the next sequence point (or something similar),
so the behavior of "this->refresh_count = this->refresh_count ++" is
undefined.
Dan Dennedy [Sat, 1 Jan 2011 23:08:14 +0000 (15:08 -0800)]
Default to progressive rendering in composite.
Field-based rendering is not sensitive to whether the composite has
motion and therefore produces ugly results for static things by default.
Field-based rendering can be explicitly requested on an animated
composite by setting the progressive property to 0.
Dan Dennedy [Mon, 20 Dec 2010 03:43:47 +0000 (19:43 -0800)]
Increase the speed of switching between sdl_still and sdl.
Based on patch from Jonathan Thomas.
It does this by not calling the SDL_InitSubSystem( SDL_INIT_AUDIO ) and
SDL_QuitSubSystem( SDL_INIT_AUDIO ) methods every time it switches, but
rather when the SDL Preview consumer is started and stopped.
Dan Dennedy [Thu, 16 Dec 2010 07:49:54 +0000 (23:49 -0800)]
Synchronize Producer.set_speed(0) with sdl_preview.
This also helps prevent deadlock while waiting for consumer-sdl-paused
event. Not 100% yet, but 100% requires script (swig) apps to handle the
event asynchronously via an event listener, which is not available yet
for most - only ruby. Furthermore, they would really like to be able to
pass opaque data to the asynchronous handler, which is not yet available
in the framework.
A good example here is pausing playback prior to seeking to a specific
frame. The app should be able to make a consumer-paused event handler to
which it can pass the new position, so it can properly seek after the
pause has officially occurred. Without the ability to pass opaque data,
it must save the new position as an instance variable to use within the
handler - once it has support for event listeners that is.