Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal

From: Dave Rice <[email-masked]>
Date: Wed, 3 Feb 2016 01:25:26 -0500

> On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel <[email-masked]> wrote:
> 
> On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme <[email-masked] <mailto:[email-masked]>> wrote:
> 2016-01-06 23:30 GMT+01:00 Frank Galligan <[email-masked] <mailto:[email-masked]>>:
> >
> >
> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[email-masked] <mailto:[email-masked]>>
> > wrote:
> >>
> >> Thanks for your detailed proposal.
> >> It is a lot of items, I am not expert in all domains but I have some
> >> comments:
> >
> > Neither am I, but I figured we might as well start from a proposal and
> > iterate from there.
> >
> >>
> >> Name: MatrixCoefficients (or Matrix. You don't use "Colour" with
> >> "Primaries" element, so I would not use it here too)
> >
> >  Sounds good to me.
> >
> >>
> >>
> >>
> >>
> >>
> >> Element Name: BitsPerChannel
> >> Level:        5
> >> ID:           [55][A2]
> >> Mandatory:    ma
> >> Multiple:     -
> >> Default:      8
> >> Type:         u
> >> Description:  Number of bits per channel. This number may be less for
> >> specific
> >>               channels depending on the ColourFormat and
> >> ChromaSubsampling.
> >>
> >>
> >>
> >> BitsPerChannel is misleading, used to be the technical count of bits.
> >> I propose QuantizationBits or ValidBitsPerChannel
> >> Not mandatory, not default (this value is often unknown)
> >
> > When authoring the video, I'm not sure why the software would not know the
> > bits per channel. Can you describe a use case where the this is unknown?
> 
> When remuxing an older file. Either from Matroska source or AVI or other.
> 
> Now if elements are mandatory with a default value to "unknown" it's fine.
> 
> > I really think we should make this mandatory and have authoring software
> > populate the element (or default) vs software thinking this was
> > non-mandatory and not populating this element because the developer didn't
> > think it was needed.
> >>
> >>
> >>
> >>
> >> Element Name: ChromaSubsampling
> >> Level:        5
> >> ID:           [55][A3]
> >> Mandatory:    ma
> >> Multiple:     -
> >> Default:      0
> >> Type:         u
> >> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)
> >>
> >>
> >> FFV1, for example, permits "weird" chroma values, more possibilities.
> >> And the following chroma values were seen at least once in some specs:
> >> 4:4:4
> >> 4:2:2
> >> 4:2:1
> >> 4:1:1
> >> 4:2:0
> >> 4:1:0
> >> 3:1:1
> >>
> >> So having a list is maybe not the solution.
> >> I like the way it is done in FFV1, except the power of 2 (so 3 can not be
> >> expressed).
> >> I propose to find a way for describing Chroma subsampling (e.g.
> >> h_chroma_subsample and v_chroma_subsample; a ratio per plane with any number
> >> of plane, think to alpha channel with a subsampling).
> >
> > I'm fine with coming up with a more extensible solution (Micheal asked for
> > that as well).
> >>
> >>
> >>
> >>
> >>
> >>
> >> Element Name: ColourRange
> >> Level:        5
> >> ID:           [55][A4]
> >> Mandatory:    ma
> >> Multiple:     -
> >> Default:      1
> >> Type:         u
> >> Description:  (0: Unspecified, 1: Defined by
> >> ColourMatrix/TransferFunction,
> >>               2: Full range)
> >>
> >>
> >> I don't understand the 1 value.
> >> in at least AVC and HEVC, range is orthogonal to
> >> ColourMatrix/TransferFunction.
> >> I propose 0: unspecified 1: Broadcast range 1: Full range
> >> and Default:0
> >
> > I thought someone mentioned to me before that the range could change based
> > on the matrix and transfer function. I'm fine with your proposal.
> >
> >>
> >>
> >>
> >> I got requests for having information about "Capture Gamma Equation" (or
> >> "Tone Curve"), e.g. "same as transfer characteristic", Scene Linear, S-Log,
> >> Cine-Log, Log-C...
> >> I am not an expert of this domain, but looks like it is sometimes
> >> important.
> >
> > Someone who knows more about  this should propose something to this list to
> > be included.
> >
> >>
> >> there are also other colour ideas with e.g. EBU Tech 3349.
> >
> > If this is important to people, then we could add this as well.
> >>
> >>
> >>
> >>
> >>
> >>
> >> I can post a link to a formatted document if that would be easier. For
> >> Matrix, Range, and Primaries, I'm pretty much using values that map directly
> >> to values defined in FFmpeg.
> >>
> >>
> >> I don't like the idea to use the source code of a piece of software for
> >> lists. Too much subjective, may have historical flaws.
> >> Lists from FFmpeg are nearly same as the ones in H.26x, I think I prefer
> >> we base our list on their list (I don't think there are copyright issues
> >> with such list) directly.
> >
> > I don't know the H.26x list. I started with my own, but then switched to
> > FFmpeg as they already had an extensive list and assumed they have seen a
> > lot of the video already.
> >
> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg would be
> > better as it handles a lot more video than H.26x.
> >
> >>
> >> Or that we have a prefix with the origin of the list (e.g. ARIB STD-B67,
> >> from Japan, is not in ITU/ISO list, a 18 will be used in the future for
> >> something in ITU/ISO)
> >
> > Yeah HLG is relatively new, but has been requested by a few people.
> >
> >
> >
> > _______________________________________________
> > Cellar mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/cellar <https://www.ietf.org/mailman/listinfo/cellar>
> >
> 
> 
> 
> --
> Steve Lhomme
> Matroska association Chairman
> 
> So I updated my original proposal based on comments from this list.
> 
> Changes:
> - Added more common ChromaSubsampling values
> - ColourMatrix renamed to Matrix
> - Added a default value of 0 to BitsPerChannel to signify "unspecified".
> - Added "decoded" to BitsPerChannel note.
> - Added ChromaSittingHorz and ChromaSittingVert elements.

In this case, I think the intended term is ‘siting’ rather than ‘sitting’.

