[FFmpeg-devel] [RFC/PATCH] TrueHD, DTS-HD, E-AC3 over HDMI (IEC 61937)
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
> 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?
More information about the ffmpeg-devel