[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
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
> 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...
More information about the Matroska-devel