[Matroska-devel] [Cellar] Colour Format proposal

Steve Lhomme via Matroska-devel matroska-devel at lists.matroska.org
Sun Feb 14 18:21:37 CET 2016

2016-02-13 17:22 GMT+01:00 Jerome Martinez <jerome at mediaarea.net>:
> 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> 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
> SubsamplingVert.
> 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.

The goal (of Youtube) for now is to have a set of specs that will not
change in the future making their files invalid/unreadable. So I think
leaving values that are still up in the air is the best strategy for
now. Such values can be added later when finalizing the specs (if the
other standard bodies come up with something in time).

> Jérôme
> _______________________________________________
> Cellar mailing list
> Cellar at ietf.org
> https://www.ietf.org/mailman/listinfo/cellar

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list