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 – ma...@ieee.org - http://marknelson.us _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user