[FFmpeg-user] Ingest of SMPTE-377M

[Mark Nelson]

>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. Similarly
encoded files from the Dolby test kit in both eac3 and ac3 formats work
with AJA Control Room. I'm not sure what other tools Dolby targets for
files in this format. (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.)

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

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
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

So the dolby file and the ffmpeg created file have different endian layouts
of just that section of the SMPTE-377M the data. Both have a reserved data
type, but one is 0x03 and one is 0x10.

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



------------------------------------------------------------------------------

Mark Nelson – markn at ieee.org - http://marknelson.us