GNOME Bugzilla – Bug 516278
[dvdreadsrc] FORMAT_BYTES based seek stopped working since 0.10.6
Last modified: 2008-02-13 22:58:30 UTC
Please describe the problem: pipeline seek() command which used to work in previous revision now causes the pipeline to freeze Steps to reproduce: 1. cvs update code under gst-plugins-ugly/ext/dvdread to HEAD 2. make install 3. run python and use the gst-python gstreamer binding: 4. >>> import gst 5. >>> pipeline = gst.parse_launch("dvdreadsrc ! dvddemux name=demux .current_video ! queue ! mpeg2dec ! ffmpegcolorspace ! xvimagesink") 6. >>> pipeline.seek ( 1.0, gst.FORMAT_BYTES, gst.SEEK_FLAG_FLUSH, gst.SEEK_TYPE_SET, long ( pipeline.query_duration ( gst.FORMAT_BYTES ) [0] * 0.3 ) , gst.SEEK_TYPE_NONE, 0 ) Actual results: pipeline stops playing (video is now frozen/paused) Expected results: video playing should seek to the requested position in the DVD stream and playing continue. Does this happen every time? yes, I have tried with a few DVDs and it happens each time Other information: If I revert dvdreadsrc.c to revision 1.48 it works. It stops working in revision > 1.49
Yep, that revision breaks seeking on BYTES, alright. The problem is that after a bytes seek, you have no guarantee of landing on a NAV block, which is what you need in order to know where you are. The previous code would skip blocks until it found the nav packet, instead of erroring.
See bug #358891
Created attachment 105184 [details] [review] possible fix Any chance you could test the attached patch?
@ds: Do you still have that disk which you tested 358891 with?
Marking as a blocker, since this is a regression
After some tests and confirmation on IRC, committed: 2008-02-13 Jan Schmidt <jan.schmidt@sun.com> * ext/dvdread/dvdreadsrc.c: Fix regression in DVD seeking - when a pack we expect to be a NAV block turns out not to be, scan forwards for up to 2MB (at most ~1sec) until we find one. Fixes: #516278