[matroska-devel] Re: Audio ACM compatibility

Cyrius suiryc at yahoo.com
Tue Feb 18 20:40:57 CET 2003

--- Christian HJ Wiesner <chris at wiesneronline.net>
> Steve Lhomme wrote:
> >En réponse à Christian HJ Wiesner
> <chris at matroska.org>:
> >  
> >
> >>An interesting question was asked by Mosu :
> >>
> >>Why do we need the KaxVideoColourSpace element at
> all ? We can put the
> >>
> >>relevant info into the KaxCodecID element easily ?
> Or is the element 
> >>used for other video codecs also, describing what
> colour space there 
> >>content is ? If so then i guess we should use the
> existing Colour Space
> >>
> >>element and change the Codec ID to something
> simple like
> >>
> >>
> >>What do you all think ?
> >>    
> >>
> >
> >Well, I just took the field from MCF and put it in
> matroska...
> >I think we discussed than on #mcf a long time ago
> and I didn't understand :)
> >If you hae old logs, you might investigate in
> there.
> >http://www.matroska.org
> >
> Well, i am not complete certain here but i guess
> that at least some 
> codecs can work in the YUV or in the RGB colour
> space. Now, to be able 
> to handle the content correctly you would have to
> know what colour space 
> was used for this encoding, and if i am not
> completely mistaken this 
> info is also to be found somewhere in the
> anybody confirm ? Cyrius ?

Hmm if you are talking of encoded video then I don't
think the BITMAPINFOHEADER contains any information of
the colorspace used (well there is still the case of
HuffYUV that uses the biBitCount field for its own
settings), but I'm no codec video nor MS expert here
The biCompression field contains the FourCC, and
biBitCount the number of bits per pixel. I think that
biBitCount isn't really useful with compressed streams
because the data Windows will really use are somewhere
further in the process (after the codec has decoded
the frames) where there is another  BITMAPINFOHEADER
filled by the codec this time (so the codec will tell
Windows what colorspace it is  decoding the data to).
That's why HuffYUV misuse this field ;)

The other fields in the structure only give
information on the size of video etc.

> As we plan to replace this M$ structure with our own
> elements, at least 
> for 'native' streams, this would mean we need such
> an element and use a 
> simple codec ID like 'V_UNCOMPRESSED' instead, and
> fill the colour space 
> into the matroska KaxVideoColourSpace element ....
> Cyrius, is that true 
> what i say above ???

The problem is that there are a lot of colorspaces,
some having only a few differences (e.g. the order in
which it stores the data etc).
An example :
I420 and YV12 both only need 12 bits per pixel, and
IIRC the only difference between the two is the order
in which values are stored (i.e. only a value
You can see this page to have an overview of those
formats (mainly YUV ones) :
You will see that some formats only differs by storing
order : some store all values of a row (Chroma/Lumi)
at once, some 'interlace' the values ...

Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

More information about the Matroska-devel mailing list