Opened 4 years ago
Closed 4 years ago
#9079 closed defect (fixed)
No head frame in new MXF Muxer
Reported by: | Francesco Bucciantini | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avformat |
Version: | git-master | Keywords: | MXF regression |
Cc: | steinar@apalnes.no, livio.aloja@skytv.it, Marton Balint | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
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:
Attachments (4)
Change History (19)
by , 4 years ago
Attachment: | Screenshot from 2021-01-25 09-19-29.png added |
---|
by , 4 years ago
Attachment: | Screenshot from 2021-01-25 09-19-35.png added |
---|
Differences between version 2
comment:1 by , 4 years ago
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.
comment:2 by , 4 years ago
Component: | ffmpeg → avformat |
---|---|
Keywords: | Muxer muxing muxers removed |
Priority: | critical → normal |
To make this a valid ticket please provide a simplified (!, using testsrc2 as input) command line including complete, uncut console output.
comment:3 by , 4 years ago
Description: | modified (diff) |
---|
comment:4 by , 4 years ago
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%
comment:5 by , 4 years ago
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?
comment:6 by , 4 years ago
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?
comment:7 by , 4 years ago
Description: | modified (diff) |
---|
comment:8 by , 4 years ago
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.
follow-up: 11 comment:9 by , 4 years ago
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.
comment:10 by , 4 years ago
Keywords: | regression added |
---|---|
Priority: | normal → important |
comment:11 by , 4 years ago
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?
by , 4 years ago
Attachment: | 0001-avformat-mxfenc-add-Coding-Equations-and-Color-Prima.patch added |
---|
comment:13 by , 4 years ago
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."
comment:14 by , 4 years ago
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.
comment:15 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in b410b14fba8d9485e288a060d6ad7346a83440d4. Reopen if Avid/EVS still does not like the file.
Differences between version 1