Re: New Matroska field: chroma range/pixel format

2015-09-24 11:38 GMT+02:00 Jerome Martinez <[email protected]>:
> Le 23/09/2015 18:00, Steve Lhomme a écrit :
>>
>> We currently have a ColourSpace field that is just mapped from AVI.
>> I'm not even sure it's used.
>>
>> When storing raw video, the pixels are stored in a certain way and
>> decoding the pixels need some conversion from this encoding to
>> whatever your screen is using. Right now we don't have all the fields
>> needed to describe these raw data.
>>
>> It may also be useful to tell easily if a H264 or VP9 video is in 8
>> bits per pixels, 10 or 12 bits, without having to inspect codec
>> private data or even Blocks.
>
>
> Not sure it is worth it.
> Is there an use case for it?
>
>>
>> I think a field for Chroma Subsampling (I420, I422, Y410, etc)
>
>
> Chroma subsampling is transported by the 4CC, I don't think it is useful to
> add such info at the Matroska level.
> If the decoder doe not know the Chroma subsampling from the 4CC, it does not
> know the position of pixels so it is not decodable anyway.

True, the codec name could be enough. But if we need a codec for each
variant of compression+pixel format+transfer+etc that will be
unmanageable.
I'd rather have one V_RAW codec ID and each value described elsewhere.
It could be in codec private data. But it may be easier to add the
values in the Video Track Information fields. Just like what we did
for audio.

>> and one
>> for Chroma Range (BT.608, BT.709, BT.2020) should be sufficient.
>
>
> one value for chroma range is not enough.
> We need:
> - Colour primaries
> - Transfer characteristics
> - Matrix coefficients
> - Colour range
> This looks like crazy but some files have a Colour primaries from BT.709 and
> Matrix coefficients from BT.601.
>
> Such metadata is not transported by the 4CC in uncompressed video format
> (V210...) and in some compressed formats (e.g. AVC can transport it, FFV1
> can not for the moment), so this is not redundant, this is the only way to
> transport it.
>
>>   The
>> Chroma Subsampling generally described how each "plane" is layed out
>> in the raw data.
>
>
> Not exactly. Chroma subsmapling says how many chroma pixels compared to luma
> pixels (e.g. 420 is 1 chroma pixel for 2 pixels width and 2 pixels height) ,
> but do not provide the location of chroma samples (they are not always at
> the center of the luma pixels)
> for example, HEVC has a list of 6 different layouts (chroma at the top left,
> chroma at the center...). I don't see a need on my side but I guess some
> people may be interested in having such additional information about layout.

Yes, that's the info I was talking about.

> _______________________________________________
> Matroska-devel mailing list
> [email protected]
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel