[Matroska-devel] Support for DTS and DTS-HD formats in the mkv container

Moritz Bunkus moritz at bunkus.org
Fri Jun 10 09:56:42 CEST 2011


On Friday 10 June 2011 03:14:50 Phillip Maness wrote:

> I would like to add support for some additional DTS-HD audio
> configurations to the mkv format. Currently we have A_DTS defined,
> which seems to have been used somewhat successfully with DTS-HD
> formats that include the DTS core substream (e.g. DTS-HD Master
> Audio), in that DTS-HD decoders will process the complete substream,
> and most DTS decoders will process the core substream portion and
> discard the remainder, but I think there are some decoders that choke
> on the DTS-HD streams.

That is indeed the case. A_DTS is used for DTS-HD as well with the
assumption that DTS decoders must skip unknown content if they don't
support it -- meaning the HD extensions. This was done in order not to
require existing demuxers to be updated for DTS-HD as they mapped DTS
and DTS-HD to the same codecs/media types at that time.

> We have two additional configurations of DTS-HD that we would like to
> support, and these formats will definitely not play on older DTS
> decoders, so they need be signaled differently than the other DTS
> format. One of these formats is DTS Express, a.k.a. DTS LBR, the other
> is DTS-HD Lossless without a core substream. (we don't have a
> marketing name for this yet).

If they're that incompatible then they do indeed need their own codec ID
in Matroska, yes.

> We have also have registered a code for the original DTS format with
> MPEG4RA, which is 'dtsc'. I don't know if it would be problematic to
> have a redundant definition or to switch over from the old FOURCCMap
> (0x2001) and CodecID (A_DTS)? It might make life easier for our
> partners starting with MPEG-4 ISO media files and embedding them into
> the Matroska container. I realize the existing codes for DTS were
> defined prior to our registration in MPEG4RA.

I don't like renaming codec IDs for existing formats just to fit with a
new naming scheme. There are tons of hardware and software devices out
there that use the existing A_DTS and that would be incompatible for no
good reason. Therefore I'd veto renaming A_DTS to anything else (neither
A_DTSC nor anything else).

I'm undecided about splitting HD from A_DTS ( -> A_DTS). I'd argue that
there are so few problems (in fact I haven't heard of a single problem
on doom9 or in private mails) that I again think that breaking
compatibility with existing devices is not worth it.

For the other types: the current naming scheme for codec IDs is a bit
more verbose than what you're proposing. Also we don't aim to name codec
ID the same as they're named in registries for other formats. Therefore
what about...

> DTS Lossless

A_DTS/LOSSLESS or A_DTS/HD/LOSSLESS, depending on the marketing name

> DTS Express



Like I said above, but if we split it up then it would be probably be


Like I said above, I don't want this unless you can convince me of a
technical necessity for it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110610/b8cff2e8/attachment.pgp>

More information about the Matroska-devel mailing list