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

[Jean-Yves Avenard]

Hi

On 20 November 2010 03:30, Anssi Hannula <anssi.hannula at iki.fi> wrote:
> Ok, here's a suggestion. Please comment :)
>
> 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.
>
>> - 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?

Just me raising my hands on saying that Anssi latest patches have been
tested in depth and I implemented support for DTS-HD, TrueHD and E-AC3
passthrough in MythTV.
I have used the spdif muxer quite intensively, and mux_rate, bit_rate
behaviour were just as expected.

There are things I think that could be done to simplify a tad from a
programmer perspective, in particular making it less important for the
developer to know the difference between the various dts type,
provided that ffmpeg doesn't give much clue as if a stream is DTS or
DTS-HD.

So thumbs up for Anssi work, absolutely awesome. The earlier committed
the better

JY