[gstreamer-bugs] [Bug 158976] [oggdemux] seeking broken again [regression]

[bugzilla-daemon at bugzilla.gnome.org]

http://bugzilla.gnome.org/show_bug.cgi?id=158976
GStreamer | gst-plugins | Ver: HEAD CVS





------- Additional Comments From t.i.m at zen.co.uk  2004-11-21 19:02 -------
Created an attachment (id=34008)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=34008&action=view)
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


------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.