[FFmpeg-trac] #9257(undetermined:new): -ss fast seek can use bad (damaged) i-frame as references

[FFmpeg]

#9257: -ss fast seek can use bad (damaged) i-frame as references
-------------------------------------+-------------------------------------
             Reporter:  parbruek     |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:
 My apologies for what is a particularly minor bug, if it even qualifies as
 such. This is about the error handling of -ss before versus after the
 input line.
 According to the official documentation and wiki pages, when -ss is used
 before a video input, ffmpeg will seek via I-frames and merely use the
 nearest I-Frame as a starting point for decoding video. According to
 virtualdub, I have found several videos with false I-frames in their
 streams, followed by B-frames which contained complete frame info. When
 using the faster seek (-ss before input) from such an I-frame, ffmpeg will
 produce an initial grey frame, as well as attempting to repair the initial
 frame of the output, starting from any frame in the GOP after the false
 I-frame. However, if I use slow seek, or a combination of fast and slow
 seek, ffmpeg will recognize the false I-frame as such, and generate no
 grey frames or errors.

 How to reproduce.
 I don't know what videos you have available. That being said, if you have
 the extended edition of the fellowship of the ring on hand, take disc 1
 and check out the main film:
 {{{
 % ffmpeg -ss 6083.618 -i "C:\Video\THE LORD OF THE RINGS- THE FELLOWSHIP
 OF THE RING (EXT.) PT. 1\THE LORD OF THE RINGS- THE FELLOWSHIP OF THE RING
 (EXT.) PT. 1_t02.mkv" -o test.mkv

 ffmpeg version 2021-05-19-git-2261cc6d8a

 }}}
 In this case, fast seek will attempt to decode using the false I-frame
 #145857, that is, the frame at 1:41:23.452. If ffmpeg uses slow seeking
 from an I-frame before 1:41:23.452, no error is encountered. If this bug
 is reproducible, would you consider updating the wiki page on seeking to
 mention the utility of using a combo of fast and slow seeking, until a
 time when fast seeking handles errors as well as slow seeking? It took me
 several hours to discover the bad I-frames and the fix, and I'd like to
 save the next person the time.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9257>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker