[FFmpeg-user] Ingest of SMPTE-377M

[Mark Nelson]

I have WAV files from the Dolby test kit that contain AC3 or EAC3 data that
has been packetized into SMPTE 337M format. These are suitable for a
program like AJA Control Room, which can get the data into SDI cards for
testing of AC3 ingest.

Most software looks at these WAV files and takes them at face value -
viewing them as 1536 kpbs stereo PCM data. As an example, if you try to
play one with VLC you just get static as the data is played out as PCM.

AJA Control Room is just as ignorant, and just plays out the bytes
sequentially, not worrying about the fact that the PCM actually contains
packetized AC3. The result is that the SDI stream contains AC3 in the audio
channel as desired.

My goal is to build an MOV container that has the PCM track directly copied
from WAV file, the ffmpeg ingest code is a little too smart - it looks into
the input stream and figures out that the WAV file is not really a PCM
file, but rather AC3. It then unmuxes it and converts it to a valid AC3
stream:

ffmpeg.exe -y -i ddp.337.wav -i ddp.264 -vcodec prores -acodec pcm_s16le
 ddp.337.mov
...
  Stream #0:0 -> #0:1 (ac3 (native) -> pcm_s16le (native))

Oddly, it does not do this when the stream is eac3, but that is a different
issue.

As a temporary workaround, I can go in and hack the WAV file, mangling the
first few headers and then encoding. This works properly, and I can easily
then revert the process.

But it seems I should be able to do this from the command line without
hackery. I thought I could simply force it with the codec option, but when
I do, some other sort of misinterpretation results, and the output is
invalid:

ffmpeg.exe -y -i ddp.337.wav -i ddp.264 -vcodec prores -acodec pcm_s16le
 ddp.337.mov
...
  Stream #0:0 -> #0:1 (pcm_s16le (native) -> pcm_s16le (native))
[wav @ 000000000507aac0] Codec change in IEC 61937 is not implemented.
Update your FFmpeg version to the newest one from Git. If the
 problem still occurs, it means that your file has a feature which has not
been implemented.
dd.337.wav: Not yet implemented in FFmpeg, patches welcome

This error is puzzling, because if I run with the hacked WAV file which
properly masquerades as PCM, I still see this:

  Stream #0:0 -> #0:1 (pcm_s16le (native) -> pcm_s16le (native))

but no error message, the the output of ffmpeg is what I want it to be.

So the question is, how can I get the ffmpeg ingest to not peek into the
WAV file for deeper info - simply accept it as is, assuming it is stereo 16
bit PCM at 1536 kbps?

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

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