FFV1 encodes files that fail strict 3rd-party MediaConch validation when using 2-pass encoding

[James Johnston]

Summary of the bug:

FFmpeg / FFV1 encodes FFV1 slices that fail multiple MediaConch validation rules when using 2-pass encoding.

How to reproduce:

This is on Windows 10 64-bit with nightly build "ffmpeg-2024-08-04-git-eb3cc508d8-full_build" downloaded from ​https://www.gyan.dev/ffmpeg/builds/

1. Download the attached TestVideo.avi file (it has HuffYUV encoding and PCM audio).

2. Run this FFmpeg command:

# Input file is AVI container with HuffYUV video and PCM audio; probably many other inputs will work
ffmpeg -i TestVideo.avi -map 0 -vf setfield=tff -c:a flac -c:v ffv1 -level 3 -g 1 -context 1 -coder 2 -slicecrc 1 -passlogfile TestVideo.log -pass 1 -aspect 4:3 -pix_fmt yuv422p TestVideo.mkv

# Second pass
ffmpeg -i TestVideo.avi -map 0 -vf setfield=tff -c:a flac -c:v ffv1 -level 3 -g 1 -context 1 -coder 2 -slicecrc 1 -passlogfile TestVideo.log -pass 2 -aspect 4:3 -pix_fmt yuv422p TestVideo.mkv

3. Validate the file using MediaConch (available online/live at ​https://mediaarea.net/MediaConchOnline/checker, download from ​https://mediaarea.net/MediaConch, or your favorite package manager).

Expected behavior

FFV1 files should pass validation tests with flying colors.

Note that 1-pass FFV1 files do, in fact, pass. It is the 2-pass encoding that fails.

Actual behavior

MediaConch reports these validation failures (also see screenshot):

FFV1-SLICE-SliceContent Tests run: 24 | Results: ❌ | Fail count: 24
Results: fail ❌ 
Name: SliceContent
Offset: 30925
Value context: /Segment[1]/Cluster[1]/SimpleBlock[1]/Data[1]/Frame[1]/Slice[1]/SliceContent[1]
Value: (57497 bytes)
Results: fail ❌ 
Name: SliceContent
Offset: 88430
Value context: /Segment[1]/Cluster[1]/SimpleBlock[1]/Data[1]/Frame[1]/Slice[2]/SliceContent[1]
Value: (54834 bytes)
Results: fail ❌ 
Name: SliceContent
Offset: 143272
Value context: /Segment[1]/Cluster[1]/SimpleBlock[1]/Data[1]/Frame[1]/Slice[3]/SliceContent[1]
Value: (53000 bytes)

<snip many more>

The validation code for this is located at ​https://github.com/MediaArea/MediaInfoLib/blob/abdbb218b07f6cc0d4504c863ac5b42ecfab6fc6/Source/MediaInfo/Video/File_Ffv1.cpp#L1335-L1336

void File_Ffv1::SliceContent(states &States)
{
    if (BS->BufferUnderRun || RC->Underrun())
        Element_Error("FFV1-SLICE-SliceContent:1");

It appears there is some kind of underrun condition / incoherency in the file. My guess is this used to be called / was intended to be called the otherwise-non-implemented rule "FFV1-SLICE-END", documented at ​https://github.com/MediaArea/MediaConch/blob/d2a4b62ffbaf5475c5c3e82b3e6fc9883a6be592/MetadataDevelopment/ImplementationChecks/FFV1Registry.xml#L203, as "Real slice end is met before or after expected slice end" as a coherency violation.

[James Johnston]

I don't know if this is related to #11127 or not. Both only seem to happen when I used 2-pass encoding, but they also seem like very different validation failures that aren't related. So I've opened two issues.

[Michael Niedermayer]

I suspect this is the same issue as #11127. If thats a bug in MediaConch, i cannot tell but that would explain these errors which seem not to affect FFmpegs ability to decode the files.
Either way, i dont think i can really help as long as FFmpeg parses everything correctly and within spec ranges.
Is there some evidence that FFmpeg would parse something as a out of spec value ?

[James Johnston]

If it's not likely to be an actual FFmpeg issue, then here is a corresponding issue I have raised in the MediaConch project: ​https://github.com/MediaArea/MediaConch_SourceCode/issues/787

There must be a bug in one of these two projects...