Need to add EOTF support for HDR

[johnpallett]

'bt709', indicating ITU-R BT.1886 support
'smpte2084', to indicate SMPTE 2084 EOTF support
‘arib-std-b67’, to indicate ARIB STD-B67 support

[mwatson2]

#13 is a dup of this.

HDR10 is a broader term, incorporating transfer function, color space, bit depth and metadata. The transfer function used by HDR10 is PQ (SMPTE 2084).

We should probably align the terms with those used in video codec signaling.

We should be clear that transfer function support is a renderer function which may depend on video codec (or even video decoding pipeline, hw vs sw etc.) and may differ between video a graphics planes.

[johnpallett]

Updated list above to more accurately reflect valid EOTF options

[mounirlamouri]

Disclaimer: I might be confusing various things here because I'm not familiar with some details of EOTF.

@mwatson2 as you pointed, EOTF support is a combination of multiple things. Can we expect decoder support to be handled by the codec string? For example, my understanding is that VP9.2 would imply some EOTF which means that support for it would imply the EOTF support. Did I understand this correctly? If that's correct, what information would be missing for a full EOTF support? Let's put aside the video/graphics differences.

[mwatson2]

@mounirlamouri HDR10 is a broader term. EOTF, or more generally transfer function or transfer characteristics, is specifically the function used to map from pixel code points to luminance.

Actually, the codec doesn't care about the EOFT (or the color primaries for that matter) - the codec just compresses arrays of pixel code point values without caring what they mean. But the transfer characteristics and color primaries are usually signalled with the codec bitstream in some way and it makes sense to ask whether the video decoder supports those things.

However, the device may support decoding of video data with PQ EOTF and 2020 primaries but the display may not support rendering them (for example, an HDR-capable device attached to a non-HDR capable display over HDMI or DisplayPort). So we need these as separate capabilities for video rendering specifically.

[jdsmith3000]

The current spec is built around separating decoding/media pipeline from screen, which acknowledges the need to query for capabilities on both.

[mwatson2]

I think this issue is addressed by the current proposal in PR #124 and we should close it.