[Matroska-devel] problem with AAC-in-Matroska
moritz at bunkus.org
Mon Nov 22 23:13:53 CET 2004
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
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
More information about the Matroska-devel