[FFmpeg-devel] Fixing av_seek

Michael Niedermayer michaelni at gmx.at
Tue Jan 31 00:02:57 CET 2012


On Mon, Jan 30, 2012 at 03:53:35PM -0500, Don Moir wrote:
> For the most part, I have seeking in my app working really well. I have 
> flags for exact time seeking or key frame seeking. When doing exact time 
> seeking, I have a seek slop factor that currently ranges from 0 to 1/2 
> second. I compute this depending on the file and it just governs how close 
> you want it to the timestamp of interest. In the odd case where the actual 
> seeked to time is far off from the requested timestamp, it could go back to 
> keyframe seeking and this could be controlled with flags at a users 
> degression. This is a pretty rare event though considering that large files 
> generally have an adequate supply of keyframes and with low res or short 
> files, it's quick enough to do it.
> 
> Most of the work has been in over coming a few problems with 
> avformat_seek_file and the related decoders.
> 
> The problem is you cannot have avformat_seek_file failing when it should not 
> and even if it succeeds it must be doing the right thing.
> 
> Some cases when avformat_seek_file fails or fails to do the right thing:
> 
> o - No frames are marked as keyframes. avformat_seek_file returns -1. I 
> think I only have one file like this so we could say this is a rare case. I 
> just make sure I at least seek to the first frame. In order to keep 
> avformat_seek_file from failing, you have to mark the first frame as a key 
> frame and I do this. The one file I have like this is filecopy.avi and it 
> can be found here: https://ffmpeg.org/trac/ffmpeg/ticket/504

patch to fix this one posted to teh ML


> 
> o - The ogg decoder read_seek function is weak. It does not make an attempt 
> to create it's index_entries and without these seeking is going to be bad. 
> This is outlined here: https://ffmpeg.org/trac/ffmpeg/ticket/941
> 
> o - The matroska decoder read_seek function has a couple bugs that effects 
> at least one file I have and that is outlined here: 
> https://ffmpeg.org/trac/ffmpeg/ticket/958
> 
> With the above changes, things work very well but there are a few odd cases 
> still. These cases don't effect things too much. Mostly just a lag after 
> seeking is done and before the next frame can be displayed. This happens 
> only on a few ogg files and matroska files that I know of. It could be 
> because of improper timestamps, improper index_entries, or even just a bad 
> file. Not sure.
> 
> I have a case with WMV2 where after seeking is done, audio is far behind. 
> This was easy for me to deal with and I have not investigated it further at 
> present.
> 
> I tested about 200 files of varing sizes, formats, etc and it works pretty 
> good when the above fixes are applied. For most file formats, I don't have 
> to do much and they just work.

I would be quite interrested to see patches for the changes you did.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120131/2d0ce280/attachment.asc>


More information about the ffmpeg-devel mailing list