On Tue, Aug 8, 2017 at 4:52 PM, Vittorio Giovara <vittorio.giov...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
