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

[Anssi Hannula]

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?

> WDYT on how to handle all this?

-- 
Anssi Hannula