[FFmpeg-devel] [RFC/PATCH] TrueHD, DTS-HD, E-AC3 over HDMI (IEC 61937)
Tue Nov 16 02:44:44 CET 2010
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 . :)
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
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
- The user may want to transmit the stream over a non-HBR ( <= 192 kHz)
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)
 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
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
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):
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 :)
More information about the ffmpeg-devel