> - Added Broadcast range to Range element.
> - Removed mandatory flag for elements with unspecified defaults.
> - Updated element IDs.
> 
> 
> - I kept "Defined by Matrix/TransferFunction" in Range element because there are ranges that fall outside of Broadcast and Full depending on the TF. E.g. xvYCC (61966-2-4)
> - Does someone want to propose something better for ChromaSubsampling?
> - I know some people expressed that they don't think starting from FFmpeg for the TransferFunction is a good idea as they might have got something wrong or too subjective. But I just used it as a starting point for a list. I can reorder the list however we want. I also don't think following another list, so we will be compatible with future additions, will give us what we want as that list most likely will be incomplete with something that is defined only in a different list. So should we just start with a list, re-order it (so we are not explicitly following it), then add what is currently missing? Then in the future if someone needs to add something to the list it can be brought up here?

I think Jerome’s main point was that FFmpeg’s list themselves were based on something else, so we should follow the source for a vocabulary authority. For instance, see ITU Recommendation H.264 at https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. Pages 387 (pdf page 409) gives a table of color primaries, page 388 has transfer characteristics, and 392 has Matrix coefficients. The information in the ITU docs provides a lot more context than FFmpeg source code.

> This is what I currently have:
> 
> The parent element would be Video [E0].
> 
> 
> Element Name: Colour
> Level:        4
> ID:           [55][A0]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         m
> Description:  Settings describing the colour format.
> 
> 
> Element Name: Matrix
> Level:        5
> ID:           [55][A1]
> Mandatory:    -
> Multiple:     -
> Default:      2
> Type:         u
> Description:  Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: BT709,
>               2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,
>               7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance,
>               10: BT2020 Constant Luminance) 

I suggest referencing a specific ITU document for these values and their meaning.

> Element Name: BitsPerChannel
> Level:        5
> ID:           [55][A2]
> Mandatory:    -
> Multiple:     -
> Default:      0
> Type:         u
> Description:  Number of decoded bits per channel. This number may be less for 
>               specific channels depending on the Matrix and ChromaSubsampling. A
>               value of 0 is unspecified.
> 
> 
> Element Name: ChromaSubsampling
> Level:        5
> ID:           [55][A3]
> Mandatory:    -
> Multiple:     -
> Default:      0
> Type:         u
> Description:  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: 4:2:0,             
>               6: 4:1:1, 7: 4:1:0, 8: 3:1:1)
> 
> Element Name: ChromaSittingHorz

Siting

> Level:        5
> ID:           [55][A4]
> Mandatory:    -
> Multiple:     -
> Default:      0
> Type:         u
> Description:  How Chroma is subsampled horizontally. (0: Unspecified, 1: Left 
>               collocated , 2: Half)
> 
> Element Name: ChromaSittingVert

Siting

> Level:        5
> ID:           [55][A5]
> Mandatory:    -
> Multiple:     -
> Default:      0
> Type:         u
> Description:  How Chroma is subsampled vertically. (0: Unspecified, 1: Top
>               collocated , 2: Half)
> 
> 
> Element Name: Range
> Level:        5
> ID:           [55][A6]
> Mandatory:    -
> Multiple:     -
> Default:      0
> Type:         u
> Description:  (0: Unspecified, 1: Broadcast range, 2: Full range, 3: Defined by 
>               Matrix/TransferFunction)

I think a description (beyond the list) is needed.

> Element Name: TransferFunction
> Level:        5
> ID:           [55][A7]
> Mandatory:    -
> Multiple:     -
> Default:      2
> Type:         u
> Description:  Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,
>               4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M,
>               7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
>               11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,
>               13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
>               15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
>               17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))

Consider referencing ITU document as an external authority for the vocabulary. 

> Element Name: Primaries
> Level:        5
> Mandatory:    -
> Multiple:     -
> ID:           [55][A8]
> Default:      2
> Description:  (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R BT.470M,
>                5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,
>                9: ITU-R BT.2020, 10: SMPTE ST 428-1)

Consider reference to ITU document. Needs a description besides list.

> Element Name: MaxCLL
> Level:        5
> ID:           [55][A9]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         u
> Description:  Maximum brightness of a single pixel in candelas per square
>               meter (cd/m²).
> 
> 
> Element Name: MaxFALL
> Level:        5
> ID:           [55][AA]

[55][AA] is already in use as FlagForced.

> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         u
> Description:  Maximum brightness of a single full frame in candelas per square
>               meter (cd/m²).
> 
> 
> Element Name: MasteringMetadata
> Level:        5
> ID:           [55][D0]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         m
> Description:  SMPTE 2086 mastering data.

I’m not well experienced in MasteringMetadata but wouldn’t this data need to change from scene to scene rather than be stored within the Tracks element where the same values would apply to all scenes?

> Element Name: PrimaryRChromaticityX
> Level:        6
> ID:           [55][D1]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.

The description is actually a range. When we initially drafted information on expressing ranges in EBML definitions, I ignored float, see https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#expression-of-range. I can update this definition to include floats and greater-than-or-equal values. But the description for this and the following elements should be moved to range (suggested formatting as "0-1”). Then these elements need actual descriptions.

> Element Name: PrimaryRChromaticityY
> Level:        6
> ID:           [55][D2]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: PrimaryGChromaticityX
> Level:        6
> ID:           [55][D3]
> Mandatory:    -
> Multiple:     -
> Default:      -
> f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: PrimaryGChromaticityY
> Level:        6
> ID:           [55][D4]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: PrimaryBChromaticityX
> Level:        6
> ID:           [55][D5]
> Mandatory:    -
> Multiple:     -
> Default:      -
> f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: PrimaryBChromaticityY
> Level:        6
> ID:           [55][D6]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: WhitePointChromaticityX
> Level:        6
> ID:           [55][D7]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: WhitePointChromaticityY
> Level:        6
> ID:           [55][D8]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
> 
> 
> Element Name: LuminanceMax
> Level:        6
> ID:           [55][D9]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Maximum luminance. Shall be represented in candelas per square
>               meter (cd/m²). Valid value is in the range 0 <= f <= 9999.99

Add a Range value and split the Description and Range.

> Element Name: LuminanceMin
> Level:        6
> ID:           [55][DA]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Minimum luminance. Shall be represented in candelas per square
>               meter (cd/m²). Valid value is in the range 0 <= f <= 999.9999

Add a Range value and split the Description and Range.

Best Regards,
Dave Rice

---

From: Steve Lhomme <[email-masked]>
Date: Wed, 3 Feb 2016 10:30:47 +0100

2016-02-03 7:25 GMT+01:00 Dave Rice <[email-masked]>:
>
> On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel
> <[email-masked]> wrote:
>
> On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme <[email-masked]> wrote:
>>
>> 2016-01-06 23:30 GMT+01:00 Frank Galligan <[email-masked]>:
>> >
>> >
>> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[email-masked]>
>> > wrote:
>> >>
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/cellar
>> >
>>
>>
>>
>> --
>> Steve Lhomme
> - I kept "Defined by Matrix/TransferFunction" in Range element because there
> are ranges that fall outside of Broadcast and Full depending on the TF. E.g.
> xvYCC (61966-2-4)
> - I know some people expressed that they don't think starting from FFmpeg
> for the TransferFunction is a good idea as they might have got something
> wrong or too subjective. But I just used it as a starting point for a list.
> I can reorder the list however we want. I also don't think following another
> list, so we will be compatible with future additions, will give us what we
> want as that list most likely will be incomplete with something that is
> defined only in a different list. So should we just start with a list,
> re-order it (so we are not explicitly following it), then add what is
> currently missing? Then in the future if someone needs to add something to
> the list it can be brought up here?
>
>
> I think Jerome’s main point was that FFmpeg’s list themselves were based on
> something else, so we should follow the source for a vocabulary authority.
> For instance, see ITU Recommendation H.264 at
> https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. Pages 387
> (pdf page 409) gives a table of color primaries, page 388 has transfer
> characteristics, and 392 has Matrix coefficients. The information in the ITU
> docs provides a lot more context than FFmpeg source code.
>
> I’m not well experienced in MasteringMetadata but wouldn’t this data need to
> change from scene to scene rather than be stored within the Tracks element
> where the same values would apply to all scenes?
>
> The description is actually a range. When we initially drafted information
> on expressing ranges in EBML definitions, I ignored float, see
> https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#expression-of-range.
> I can update this definition to include floats and greater-than-or-equal
> values. But the description for this and the following elements should be
> moved to range (suggested formatting as "0-1”). Then these elements need
> actual descriptions.

Rather "0.0-1.0" then.

> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

---

From: Frank Galligan <[email-masked]>
Date: Thu, 4 Feb 2016 12:51:51 -0800

On Wed, Feb 3, 2016 at 1:30 AM, Steve Lhomme <[email-masked]> wrote:

> >> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[email-masked]
> >
> >> > wrote:
> >> >>
> >> >> I like the way it is done in FFV1, except the power of 2 (so 3 can
> not
> >> >> be
> >> >> expressed).
> >> > Someone who knows more about  this should propose something to this
> list
> >> > to
> >> > be included.
> >> >
> >> >>
> >> > FFmpeg as they already had an extensive list and assumed they have
> seen
> >> > a
> > Description:  (0: Unspecified, 1: Broadcast range, 2: Full range, 3:
> Defined
> > by
> >              Matrix/TransferFunction)
> >
> >

---

From: Frank Galligan <[email-masked]>
Date: Thu, 4 Feb 2016 13:00:30 -0800

On Thu, Feb 4, 2016 at 12:51 PM, Frank Galligan <[email-masked]>
wrote:

>> >> > When authoring the video, I'm not sure why the software would not
>> know
>> >> > the
>> >> >> h_chroma_subsample and v_chroma_subsample; a ratio per plane with
>> any
>> >> >> number
>> >> > I'm fine with coming up with a more extensible solution (Micheal
>> asked
>> >> > for
>> >> > that as well).
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> > Description:  Number of decoded bits per channel. This number may be
>> less
>> > for
>> > Description:  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1,
>> 5:
>> > 4:2:0,

I'll look into referencing an ITU document.

siting. Yes :)

[55][AA], Yes I know I currently changed all the [55][Ax] to [55][Bx].

Range Description: How about:

Clipping of the color ranges. (0: Unspecified, 1: Broadcast range,

             2: Full range (no clipping), 3: Defined by
             Matrix/TransferFunction)

2086 Mastering metadata refers to the display the content was mastered on.
So these values should not change scene to scene.

How about these for the values with ranges. I didn't add a .0 for values
which should be close to the integer value.

Level:        6

ID:           [55][D1]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Description:  Red X chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D2]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Description:  Red Y chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D3]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

f

Description:  Green X chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D4]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Description:  Green Y chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D5]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

f

Description:  Blue X chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D6]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Description:  Blue Y chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D7]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Description:  White point X chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D8]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Description:  White point Y chromaticity coordinate as defined by CIE 1931.

Level:        6

ID:           [55][D9]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 9999.99

Default:      -

Type:         f

             meter (cd/m²).

Level:        6

ID:           [55][DA]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 999.9999

Default:      -

Type:         f

             meter (cd/m²).

---

From: Jerome Martinez <[email-masked]>
Date: Mon, 8 Feb 2016 18:15:06 +0100

Sorry for the late answer, here are my comments:

On 22/01/2016 23:54, Frank Galligan wrote:
> [...]
>
> - I know some people expressed that they don't think starting from 
> FFmpeg for the TransferFunction is a good idea as they might have got 
> something wrong or too subjective. But I just used it as a starting 
> point for a list. I can reorder the list however we want. I also don't 
> think following another list, so we will be compatible with future 
> additions, will give us what we want as that list most likely will be 
> incomplete with something that is defined only in a different list. So 
> should we just start with a list, re-order it (so we are not 
> explicitly following it), then add what is currently missing? Then in 
> the future if someone needs to add something to the list it can be 
> brought up here?

That was me.
I am OK with that as long as we are clear that we don't follow FFmpeg list.

> [...]

If we don't follow FFmpeg list, what is the purpose of  value 3 and why 
unspecified is 2 rather than 0?
Using FFmpeg list (which is based on MPEG list, with same oddities) is 
not bad, and I am not against it, just wondering if it is good to take 
the same oddities rather than a clean list without oddities.

Does anyone plan to transfer from DPX? If yes, we may need to add now 
missing elements in the list (e.g. "Printing density") but I am not 
expert enough for know which one is worth it.

> [...]
> 5: 4:2:0,

