Subject: [Cellar] Colour Format proposal

From: Frank Galligan <[email-masked]>
Date: Tue, 5 Jan 2016 13:12:24 -0800

Hello all,

I would like to bring up the discussion again about better representing the
color format of video. It looks like the discussion was started here [1] on
matroska-devel list. I think we need to add some Colour elements so
Matroska files can (potentially) more faithfully represent the video source
on many devices. Here is a proposal I created to start from:

Element Name: Colour
Level:        4
ID:           [55][A0]
Mandatory:    -
Multiple:     -
Default:      -
Type:         m
Description:  Settings describing the colour format.

Element Name: ColourMatrix
Level:        5
ID:           [55][A1]
Mandatory:    ma
Multiple:     -
Default:      2
Type:         u
Description:  ColourMatrix 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)

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.

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)

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)

Element Name: TransferFunction
Level:        5
ID:           [55][A6]
Mandatory:    ma
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))

Element Name: Primaries
Level:        5
Mandatory:    -
Multiple:     -
ID:           [55][A7]
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)

Element Name: MaxCLL
Level:        5
ID:           [55][A8]
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][A9]
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][B0]
Mandatory:    -
Multiple:     -
Default:      -
Type:         m
Description:  SMPTE 2086 mastering data.

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

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

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

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

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

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

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

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

Element Name: LuminanceMax
Level:        6
ID:           [55][B9]
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

Element Name: LuminanceMin
Level:        6
ID:           [55][BA]
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

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.

Thanks,
Frank

[1]
http://lists.matroska.org/pipermail/matroska-devel/2015-September/004778.html

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 05 Jan 2016 13:19:52 -0800

Frank Galligan wrote:
> I would like to bring up the discussion again about better representing
> the color format of video. It looks like the discussion was started here

Nothing describing chroma siting?

---

From: Michael Bradshaw <[email-masked]>
Date: Tue, 5 Jan 2016 13:33:32 -0800

> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)
FFmpeg supports more subsampling schemes like 4:1:0, 4:1:1, and 4:4:0.

Additionally, these formats assume 3-channel pixel formats. What about an
alpha-channel or other color spaces with > 3 channels?

Perhaps a per-channel master element could exist that contains subsampling
and bit information?

---

From: Dave Rice <[email-masked]>
Date: Tue, 5 Jan 2016 16:54:04 -0500

> On Jan 5, 2016, at 4:12 PM, Frank Galligan <[email-masked]> wrote:
> 
> Hello all,
> 
> I would like to bring up the discussion again about better representing the color format of video. It looks like the discussion was started here [1] on matroska-devel list. I think we need to add some Colour elements so Matroska files can (potentially) more faithfully represent the video source on many devices. Here is a proposal I created to start from:
> 
> 
> Element Name: Colour
> Level:        4

Please clarify the proposed Parent Element.

[...]

>               2: Unspecified,

Any reason for "Unspecified" to be #2 rather than #0? Do these numbers align with a FFmpeg/libav enumeration?

[...]

> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)

This is mandatory, but there is no Unspecified option. If I want to clarify that a contained 4:1:1 DV stream uses bt.601 there is no valid way to say this, since if ColourMatrix is used then ChromaSubsampling must also be used, but there is no options that fit 4:1:1.

[...]

Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 5 Jan 2016 22:58:56 +0100

Thanks for your detailed proposal.
It is a lot of items, I am not expert in all domains but I have some 
comments:

Le 05/01/2016 22:12, Frank Galligan a écrit :
> Hello all,
>
> I would like to bring up the discussion again about better 
> representing the color format of video. It looks like the discussion 
> was started here [1] on matroska-devel list. I think we need to add 
> some Colour elements so Matroska files can (potentially) more 
> faithfully represent the video source on many devices. Here is a 
> proposal I created to start from:
>
>
> Element Name: Colour
> Level:        4
> ID:           [55][A0]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         m
>               2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: 
> SMPTE 170M,

Name: MatrixCoefficients (or Matrix. You don't use "Colour" with 
"Primaries" element, so I would not use it here too)
See my comment about FFmpeg values at the end of the email.

>               channels depending on the ColourFormat and 

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)

> 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).

Or to remove entirely this element, because it is a technical piece of 
information and raw stream must contain it somewhere else (else it is 
not decodable)
(I am aware it is not the case for uncompresse data, but we need the 4CC 
in that case for the order of pixel, so we get chroma subsamping this way)

> ColourMatrix/TransferFunction,

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

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

See my comment about FFmpeg values at the end of the email.

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

