Clarify the `colr` box - Githubissues

AOMediaCodec / av1-isobmff

Official specification of the AOM group for the carriage of AV1 in ISOBMFF

https://AOMediaCodec.github.io/av1-isobmff

64 stars 16 forks source link

Clarify the `colr` box #167

Closed wantehchang closed 1 year ago

wantehchang commented 1 year ago

Fix https://github.com/AOMediaCodec/av1-isobmff/issues/126.

Preview | Diff

cconcolato commented 1 year ago

Comments:

we should indicate why the information is "authoritative" (because of ISOBMFF)
we note that for CMAF video tracks that are NALU-based, the colr box is mandatory but that there is no such provision in general for video tracks. We should add it to our CMAF section and request MPEG to consider requiring the box for non-NALU video tracks.

cconcolato commented 1 year ago

We think the change is not breaking any existing content:

old files without colr, we are not saying anything new in this PR, files remain valid or invalid
old files with colr and flag=1, the change is from SHALL to SHOULD, so the old compliant files remain compliant. Old invalid files (used for negative testing) become valid.
old files with colr and flag=0, the old spec was silent about it. With this PR all files become valid but clarifying that container-level information overrides stream-level information.

cconcolato commented 1 year ago

We could improve by saying:

when SH does not have any 2, then we should NOT override the values but when a 2 value is used, then MAY/SHOULD be overriden.

podborski commented 1 year ago

After syncing with our guys on this. SH and colr SHALL match if SH is not signaling unspecified values. For any 2 (unspecified in SH) we agree with Cyril, the container level signaling could specify what it is. We also need to highlight in the AV1 ISOBMFF spec the sentence from ISOBMFF spec which says that container level over-rides the information in the bitstream.

In addition to that full range signaling SHALL match whatever is in the bitstream.

wantehchang commented 1 year ago

Dimitri: Just wanted to confirm I understood your comment correctly. You don't want the colr box to contradict any specified value (i.e., != 2) in the AV1 sequence header OBU, even though ISOBMFF allows that. Is this correct?

podborski commented 1 year ago

Dimitri: Just wanted to confirm I understood your comment correctly. You don't want the colr box to contradict any specified value (i.e., != 2) in the AV1 sequence header OBU, even though ISOBMFF allows that. Is this correct?

Correct.

cconcolato commented 1 year ago

The sentence in ISOBMFF indicating that the container level information has precedence is in section 12.1.5.1 "Colour information Definition" of the 7th edition:

If colour information is supplied in both this box, and also in the video bitstream, this box takes precedence, and over-rides the information in the bitstream.

We should simply rephrase it and point to the "Colour Information" box definition (rather than to a specific section, as this might change in future versions)

cconcolato commented 1 year ago

As discussed in the meeting:

If the colr box is present:

for colour_primaries, transfer_characteristics, and matrix_coefficients, if a field is specified with a value different than 2 in the Sequence Header OBU (in the configOBUs field or in the associated samples), then the value of that field in the colr box SHALL match the value in the Sequence Header OBU

if the value any of colour_primaries, transfer_characteristics, and matrix_coefficients is NOT specified or specified with a value equal to 2 in the Sequence Header OBU, then the value of that in the colr box MAY be different and the value in the colr box overrides the value in the bitstream, as specified in the ColourBox definition in ISOBMFF

wantehchang commented 1 year ago

@cconcolato @podborski I made the changes as you suggested. Please review the new version of this PR. Thanks.