After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 523334 - qtdemux loses on multiple segment seeks
qtdemux loses on multiple segment seeks
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.7
Other Linux
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-19 10:11 UTC by Andy Wingo
Modified: 2012-08-13 23:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andy Wingo 2008-03-19 10:11:45 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.
Comment 1 Wim Taymans 2008-05-26 15:45:01 UTC
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.
Comment 2 Tim-Philipp Müller 2009-02-03 14:52:12 UTC
> 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?


Comment 3 Tim-Philipp Müller 2012-06-27 18:30:57 UTC
> > 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?
Comment 4 Wim Taymans 2012-06-27 18:39:12 UTC
yes, it is. It's also in 0.10 AFAIK
Comment 5 Tim-Philipp Müller 2012-08-13 23:19:20 UTC
Ok, let's close this then.