No head frame in new MXF Muxer

[Francesco Bucciantini]

Summary of the bug:

Ever since August 2020, all files muxed in .mxf with FFMpeg fail to be checked-in correctly in AVID Interplay Access. Whenever a file is checked-in, it fails and if it's played back, it says "no head frame found" and it shows the first frame (frame 0) either as black or with an error as it fails to decode it. This is particularly frustrating for broadcasters 'cause playout ports are prone to misbehave when decoding XDCAM-50 files created with the new MXF Muxer unless they're remuxed with BBC BMX Transwrap. I took a look at what changed and I believe this is related to this commit:
64ff61b3c52af335e811fe04b85108775e1f2784

The August 06, 2020 build works, the August 24th build and all consequent ones don't.

How to reproduce:

ffmpeg.exe -i "%%~nxF" -pix_fmt yuv422p -vcodec mpeg2video -s 1920:1080 -aspect 16:9 -vf setfield=tff -flags +ildct+ilme -r 25 -b:v 50000k -minrate 50000k -maxrate 50000k -bufsize 36408333 -af loudnorm=I=-24:LRA=1:tp=-2 -acodec pcm_s24le -ar 48000 -g 12 -bf 2 -profile:v 0 -level:v 2 -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -f mxf "%%~nF encoded.mxf"

#The ones that fail are all the ones after
ffmpeg version git-2020-08-24-3477feb
built on 24th August, 2020

Including that one and the latest git-master as of today (25th of January 2021).

#The last one that works is
ffmpeg version git-2020-08-06
built on 6th August, 2020

The main differences when producing an MXF file between the two builds with the very same source (color bars) and command line are:

[Francesco Bucciantini]

Differences between version 1

[Francesco Bucciantini]

Differences between version 2

[Francesco Bucciantini]

Error in Interplay Access

[Francesco Bucciantini]

Thanks to further investigation, we found out that adding either -color_primaries 1 or -colorspace 1 makes the decode of our playout ports and Interplay fail and produces the issue reported above.

[Carl Eugen Hoyos]

To make this a valid ticket please provide a simplified (!, using testsrc2 as input) command line including complete, uncut console output.

[steipal]

ffmpeg.exe -f lavfi -i testsrc2=s=hd1080:d=5 -pix_fmt yuv422p -c:v mpeg2video -vf setfield=tff -flags +ildct+ilme -b:v 50M -minrate 50M -maxrate 50M -bufsize 36408333 -g 12 -bf 2 -profile:v 0 -level:v 2 -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -f mxf z:\xdcamhd.mxf

ffmpeg version N-99922-g8b819bcb9e Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 10.2.0 (Rev5, Built by MSYS2 project)
  configuration:  --disable-static --enable-shared --cc='ccache gcc' --cxx='ccache g++' --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libsrt --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-mbedtls --extra-cflags=-DLIBTWOLAME_STATIC -extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads --shlibdir=/local64/bin-video
  libavutil      56. 60.100 / 56. 60.100
  libavcodec     58.112.103 / 58.112.103
  libavformat    58. 64.100 / 58. 64.100
  libavdevice    58. 11.102 / 58. 11.102
  libavfilter     7. 89.100 /  7. 89.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Input #0, lavfi, from 'testsrc2=s=hd1080:d=5':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Output #0, mxf, to 'z:\xdcamhd.mxf':
  Metadata:
    encoder         : Lavf58.64.100
    Stream #0:0: Video: mpeg2video (4:2:2), yuv422p(tv, bt709, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 50000 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.112.103 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 50000000/50000000/50000000 buffer size: 36408333 vbv_delay: N/A
frame=  125 fps= 46 q=2.0 Lsize=   29522kB time=00:00:04.96 bitrate=48758.2kbits/s speed=1.81x
video:29406kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.391313%

[Carl Eugen Hoyos]

Looking at the commit message, it seems that compliance with some standard is claimed:
Is there any indication that you aren't simply seeing a limitation in AVID Interplay Access?

[Carl Eugen Hoyos]

Replying to FranceBB:

I believe this is related to 64ff61b3c52af335e811fe04b85108775e1f2784

Since I am not a native speaker:
Did you test that the commit is responsible for the change of behaviour?

[Francesco Bucciantini]

It's not just a limitation of interplay (AVID), it has also affected our EVS Playout Ports which are no longer able to decode the MXF files muxed by FFMpeg unless we remux them with the BBC BMX Transwrap. By the way, I work for Sky (Comcast) and on top of that, we've been sending football highlights to the league encoded with the very same parameters we've been using for years and this time they complained and we had to remux with BMX Transwrap. We've also been sending files overseas due to the sailing competition that was going on in New Zealand and the guys at the other hand said they had Telestream Vantage which failed to detect them as XDCAM-50 until we remuxed with BMX Transwrap. We're a very large broadcaster and we also have a 24/7 news channel, so remuxing everything all the time isn't a feasible option.
This is a pretty important topic for us, which is why I flagged the ticket as critical initially.

[Francesco Bucciantini]

As to the commit, we've been testing several different builds to try to find out what went wrong between August and now and we tracked that individual commit, in fact the August 2020 builds before that commit are fine and the subsequent ones are not. If we analyse that commit, what is doing is writing information about the color primaries, the transfer characteristics and the color space to the .mxf header, thus changing the header. By doing so, decoders find data that don't expect instead of the one that usually is supposed to be there and they fail. As a double check, if we encode the very same file with the very same parameters muxed in MXF with the latest FFMpeg master, but removing color_primaries, color_trc and color_space, the file is recognised again 'cause the header is exactly the same of how it used to be. I'm not saying that writing those things in the header is wrong and I don't know whether other muxers like BBC BMX Transwrap are doing it or not, but I definitely think that they're not written in the right place inside the header as they're causing many broadcast decoders to misbehave.

[Carl Eugen Hoyos]

Replying to FranceBB:

As to the commit, we've been testing several different builds to try to find out what went wrong between August and now and we tracked that individual commit, in fact the August 2020 builds before that commit are fine and the subsequent ones are not.

Just because of the language barrier:
Could you confirm that f95dac66 works fine and 64ff61b3 is broken for you with above command line?

[Marton Balint]

Can you try the attached patch?

[Tomas Härdin]

Patch looks OK, post it on the list. The way mxfenc.c is designed makes it too easy to forget to add ULs to the primer pack. If we rewrote it slightly to keep track of which ULs and local tags are used and don't allow random tags to be written then we could reduce the size of the primer pack as a nice little bonus.

I thought for a while that the primer doesn't need to contain any of the static local tags, but S377m proved me wrong: "The Primer shall contain all Local Tags used in Header Metadata Sets using 2-byte Local Tag encoding the Partition in which it occurs."

[steipal]

Tried the patch and it looks good. Although I have not been able to test on the systems initially reporting the problem but other tools like Baton and BMX does no longer complain about missing item in primer.

[Marton Balint]

Fixed in b410b14fba8d9485e288a060d6ad7346a83440d4. Reopen if Avid/EVS still does not like the file.