[FFmpeg-devel] ogg seeking status

[Don Moir]

o - the reimar patch to ogg_read_timestamp does provide somewhat accurate keyframe seeking - problem is it doesn't get close enough - not sure if this is a failure of the algorithm or not but I do know that much closer keyframes are available - I was not able to improve on it. Since you still don't have the index entries, future seeks will tend to have the same "not close enough" problem and this can effect exact timestamp seeking quite abit. If you don't care about exact timestamp seeking then I suppose it works well enough, but expect it to be off sometimes quite abit.

o - the reimar patch to ogg_read_page to fix potential infinite discard loop seems to work well - It fixes some main problems with ogg seeking.

o - as mentioned by reimar, Ogg Skeleton 4 files do contain an index table that is intended for faster seeking. This falls in line with some of the other demuxers and hopefully this will be implemented in ffmpeg. Information on Ogg Skeleton 4 and keyframe indexes can be found here: http://wiki.xiph.org/Ogg_Skeleton_4#Keyframe_indexes_for_faster_seeking

o - I have to set os->keyframe to zero after a seek - I think it may be a hyothetical that this can cause a failure - so be it - I cannot find a single file where this is a problem but I can find about 20 percent of files tested that will have a problem if I don't do this. I would rather have most of the files working rather than one that might fail on occasion.'

o - overall, reading the packets in and making sure the index entries are created typically works better. A little slow on some files but future seeks are always faster. For now, I will look into improving this but it's not something you want to have to do, especially since more than likely the index is already in the file and could be read.

o - the ffdshow libavcodec implementation seems to work better than the ffmpeg implementation for ogg files. Mostly this means it dosen't have the problems associated with not setting os->keyframe to zero after seek in ffmpeg. Seeking can be faster but doesn't always appear to be optimal. (ffdshow's libavcodec is not the same as ffmpeg's libavcodec - just the same name as far as I know)