Re: [Cellar] Colour Format proposal

On Sun, Feb 14, 2016 at 9:21 AM, Steve Lhomme <[email protected]> wrote:

> 2016-02-13 17:22 GMT+01:00 Jerome Martinez <[email protected]>:
> > On 13/02/2016 02:53, Dave Rice wrote:
> >
> >
> > On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel
> > <[email protected]> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/cellar
> >
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman
>

As Dave mentioned, there are strong indications from other sources that 18
will be used for "ARIB STD-B67 (HLG)". So I think we are OK with that, but
we should figure out how we want to handle values in the future.

_______________________________________________
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