I am more, as some other people, for something more generic, e.g. 
ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the 
subsampling (0 unspecified and default). I am afraid that someone crazy 
used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X 
values), it is possible (and I have a file like that if I remember well) 
with FFV1.

> [...]

Same remark as with Matrix.

> [...]

---

From: Frank Galligan <[email-masked]>
Date: Mon, 8 Feb 2016 14:23:05 -0800

On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez <[email-masked]>
wrote:

> I can reorder the list however we want. I also don't think following
> another list, so we will be compatible with future additions, will give us
> what we want as that list most likely will be incomplete with something
> that is defined only in a different list. So should we just start with a
> list, re-order it (so we are not explicitly following it), then add what is
OK, I changed the text to see ISO/IEC 23001-8 document, which has the same
values as FFmpeg as well as the 264 ITU doc.

> unspecified is 2 rather than 0?
That is the way it is specified in ISO/IEC 23001-8 and 264 ITU doc.

Using FFmpeg list (which is based on MPEG list, with same oddities) is not
> bad, and I am not against it, just wondering if it is good to take the same
> oddities rather than a clean list without oddities.
>
I don't think there are any oddities. Looks like FFmpeg's list matches
exactly to  ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries
and #16 and #17 in Transfer function, which were added here [1]. Also #18
in Transfer, which is HLG [2].

I think this is the whole issue. Do we follow some list (standardized or
not)? What if the list goes stale? What if the list doesn't include
algorithms from different lists (E.g. maybe HLG)?

> missing elements in the list (e.g. "Printing density") but I am not expert
> enough for know which one is worth it.
>
>
>
>
> [...]
>
>
[1]
https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8aa17746
[2] http://www.arib.or.jp/english/html/overview/std-b67.html

---

From: Frank Galligan <[email-masked]>
Date: Thu, 11 Feb 2016 10:32:30 -0800

> [2] http://www.arib.or.jp/english/html/overview/std-b67.html
So this is what I have currently:

Element Name: Colour

Level:        4

ID:           [55][B0]

Mandatory:    -

Multiple:     -

Default:      -

Type:         m

Element Name: Matrix

Level:        5

ID:           [55][B1]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Description:  ColourMatrix of the video. See ISO/IEC 23001-8 for more

             information on enumerations. (0: IEC 61966-2-1 (sRGB), 1:
BT709,

Level:        5

ID:           [55][B2]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

Description:  Number of decoded bits per channel. This number may be less
for

             specific channels depending on the Matrix and
ChromaSubsampling. A

Element Name: ChromaSubsamplingHorz

Level:        5

ID:           [55][B3]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of chrominance pixels to remove for every
chrominance

             pixel not removed horizontally.

Element Name: ChromaSubsamplingVert

Level:        5

ID:           [55][B4]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of chrominance pixels to remove for every
chrominance

             pixel not removed vertically.

Element Name: CbSubsamplingHorz

Level:        5

ID:           [55][B5]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of Cb chrominance pixels to remove for every Cb

             chrominance pixel not removed horizontally. This is additive
with

             ChromaSubsamplingHorz.

Element Name: CbSubsamplingVert

Level:        5

ID:           [55][B6]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of Cb chrominance pixels to remove for every Cb

             chrominance pixel not removed vertically. This is additive with

             ChromaSubsamplingVert.

Element Name: ChromaSitingHorz

Level:        5

ID:           [55][B7]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

Description:  How Chroma is subsampled horizontally. (0: Unspecified, 1:
Left

             collocated , 2: Half)

Element Name: ChromaSitingVert

Level:        5

ID:           [55][B8]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

             collocated , 2: Half)

Element Name: Range

Level:        5

ID:           [55][B9]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

Description:  Clipping of the color ranges. (0: Unspecified, 1: Broadcast
range,

             Matrix/TransferFunction)

Level:        5

ID:           [55][BA]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Description:  Transfer Function. See ISO/IEC 23001-8 for more information on

             enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

             3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve,

             6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,

Element Name: Primaries

Level:        5

Mandatory:    -

Multiple:     -

ID:           [55][BB]

Default:      2

Type:         u

Description:  Values that can be represented in the CIE 1931 colour space.
See

             ISO/IEC 23001-8 for more information on enumerations.

             (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved,

             4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE
240M,

             8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)

Element Name: MaxCLL

Level:        5

ID:           [55][BC]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

             meter (cd/m²).

Element Name: MaxFALL

Level:        5

ID:           [55][BD]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  Maximum brightness of a single full frame in candelas per
square

             meter (cd/m²).

Level:        5

ID:           [55][D0]

Mandatory:    -

Multiple:     -

Default:      -

Type:         m

Level:        6

ID:           [55][D1]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Level:        6

ID:           [55][D2]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Level:        6

ID:           [55][D3]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

f

Level:        6

ID:           [55][D4]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Level:        6

ID:           [55][D5]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

f

Level:        6

ID:           [55][D6]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Level:        6

ID:           [55][D7]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Level:        6

ID:           [55][D8]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 1

Default:      -

Type:         f

Level:        6

ID:           [55][D9]

Mandatory:    -

Multiple:     -

Range:        0 <= f <= 9999.99

Default:      -

Type:         f

             meter (cd/m²).

Level:        6

ID:           [55][DA]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

             meter (cd/m²).

I removed ChromaSubsampling and added ChromaSubsamplingHorz,
ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert.

This is how I think the elements should be written for the different
subsampling types:
1: 4:4:4
    - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as
there should be no chroma subsampling.

2: 4:4:0
  - ChromaSubsamplingHorz :not set
  - ChromaSubsamplingVert :1

3: 4:2:2
  - ChromaSubsamplingHorz :1
  - ChromaSubsamplingVert :not set

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.

5: 4:2:0
  - ChromaSubsamplingHorz :1
  - ChromaSubsamplingVert :1

6: 4:1:1
  - ChromaSubsamplingHorz :3
  - ChromaSubsamplingVert :not set

7: 4:1:0
  - ChromaSubsamplingHorz :3
  - ChromaSubsamplingVert :1

8: 3:1:1
  - ChromaSubsamplingHorz :2
  - ChromaSubsamplingVert :not set
  - I'm assuming the luma subsampling can be handled by PixelWidth, and
DisaplyWidth.

Jerome's vertical subsampling of 4
  - ChromaSubsamplingHorz :not set
  - ChromaSubsamplingVert :3

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.

Thanks,
Frank

---

From: Dave Rice <[email-masked]>
Date: Fri, 12 Feb 2016 20:53:15 -0500

Hi,

> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel <[email-masked]> wrote:
> 
> 
> On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez <[email-masked] <mailto:[email-masked]>> wrote:
> OK, I changed the text to see ISO/IEC 23001-8 document, which has the same values as FFmpeg as well as the 264 ITU doc.
> 
>> 
>> [...]
>> 
>> Element Name: Matrix
>> Level:        5
>> ID:           [55][A1]
>> Mandatory:    -
>> Multiple:     -
>> Default:      2
>> Type:         u
> If we don't follow FFmpeg list, what is the purpose of  value 3 and why unspecified is 2 rather than 0?
> Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities.
> I don't think there are any oddities. Looks like FFmpeg's list matches exactly to  ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries and #16 and #17 in Transfer function, which were added here [1]. Also #18 in Transfer, which is HLG [2].
> 
> I think this is the whole issue. Do we follow some list (standardized or not)? What if the list goes stale? What if the list doesn't include algorithms from different lists (E.g. maybe HLG)?
> 
> 
> 
> Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") but I am not expert enough for know which one is worth it.
> 
> 
>> 
>> 
>> [...]
>> 
>> 
> I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1.
> 
> 
> 
>> 
>> [...]
>> 
> [1] https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8aa17746 <https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8aa17746>
> [2] http://www.arib.or.jp/english/html/overview/std-b67.html <http://www.arib.or.jp/english/html/overview/std-b67.html>
> 
> 
> 

To align better with ISO/IEC 23001-8, could this be labelled as MatrixCoefficients?

>               information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: BT709,

Suggested description edit:
The Matrix Coefficients of the video used to derive luma and chroma values from reg, green, and blue color primaries. For clarity, the value and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance)

Question:
Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as RGB". Should value 0 = RGB?

Add footnote:
[IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media description code points", 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-8_2013.zip>.

>               value of 0 is unspecified.

It may be fine, but I don't understand "This number may be less for specific channels depending on the Matrix and ChromaSubsampling." Is the value is less for specific channels, then it seems as if the value would different among channels, but only one BitsPerChannel is stored for a multi-channel video.

I suggest changing the last line to: A value of 0 indicates that the BitsPerChannel is unspecified.

> Description:  The amount of chrominance pixels to remove for every chrominance

For these subsampling elements, we may need a statement to say when they should be used. For instance in QuickTime's TN2162 https://developer.apple.com/library/mac/technotes/tn2162/_index.html <https://developer.apple.com/library/mac/technotes/tn2162/_index.html> it mandates the use of many values to better describe uncompressed video. When would these chroma subsampling elements be suggested?

I also suggest including an example; such as "Example: For video with 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3.

> Description:  The amount of chrominance pixels to remove for every chrominance
>               chrominance pixel not removed horizontally. This is additive with
>               ChromaSubsamplingHorz.

I'm confused about the relationship between CbSubsamplingHorz and ChromaSubsamplingHorz.

> Description:  Clipping of the color ranges. (0: Unspecified, 1: Broadcast range,

To align with ISO/IEC 23001-8, could we use TransferCharacteristics?

>               17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))

Comment:
The table in ISO/IEC 23001-8 for transfer characteristics does not include values or meaning for 16, 17 and 18 as above. Are these values from ffmpeg's list?

Suggested description edit:
The transfer characteristics of the video. For clarity, the value and meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit)

> Element Name: Primaries
> Level:        5
> Mandatory:    -
> Multiple:     -
> ID:           [55][BB]
> Default:      2
> Type:         u
> Description:  Values that can be represented in the CIE 1931 colour space. See
>               4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M,

Suggested description edit:
The colour primaries of the video. For clarity, the value and meanings for TransferCharacteristics are adopted from Table 2 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)

Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 phosphors. Any reason to exclude this?

> Description:  Maximum brightness of a single pixel in candelas per square

Suggested:
Maximum brightness of a single pixel (Maximum Content Light Level) in candelas per square meter (cd/m²).

> Description:  Maximum brightness of a single full frame in candelas per square

Suggested:
Maximum brightness of a single full frame (Maximum Frame-Average Light Level) in candelas per square meter (cd/m²).

> Element Name: PrimaryRChromaticityX

I think "0.0-1.0" is preferred for float range expressions.

> I removed ChromaSubsampling and added ChromaSubsamplingHorz, ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert.
> 
> This is how I think the elements should be written for the different subsampling types:
> 1: 4:4:4
>     - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as there should be no chroma subsampling.
> 
> 2: 4:4:0
>   - 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'm assuming the luma subsampling can be handled by PixelWidth, and DisaplyWidth.
> 
> 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 <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. 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.

> Frank

Thanks too,
Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Sat, 13 Feb 2016 17:22:31 +0100

On 13/02/2016 02:53, Dave Rice wrote:
>
>> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> [...]
>>
>> 4: 4:2:1
>>   - 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.

Jérôme

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 14 Feb 2016 18:21:37 +0100

2016-02-13 17:22 GMT+01:00 Jerome Martinez <[email-masked]>:
> SubsamplingHorz and SubsamplingVert are for both Cb and Cr except indicated
> otherwise.
> 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.
> 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.
>
> 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)
> 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).

---

From: "Peter B." <[email-masked]>
Date: Tue, 16 Feb 2016 10:01:39 +0100

> expert enough for know which one is worth it.

I wouldn't want to rule out the option of transcoding from DPX to FFV1/MKV.
But on the other hand, I'm very much in favor of keeping things simple -
and not overdoing it.

I think being able to handle non-linear color values (as often found in
DPX scans) is important, but I wouldn't go as far as putting something
like "printing density" into the standard.

Anyone more familiar with digital film, please correct or augment my
statements, as I'm not so experienced with film.

Kind regards,
Pb

---

From: Frank Galligan <[email-masked]>
Date: Tue, 16 Feb 2016 11:01:33 -0800

> To align better with ISO/IEC 23001-8, could this be labelled as
Done

> The Matrix Coefficients of the video used to derive luma and chroma values
> from reg, green, and blue color primaries. For clarity, the value and
> meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC
> 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, 3:
> Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9:
> BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance)
>
Done

