[FFmpeg-devel] Fixing av_seek

[Don Moir]

> with h264 you are not guranteed to have any keyframes at all.

Yes thats fine, but I assume that when a AVIndexEntry in the index_entries 
table is marked with AVINDEX_KEYFRAME, it is supposed to represent a 
keyframe.

Is this a valid assumption ? All the entries in the bad_seek sample h264 
video are marked with AVINDEX_KEYFRAME. Is this just an invalid assumiption 
when there are B / I / P frames ?

If  the index_entries table is correct and my assumption is correct, then 
when I call avformat_seek_file, I would expect that to land dead on a 
keyframe regardless of B/I frames etc. but maybe this is not the case.

If the index_entries being marked with AVINDEX_KEYFRAME for h264 (or in 
other cases) is not valid I can deal with it.

> Your video above works fine with "-threads 1" its thus a "multi
> threading is now default regression".

At this point I am not sure what "fine" is supposed to mean :)

o - I can play this using ffplay or SMPlayer and seek sort of works ok but 
not without artifacts in the video. Not sure if ffplay is really doing this 
right or not. (it may be seeking to zero and procedding forward - not 
sure) - It's pretty easy to get ffplay all messed up when seeking with this 
file. That is, multiple artifacts, etc

o - if I seek with avformat_seek_file and use my video stream index (which 
is what I want to do), it seeks ok but then on playback there is about a 4 
second delay before animation begins again since ffmpeg is trying to figure 
what the next finsihed frame should be. The video stream index in this case 
is zero which is the default stream index. I cross checked this by not using 
avformat_seek_file and just searching the index_entries, setting the file 
position, and updating the cur_dts. (seek_frame_generic). I get the same 
results as expected.

o - I can get performance results similiar to ffplay but without artifacts, 
just by seeking to zero with the sample video, and proceeding to the 
timestamp of interest. This is just slower but I can deal with that if 
needbe.

Michael, if you could comment on the above, it may lead to a better 
understanding. In the meantime I will be looking further and reading thru 
the D.2.7 documentation and it appears to go thru quite alot of detail on 
h264.

Again, the particular h264 sample file I am dealing with presently is here:

http://sms.pangolin.com/temp/bad_seek_index_h264.zip  (2.5mb)