Re: [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution

From: "Tomas Härdin" <git@haerdin.se>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution
Date: Wed, 22 Feb 2023 11:07:11 +0100
Message-ID: <18c43fac75f979854574955788202ca0e710d8df.camel@haerdin.se> (raw)
In-Reply-To: <MR1P264MB24835723335B9DEC35EC64B89BA59@MR1P264MB2483.FRAP264.PROD.OUTLOOK.COM>

tis 2023-02-21 klockan 10:43 +0000 skrev Nicolas Gaullier:
> > I haven't worked enough with S377m to really know, but I do know
> > it's a mess. Is there a way to differentiate "regular" packed 20-
> > bit audio from S377m in wav?
> > 
> > /Tomas
> 
> There is a relevant overview of S337m in this dolby paper:
> https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-tech-doc_1.2.pdf
> Page 25, one can read:
> SMPTE 337M is the primary method by which Dolby E is able to work in
> existing
> facilities and with existing devices. The standard is written such
> that the same AES3
> interface can be shared with the normal PCM audio usage either by
> treating the AES3
> channels independently or by alternating between data and linear PCM
> usage.
> Devices that are specifically designed for SMPTE 337M/Dolby E
> compatibility
> should be able to transition easily between both usages.
> 
> The whole design is to not signal, not differentiate "normal PCM
> audio usage" from s337m.
> And indeed, manufacturers have implemented probing in all their
> hardware/software (be it linear/SDI input, or mxf/wav files input
> etc.).

Right, it's a deliberate mess.

> Note: ARD/ZDF mxf file format being "the" world exception here, as
> dolby_e/non-pcm must be signaled, made explicit:
>  
> https://www.ard.de/ard/die-ard/ARD-ZDF-HDF02a-AVC-I-100-1080i-25-8-Audio-Tracks-100.pdf

This is the correct approach and precisely what I would expect in the
MXF space. You make it possible to probe in case you have stupid
hardware, but you also explicitly signal it in the container for
systems that are capable of carrying that over.

I will note that Dolby-E support in mxfdec seems to have been in
Baptiste's mind when he first committed the code:

>   //{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x02,0x03,0x02
> ,0x1C,0x00 }, 15,    AV_CODEC_ID_DOLBY_E }, /* Dolby-E */

Since ccba07d12c. It remains commented out to this day.

Anyway I don't think this has to hold up this patchset. If it works it
works. We can always improve this later if necessary.

/Tomas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".