[FFmpeg-trac] #1607(avformat:new): av_seek_frame() without AVSEEK_FLAG_ANY on mpg files returns success without seeking to a keyframe

[FFmpeg]

#1607: av_seek_frame() without AVSEEK_FLAG_ANY on mpg files returns success
without seeking to a keyframe
------------------------------------+------------------------------------
             Reporter:  mbradshaw   |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by DonMoir):

 The reason ff_seek_frame_binary is not effective in this case is because
 there is no index table that marks keyframes. So ff_seek_frame_binary
 basically does nothing and falls into ff_gen_search with the original
 requested timestamp. If an index table could be built then
 ff_seek_frame_binary would probably be fine as it is. Some other formats
 have a simple read_seek that builds the index table and then calls
 ff_seek_frame_binary. So Michael Bradshaw says it is not possible to build
 an index table in this case.

 Special seek code can always be available for any format but in this case
 it just defaults to the generic seek code and ends up in ff_gen_search.
 ff_gen_search is currently blind about any keyframes as far as I can tell
 in this case. Your requested timestamp is unlikely to fall on a keyframe
 and since there were no index entries. ff_gen_search does work if you have
 seeked to a known keyframe timestamp.

 ff_gen_search is the code that actually closes in on the timestamp and it
 does appear to work for timestamps that represent actual keyframes. So you
 probably don't want to modify ff_gen_search to do extra work in the case
 when a timestamp is passed in that is known to represent a keyframe. These
 known timestamps are typically retrieved from an index table.

 ff_gen_search seems to be more of a subroutine that works off whatever you
 pass it and used for reading the timestamp position.

 So now we are back to needing a specialized read_seek function in this
 case. This is because you probably don't want to modify the existing
 generic seek functions. It is completely normal for various formats to
 have a specialized read_seek function. The read_seek could be a modified
 version of ff_gen_search or whatever that does the right thing.

 Would be good if someone that knew for sure would comment on all this.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1607#comment:14>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker