[FFmpeg-devel] ogg seeking status

Wed Feb 8 20:29:42 CET 2012

----- Original Message ----- 
From: "Don Moir" <donmoir at comcast.net>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, February 08, 2012 5:06 AM
Subject: Re: [FFmpeg-devel] ogg seeking status


>> 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);'

**************************
sorry meant to say do:

Then do: avformat_seek_file (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.
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel