[Matroska-devel] problem with AAC-in-Matroska

[Moritz Bunkus]

Hey,

The fact that we do not store the AAC ESDS decoder config bytes in the
CodecPrivate is coming back to haunt us, it seems.

So far we have two "types":

1. Normal AAC with two bytes of AAC ESDS decoder config data (=
   "decoder_config" from now on). It contains the object type index, the
   sampling frequency index and the number of channels.

2. The SBR extension to AAC (also called HE-AAC). It has five bytes of
   decoder_config. The first two are identical to the simple one. The
   next three contain a constant ("sync extension" = 0x02b7) and the
   output sampling frequency index.

So far we could map that 1:1 onto the Matroska structures. But now a
user has uploaded a file with what I believe is called "parametric
stereo" (which is another extension on top of SBR (?)). This one
contains _four_ bytes of decoder_config. Stepping through libfaad's
initialization routine revealed some additional info being stored there
which we definitely cannot map onto Matroska elements.

So what do we do about this? I see the following options:

1. Create the appropriate elements in Matroska, invent one/some more
   CodecID(s), and keep CodecPrivate empty.
2. Create one/some new CodecID(s) and explicitely say that for these the
   CodecPrivate MUST contain the complete decoder_config.
3. Like 2. but also change the specs so that for all other AAC types
   CodecPrivate MAY contain the complete decoder_config. If CodecPrivate
   hsa been set then the demuxer can simply pass that data over to the
   decoder. If it hasn't been set then nothing changes, because the
   demuxers are already able to reconstruct the decoder_config for all
   supported AAC types ("normal" and "SBR").
4. Do nothing. This way those "parametric stereo" files are recognized
   as being SBR (because their sampling frequency is 24000 Hz, and the
   standard says that all files with a sampling frequency <= 24000 Hz
   are implicitely SBR). The problem is that two bytes of decoder_config
   are simply lost. This may make some files undecodable.

Here are my preferences:

4. sucks because this means that Matroska doesn't support such files.

1. sucks because it would be us constantly chasing after some standards
and inventing elements that will only be used for a single codec
type. Also we really shouldn't translate codec-specific stuff into
general container level stuff.

2. is nice, but 3. is IMHO a bit better -- although it doesn't have any
real advantage over 2.

I've uploaded the sample to
http://www.bunkus.org/videotools/mkvtoolnix/temp/problem_sample.3gp

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds