#11128: FFV1 encodes files that fail strict 3rd-party MediaConch validation when using 2-pass encoding -------------------------------------+------------------------------------- Reporter: James | Type: defect Johnston | Status: new | Priority: normal Component: avcodec | Version: | unspecified Keywords: FFV1 ffv1 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- **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/abdbb218b07f6cc0d4504c863ac5b... {{{ 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/d2a4b62ffbaf5475c5c3e82b3e6fc98..., as "Real slice end is met before or after expected slice end" as a coherency violation. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11128> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker