[FFmpeg-trac] #10392(avcodec:new): mxf with DolbyE and channel_count != 02 is wrongly read by FFMpeg and cannot be remuxed
FFmpeg
trac at avcodec.org
Tue May 30 17:05:28 EEST 2023
#10392: mxf with DolbyE and channel_count != 02 is wrongly read by FFMpeg and
cannot be remuxed
-------------------------------------+-------------------------------------
Reporter: Francesco | Type: defect
Bucciantini |
Status: new | Priority: normal
Component: avcodec | Version: git-
| master
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Summary of the bug:
mxf files which carry DolbyE 5.1 + 2.0 audio and whose channel_count value
in the mxf header is 08 instead of 02 are wrongly read by FFMpeg and
therefore are remuxed incorrectly.
Expected behavior:
files are read and remuxed correctly
Actual behavior:
edit unit sync lost on stream 1, jumping from 0 to 1
How to reproduce:
{{{
% ffmpeg -i "video.mxf" -map 0:0 -map 0:1 -c:v copy -c:a copy -f mxf -y
"output.mxf"
ffmpeg version n6.1-dev
built on 30-05-2023
}}}
Explanation:
DolbyE is generally carried as fake stereo pairs in an mxf container so
that it can be passed through via SDI.
As such, the channel_count value inside the mxf header is supposed to be
02 to indicate the fake stereo pairs it's supposed to be spoofed as. In
other words:
[[Image(https://i.imgur.com/FuVL7H3.png)]]
however some muxers like ommcp (the Omneon muxer, from version 7.x 'till
version 9.5) write the actual number of channels of the DolbyE stream
instead, so for a DolbyE 5.1 + 2.0 (where 5.1 is the surround and 2.0 is
the stereo downmix), they wrote 08 (6 channels + 2 channels = 8 channels).
In other words:
[[Image(https://i.imgur.com/NDmxPWd.png)]]
As such, instead of reading it as fake stereo pairs and remux it
correctly:
[[Image(https://i.imgur.com/VWE3d08.png)]]
FFMpeg thinks it's an 8 channel stream and fails to remux it, thus
screwing up the whole audio stream:
[[Image(https://i.imgur.com/fnkyraE.png)]]
[[Image(https://i.imgur.com/GryUzHB.png)]]
so much so that the final remuxed file says PCM and it's undecodable:
General
Complete name : A:\MEDIA\temp\remux.mxf
Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 1.23 MiB
Duration : 20 ms
Overall bit rate : 517 Mb/s
Frame rate : 50.000 FPS
Encoded date : 0-00-00 00:00:00.000
Writing application : FFmpeg OP1a Muxer 59.35.100.0.0
Writing library : Lavf (mingw32) 59.35.100.0.0
Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2 at L5.2
Format settings, CABAC : No
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201323001
Duration : 20 ms
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 50.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant
Format_Profile_Original : High 4:2:2 Intra at L5.2
Audio
ID : 3
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Codec ID : 0D01030102060300
Duration : 20 ms
Bit rate mode : Constant
Bit rate : 9 216 kb/s
Channel(s) : 8 channels
Sampling rate : 48.0 kHz
Frame rate : 50.000 FPS (960 SPF)
Bit depth : 24 bits
Stream size : 22.5 KiB (2%)
Locked : Yes
Other #1
ID : 1-Material
Type : Time code
Format : MXF TC
Frame rate : 50.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:00:00:00
Time code settings : Material Package
Time code, stripped : Yes
Other #2
ID : 1-Source
Type : Time code
Format : MXF TC
Frame rate : 50.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:00:00:00
Time code settings : Source Package
Time code, stripped : Yes
instead of saying DolbyE 5.1 + 2.0 as it should:
General
Complete name : A:\MEDIA\temp\original.mxf
Format : MXF
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 1.54 MiB
Duration : 20 ms
Overall bit rate : 645 Mb/s
Frame rate : 50.000 FPS
Encoded date : 2023-05-30 13:58:23.372
Writing application : Omneon Inc. Omneon Media Subsystem 8.3.0.0.1
Writing library : Omneon Media Api (windows)
Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2 at L5.2
Format settings, CABAC : No
Format settings, wrapping mode : Frame
Codec ID : 0D01030102106001-0401020201323001
Duration : 20 ms
Maximum bit rate : 500 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 50.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant
Delay_SystemScheme1 : 0
Format_Profile_Original : High 4:2:2 Intra at L5.2
Audio
ID : 3
Format : Dolby E
Format settings, wrapping mode : Frame (BWF)
Codec ID : 0D01030102060100-0402020203021C00
Duration : 20 ms
Bit rate : 1 152 kb/s
Channel(s) : 8 channels
Sampling rate : 48.0 kHz
Frame rate : 50.000 FPS (960 SPF)
Bit depth : 24 bits
Stream size : 2.81 KiB (0%)
Delay_SystemScheme1 : 0
Locked : Yes
Other #1
ID : 1-Material
Type : Time code
Format : MXF TC
Frame rate : 50.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:00:00:00
Time code settings : Material Package
Time code, stripped : Yes
Other #2
ID : 1-Source
Type : Time code
Format : MXF TC
Frame rate : 50.000 FPS
Time code of first frame : 00:00:00:00
Time code of last frame : 00:00:00:00
Time code settings : Source Package
Time code, stripped : Yes
Other #3
Type : Time code
Format : SMPTE TC
Muxing mode : System scheme 1
Time code of first frame : 00:00:00:00
Actual fix: the only current fix is to use a newer version of ommcp like
9.8 to remux the file and force the channel_count value to 02 (fake stereo
pairs) and then use FFMpeg to open the file OR use gsar to change the hex
value relative to the channel count inside the mxf container and THEN use
FFMpeg. Both options are time consuming and really should be avoided.
This should be handled internally by FFMpeg itself instead of choking upon
decoding.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10392>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list