[FFmpeg-devel] ogg seeking status

[Don Moir]

Good to see you are persistent reimar, I figured you and others might be 
getting tired of this by now.

> On Mon, Feb 06, 2012 at 12:14:09PM -0500, Don Moir wrote:
>> 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.
>
> Can you provide a sample?

This file is kind of large but shows a couple things. Probably best tested 
in MPlayer for you. I can also provide more samples.

1) with your ogg_read_timestamp patch in and on startup, click around the 
6 - 7 minute mark and it should jump back to the 3 - 4 minute mark and this 
is way too short to do effective exact timestamp seeking - most places you 
try to seek in this file will bump you back at least 2 or 3 minutes and 
sometimes more. There are some places where it will be pretty close though. 
The good news is, your frames should display without distortion or at least 
very minimal. As the file continues to play you should start to see closer 
seek positions because the index_entries will be built up gradually.

2) with ogg_read_timestamp prior to your patch, the seek position will be 
almost dead on but you will get distorted frames.

3) Creating the index entries for this file is pretty fast and I am 
improving on that. But these show me that keyframes are indeed very much 
closer to that reported by 1) above. I now have no problem seeking with this 
file and everything is quick with no distorted frames. Not to say it's all 
good for me with every file just yet but improving.

http://sms.pangolin.com/temp/bad_seek_not_accurate.ogv  (104 mb)

>> 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.'
>
> Well, the patch I posted fixes the issues for the sample file you have.
> If you still have issues with other files, we'll need more samples since
> that should be a different bug then.

I am not sure what patch you are talking about here. Please point me to that 
patch if you will so we can make sure we are on the same track. If I find 
that I already have the correct patch, then I will post more examples.

> And if the files that are fixed by setting os->keyframe to zero are all
> broken whereas the one that is broken is valid, I prefer the valid file
> to work almost no matter how many % it fixes.

When I say above that I cannot find a single file where this is a problem 
means I cannot find any file period that breaks because of setting 
os->keyframe to zero . They can be good files, bad files, it does not 
matter. If you have one that would fail because of it, I would like to see 
it. It just happens to fix the broken cases without breaking the good cases 
and the broken cases are easy to find.

>
>> 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)
>
> libavcodec is not involved at all in this, only libavformat.
> And I wasn't even aware ffdshow handles demuxing nowadays.

Clearly, just trying to avoid confusion but quess it didn't work :) I think 
they wrap libtheora into the ffdhow libavcodec.