GNOME Bugzilla – Bug 158976
[oggdemux] seeking broken again [regression]
Last modified: 2004-12-22 21:47:04 UTC
In very long ogg/vorbis files (=50-70 mins/50-130MB), seeking is partially broken again. Everything worked great after Ronald fixed bug #156387, but something seems to have been broken again since. This is the scenario: a normal demux/decode pipeline, where the audiosink is queried for the current position ca. 5-10 times per second. Now, when I seek to a certain position in the ogg/vorbis file, the 'current position' pointer in my media player continually jumps back and forth +/- 1-3 seconds or so for a couple of seconds, sometimes ca. 5-10 seconds, before it settles down and actually goes on to play from that position again. While it is jumping back and forth, it's mostly quiet, with a couple of extremely short sound output burtst/stutter sounds once in a while (each 1-2 secs). Marking this as a blocker, as it's a quite noticeable regression. Cheers -Tim
Created attachment 34007 [details] seek log 1
Created attachment 34008 [details] seek log 2 (playing from 16:35 to 17:35 to get the granulepos) attached gst debug logs for oggdemux, and IRC log snippet, so it doesn't get lost: <tim> BBB: http://sceptic.centricular.net/oggdemux-seek-log-1.txt <BBB> 391):gst_ogg_demux_push: Seeking took too long, continuing with current <BBB> hm <BBB> hm <BBB> hm <BBB> crappycrap <tim> BBB: here the seeking process lasts about 15 seconds or so, maybe longer. and it goes 17:01, 17:02, 17:03, 17:04, 17;05, and then back, about 3-6 times, and then plays from 17:05 or so <BBB> <oggdemux0> initiating seeking to format 1, offset 45026100 <BBB> what's that? <BBB> default <BBB> ehm <BBB> is that good? <tim> don't ask me, I'm doing a time based seek, that code in my app hasn't changed since gstreamer 0.7.x, and has never been a problem since AFAIK <BBB> but why DEFAULT? <BBB> it should be TIME <BBB> only TIME is lineair <BBB> hm, ok, that's a log thing <tim> ev = gst_event_new_seek (GST_FORMAT_TIME | GST_SEEK_METHOD_SET | GST_SEEK_FLAG_FLUSH, (guint64) newtime); (void) gst_element_send_event (play->priv->audiosink, ev); that's all I'm doing <BBB> do you're seeking to ~ 1000 secs here? <BBB> i.e. ~ 15 min.? <tim> Seeking to 1021 secs <tim> gotta go, biab, let me know if you need anything else <BBB> yes, can you seek to 16:30 and let it play for a minute? I'd like to know the pages/granulepos in the file <tim> BBB: http://sceptic.centricular.net/oggdemux-seek-log-2.txt (that starts from 0, then seeks to ca 16:35 and plays to 17:35) <BBB> so now it did work <BBB> right? <BBB> seeking didn't fail this time <tim> yep, it seemed to work there <tim> it only fails ca. 50% of the time <tim> dunno about the percentage, but often enough to be annoying :) <BBB> right... well, logarithmically, there's a larger percent chance of it failing if the file is larger <tim> with 50% of the time I meant it fails with about 50+% of my 'large files' <BBB> right... <BBB> well, the funky thing is that it fails to resync, apparently <BBB> I'd be interested in why <BBB> because it sweeps between 6636 and 6662 (packetno.) <BBB> actually <BBB> pageno <BBB> that's not_good(tm) <tim> the problem must have been introduced in the last 2 1/2 weeks, there can't have been two many changes since then, can there? <tim> well, I hope you can reproduce it <tim> biab <BBB> hard to say with cvs being offline :) Cheers -Tim
Created attachment 34027 [details] [review] fix The problem appears to be with broken files that fail to resync on the requested seek position. The consequent resync position and the sent discont don't match. This patch fixes that. Tim confirmed it to fix his problems.
commited