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

Anssi Hannula anssi.hannula
Mon Dec 20 03:56:21 CET 2010

On 19.11.2010 18:30, Anssi Hannula wrote:
> Ok, here's a suggestion. Please comment :)

No comments from ffmpeg devs, I see.
But that is not the reason I haven't yet posted an updated patch, I've
just been busy with other work. I'll do that as soon as I can.

One updated thought below.

> On 16.11.2010 03:44, Anssi Hannula wrote:
>> - 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.
> Use bit_rate in AVFormatContext for this, defining it as follows (or
> some better description if we come up with one):
> - muxing: Set by libavformat at least in those CBR cases where the user
>   normally needs this information and it isn't possible to infer it from
>   the basic stream properties (e.g. when using DTS in IEC 61937 muxer).
> Thus the user can calculate the needed transmission sample rate from the
> bit_rate field.
>> - 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)
> Use mux_rate in AVFormatContext for this, defining it as follows:
>      * Muxing: maximum stream bitrate in bit/s for muxers that support
>      * such a setting. Set by user.
> Currently it is used in mpeg/mpegts muxers. I'm not really sure if the
> use case is similar enough to warrant the use of the same field, but I
> believe it might be.
> For legacy S/PDIF one would set this to 48000 * 32.

I guess we should make 48000 * 32 the default for the DTS case in S/PDIF
muxer, ensuring backward compatibility with non-HD-handling
applications. If the caller can handle DTS-HD, they can set it to 768000
* 32 or 192000 * 32 themself.

>> - 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).
> Set above mux_rate to 192000 * 32.
>> - 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.
> See above bit_rate.
>> 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).
> No separate codec id is needed for now, then, I guess?
>> WDYT on how to handle all this?

Anssi Hannula

More information about the ffmpeg-devel mailing list