[Matroska-devel] [Cellar] Colour Format proposal

Jerome Martinez via Matroska-devel matroska-devel at lists.matroska.org
Sat Feb 13 17:22:31 CET 2016

On 13/02/2016 02:53, Dave Rice wrote:
>> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel 
>> <matroska-devel at lists.matroska.org 
>> <mailto:matroska-devel at lists.matroska.org>> wrote:
>> [...]
>> 4: 4:2:1
>>   - ChromaSubsamplingHorz :1
>>   - ChromaSubsamplingVert :not set
>>   - CbSubsamplingHorz :1
>>   - CbSubsamplingVert :not set
>>   - We could remove CbSubsamplingHorz and CbSubsamplingVert if we 
>> didn't care about handling formats where the Cr and Cb channels are 
>> different sizes.
> I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz 
> though perhaps we need a narrative section to expand on this with the 
> examples you have here.

I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because 
there is no explaination about Cb and Cr in SubsamplingHorz and 
So maybe we need to add explanation.
SubsamplingHorz and SubsamplingVert are for both Cb and Cr except 
indicated otherwise.
CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and 
SubsamplingVert if not present.

>> [...]
>> The other issue I want to bring up is the value of "18: ARIB STD-B67 
>> (HLG)" in TransferFunction. Unfortunately, in WebM we will need to 
>> use this value sooner than Matroska v4 will be finalized. Should I 
>> make this value much higher? Or leave at 18? I think "16: SMPTE ST 
>> 2084" and "17: SMPTE ST 428-1" will be standardized across most 
>> documents, like 1-15 are. Just not sure if 18 will be HLG.
> I see a few references to ARIB STD-B67 as 18, such as 
> http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. 
> Perhaps we need a caveat that values 1-15 are defined based upon 
> ISO/IEC 23001-8.

I don't follow: either we say that the list is the ISO/MPEG one and we 
need to find another way to provide HLG value, or we say that we don't 
care of MPEG list.
Looks like we are in the middle (+ trying to use the FFmpeg list).
For example an answer about the reason we keep 0 and 3 as reserved is 
that it is in other specs, but we also say that we don't care of other 
specs. I am lost.

About HLG, my concern is not about Matroska v4 finalization, a bit out 
of topic actually (a list would be update without a new version of 
Matroska) but about the MPEG list. From document pointed by Dave, looks 
like ARIB has a deal with MPEG and ISO, or tries to force value 18 for 
HLG, so I would also use value 18, hoping that MPEG and ISO and ITU will 
accept value 18 for HLG.

> Then for values 16, 17, and 18 we could add better descriptions and 
> citations to define it better internally. If (hopefully) a revision to 
> ISO/IEC 23001-8 adds those values (as expected) then we could update 
> are description to say all values are defined by ISO/IEC 23001-8.

Values 16 and 17 are already in ITU H.265 documentation. I would 
reference this document (bonus: it is publicly available)
I would just add a comment about value 18 = HLG.

But as a general view of how we manage the list: how do we plan to 
manage it? If we say we try to follow MPEG list, maybe we need to have 
"temporary" value e.g. >0x1000000 and we wait for an official 
announcement from ITU/MPEG/ISO about value 18; if we don't care on any 
other list, we don't care of the value for HLG (18 or whatever).

I think that before freezing the list, we need to clear about what is 
this list, if we try to follow another list we need to wait for its 
maintainer, else we need to be coherent e.g. if we don't follow MPEG or 
FFmpeg list, why do we have 0=reserved and 3=reserved and why 
2=unspecified when all other tags have 0=unspecified and why 4 values 
(1, 6, 14, 15) for the same transfer characteristic? I would ask for a 
reason to have such value in the list or remove it from the list, i.e 
0=unspecified, 1=ITU-R BT.709, 2=ITU-R BT.470M...
And define a method for updating it (and say who is the list maintainer) 
if we are the "owner" of the list.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20160213/f87ba213/attachment.html>

More information about the Matroska-devel mailing list