View Bug Details

IDProjectCategoryView StatusLast Update
0002631DCP-o-maticBugspublic2024-01-13 10:02
Reporteroverlookmotel Assigned Tocarl  
Status closedResolutionfixed 
PlatformMacOSOS XOS Version10.14
Product Version2.16.64 
Target Version2.16.67 
Summary0002631: Audio MXF in SMPTE DCP made with 2 audio channels cannot be read by ffmpeg/ffprobe

We've received 3 DCPs recently which were made with DCP-o-matic 2.16.x (2.16.38 and 2.16.65 specifically) where we've found FFMPEG/FFPROBE are unable to read the audio MXF file.

In all 3 cases, the DCPs have 2 audio channels. They're also all SMPTE, though I'm not sure if that's relevant.

When running ffprobe on the audio MXF file in the DCP, it fails immediately with an error:

[mxf @ 0x7fb362904240] "OPAtom" with 2 ECs - assuming OP1a
[mxf @ 0x7fb362904240] AudioChannelLabelSubDescriptor has invalid MCA channel ID 3
/path/to/pcm.mxf: Invalid data found when processing input

ffmpeg also returns the same error.

I don't know for sure if this is a bug in DCP-o-matic, or in FFMPEG.

However, we've only seen this error with 2-channel DCPs made with DCP-o-matic. FFMPEG can successfully read 2-channel DCPs made with other software, and 6/8/16-channel DOM DCPs.

We are using FFMPEG 6.0 static builds downloaded from:
Mac OS (Intel):
Ubuntu (AMD64):

In case it's relevant, have reproduced this on:

  • Mac OS Ventura 13.4.1
  • Ubuntu 20.04

I've managed to produce a DCP which FFMPEG cannot read the audio MXF from with DCP-o-matic 2.16.65 (SMPTE DCP with 2-channel audio). Repro case here:

Repro includes:

  • sources/ - Short ProResHQ file used to make DCP from
  • DOM project - DCP-o-matic project used to make DCP
  • DOM project/StereoTest_TST-1-25_F_XX-XX_MOS_2K_20231016_SMPTE_OV - the resulting DCP
  • ffprobe output.txt - ffprobe's output for the audio MXF file in this DCP

Googling the "AudioChannelLabelSubDescriptor" error doesn't bring up much, but this post on ffmpeg development list may shed some light:

This appears to be the code in FFMPEG which produces the error:

TagsNo tags attached.
Estimated weeks required
Estimated work requiredUndecided



2023-10-16 17:48

developer   ~0006023

Don't know if this is related, but also noted that the CPL of the DCP seems to erroneously list 6 audio channels in the mca:MCASubDescriptors section (the DCP only has 2 channels):

<mca:MCASubDescriptors xmlns:mca="" xmlns:r0="" xmlns:r1="">
    <r1:MCATagName>Left Surround</r1:MCATagName>
    <r1:MCATagName>Right Surround</r1:MCATagName>


2023-10-16 17:57

developer   ~0006024

Update: I made a 2nd DCP identical to the repro case above but Interop instead of SMPTE. ffprobe can read the audio MXF in the Interop version without error. So it seems to be a SMPTE-only thing.


2023-10-16 18:06

administrator   ~0006025

Thanks for the note. I've never found any definitive documentation on this. I'll try fixing DoM not to write more subdescriptors than there are channels.


2023-10-16 18:31

developer   ~0006026

Thanks for swift reply Carl. Would that also possibly fix the problem of FFMPEG not being able to read the audio MXF? Or is that an unrelated problem? I have no idea what an "MCA channel ID" is!


2023-10-16 22:38

administrator   ~0006027

It should fix the ffmpeg error - it's not unreasonably saying that we shouldn't have a descriptor for a channel that isn't there. MCA channel IDs are (so far as I can tell) a way to describe the function of a channel of audio, and probably how all this should have been done in the first place (i.e. maybe you have some channels, and then you have a list of descriptors which say what those channels are, then we wouldn't have all this messing about with empty channels and all that).

Sadly they are quite complicated and poorly documented so it's hard to know how to get them right. And I have a sneaking suspicion that most projection systems ignore them anyway.


2023-10-17 14:44

developer   ~0006028

Thanks for the explanation.

By the way, we did have a cinema complaining a couple of months ago that a DCP we'd made with DOM 2.14.x (so before DOM added audio channel descriptors CPLs) didn't have a 5.1 mix, whereas the CPL title said it did. They were wrong - there was signal in all 6 channels - but they were completely adamant that there wasn't. It was a bit of a head-scratcher.

Turned out they weren't making this judgement based on actually playing the DCP in a screen. They'd concluded it wasn't 5.1 because their TMS software usually listed DCPs with a "5.1" icon where a 5.1 mix was present, and with this DCP it didn't say that.

I assume the only place the TMS could get the info on audio layouts is from the audio channel descriptor info in the CPL. So that'd suggest this info is getting at least some use in the field.


2023-10-17 19:35

administrator   ~0006029



2023-10-17 19:39

administrator   ~0006030


Bug History

Date Modified Username Field Change
2023-10-16 17:44 overlookmotel New Bug
2023-10-16 17:45 carl Assigned To => carl
2023-10-16 17:45 carl Status new => acknowledged
2023-10-16 17:45 carl Target Version => 2.16.67
2023-10-16 17:45 carl Estimated work required => Undecided
2023-10-16 17:48 overlookmotel Note Added: 0006023
2023-10-16 17:57 overlookmotel Note Added: 0006024
2023-10-16 17:59 carl Status acknowledged => confirmed
2023-10-16 18:06 carl Note Added: 0006025
2023-10-16 18:31 overlookmotel Note Added: 0006026
2023-10-16 19:19 carl Branch => 2631-mca-again
2023-10-16 22:38 carl Note Added: 0006027
2023-10-16 22:38 carl Status confirmed => tests running
2023-10-17 14:44 overlookmotel Note Added: 0006028
2023-10-17 19:35 carl Note Added: 0006029
2023-10-17 19:39 carl Status tests running => resolved
2023-10-17 19:39 carl Resolution open => fixed
2023-10-17 19:39 carl Note Added: 0006030
2024-01-13 10:02 carl Status resolved => closed