GNOME Bugzilla – Bug 523334
qtdemux loses on multiple segment seeks
Last modified: 2012-08-13 23:19:20 UTC
Steps to reproduce: 1. Set up a pipeline with qtdemux and multiple streams, for example with audio and video. Set it to paused. 2. Attach an asynchronous handler for message::segment-done. Configure the stream for looping via sending it a flushing segment seek. Play the pipeline. 3. When you get segment-done, send a non-flushing segment seek *to the pipeline* setting start=0. Expected results: 1. Playback loops, accumulating the old segment. Actual results: Since we send the seek to the pipeline and not to only one sink, there is a race condition betweeen the two seeks arriving at qtdemux, and the streaming thread running in qtdemux. If the second seek arrives before the first seek's new segment was pushed out, the accumulated play time is lost. The fix is to be more clever in qtdemux. For now I will just send a seek to one sink.
We basically require to send seeks to only one sink, playbin will do that automatically. We can't really fix this for 0.10, it probably requires us to add a counter to the seek event so that we can ignore the same seek in the demuxer.
> We can't really fix this for 0.10, it probably requires us to add a counter > to the seek event so that we can ignore the same seek in the demuxer. Don't we have that now with the event seqnum?
> > We can't really fix this for 0.10, it probably requires us to add a counter > > to the seek event so that we can ignore the same seek in the demuxer. > > Don't we have that now with the event seqnum? Wim? Is this what seqnum is supposed to cater for or not?
yes, it is. It's also in 0.10 AFAIK
Ok, let's close this then.