>
> Question:
> Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix
> coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as RGB".
> Should value 0 = RGB?
>
I changed it to GBR to match 23001-8.

> Add footnote:
> [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media
> description code points", 2013, <
> http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-8_2013.zip
> >.
>
> It may be fine, but I don't understand "This number may be less for
> specific channels depending on the Matrix and ChromaSubsampling." Is the
> value is less for specific channels, then it seems as if the value would
> different among channels, but only one BitsPerChannel is stored for a
> multi-channel video.
>
So we could have separate bits per channel, but then we would have to
define rgb and yuv. Most people know what this is. Basically the
information needed is, will the decoded video be 8 bits, 10 bits, 12 bits,
16 bits, ... Maybe I was just trying to be a little too pedantic. I'm fine
with removing this sentence. if any of the ChromaSubsampling elements are
set then that implies that one or more channels will have a different value.

So how about we just remove this sentence?

> BitsPerChannel is unspecified.
Done

> For these subsampling elements, we may need a statement to say when they
> should be used. For instance in QuickTime's TN2162
> https://developer.apple.com/library/mac/technotes/tn2162/_index.html it
> mandates the use of many values to better describe uncompressed video. When
> would these chroma subsampling elements be suggested?
>
I'm not really sure I follow. If any of the Cb or Cr channels are down
sized before encoding, then these elements should be set accordingly.

> I also suggest including an example; such as "Example: For video with
> 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3.
>
I added "Example: For video with 4:2:0 chroma subsampling the
ChromaSubsamplingHorz should be set to 1." As pretty much most video is
4:4:4 or 4:2:0 nowadays.

> and ChromaSubsamplingHorz.
These elements are only defined because I was trying to handle 4:2:1.
Basically this is an old format where the Cr channel is half the size of
the Y channel, and the Cb channel is half the size of the Cr channel. The
Cb channel is a quarter the size of the Y channel.

The CbSubsampling* elements were a late edition, right before I sent my
previous email. At first I didn't have these elements and had text that
4:2:1 was not supported.

How about I change the CbSubsamplingHorz element text too: "The amount of
pixels to remove in the Cr and Cb channels for every pixel not removed
horizontally." And the CbSubsamplingHorz too: "The amount of pixels to
remove in the Cb channel for every pixel not removed horizontally. This is
additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma
subsampling the ChromaSubsamplingHorz should be set to 1 and
CbSubsamplingHorz should be set to 1." Does this help the confusion?

> To align with ISO/IEC 23001-8, could we use TransferCharacteristics?
Done.

> The table in ISO/IEC 23001-8 for transfer characteristics does not include
> values or meaning for 16, 17 and 18 as above. Are these values from
> ffmpeg's list?
>
16 and 17 is an artifact form the FFmpeg list, but also form looking at
FFmpeg CL's I think they are defined in an h265 spec. 18 is a proposed
value for HLG.

> The transfer characteristics of the video. For clarity, the value and
> meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC
> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3:
> Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE
> 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361
> Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15:
> ITU-R BT.2020 12 bit)
>
Done.

> The colour primaries of the video. For clarity, the value and meanings for
> TransferCharacteristics are adopted from Table 2 of ISO/IEC
> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3:
> Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE
> 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)
>
Done.

> phosphors. Any reason to exclude this?
Added.

> candelas per square meter (cd/m²).
Done

> Maximum brightness of a single full frame (Maximum Frame-Average Light
> Level) in candelas per square meter (cd/m²).
>
Done

> I think "0.0-1.0" is preferred for float range expressions.
Done

> 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.
>
>
> Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC
> 23001-8. Then for values 16, 17, and 18 we could add better descriptions
> and citations to define it better internally.
>
I'm fine with this. I'm just worried about the case where we diverge from
one of the lists. Would be nice to have one canonical list.

> 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.
>
Sounds good to me.

---

From: Dave Rice <[email-masked]>
Date: Tue, 16 Feb 2016 14:14:59 -0500

