GNOME Bugzilla – Bug 610005
[oggdemux] regression: bad seek granularity
Last modified: 2010-02-23 13:26:23 UTC
Created attachment 153839 [details] sample recording When trying to seek the following file in totem (gstreamer 0.10.26), the position slider never goes exactly where I want. If I click at 14 seconds, for example, it goes to 9 seconds instead. On longer files (ie: 3 hours long), I am usually unable to be more precise than 5-10 minutes for seeking. I don't recall this being a problem before.
This works indeed with -base 0.10.25 / -good 0.10.17, so looks like a regression in GStreamer.
FWIW this fixes it for this file: diff --git a/ext/ogg/gstoggdemux.c b/ext/ogg/gstoggdemux.c index 84f3ad7..399cac5 100644 --- a/ext/ogg/gstoggdemux.c +++ b/ext/ogg/gstoggdemux.c @@ -1791,7 +1791,7 @@ do_binary_search (GstOggDemux * ogg, GstOggChain * chain, GST_TIME_FORMAT, granulepos, GST_TIME_ARGS (granuletime)); granuletime -= pad->start_time; - granuletime += begintime; + //granuletime += begintime; GST_DEBUG_OBJECT (ogg, "found page with granule %" G_GINT64_FORMAT " and time %"
From some tests this doesn't seem to break anything... but I can't say that I understand the timestamping in oggdemux ;)
Created attachment 154431 [details] [review] 0001-oggdemux-Don-t-add-last-page-s-time-to-the-current-o.patch ... but it doesn't make much sense to always add the last found page's time to the current page's time when doing the binary search.
This seems to work fine for me with git everything. Let me figure out what happened.
Created attachment 154484 [details] [review] possible patch This should be the proper fix.
Comment on attachment 154484 [details] [review] possible patch Works for me, thanks!
commit 63593f5f1e9ab0b00bff487a42f8f04e62c2a1cc Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Feb 23 11:41:20 2010 +0100 oggdemux: use the chain begin_time instead of our counter We update the passed begintime argument to narrow our search region in the binary search. This means that it does not always contain the chain begin time after a couple of bisects. Use the real chain->begin_time to bring the granuletime to the time in the chain instead. Fixes #610005