[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     |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Description changed by parbruek:

Old description:

> 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.

New description:

 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#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker