[FFmpeg-devel] [PATCH] Fix potential infinite discard loop.

Don Moir donmoir at comcast.net
Mon Feb 6 00:28:35 CET 2012


On Sun, Feb 05, 2012 at 03:36:21PM +0100, Reimar Döffinger wrote:
> On Sun, Feb 05, 2012 at 03:11:25PM +0100, Reimar Döffinger wrote:
> > The alternative is to make read_timestamps parse every single
> > packet manually and just ignore what the demuxer claims it to
> > be (though with printing a big fat warning every time it's wrong).
>
> > As in attached, but only for theora.
> > I guess you can imagine what kind of mess that becomes if you have
> > to add such a piece of code for every single codec know to man.

> we only need to for every single video codec known to ogg, which
> should be quite a bit less.
> Besides anyone knows how the official libogg handles this ? Does it
> fail or parse too ?

The Reimar patches work good but it seems to me that "ff_gen_search" falls 
short in the sense that it makes no attempt to add index_entries. Adding 
these entries make future seeks more accurate and closer to any future 
requested timestamp and can speed seeks up.

With the attempt to seek to the exact timestamp and on just some files, the 
seeked to position is kind of short of the requested timestamp and so it 
takes longer to get to the exact requested timestamp. I have this one file 
that I tried in VLC, WMP, and my own app and they all take about the same 
amount of time(slow) to hit the exact requested timestamp.

I would be willing to give up and just goto the nearest keyframe, but in 
this particular ogg case, it's not neccessary.

As a test case, I modified seeking for ogg files a little. I go ahead and 
seek with the Reimar patches. This normally gets it very close to the 
requested timestamp but not always (and this could be some other bug because 
I know a keyframe is available that is much closer but it has not been added 
to the index_entries yet and was not detected by Reimar patches or VLC or 
WMP).

I then do a quick check to see how close it got to my requested timestamp 
and it's going to be pretty close normally. If I detect that it's not close 
enough then I read a few packets to see if I can get it closer. If I can, 
then I just do a quick seek (not avformat_seek_file) on the nearest 
index_entry and things get much better.

It's necessary to get as close as possible with the seek to do exact 
timestamp seeking. If I know I have all the bases covered and I can't get 
close enough then I am done and just let it stop at the nearest keyframe. 
Normally and with the above changes I don't have to do too much to get very 
close to the exact time.

There has to be some kind of happy balance here. This is just a problem with 
ogg and maybe a few others. Seems at least that ff_gen_search should be 
adding index_entries. At any rate, this is easy for me deal with and perhaps 
some additional improvements for ffmpeg seeking could be added in the 
future. Maybe a flag or 2 for avformat_seek_file that will allow closer 
seeks. 



More information about the ffmpeg-devel mailing list