On Tue, Nov 30, 2021 at 10:36 AM Marton Balint <c...@passwd.hu> wrote: > > > > On Mon, 29 Nov 2021, Pierre-Anthony Lemieux wrote: > > > On Mon, Nov 29, 2021 at 11:20 AM Marton Balint <c...@passwd.hu> wrote: > >> > >> > >> > >> On Sun, 28 Nov 2021, Pierre-Anthony Lemieux wrote: > >> > >>> On Sun, Nov 28, 2021 at 5:00 PM Marton Balint <c...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
