After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 156387 - [oggdemux] seeking is off by up to 30 secs (regression)
[oggdemux] seeking is off by up to 30 secs (regression)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: 0.8.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-10-25 13:36 UTC by Tim-Philipp Müller
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2004-10-25 13:36:15 UTC
Seeking with current CVS HEAD's oggdemux isn't exact enough. 
 
I'm getting deviations of up to 30 seconds, e.g. I'm seeking to 3223 seconds 
(53:43 mins) from the start of the file, and it actually seeks to 53:12 
minutes. 
 
That's pretty bad if you have a continuous stream with multiple songs, e.g. a 
whole album (.ogg + .cue file) and want to seek to a certain song within the 
album. 
 
Would be great if this got fixed before the next plugins release. 
 
Cheers  
 -Tim 
 
<__tim> BBB: is there some kind of accepted error margin with oggdemux seeking 
now? 
<BBB> yeah 
<__tim> BBB: 'cause I'm seeking to 3223 seconds into the file, and it goes to 
53:12 instead of 53:43 
<__tim> that's 30 seconds ... 
<BBB> we can get that more eaxct, but I didn't include binary tree search in 
my first try 
<__tim> oh, okay. So that's within the expected margin then? 
<BBB> I guess so 
<BBB> it just seeks to byte_length*position_time/length_time
Comment 1 Ronald Bultje 2004-10-29 15:59:37 UTC
Fixed.