FFMS2 produces broken frames when indexing m2ts files.

[Ravencentric]

The file in question is:

[BDMV][Haikyuu!! S2][Vol.01-Vol.09]\[BDMV][160120][Haikyuu!! S2][Vol.01]\BDROM\BDMV\STREAM\00007.m2ts

sha256:
4a6c334ab146268ee14bdb344c49cf9aec197d14f39a093aed92e3f8bc57676c

You can grab it from U2 at /details.php?id=31265&hit=1 or from this temporary (one week) mirror:
https://filebin.net/jjholzu2evzcxr7s/00007.m2ts (~7.5GB)

MRE

from vapoursynth import core
from vsview import set_output
from vstools import initialize_clip

clip = core.ffms2.Source("00007.m2ts")[108:]
clip = initialize_clip(clip)
set_output(clip)

Some known bad frames to look for are 6384, 18392, and 28348. Here's a comparison showing frame 6384: https://slow.pics/c/9fWKvaoT
FFMS2 only exhibits the issue when reading the original m2ts. Remuxing the file to mkv causes the issue to disappear.

Versions

vapoursynth R76
FFMS2 5.0

[arch1t3cht]

This is one of those files where not every IDR access unit contains a picture parameter set, but where the picture parameter sets (more specifically, pic_init_qp_minus26) change throughout the stream. (See also: https://arch1t3cht.org/blog/idr_frames/ )

Such files cannot easily be fixed from ffms2's side since ffmpeg does not expose whether its keyframe flags come from an IDR picture or a recovery point SEI. Workarounds are:

• Remuxing to mkv (with mkvtoolnix!)
• Running the file through ffmpeg's h264_redundant_pps BSF
• Using bestsource instead, which does a full decode when indexing rather than only using packet-based heuristics.