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
Clarifications on mdcv box #138
Comments
If it's not clear, we should clarify it. Let's take examples. If a luminance value is 1 cd/m^2:
So the coded value is not the same but the actual value (in cd/m^2) is the same. I think that's why the spec uses "match" and not "equal". The same applies for chromaticity values. The MPEG specifications uses 0.00002 increments and limits the value to the range 0 to 50000. The AOM specification uses a 0.16 fixed-point representation. So a CIE value of 0.6900 would be coded in MPEG-space as 0.6900/0.00002 = 34500, i.e. 0x86C4, while in AOM-space it would be coded 0.6900*65536 = 45,219.84 ~= 0xB0A4. |
I think 'match' is misleading here, as it could be interpreted as 'equal', especially since there are several occurrences of 'shall match' in this text for which the meaning is 'equal' |
I think it is useful to add a note/warning about the different units and encodings used in the AV1 HDR MDCV metadata OBU and the HEVC mastering display colour volume SEI message. Also, it seems that certain fractional values cannot be represented exactly in either format. For example, consider a luminance value of 1.1 cd/m^2. This luminance value can be coded exactly in the SEI message but cannot be coded exactly in the MDCV OBU. So it is not clear what it means for values to "match" or be "equal". |
The group agrees to add a note, to clarify the precision aspect and highlight that coded values are not the same as in an SEI message. |
The groups agrees to update the word "match" to "equal (except for precision issues, see note below)". And also to remove the extraneous "of". |
In "their values SHALL match", change the word "match" to "equal (except for precision issues, see note below)". Exchange METADATA_TYPE_HDR_CLL and METADATA_TYPE_HDR_MDCV so that they correspond to mdcv and clli in the right order. Fix AOMediaCodec#138.
Cyril: After reading this issue again,I realized that it's not good to change "match" to "equal", because that's exactly what jeanlf found confusing (see the second comment of jeanlf). One solution is to change "values" to "actual values" or "decoded values" (as opposed to coded values). |
In "their values SHALL match", change the word "match" to "equal (except for different binary representations and precision issues, see the second note below)". Exchange METADATA_TYPE_HDR_CLL and METADATA_TYPE_HDR_MDCV so that they correspond to mdcv and clli in the right order. Fix AOMediaCodec#138.
In "their values SHALL match", change the word "match" to "equal (except for different binary representations and precision issues, see the second note below)". Exchange METADATA_TYPE_HDR_CLL and METADATA_TYPE_HDR_MDCV so that they correspond to mdcv and clli in the right order. Fix AOMediaCodec#138.
Split the requirements on 'clli' and 'mdcv' into separate list items so that we can state the more complicated requirements that only apply to 'mdcv'. Fix AOMediaCodec#138.
The spec says:
For mdcv, this is not very clear. Does this mean that the values shall be exactly the same values as in the METADATA_TYPE_HDR_MDCV OBU, or shall be rewritten into the binary representation of the corresponding HEVC/VVC SEIs ?
The text was updated successfully, but these errors were encountered: