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

[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.).

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

In ffmpeg, we already have spdif probing in wav, so there is nothing really new technically speaking.
Quoting the previous dolby paper, about spdif (IEC61937):
The IEC61937 format is similar to the SMPTE 337M format and can be considered a subset of SMPTE 337M
for some data types (see SMPTE 337M Section 7), however there are significant differences in the two standards.
In particular IEC61937 does not support the Dolby E data type.

Nicolas