> Following their logic, what if I can't deal with HLG yet, and I want
> the original transfer?
> Maybe it should be exported somehow, or have an option to not use the
> alternate one, or something?
> One of the key points of HLG is compatibility with non-HDR systems, so
> if the bitstream already offers this choice, maybe so should we,
> without having to "guess" if its bt709 or bt2020 or...?
You don't have to guess anything with HGL, the backward compatible
slope supports both.
I believe this system was designed for decoders that discard unknown
or unsupported frame properties: such a decoder will read bt709
instead of "unknown" so it be able to render the SDR version
correctly, rather than let the decoder choose the transfer in an
uncontrolled manner. An updated decoder can read this SEI and apply
the proper transfer: if the decoder supports HDR, then it will use the
full HLG, otherwise it will use the compatible slope, which matches
the bt709 one (or bt2020).
I don't think there is a need for extra options, because the
libavcodec decoder can detect and support correctly both transfers.
It's the encoder that needs to be updated for the case that you
mention, but I haven't found encoders interacting with color
properties in libavcodec.
ffmpeg-devel mailing list