See my comment about FFmpeg values at the end of the email.

> Description:  Maximum brightness of a single full frame in candelas 
> per square
>               meter (cd/m²).
>
>

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.
there are also other colour ideas with e.g. EBU Tech 3349.

> 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. 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)

Jérôme

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 5 Jan 2016 23:08:48 +0100

> align with a FFmpeg/libav enumeration?

Similar to Apple QuickTime nclc specs, ISO/MPEG Video / AVC / HEVC, ITU 
H.26x.
I recommend to not change that.

> This is mandatory, but there is no Unspecified option. If I want to 
> clarify that a contained 4:1:1 DV stream uses bt.601 there is no valid 
> way to say this, since if ColourMatrix is used then ChromaSubsampling 
> must also be used, but there is no options that fit 4:1:1.

+1 (must be optional or unknown possibility, and more cases)

Jérôme

---

From: Michael Niedermayer <[email-masked]>
Date: Wed, 6 Jan 2016 03:14:25 +0100

[...]
> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)

i suggest to store 2 integers, one for vertical and one for horizontal
chroma subsampling, that allows indicating any subsampling
and its a logic and simple way to indicate the subsampling

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

---

From: Frank Galligan <[email-masked]>
Date: Wed, 6 Jan 2016 12:19:53 -0800

On Tue, Jan 5, 2016 at 1:19 PM, Timothy B. Terriberry <[email-masked]>
wrote:

> Sorry took it out. Yes we need this.

Should we define something that is more extensible? Or just go with the
common sittings? I.e. co-located luma (0,0), sitting for Mpeg2, sitting
Jpeg,...

---

From: Frank Galligan <[email-masked]>
Date: Wed, 6 Jan 2016 13:46:44 -0800

> FFmpeg supports more subsampling schemes like 4:1:0, 4:1:1, and 4:4:0.
Yes all the rest should have been included. Looking over some of the other
messages we could change too:
Element Name: ChromaSubsampling
Level:        5
ID:           [55][A3]
Mandatory:    ma
Multiple:     -
Default:      0
Type:         u
Description:  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 2: 4:2:2, 3: 4:2:1, 4:
4:2:0, 5: 4:1:1, 6: 4:1:0, 7: 3:1:1)

> alpha-channel or other color spaces with > 3 channels?
We could add another element to signify an alpha channel. Are there any
common formats where the alpha is subsampled?

> Perhaps a per-channel master element could exist that contains subsampling
This seems like a little overkill to me, but if other people want to do it
this way, then it is fine with me.

---

From: Frank Galligan <[email-masked]>
Date: Wed, 6 Jan 2016 14:00:35 -0800

On Tue, Jan 5, 2016 at 1:54 PM, Dave Rice <[email-masked]> wrote:

> [1] on matroska-devel list. I think we need to add some Colour elements so
Sorry. The parent element would be Video [E0].

> align with a FFmpeg/libav enumeration?
Yes (and what Jerome mentioned)

> clarify that a contained 4:1:1 DV stream uses bt.601 there is no valid way
> to say this, since if ColourMatrix is used then ChromaSubsampling must also
> be used, but there is no options that fit 4:1:1.
>
> [...]
>
That was an omission on my part. I added Unspecified as well as 4:1:1 in a
previous email.

---

From: Frank Galligan <[email-masked]>
Date: Wed, 6 Jan 2016 14:30:41 -0800

> It is a lot of items, I am not expert in all domains but I have some
Neither am I, but I figured we might as well start from a proposal and
iterate from there.

> "Primaries" element, so I would not use it here too)
 Sounds good to me.

> 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?

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.

> I like the way it is done in FFV1, except the power of 2 (so 3 can not be
> expressed).
I'm fine with coming up with a more extensible solution (Micheal asked for
that as well).

> I propose 0: unspecified 1: Broadcast range 1: Full range
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.

> "Tone Curve"), e.g. "same as transfer characteristic", Scene Linear, S-Log,
> Cine-Log, Log-C...
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.

> 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.

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 7 Jan 2016 00:00:31 +0100

Le 06/01/2016 23:30, Frank Galligan a écrit :
>
>
> On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     It is a lot of items, I am not expert in all domains but I have
>     some comments:
>
>>     Description:  Number of bits per channel. This number may be less
>>     for specific
> 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 you don't author the video (e.g. when you transcode a video from a 
source you don't handle and without such information).
Just take any QuickTime file with FFV1, you want to move to 
Matroska/FFV1, you have Colour Primaries from QuickTime container so you 
want to keep it so you save this colour Element (else you lose 
metadata), how should be filled this mandatory element.
FFV1 bit depth (the one we get from FFV1) is not always the real number 
of bits per channel (it is possible to transform a 8-bit stream to a 
12-bit stream, nothing prevents that), so I don't see where is this 
piece of information.

