[matroska-devel] Re: Audio ACM compatibility
steve.lhomme at free.fr
Tue Feb 18 14:34:00 CET 2003
En réponse à Moritz Bunkus <moritz at bunkus.org>:
> > Remember we're not building smething for a demo and change everything
> after !!!
> > We're building something that is going to last. So please stop doing
> this kind
> > of ugly hack !
> So using A_MS/ACM is strongly discouraged and we should use A_* if
> there is one for the current audio codec. Then we store what private
> data the codec has in KaxCodecPrivate. This could be:
I agree with the 'if' but there is a 'else'. Else we use "A_MS/ACM" we don't
just drop an assertion saying this codec should not go in matroska...
> - the data after the WAVEFORMATEX as given by the cbSize member
Why do you want to store a Microsoft structure in something that has *nothing*
to do with any Microsoft system (ie CodecID != A_MS/ACM) ?
> - other data as produced by the audio codec, e.g. headers, comment
> and setup packets produced by the Vorbis encoder
Yes, native matroska IDs should define for each what to put in KaxCodecPrivate.
We need to have a list of these IDs and the description of what to put in the
> All fields of WAVEFORMATEX can be reconstructed from the Matroska
> elements, even the wFormatTag, you just need a mapping from the
> KaxCodecID to the wFormatTags.
> So how do we save more than one packet in KaxCodecPrivate? As
> Vorbis needs three packets. So we have three possibilities:
> - create sub elements for KaxCodecPrivate, insert as many as you need
> and define the order in which they have to appear (for Vorbis it's
> easy: just take the order the Vorbis headers appear in an Ogg file:
> headers, comments, setup data)
> - insert as many KaxCodecPrivate elements as you need and define the
> order in which they appear
> - use a well-known struct and save that in KaxCodecPrivate, e.g.
> int32 length1;
> char data1[length1];
> int32 length2;
> char data2[length2];
> int32 length3;
> char data3[length3];
> int32 length4; // stop when a length field is 0
> What do you propose?
I really prefer the last option ! The other ones make things complicated for no
More information about the Matroska-devel