[FFmpeg-devel] Fixing av_seek

[Don Moir]

Finnally getting around to looking more closely at seek problems in ffmpeg.

This is a follow up to ticket #504. https://ffmpeg.org/trac/ffmpeg/ticket/504

My goal is to write a higher level seek function that depends on the lower level ffmpeg seek functions. In some cases, patches to ffmpeg may need to be applied.

The higher level function will only deal with a timestamp that might correspond to a slider or similiar, and will seek very close to that timestamp without image distortion. 

There are several categories of success or failure when seeking. This first group (Group A), deals with things that work or are easy to deal with.

o - everything works and works well. There are plently of index_entries and the format in question does the right thing. CODEC_ID_FLV1 is an example that works well but some other formats work just as well.

o - there are no index_entries or none of the index_entries are marked as AVINDEX_KEYFRAME. This will cause avformat_seek_file or av_seek_frame to fail. If there are index_entries and the first entry represents the first frame, then I have found that just marking this first index_entry with AVINDEX_KEYFRAME fixes the ffmpeg seek failure problem. If there are no index_entries then you can add one using av_add_index_entry using the correct parameters for the first frame and marking it as AVINDEX_KEYFRAME. This assumes the first frame must be a keyframe and easier to deal with this at startup rather then trying to deal with it when doing a seek.

o - lower level seek functions mostly deal with keyframes and thats all good, but thats not good enough for an end user trying to use a slider to seek. So get as close as possible using one of the ffmpeg seek functions and then proceed forward to the timestamp of interest. This works pretty good and is fast enough. Mostly, good files will have enough AVINDEX_KEYFRAME index_entries to make this behave quite well. Even when there are not enough entries, it works good. You probably want to do this in a separate thread. Make sure you first seek to a timestamp that is less than or equal to the timestamp of interest so you can proceed forward. There are probably ways to improve on this.

The second group (Group B) falls into the class of failures or bad behavior that is not easy to deal with. e.g. an inability to make it work as expected for various reasons.

I am still dealing with trying to find out Group B problems. I have had issues with MPEG1, THEORA, and a few others, and I will know more about these problems as I get into it further.

I use VLC and SMPlayer to cross check and both of these have their share of seek problems. I use my own player to test with.