GNOME Bugzilla – Bug 341719
bisection algorithm in ogg doesn't bisect in some cases
Last modified: 2006-05-15 15:01:04 UTC
Create an ogg file like this: gst-launch -v videotestsrc num-buffers=1000 ! theoraenc keyframe-force=20 ! identity ! oggmux ! filesink location=video.ogg Then play back using totem, seek to the middle, and notice how it takes 100% CPU and quite some time to get there. Not very scrubby. Attaching a patch to fix it
Created attachment 65423 [details] [review] patch to not look at pad->first_time, which is always _NONE
could someone comment on what pad->first_time was used for, and why it got lost in the refactoring ? Obviously that chunk of code should check for it being GST_CLOCK_TIME_NONE if it's to be reintroduced.
This patch fixes bug #341756 too and I didn't see any regressions until now
*** Bug 341756 has been marked as a duplicate of this bug. ***
* ext/ogg/gstoggdemux.c: (gst_ogg_pad_submit_packet): Fix seeking performance in the case where a non-header packet has a 0 granulepos (busted theora case). Fixes #341719