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 680306 - [segment] gst_segment_do_seek() does not properly handle flushing SEEK_NONE seeks
[segment] gst_segment_do_seek() does not properly handle flushing SEEK_NONE s...
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
Other Linux
: Normal blocker
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2012-07-20 10:25 UTC by Sebastian Dröge (slomo)
Modified: 2013-06-10 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Sebastian Dröge (slomo) 2012-07-20 10:25:22 UTC
In 1.0 gst_segment_do_seek() has a problem with flushing SEEK_NONE seeks. the resulting segment will be the same as before basically, but as the downstream running time is reset it will wait until the clock advanced to the current position.

It should probably subtract the running time of the current position from base, but this would lead to negative base which is not allowed currently.
Comment 1 Sebastian Dröge (slomo) 2012-07-20 10:26:49 UTC
Can be reproduced with

Just needs the file to be downloaded locally and the URI adjusted... and the seeks changed to SEEK_NONE.
Comment 2 Sebastian Dröge (slomo) 2012-07-23 10:44:37 UTC
Marking as blocker as Wim talked about not changing the base-time at all when flushing... or making it an unsigned variable. Both would be an API change.
Comment 3 Wim Taymans 2012-07-27 15:13:33 UTC
commit c8840b8270a463caee18fc8c5fccf242345eeebf
Author: Wim Taymans <>
Date:   Fri Jul 27 17:09:45 2012 +0200

    segment: add offset field
    Add an offset field that is used to track at what position the segment was
    updated. This is used to set the running time to 0 when we do a flushing
    seek that doesn't update the position.
Comment 4 Tim-Philipp Müller 2012-08-29 00:18:01 UTC
Closing, there's another bug for matroskademux.
Comment 5 Mathieu Duponchelle 2013-06-09 22:03:22 UTC
(In reply to comment #4)
> Closing, there's another bug for matroskademux.

Which I just encountered, in relation with the second (incorrect) patch mentioned here : 
Is there a report for it ?

I noticed that this bug didn't happen with qtdemux for instance.

I don't have much more information about it.
Comment 6 Sebastian Dröge (slomo) 2013-06-10 11:59:25 UTC
I think the matroskademux bug report is this one here: #679250