[FFmpeg-devel] ogg seeking status
donmoir at comcast.net
Wed Feb 8 11:06:29 CET 2012
> 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.
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,
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 :)
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.
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.
More information about the ffmpeg-devel