-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify the colr
box
#167
Clarify the colr
box
#167
Conversation
de318e5
to
5f0e3ab
Compare
Comments:
|
We think the change is not breaking any existing content:
|
We could improve by saying:
|
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. |
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. |
5f0e3ab
to
c734dc4
Compare
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:
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) |
As discussed in the meeting:
|
c734dc4
to
397984b
Compare
@cconcolato @podborski I made the changes as you suggested. Please review the new version of this PR. Thanks. |
Fix #126.
Preview | Diff