[FFmpeg-devel] [PATCH] h264: Add support for alternative transfer characterics SEI

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 4:52 PM, Vittorio Giovara
<vittorio.giovara at gmail.com> wrote:
>> 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.

The decoder doesn't need to support anything about the transfer. But
anything afterwards might.

If I want to render this video on screen, say a SDR screen, or my
player is just not HDR capable (yet), what transfer do I use? The
value avcodec gives me has not much meaning in that case (because I
can't deal with HLG yet), and the original "legacy" value meant to be
used in these cases was overriden and lost.

- Hendrik