[FFmpeg-devel] Fixing av_seek
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:
> 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
> 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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel