[FFmpeg-user] Ingest of SMPTE-377M

[Mark Nelson]

I owe you a ton of answers on this, and they will come, but I will hit the
easy ones right now.

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

This is a little tricky to answer. The output of AJA ControlRoom is SDI
format. To "listen" to that, I am connecting the output of AJA Control Room
(SDI format) to the SDI input on an AJA Kona4 card, then encoding it with a
Cisco CAL live encoder. The output from that contains correct AC3 or EAC3
audio streams, so yeah, they can be listened to.

In that SDI format, the SMPTE 377M packetized AC3 or EAC3 is encoded in the
horizontal blanking area in a standard format.

I'm pretty sure that the SDI output from AJA Control Room is correct. I can
compare that to SDI output from a Sencore encoder, and the encapsulation of
the AC3/EAC3 is identical.

There is still the possibility that AJA Control Room is broken, and the
file format that I feed it has to be wrong in order to get good output. I
am honestly not sure how to pursue this question. The SMPTE-377M encoded
data packed in a WAV file or embedded as bogus PCM in a MOV file (which I
also use in Control Room) is pretty non-standard and I don't know of
anything that expects to play it. I still need to understand how you are
able to play SPDIF encoded audio using the ALSA drivers. What exactly is
your amplifier?


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?

The answer to this is yes in two ways. A typical 377 WAV file provided by
Dolby in their testing tools contains the following SMPTE 377 header bytes:

72 F8 1F 4E 01 00 00 14 77 0B

That matches the spec in that Pa = 0xF872 (16 bit mode)
Pb = 0x4E1F (16 bit mode)
Pc (burst_info) = 0x0001 (data type 1)
Pd (length_code) = 0x1400 (0x280 bytes)

SMPTE S340 says that an AC3 data burst should have data type 1, and that an
EAC3 data burst should have a data type of 16. That spec applies to AES3
data streams. This matches the data types described in SMPTE 388. And if
that doesn't match up with the data types in IEC 61937-2, it means AES3 and
SPDIF are not quite compatible.

When I say "in two ways", the second way is that the Dolby SDK provides a
tool called SMPTE that reads a raw AC3 or EAC3 file and packs it into a WAV
file with appropriate SMPTE 377M headers. It creates the same header.

I'll continue working on better answers to what is still pretty confusing
to me. Thanks for the help so far!

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

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