[FFmpeg-devel] ogg seeking status

[Don Moir]

> On Mon, Feb 06, 2012 at 04:36:37PM -0500, Don Moir wrote:
>> 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
>
> MPlayer seeks at least within 10 seconds of any position in the 6
> - 7 minute area.
> However the audio time stamps for a while reset to 0 before going
> back to proper values, so that might cause some issues.
> I have not yet tests FFmpeg/ffplay, but it seems to me that the
> seek function in principle seems to work fine.

I guess the thing is we and/or I don't know what MPlayer might be doing to 
catch up to the requested time.

With my own app I can set that in about 3 or 4 ways to test things and thats 
the value of a special test app and looking directly at the code to see 
what's going on. As it stands I can't count on SMPlayer or ffplay to do 
things right (or any other player really for all cases of every format) but 
they can be good for a cross-check.

With this sample:

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

I just noticed that this is one of those many "good" files that won't work 
correctly if you don't set os->keyframe to zero after seek. I don't even 
notice these kind of problems because I always set keyframe to zero after 
seek. Your audio being off is is good indication of this and reminded me to 
check the behavior of that and sure enough was a problem if I don't set 
os->keyframe to zero but it's not bad for this file and it does not effect 
this test I am going to ask you to do.

Test 1)

Open this file like you would normally in some of your own code or use the 
MPlayer code to get it opened. I open the audio and video streams for this 
file.

Then do: avformat (pFormatCtx, videoStreamIndex, INT64_MIN, 0x405c, 
INT64_MAX);

For this file, the 0x405c corresponds to about 9 minutes.

Start reading packets until you get the first videoStreamIndex packet using 
av_read_frame (pFormatCtx, &packet);

The first videoStreamIndex packet should contain 0x1b41 for both the packet 
pts and dts values. 0x1b41 a little less than 4 minutes for the video stream 
for this file and this is way off.

Now I would need to proceed to read packets and making sure is all good 
until I hit the 9 minute mark. When doing exact timestamp seeking you have 
to make sure complete frames are going to be available and this can slow it 
down when your time is way off like this.

Ok the above test should get us on the same page for the way off problem :)

Test 2)

Open the file much like to did in Test 1, and just after open, read and free 
all the packets. You can then check the video stream index_entries and you 
will see many entries and they all flagged as key frames. If you now look in 
the index_entries around position 0x102 you will have a keyframe with 
timestamp at 0x4020 which is much closer than that returned by just 
avformat_seek_file. You can now seek directly to the position associated 
with 0x4020 and proceed quickly.

For ogg files only:

What I currently do is I first call avformat_seek_file but I am going to 
optimize that. I then check to see how close it got. If it's not close 
enough, I read in some packets starting at the position set by 
avformat_seek_file and check the timestamps of the packets. If I have 
determined I can get closer then I do a qucik seek to the index_entries of 
that closer timestamp. I can now proceed and be happy it's as close as 
possible and this is quick. I would not have to do this extra step if 
avformat_seek_file got closest to begin with.

All the ogg files that don't seek correctly for ffmpeg when you don't set 
os->keyframe to zero after seek, do work in ffdshow libavcodec. They also 
all work in my app because I set os->keyframe to zero after seek and I have 
not found any file it breaks. ffdshow libacodec is just not very fast at 
seeking for the above file.

Let me try and give another status list here:

o - I have not had any problem with the patch for fix potential infinite 
discard loop. This fixes files like BuckBunny on ticket #941.

o - I know I get much closer to a requested timestamp then that set by 
avformat_seek_file with your ogg_read_timestamp patch. I took a quick look 
at the patch to see if I could improve on it but wasn't able to without 
spending much time on it. Before this patch, the seek position of the 
requested timestamp was pretty much dead on, but you will be positioned such 
that you will get incomplete frames.

o - I probably could tell you why setting os->keframe to zero fixes things 
and doesn't appear to break anything, I do have some clues but I am in punt 
mode right now and don't have the time for it just yet. I just need 
something that works now and that does the trick. Setting this to zero fixes 
about 20 percent of my ogg files and I have not found any file it breaks. 
Try setting os->keyframe to zero on this file. For me it fixes it perfect. 
You told me it's a bad file. You may not be able to count on whatever it is 
that you are using to test with to do it right. 
http://sms.pangolin.com/temp/bad_seek_os-keyframe_Wiki_feel_stupid.ogv If 
you want a bunch more then ask. I hope you will look into this issue more as 
well. Don't just say this is a bad file and give up on it. I have several 
that have the same problem. I have no problem with this file.

o - with some changes I have made and some patches from reimar all my ogg 
files work and seek well. The fact is, my app now does this better than any 
other player I tested: VLC, fflpay, SMPlayer, and WMP using ffdhow. These 
players all have problems with ogg. ffdshow libavcode does get it all right, 
it just can be slow on some seeks.

> but it seems to me that the seek function in principle seems to work fine.

Yes it does appear to work in principle. That is you are going to be 
positioned at a keyframe and can expect clean results. It can be very far 
off though and I don't know why that is. Please run Test 1) and Test 2) 
above so we can see what your results are.