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

[Steve Lhomme]

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...