GNOME Bugzilla – Bug 544509
[qtdemux] Regression in segment.stop
Last modified: 2008-07-27 12:17:29 UTC
There is a regression in pre-release qtdemux whereby the 'stop' value of the newsegment outputted by qtdemux will not correspond to the stop value of the requested segment seek. This worked perfectly in gst-plugins-good-0.10.8. Still don't know exactly which commit broke it. Will figure this out.
Created attachment 115233 [details] [review] alternative patch an alternative patch to implement reverse playback in qtdemux.
probably broken with the reverse playback patch. Attached is an alternative patch for reverse playback. Last time I checked, it had some bugs but it uses a lot less special casing.
That patch fixes this issue, but still leaves us with the original problem that was fixed by julien's patch: On the following file, if you pause, seek to a position, then play ... it will stop the video playback before the end of the file. The part that breaks it around line 1273 (in _activate_segment() the part that calculates the stop position of the segment). http://dolphy-tech.net/files/iron_man.mov
Created attachment 115250 [details] [review] Fix regression The issue was kind of stupid. The original stop code (from before julien's code) was correct... except for the part where it was using the stop value directly from GstSegment which is in stream-time and not in buffer-time. This converts it so that the outputted newsegment event is correct. I also added at the top the documentation regarding quicktime segments from wim's proposal.
looks correct
Awesome - pop it in
2008-07-25 Edward Hervey <edward.hervey@collabora.co.uk> * gst/qtdemux/qtdemux.c: (gst_qtdemux_activate_segment): Fix segment-stop regression. Add documentation regarding segments in quicktime files by Wim Taymans. Fixes #544509
Alas, while fixing the vast majority of the regressions... it has brought in a new but similar regression. This time it's both the start and stop values of the newsegment which are wrong. By looking at the results, when asking for a segment seek of [start:A, stop:B] it's returning a newsegment of [start:A-(B-A), stop:A] (ergo : segment is of the proper duration, but shifted back in time by (B-A)). Most likely, this is another value in the code for which the time-realm (track time vs segment time) is unclear. Will figure this out and attach a patch soon. Sorry for re-opening this, but running the QA tests takes a long time :)
my bad, this isn't a bug in qtdemux. Just a bad assumption in the segment-seek tests. The assumption is that if I do an accurate segment seek for [start:A, stop:B], the resulting newsegment would have [start:A, stop:B, position:A]... which is wrong. The only thing that can be assumed is: * newsegment.position WILL be equal to seek.start * the sum of all the newsegments duration will be equal to ABS(seek.stop - seek.start). (if there's only one, then ABS(newsegment.stop - newsegment.start) == ABS(seek.stop - seek.start)) I was adding to that the (not always correct) assumptions that: * newsegment.start would be equal to seek.start * newsegment.stop would be equal to seek.stop The two assumptions are correct for most demuxer/decoders... but with quicktime's EDL system... it can be wrong. closing this bug again. Sorry for the noise, better be sure than regret it later :)