-ss fast seek can use bad (damaged) i-frame as references

[parbruek]

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.

[Carl Eugen Hoyos]

Please test current FFmpeg git head, provide a sample and the command line you tested together with the complete, uncut console output to make this a valid ticket.

[parbruek]

Getting the right windows components to build rightly for myself? could take me days. I guess you'll have to close the ticket. Maybe ban me. It is a flaw across multiple builds though. I guess more people will have to waste time as I did, due to the lack of info in the documentation. c'est la vie.

[Balling]

Just use ​https://github.com/BtbN/FFmpeg-Builds/

[mkver]

I guess that your video contains changing SPS/PPS without every keyframe containing these in-band. This is not uncommon for BD; commonly only pic_init_qp_minus26 is changed in which case the h264_redundant_pps-BSF could be used to fix this (by modifying the stream to no longer use changing PPS). Alternatively you could remux the BD (not the Matroska file which you already have) with MKVToolNix: It prepends the currently active SPS/PPS to every keyframe (if it detects changing parameter sets), so that this does not happen.