[FFmpeg-devel] [RFC/PATCH] TrueHD, DTS-HD, E-AC3 over HDMI (IEC 61937)

[Anssi Hannula]

Hi all!

Here is a patchset implementing TrueHD, DTS-HD, and E-AC3 support in our
IEC 61937 muxer, allowing HDMI passthrough of those formats. The E-AC3
and TrueHD ones are partially based on the earlier work of Carl Eugen
Hoyos and myself, while I only just got DTS-HD working.

I've tested these with an Intel HDA / NVIDIA NVS 3100M laptop, connected
via HDMI to Onkyo TX-SR607. The non-HBR-requiring streams were also
tested with HDMI on an integrated GF9400M.

Additional testing is always appreciated, though (TrueHD didn't work for
Carl Eugen Hoyos when this was last discussed). Testing instructions are
at the end of this message [1]. :)

However, while the patches seems to work, the situation (as usual) is
not that simple. With these formats, the compressed stream is not
transmitted over the IEC 60958 (S/PDIF) link at the sample rate of the
audio stream itself. Instead, higher sample rates are needed (4*original
for E-AC3, 768kHz for TrueHD, choosable for DTS-HD).

It may be reasonable to assume that the user knows what IEC 60958 sample
rate is needed for the current codec and audio sample rate, and that he
also knows not to try E-AC3 / DTS-HD / TrueHD over a legacy non-HDMI
link (not 100% sure if this is impossible, though; at least with my
hardware, though).

With that assumption, I think the E-AC3 and TrueHD patches are in fact
good as is.

However, this assumption gets complicated with DTS-HD:

- The user has no idea if the stream is DTS-HD or standard DTS.
  And the user needs the information to determine the sample rate
  of the outputted IEC 61937 stream.

- The user may want to transmit the stream over a non-HDMI link
  ( <= 48 kHz), which
  normally requires sending only the core portion of a DTS-HD stream.
  (this could be easily achieved by having two logical muxers, one for
   legacy spdif and one for hdmi; however, it wouldn't solve anything
   else)

- The user may want to transmit the stream over a non-HBR ( <= 192 kHz)
  HDMI link.
  HDMI requires a special "HBR" mode for bitrates over 6.1 Mbps, which
  is not supported by all audio cards/drivers. Most DTS-HD material
  (including all but one of our samples) seems to not be peaking over
  6.1 Mbps, making a transmission over a 192kHz non-HBR HDMI link
  a desirable option if HBR is unsupported (the DTS-HD patch contains
  if(0)'d code doing just that).

- Some DTS-HD formats (i.e. those with higher amount of audio blocks
  per frame) may require a lower transmission sample rate, and the user
  should get this information somewhere. However, as I've not found these
  kind of streams, I guess we could ignore this one if the other points
  above are solved.

We do not currently have a separate codec id for DTS-HD. Instead it is
simply handled as DTS, and the decoder ignores the extra data. I'm not
sure if we should add a new codec id, however, I guess doing so may not
necessarily solve everything currently, as there can be files that have
a DTS-HD track marked as plain DTS (in fact ffmpeg produces such files
with -vcodec copy).

WDYT on how to handle all this?

(comments on patches welcome as well)


[1] Testing instructions:

For testing the HBR modes (DTS-HD and TrueHD at maximum rates), one needs
either a 2.6.36 or a newer kernel, or these
patches:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=32c168c892e2c6936c714d1653ba5e19e07d5c26
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ea87d1c493aba9cf3f645eae0d6d9c0fd44d3189

ATI cards are not plugged into the generic HDMI framework (that'd need
testing and I don't have such cards) and thus HBR does not yet work with
them.

The following patch for /usr/share/alsa/cards/HDA-Intel.conf eases up
testing a little (enables the 3 non-0 DEV indexes for hdmi):
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=e6d5dcf1f625984605d362338d71162de45a6c60

The command to run:
aplay -D hdmi:CARD=NVidia,DEV=3,AES=0x06 -c8 -fs16_le -r192000 muxed_file.spdif
DEV=3 should be DEV=0..3, depending on card/port.
CARD=NVidia may need to be replaced with CARD=Intel (or something else).
-c8 -r192000 means a 768 kHz IEC 60958 link (TrueHD, "normal" DTS-HD).
-c2 -r192000 means a 192 kHz IEC 60958 link (48kHz E-AC3).

If you get no audio, confirm with "alsamixer -cX" (where X is a card
number, starting from 0) that the HDMI outputs are not muted.

The HDMI output must be active (preferably 720p or higher mode, in case
the video driver does not compensate for the lower audio bandwidth of
the smaller modes).
On NVIDIA hardware, you need the NVIDIA proprietary driver (195.x or
newer, preferably), or nouveau with extra patches adding HDMI audio.
When using the proprietary driver, X needs to be running and virtual
console of X must be active.

Hopefully I didn't miss anything :)

-- 
Anssi Hannula