> On Feb 16, 2016, at 2:01 PM, Frank Galligan <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>> 
>> Element Name: Colour
>> Level:        4
>> ID:           [55][B0]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         m
> [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media description code points", 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-8_2013.zip <http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-8_2013.zip>>.
> 
> So we could have separate bits per channel, but then we would have to define rgb and yuv. Most people know what this is. Basically the information needed is, will the decoded video be 8 bits, 10 bits, 12 bits, 16 bits, ... Maybe I was just trying to be a little too pedantic. I'm fine with removing this sentence.

+1 for removing it.

> if any of the ChromaSubsampling elements are set then that implies that one or more channels will have a different value.

Ah, I had been presuming that you meant bits per channel of a channel's sample, rather than the total of the bits per channel (all samples/pixels of a frame).

> I'm not really sure I follow. If any of the Cb or Cr channels are down sized before encoding, then these elements should be set accordingly. 

I mean that this field is defined as being optional, but there's no indication to say when it should or when it shouldn't be used. This probably applies to most of these fields (and much of the matroska spec).

> I added "Example: For video with 4:2:0 chroma subsampling the ChromaSubsamplingHorz should be set to 1." As pretty much most video is 4:4:4 or 4:2:0 nowadays.
> 
> 
> These elements are only defined because I was trying to handle 4:2:1. Basically this is an old format where the Cr channel is half the size of the Y channel, and the Cb channel is half the size of the Cr channel. The Cb channel is a quarter the size of the Y channel.
> 
> The CbSubsampling* elements were a late edition, right before I sent my previous email. At first I didn't have these elements and had text that 4:2:1 was not supported.

Right. Sorry I wrote my comments before considering 4:2:1, since the fields are quite customized for situations like 4:2:1, perhaps it should be referenced by name as an example.

> How about I change the CbSubsamplingHorz element text too: "The amount of pixels to remove in the Cr and Cb channels for every pixel not removed horizontally." And the CbSubsamplingHorz too: "The amount of pixels to remove in the Cb channel for every pixel not removed horizontally. This is additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma subsampling the ChromaSubsamplingHorz should be set to 1 and CbSubsamplingHorz should be set to 1." Does this help the confusion?

+1

> 16 and 17 is an artifact form the FFmpeg list, but also form looking at FFmpeg CL's I think they are defined in an h265 spec. 18 is a proposed value for HLG.
> 
> 

Sorry there's an open discussion elsewhere on Cellar about expressing float ranges as hexadecimal floating-point literals, so this may be changed later, but the meaning should still be the same.

> 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 <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. Then for values 16, 17, and 18 we could add better descriptions and citations to define it better internally.
> I'm fine with this. I'm just worried about the case where we diverge from one of the lists. Would be nice to have one canonical list.
>  
> 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.
> Sounds good to me.

It's a bit risky. Perhaps for now we should clarify that values 1-15 are defined by ISO/IEC 23001-8 and then give customized definitions for 16, 17, 18.
Dave Rice

---

From: Frank Galligan <[email-masked]>
Date: Tue, 16 Feb 2016 11:21:52 -0800

On Sat, Feb 13, 2016 at 8:22 AM, Jerome Martinez <[email-masked]>
wrote:

> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel <
> [email-masked]> wrote:
>
> [...]
>
> 4: 4:2:1
Jerome, check out the text I added to Dave's email and let me know if you
think that is better.

> <http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf>
> 23001-8.
> need to find another way to provide HLG value, or we say that we don't care
> of MPEG list.
I think the FFmpeg list is just using the 265 list, which is basically a
superset of 23001-8 (or 264 list).

> it is in other specs, but we also say that we don't care of other specs. I
If we forego the other lists, then I agree we should only have one value as
unspecified.

> also use value 18, hoping that MPEG and ISO and ITU will accept value 18
> for HLG.
>

> I would just add a comment about value 18 = HLG.
If everyone else wants to do this, then I wouldn't object. The only reason
I wouldn't want to do this, is that H.265 is a specific codec. I don't want
to confuse people that these values are 265 specific.

> care of the value for HLG (18 or whatever).
This is what I was trying to get at from the start. Do we want to try and
follow another list? It seems like all of the lists try and follow each
other, which I guess is good. But what happens when two diverge?

> 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
I agree if Matroska decides to maintain their own list, we should get rid
of any redundant values.

But I would rather follow another list (or bunch of lists that follow each
other) then try and maintain our own.

---

From: Frank Galligan <[email-masked]>
Date: Tue, 16 Feb 2016 11:24:58 -0800

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

> indicated
> (HLG)"
> 428-1"
> Perhaps
> need
> that
> reference
> this
> why

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.

---

From: Frank Galligan <[email-masked]>
Date: Tue, 16 Feb 2016 11:56:12 -0800

On Tue, Feb 16, 2016 at 11:14 AM, Dave Rice <[email-masked]> wrote:

>> The Matrix Coefficients of the video used to derive luma and chroma
>> values from reg, green, and blue color primaries. For clarity, the value
>> and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC
> with removing this sentence.
>
>
> +1 for removing it.
>
Done

>
> if any of the ChromaSubsampling elements are set then that implies that
> one or more channels will have a different value.
>
>
> Ah, I had been presuming that you meant bits per channel of a channel's
> sample, rather than the total of the bits per channel (all samples/pixels
> of a frame).
>
> I mean that this field is defined as being optional, but there's no
> indication to say when it should or when it shouldn't be used. This
> probably applies to most of these fields (and much of the matroska spec).
>
Ahh, OK. Yeah I have always been under the impression that you shouldn't be
using these elements unless you know what you are doing. Again as you said
that pertains to a lot of the elements in the Matroska spec (as well as
other specs).

We could always expand upon these further in other documents/guides, but
for the spec I just want to accurately represent information that will be
used.

> Right. Sorry I wrote my comments before considering 4:2:1, since the
> fields are quite customized for situations like 4:2:1, perhaps it should be
> referenced by name as an example.
>
>> The table in ISO/IEC 23001-8 for transfer characteristics does not
>> include values or meaning for 16, 17 and 18 as above. Are these values from
>> ffmpeg's list?
>>
>> The colour primaries of the video. For clarity, the value and meanings
>> for TransferCharacteristics are adopted from Table 2 of ISO/IEC
> Sorry there's an open discussion elsewhere on Cellar about expressing
> float ranges as hexadecimal floating-point literals, so this may be changed
> later, but the meaning should still be the same.
>
No problem. I just had it that way for brevity, much like a lot of my other
descriptions. I don't want to add to much text to a cell of the Matroska
spec table. :)

>> (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.
>>
>>
> It's a bit risky. Perhaps for now we should clarify that values 1-15 are
> defined by ISO/IEC 23001-8 and then give customized definitions for 16, 17,
> 18.
>

Following Jerome's comment,  how about this for TransferCharacteristic:
"The transfer characteristics of the video. For clarity, the value and
meanings for TransferCharacteristics 1-15 are adopted from Table 3 of
ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristics 16-17 are adopted from
<265 doc> and 18 is the proposed value of ARIB STD-B67. (0: Reserved, 1:
ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8
curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11:
IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1,
14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17:
SMPTE ST 428-1 18: ARIB STD-B67 (HLG))"

Dave Rice

---

From: Frank Galligan <[email-masked]>
Date: Thu, 18 Feb 2016 11:50:27 -0800

Here is the current proposal, minus the reference to the 265 doc.

Element Name: Colour

Level:        4

ID:           [55][B0]

Mandatory:    -

Multiple:     -

Default:      -

Type:         m

Element Name: MatrixCoefficients

Level:        5

ID:           [55][B1]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Description:  The Matrix Coefficients of the video used to derive luma and

             chroma values from reg, green, and blue color primaries. For

             clarity, the value and meanings for MatrixCoefficients are
adopted

             from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: BT709,

Level:        5

ID:           [55][B2]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

Description:  Number of decoded bits per channel. A value of 0 indicates
that

             the BitsPerChannel is unspecified.

Level:        5

ID:           [55][B3]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of pixels to remove in the Cr and Cb channels for
every

             pixel not removed horizontally. Example: For video with 4:2:0

             chroma subsampling, the ChromaSubsamplingHorz should be set to
1.

Level:        5

ID:           [55][B4]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of pixels to remove in the Cr and Cb channels for
every

             pixel not removed vertically. Example: For video with 4:2:0
chroma

             subsampling, the ChromaSubsamplingVert should be set to 1.

Level:        5

ID:           [55][B5]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of pixels to remove in the Cb channel for every
pixel

             not removed horizontally. This is additive with

             ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma

             subsampling, the ChromaSubsamplingHorz should be set to 1 and

             CbSubsamplingHorz should be set to 1.

Level:        5

ID:           [55][B6]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  The amount of pixels to remove in the Cb channel for every
pixel

             not removed vertically. This is additive with

             ChromaSubsamplingVert.

Level:        5

ID:           [55][B7]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

             collocated , 2: Half)

