Reimar Döffinger <[EMAIL PROTECTED]> added the comment: > I can't see > how it would be O(N^2), but it may well end up reading significant amounts of > data twice, if the pages are large. It certainly is O(N) in the worst case.
Sorry, I thought ogg_read_page would read until it finds a sync word, but it actually reads at most 65307 bytes. So yes, it is "only" O(n). > The issue is that without the patch, seeking is O(N), but it is a much slower > kind of O(N) -- a full decode of the theora stream rather than a scan of the > ogg > packet headers. The patch vastly improves the execution time of a seek, for > both > malicious and typical input. The patch has its merits, but it definitely is the wrong way to fix seeking. > The patch is an absolutely necessary stopgap measure for our application. I'm > not intending on writing a bisection-based seek for ogg files any time soon. > So > take it or leave it. All you need to implement for a bisection based seek is to implement a ogg_read_timestamp function (or more precisely fix the stub that is there to do ogg_read_page and ogg_gptopts) and add it to the ogg_demuxer struct. As an example for a read_timestamp function see libavformat/gxf.c, it is only 9 lines... ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue159> ______________________________________________________