That said, I am now not sure about the purpose of this element:
- do you mean the real count of valid bits (e.g. this is a 8-bit stream 
oversampled to 10-bit)? In that case, we can not always know if it is 
oversampled and having it mandatory without "unknown" info is blocking.
- do you mean the bits per channel technically in the bitstream? I don't 
see any reason to have such element (useless, we get the info from the 
bitstream, risk of incoherencies)

>
> 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.
>
> [...]
>
>
>
>>
>>
>>
>>     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.
>

FFmpeg is made by volunteers, and some parts (e.g. colours) may be not 
so perfect (there was another example in other emails: DPX. the list is 
different, FFmpeg does not support it).
Thinking more about it, maybe we need 2 bytes (or something else): the 
source of the list (MPEG, DPX...) + the list itself.
I am reluctant to create a list from scratch, developers may have issues 
for doing the mapping between lists from different sources.
Anyway, if we create our own list, the question is what to do when MPEG 
add an element to their list: will we be fast enough to update our list 
before people complain that they can not map the new element from their 
source to Matroska? MPEG has numbers 11..255 reserved for future usages, 
I think it is good to reserve something for the future usages from MPEG.
Maybe I go too far and a Matroska-specific list, based on FFmpeg (But 
FFmpeg is not the "reference decoder"...), is enough.

List from H.265 is available at:
https://www.itu.int/rec/T-REC-H.265-201504-I/en
starting page 347 (no paywall)

>     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)
>

---

From: "Peter B." <[email-masked]>
Date: Thu, 07 Jan 2016 19:09:01 +0100

> I propose 0: unspecified 1: Broadcast range 1: Full range

Just for the sake of completeness, I think you have a small typo:
You proposed:

// ------------------
0: default
1: broadcast range
1: full range
// ------------------

I guess you meant "2" for "full range", as it was before?

Regards,
Pb

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 7 Jan 2016 19:10:30 +0100

> Just for the sake of completeness, I think you have a small typo:

Oops :).

// ------------------
0: unspecified
1: broadcast range
2: full range
// ------------------

and default is 0.

---

From: Dave Rice <[email-masked]>
Date: Thu, 7 Jan 2016 13:14:01 -0500

> On Jan 7, 2016, at 1:10 PM, Jerome Martinez <[email-masked]> wrote:
> 

Perhaps a statement is needed on when the value is applicable. For instance is 'broadcast range' with a JPEG2000-RCT encoding valid?

I suggest adding a citation to explain how 'broadcast range' and 'full range' are defined.
Dave

---

From: Steve Lhomme <[email-masked]>
Date: Thu, 14 Jan 2016 13:04:34 +0100

> 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.

>> h_chroma_subsample and v_chroma_subsample; a ratio per plane with any number
>> of plane, think to alpha channel with a subsampling).
>
>> Matrix, Range, and Primaries, I'm pretty much using values that map directly
>> to values defined in FFmpeg.
>>
>>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman

---

From: Frank Galligan <[email-masked]>
Date: Fri, 22 Jan 2016 14:54:26 -0800

On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme <[email-masked]> wrote:

> the
> be
> number
> S-Log,

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.
- 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?

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

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,

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.

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

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

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)

Level:        5

ID:           [55][A7]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Element Name: Primaries

Level:        5

Mandatory:    -

Multiple:     -

ID:           [55][A8]

Default:      2

Element Name: MaxCLL

Level:        5

ID:           [55][A9]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

             meter (cd/m²).

Element Name: MaxFALL

Level:        5

ID:           [55][AA]

Mandatory:    -

Multiple:     -

Default:      -

Type:         u

             meter (cd/m²).

Level:        5

ID:           [55][D0]

Mandatory:    -

Multiple:     -

Default:      -

Type:         m

Level:        6

ID:           [55][D1]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][D2]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][D3]

Mandatory:    -

Multiple:     -

Default:      -

f

Level:        6

ID:           [55][D4]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][D5]

Mandatory:    -

Multiple:     -

Default:      -

f

Level:        6

ID:           [55][D6]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][D7]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][D8]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][D9]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f

Level:        6

ID:           [55][DA]

Mandatory:    -

Multiple:     -

Default:      -

Type:         f