[Matroska-devel] problem with AAC-in-Matroska
steve.lhomme at free.fr
Tue Nov 23 09:32:59 CET 2004
Moritz Bunkus a écrit :
> 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
Indeed, that's being developped a lot at Ahead. It's said to improve
even more SBR (and make the top codec for low bitrates).
> 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.
If 3 keeps the old CodecIDs and improve themn that's the way to go. IMO
we don't want 5 IDs to handle basically the same codec...
More information about the Matroska-devel