[FFmpeg-user] Ingest of SMPTE-377M

[Carl Eugen Hoyos]

Mark Nelson <markn <at> ieee.org> writes:

> >But my question was if there is a receiver
> >that plays the eac3 spdif file you uploaded:
> 
> So the specific file that I posted here:
> https://www.dropbox.com/s/tec7al5bcmihwey/sample.eac3.337.wav?dl=0
> 
> Works fine in my configuration, which is: File 
> playing in AJA Control Room, which generates an SDI 
> signal for ingest on a video encoder.

Does "playing" here mean you can hear the sound?

> Similarly encoded files from the Dolby test kit in 
> both eac3 and ac3 formats work with AJA Control Room. 

Does "similarly" mean thy have the same "wrong" (see 
below) data-type as the file you uploaded?

> I'm not sure what other tools Dolby targets for
> files in this format.

I use my amplifier to test and I consider that a very 
useful test.

> (Similar files with AC3 content work fine also, and
> I'm not entirely clear on what you mean when you 
> say this process can only work with eac3. But that's 
> a different issue.)

It works for ac3, eac3, truehd and dts with my receiver.
FFmpeg also supports MP3 and AAC but iirc, it is 
difficult to buy a receiver that supports them so I 
suspect this code is untested.

> When I compare the Dolby WAV file to the 
> ffmpeg-created WAV file, by extracting the raw spdif:
> 
> ffmpeg -i sample.eac3.337.wav -f s16le 
> -acodec pcm_s16le  sample.eac3.spdif
> 
> The payloads look fine, but I see a difference is in 
> the burst_info and length_code field of the SMPTE 
> 377M headers.
> 
> header created by ffmpeg: 72 f8 1f 4e 15 00 00 03
> header stripped from dolby WAV file: 72 f8 1f 4e 10 00 00 18

I am looking at IEC 61937-2 and it specifies the 
following data-types in table 2:
16: ATRAC-X
21: Enhanced AC-3

So FFmpeg seems more correct to me;-)

Btw, my receiver interprets "16" as TrueHD (which is 22).

> The interesting thing here is that there is a 
> discrepancy in the location of the burst_info and 
> length_code data in these two files. One of them is
> broken (I have a feeling I know which one you suspect.)
> 
> The EAC3 frame in the ffmpeg created spdif file has a 
> length of 672 bytes, or 5376 bits, giving a length code 
> of 0x1500

Above table specifies "6 144" and this value has to be 
multiplied by 4 (afair) giving a frame size of 24576 
which is what FFmpeg produces here for eac3 in spdif.

This is the only frame size that works with my receiver 
for eac3.

> The EAC3 frame in the spdif file extracted from the 
> dolby WAV file has a length of of 768 bytes, or 
> 6144 bytes, giving a length code of 0x1800

This is exactly one quarter of the required size 
and this simply doesn't work with the receivers I 
tested.

> So the dolby file and the ffmpeg created file have 
> different endian layouts of just that section of 
> the SMPTE-377M the data.

I did not see a difference in endianess:
If I allow autodetection of "16" as eac3, your 
file can be decoded with FFmpeg.

> Both have a reserved data type, but one is 0x03 
> and one is 0x10.

Maybe a newer version of IEC 61937 exists?

> Maybe the problem here is that we are comparing 
> apples and oranges? S/PDIF vs. AES3?

I don't know anything about AES3 but if it uses 
the same burst-preamble as spdif but different 
data-types then it is not the most useful format I 
ever saw;-)

Did you test the file I produced with the commands 
I posted on your equipment?

I still owe you a patch to disable spdif 
auto-detection (which is trivial) but I would also 
like to understand why your file is correct...

Carl Eugen