[FFmpeg-devel] [PATCH 5/5] avformat/mxfdec: rework MCA channel layout parsing

[Pierre-Anthony Lemieux]

On Tue, Nov 30, 2021 at 10:36 AM Marton Balint <cus at passwd.hu> wrote:
>
>
>
> On Mon, 29 Nov 2021, Pierre-Anthony Lemieux wrote:
>
> > On Mon, Nov 29, 2021 at 11:20 AM Marton Balint <cus at passwd.hu> wrote:
> >>
> >>
> >>
> >> On Sun, 28 Nov 2021, Pierre-Anthony Lemieux wrote:
> >>
> >>> On Sun, Nov 28, 2021 at 5:00 PM Marton Balint <cus at passwd.hu> wrote:
> >>>>
> >>>> Setting the channel layout was based on SoundfieldGroupLabelSubDescriptor, but
> >>>> this was wrong, because soundfield groups are not necessarily used and a file
> >>>> can also contain e.g. a single channel of a multichannel audio.
> >>>
> >>> For reference, below are MCA scenarios I am aware of:
> >>>
> >>> - single MXF file containing a single soundfield and all its
> >>> constituent channels (specified in the Interoperable Master Format -
> >>> IMF)
> >>> - single MXF file containing a single soundfield and all its
> >>> constituent channels, plus additional auxiliary channels, e.g.
> >>> visually-impaired narration (specified in Digital cinema)
> >>> - N MXF files, each containing one channel of a single soundfield
> >>> (specified in IMF, but I have personally never seen it in practice)
> >>>
> >>>>
> >>>> The new approach is to parse every AudioChannelLabelSubDescriptor and create a
> >>>> channel layout based on those. We should also make sure that we only provide a
> >>>> channel layout if every channel designation is recognized and is supported. If
> >>>> a designation is not supported, or if a channel designation is used more than
> >>>> once (e.g. multiple languages) we fall back to the unknown channel layout.
> >>>>
> >>>> MCA channel ID was also ignored previously, that should have been used to
> >>>> determine which AudioChannelLabelSubDescriptor references which audio channel.
> >>>> This is also fixed now.
> >>>>
> >>>> The new parsing code also detects ambigous language or service types, and only
> >>>> set these metadata if all channels have the same value.
> >>>>
> >>>>
> >>>> Soundfield groups are now only used for determinig the language of the tracks,
> >>>> if it is not provided in the AudioChannelLabelSubDescriptor. Track sub
> >>>> descriptors not necessarily contain the references to their soundfield groups,
> >>>
> >>> ST 377-4 states that "If the Audio Channel is part of a Soundfield
> >>> Group then the SoundfieldGroupLinkID shall be present in the
> >>> AudioChannelLabelSubDescriptor Set. The SoundfieldGroupLinkID shall be
> >>> the MCA Link ID of the SoundfieldGroupLabelSubDescriptor to which this
> >>> Audio Channel belongs."
> >>>
> >>> What do you mean by "Track sub descriptors not necessarily contain the
> >>> references to their soundfield groups,"?
> >>
> >> I mean that the SubDescriptors item of the WavePCMDescriptor not
> >> necessarily contains the references to the soundfield group. E.g. if a
> >> soundfield group consist of two channels, one channel is in audio track 1,
> >> another channel is in audio track 2. As far as I understand only one
> >> WavePCMDescriptor can reference the SoundfieldGroup in its SubDescriptors,
> >> because it is a strong reference.
> >
> > As I recall, the intent is for all MCA subdescriptors relevant to a
> > track to be contained within the File Descriptor for that track, as
> > suggested by Figures 1 and A.2 of the MCA spec (see attached).
> >
> > For example, if the L channel of a stereo soundfield is in track 1 and
> > the R channel of a stereo soundfield is in track 2, then the File
> > Descriptor for track 1 would contain one L MCA Audio Channel
> > SubDescriptor and one Stereo MCA Soundfield SubDescriptor, while the
> > the File Descriptor for track 2 would contain one R MCA Audio Channel
> > SubDescriptor and one Stereo MCA Soundfield SubDescriptor. The two MCA
> > Soundfield SubDescriptors would have identical MCA Link ID.
>
> I guess duplicating the SoundfieldGroupLabelSubDescriptors as many
> times as it is referenced as a strong reference can work, but having more
> than one SoundfieldGroupLabelSubDescriptor with the same MCA Link ID in
> the same file seems a bit ugly...
>
> >
> > The MCA spec states "all MCALabelSubDescriptor instances associated
> > with the audio described by a File Package shall be contained within
> > the same File Package". This could be construed as allowing a MCA
> > Soundfield SubDescriptor in one child descriptor of a
> > MultipleDescriptor to be referenced by a MCA Audio Channel
> > SubDescriptor from another child descriptor of the same
> > MultipleDescriptor. Happy to check with other implementers and report.
>
> The MCA tests of BMXlib applications (raw2bmx, bmxtranswrap) can generate
> such files. Actually raw2bmx can generate both types, either with repeated
> soundfield groups, or non-repeated. See the attached samples and the track
> maps which were provided to raw2bmx.
>
> > In any case, this is somewhat academic at this point unless anyone is
> > aware of MCA-enabled MXF files that are not single track and/or that
> > have soundfields split across File Packages. [ed.: I am not aware of
> > such files.]
> >
> > It might therefore make sense to focus, for now, on single track MXF
> > files that contain complete soundfields, which your patch addresses if
> > I am not mistaken.
>
> Yeah, those should work no problem, as long as all the channels in a
> track have different designation, but this is an ffmpeg limitation, and
> not an issue with parsing.

LGTM. The following outputs the channels in L,R,C,LFE,LS,RS order,
despite the channels being ordered as L,C,R,LS,RS,LFE in the MXF file:

ffmpeg -i http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_c_r_ls_rs_lfe.mxf
build/out.wav

The MXF file was created using ASDCPLib:

as-02-wrap wav/Left.wav wav/Center.wav wav/Right.wav wav/LS.wav
wav/RS.wav wav/LFE.wav  -g en -m "51(L,C,R,Ls,Rs,LFE)"
callout_51_l_c_r_ls_rs_lfe.mxf

>
> Regards,
> Marton_______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".