[Libav-user] Why does av_seek_frame() not seek to a keyframe?

[Don Moir]

> Afair, Reimar believes the seek function should not try hard to find
> a keyframe because seeking faster is more important.

This most important thing is consistency. In my case (and anyone really), 
that means when I do a seek, the first returned packet should be a key frame 
packet and the time of that packet should be less than or equal to my 
requested seek time.

Testing with the sample provided by Michael Bradshaw at (785mb):

https://doc-04-50-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/t0csnri6mmjsd3mqbnb8qdv7b1tiq1e8/1342713600000/11977383638970716307/*/0BxWx_dIBnyRoZDNDeDVud3NNcEE?e=download

So as Michael and others have stated, seeking on the above file seeks to a 
non key packet and so there can be a pause before the next frame can be 
displayed.

The following is sort if generalized to make it simpler and assumes you know 
packet times, display times, and how they relate to your requested seek 
time.

1) The first thing is to determine is when it going to be a problem. (for 
what codecs)

2) The next thing would be how far back in time to you have to go to 
guarantee you are going to get a key packet who's time is less than what you 
requested. The how far back number seems to be guess work but there may be a 
way to get an accurate number.

3) after the seek, read and store packets up to your requested seek time 
(don't decode). Flush the stored packets whenever you hit a key packet.

4) When you are finished reading and storing your packets and if your packet 
queue contains more than one packet, read the queue and decode packet until 
you have 1 packet left in queue.

For the above file I subtracted 2 seconds from my requested seek time. The 
main thing is don't start decoding until you know you have the key packet 
that is closest to your requested time. Reading the extra packets as long as 
they are not decoded does not impact things very much.

The seek is now dead on and quick for the above file.

The main unknown is how far back in time you have to go to gaurantee success 
on a general basis.

The above was easy enough for me to do (outside of unknown subtract time) 
but of course we should not have to do it. The nature of my projects means I 
need to be as accurate as possible. We all want accuracy but if I don't at 
lease make it happen to the best of my ability I will get complaints 
quickly.