Level:        5

ID:           [55][B8]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

             collocated , 2: Half)

Element Name: Range

Level:        5

ID:           [55][B9]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

             MatrixCoefficients/TransferCharacteristics)

Element Name: TransferCharacteristics

Level:        5

ID:           [55][BA]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Description:  The transfer characteristics of the video. For clarity, the
value

             and meanings for TransferCharacteristics 1-15 are adopted from

             Table 3 of ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristics

             16-17 are adopted from <265 doc> and 18 is the proposed value
of

             ARIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

             15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1

             18: ARIB STD-B67 (HLG))

Element Name: Primaries

Level:        5

Mandatory:    -

Multiple:     -

ID:           [55][BB]

Default:      2

Type:         u

Description:  The colour primaries of the video. For clarity, the value and

             meanings for Primaries are adopted from Table 2 of

             ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709,

             2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R
BT.470BG,

             6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020,

             10: SMPTE ST 428-1, 22: JEDEC P22 phosphors)

Element Name: MaxCLL

Level:        5

ID:           [55][BC]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  Maximum brightness of a single pixel (Maximum Content Light
Level)

             in candelas per square meter (cd/m²).

Element Name: MaxFALL

Level:        5

ID:           [55][BD]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

Description:  Maximum brightness of a single full frame (Maximum
Frame-Average

             Light Level) in candelas per square meter (cd/m²).

Level:        5

ID:           [55][D0]

Mandatory:    -

Multiple:     -

Default:      -

Type:         m

Level:        6

ID:           [55][D1]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D2]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D3]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

f

Level:        6

ID:           [55][D4]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D5]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D6]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D7]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D8]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 1.0

Default:      -

Type:         f

Level:        6

ID:           [55][D9]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 9999.99

Default:      -

Type:         f

             meter (cd/m²).

Level:        6

ID:           [55][DA]

Mandatory:    -

Multiple:     -

Range:        0.0 <= f <= 999.9999

Default:      -

Type:         f

             meter (cd/m²).

<reference to h265 doc)

On Tue, Feb 16, 2016 at 11:56 AM, Frank Galligan <[email-masked]>
wrote:

>>> less for
> Ahh, OK. Yeah I have always been under the impression that you shouldn't
> be using these elements unless you know what you are doing. Again as you
> said that pertains to a lot of the elements in the Matroska spec (as well
> as other specs).
>
> No problem. I just had it that way for brevity, much like a lot of my
> other descriptions. I don't want to add to much text to a cell of the
> Matroska spec table. :)
>
>
>> Done
>>
>>
>>>
>>> Default:      -
>>> Type:         f

---

From: Dave Rice <[email-masked]>
Date: Fri, 19 Feb 2016 14:59:41 -0500

Hi all,

Working with the IETF Cellar Working Group, https://datatracker.ietf.org/wg/cellar/charter/, Frank Galligan has drafted a proposal for the management of metadata in Matroska to accommodate information on color, full/broadcast range, HDR metadata, chroma subsampling patterns and other information. I'm forwarding it to ffmpeg-devel and libav-devel to encourage any additional comments. The background discussion thus far is visible at https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposal <https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposal>. For context, the structure for Matroska element definitions is currently in draft here: https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema-element-attributes <https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema-element-attributes>.

> Begin forwarded message:
> 
> From: Frank Galligan <[email-masked]>
> Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal
> Date: February 18, 2016 at 2:50:27 PM EST
> To: Dave Rice <[email-masked]>
> Cc: Jerome Martinez <[email-masked]>, Discussion about the current and future development of Matroska <[email-masked]>, [email-masked]
> 
>               clarity, the value and meanings for MatrixCoefficients are adopted
> Description:  Number of decoded bits per channel. A value of 0 indicates that
> Description:  The amount of pixels to remove in the Cr and Cb channels for every
>               chroma subsampling, the ChromaSubsamplingHorz should be set to 1.
> 
> 
> Description:  The amount of pixels to remove in the Cr and Cb channels for every
>               pixel not removed vertically. Example: For video with 4:2:0 chroma
> Description:  The amount of pixels to remove in the Cb channel for every pixel
> Description:  The amount of pixels to remove in the Cb channel for every pixel
> Description:  The transfer characteristics of the video. For clarity, the value
>               16-17 are adopted from <265 doc> and 18 is the proposed value of
>               2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG,
> Description:  Maximum brightness of a single pixel (Maximum Content Light Level)
> Description:  Maximum brightness of a single full frame (Maximum Frame-Average

[...]

Those interested in standardization efforts for EBML, Matroska, and FFV1 are encouraged to join the CELLAR Working Group. https://datatracker.ietf.org/wg/cellar/charter/ <https://datatracker.ietf.org/wg/cellar/charter/>.

Best Regards,
Dave Rice

---

From: Michael Niedermayer <[email-masked]>
Date: Fri, 19 Feb 2016 22:45:38 +0100

Hi

>              the BitsPerChannel is unspecified.

what would this be set to for old 16bit rgb, that is 5 bit red
6 bit green, 5 bit blue rawvideo.
This maybe does not matter and iam not strongly suggesting to add it,
rather i want to point it out so its not unintentionally forgotten

[...]

>              not removed vertically. This is additive with

What if Cr is subsampled more than Cb ?
That too is rather obscure, but theres code in FFmpeg to handle such
jpegs, so i suspect this case while very rare is not entirely non
existent ...

> Description:  How Chroma is subsampled vertically. (0: Unspecified, 1: Top

iam not sure this is enough to specify all variants
for 4:2:0 alone there are a few different variants
theres mpeg1 style
mpeg2 progressive and interlaced
the mpeg2/mpeg4 style also differs from itself if the image is fliped right-left
cropping 1 or 2 lines of the top of mpeg2 yuv420 also results in
different variants

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire