[FFmpeg-devel] ogg seeking status
donmoir at comcast.net
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
> Then do: avformat (pFormatCtx, videoStreamIndex, INT64_MIN, 0x405c,
sorry meant to say do:
Then do: avformat_seek_file (pFormatCtx, videoStreamIndex, INT64_MIN,
> 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
> 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
More information about the ffmpeg-devel