signaling of HDR content through MPD's AdaptationSet essential properties

[nlsdvl]

I have been encoding the clg1 test vectors and found the mezzanine files have been encoded as explicit HLG, as opposed backward compatible HLG.

More specifically, the content is encoded with the following libx265 options:
-colorspace bt2020nc -color_primaries bt2020 -color_trc arib-std-b67

which results in VUI with transfer_characteristics = 18 and no alternative_transfer_characteristics SEI.

This configuration is fine for the mezzanine, and may be used when the content is known to be played back by a player that is known to handle it properly.

The otherwise recommended way to encode such content for distribution is to signal transfer_characteristics = 14 (BT.2020, functionally equivalent to BT.709), with SEI of type 147 signaling alternative_transfer_characteristics = 18

The clg1 profile definition comes with requirements for querying the content capability, but the requirements are lose regarding how the properties are signaled in the MPD. Sorry if I missed informations from a coordination call here.

I have been looking at recommendations from ETSI TS 103 285 V1.4.1 - Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks

While investigating this issue, I also found that signaling the HDR metadata through EssentialProperties might result in dashjs rejecting the adaptation sets : Dash-Industry-Forum/dash.js#4384 (comment)

cc @rbouqueau @jpiesing

[nicholas-fr]

Thanks for raising this point, I see we did not agree on which signalling to use for the HLG10 test vectors.

While there is indeed no strict dependency on the mezzanine for this, it may be helpful to re-encode the HLG10 streams, to ensure they reflect the same VUI/SEI HLG signalling as intended for the final test vectors.

Looking at the sparse matrix, I propose to use the backwards compatible signalling for all HEVC HLG10 test vectors except 42 (all HEVC content options different from stream 41).

While the use of non-bc transfer_characteristics = 18 is not part of the DVB HEVC bitstream profiles, it is part of the WAVE/CMAF HLG10/clg1 profile, so I believe having at least 1 test vector using it makes sense (as originally proposed here too).

Once we've agreed on how to proceed, I can re-encode the HLG10 streams with the backwards compatible signalling as needed.

[nlsdvl]

For the purpose of test content generation, it is not critical to have HLG signaled as backward compatible in the mezzanine files.

However it is important that the sparse matrix explicits the requirement for individual test vectors to be generated with the proper configuration.