The purge will still work.
As designed, the parent consumer keeps a buffer of pre-rendered frames. By
default this buffer is 25 frames. When the SDL consumer retrieves a frame from
the parent buffer it plays the audio and then pushes the frame into a second
(smaller) buffer for the video thread to raise a callback.
When purge is called, all 25 frames held by the parent are immediately
destroyed. Additionally, any frames held in the SDL buffer (the audio has been
displayed but not the video) are immediately discarded. No delay is incurred.
When stop is called, it used to discard all the frames held by the SDL consumer
(the audio has been displayed but not the video) - just like purge. My
modification changes it so that all of those frames held by the SDL consumer
are immediately spewed out to the video callback. Any listeners to that
callback may choose to display those frames or discard them. Either way, there
is no delay in this situation. The callback is called immediately (as many
times as it takes) and then the stop command returns immediately.
In either scenario (purge or stop), the application won't be waiting for any
audio to be played.
Yes, please do try it - and let me know if you run into anything unexpected.
~Brian
From: Dan Dennedy <d...@dennedy.org>
To: Brian Matherly <c...@brianmatherly.com>
Cc: "mlt-devel@lists.sourceforge.net" <mlt-devel@lists.sourceforge.net>
Sent: Wednesday, February 25, 2015 3:41 PM
Subject: Re: [Mlt-devel] [mltframework/mlt] 15f397: Improve A/V sync when
starting/stopping/refreshing...
I am worried about this change. "if the audio was displayed for
a frame, the video should also be provided for the display" as-stated violates
the concept of frame-dropping, but I think you mean only in certain situations
because this consumer does not call mlt_frame_get_image().
Does this consumer still honor the purge request? Often, when stopping the
consumer, we intentionally want to throw away all frames as possible. Yes, that
might mean there are still audio samples in a fifo, but that should purged if
possible as opposed to continuing to play video. And if not possible, then
video should still stop asap regardless of audio. Stopping and pausing user
actions need to be as instant as possible and not 500ms later. I guess I will
have to try it and see.
On Wed, Feb 25, 2015 at 12:49 PM, Brian Matherly <c...@brianmatherly.com> wrote:
Dan,
This relates to my recent Shotcut changes. I'm very open to comments on this
change. I feel like I did a pretty thorough analysis before making the change -
and a fairly rigorous test after the change. But there is always a risk of
regression.
If you have any concerns, let me know.
~BM
From: GitHub <nore...@github.com>
To: mlt-devel@lists.sourceforge.net
Sent: Wednesday, February 25, 2015 2:09 PM
Subject: [Mlt-devel] [mltframework/mlt] 15f397: Improve A/V sync when
starting/stopping/refreshing...
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 15f397deea19ded69bd068d6b7eb9be9d7b27806
https://github.com/mltframework/mlt/commit/15f397deea19ded69bd068d6b7eb9be9d7b27806
Author: Brian Matherly <c...@brianmatherly.com>
Date: 2015-02-25 (Wed, 25 Feb 2015)
Changed paths:
M src/modules/sdl/consumer_sdl_audio.c
Log Message:
-----------
Improve A/V sync when starting/stopping/refreshing.
When stopping, the consmer would throw away frames that were in the video queue
rather than provide them to the application.
Additionally, in some cases, while stopping, the consumer thread would output a
newer frame and then the video thread would output an older frame - causing
frames to be provided out of order.
Also, when refreshing, frequently two frames would be displayed rather than
one.
The fundamental principle of this change is that if the audio was displayed for
a frame, the video should also be provided for the display - even when
stopping.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
--
+-DRD-+
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
