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

[Vittorio Giovara]

> 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.

Uh? The original "legacy" value has no meaning, bt709, bt2020, and the
SDR part of HLG are all the same.
The libavcodec decoder "prefers" using the alternative transfer
because it is the "real one", and ffmpeg offers means to support it
correctly (zscale).
As long as you don't use any odd transfer (like log316) or the ones
that are typically used for SD content, it will render the SDR
transfer correctly.
I believe this is a safe assumption for a software system (like
ffmpeg), less so for a hardware one (like a broadcaster's decoder),
hence the SEI dance.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 4:52 PM, Vittorio Giovara
 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

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

[Vittorio Giovara]

> 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.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

On Tue, Aug 8, 2017 at 4:36 PM, Vittorio Giovara
 wrote:
> The use of this SEI is for backward compatibility in HLG HDR systems:
> older devices that cannot interpret the "arib-std-b67" transfer will
> get the compatible transfer (usually bt709 or bt2020) from the VUI,
> while newer devices that can interpret HDR will read the SEI and use
> its value instead.
>

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...?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Vittorio Giovara]

The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.

Signed-off-by: Vittorio Giovara 
---
 libavcodec/h264_sei.c   | 11 +++
 libavcodec/h264_sei.h   |  9 -
 libavcodec/h264_slice.c |  6 ++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index a7e627eba3..889bea2ee0 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -382,6 +382,14 @@ static int decode_green_metadata(H264SEIGreenMetaData *h, 
GetBitContext *gb)
 return 0;
 }
 
+static int decode_alternative_transfer(H264SEIAlternativeTransfer *h,
+   GetBitContext *gb)
+{
+h->present = 1;
+h->preferred_transfer_characteristics = get_bits(gb, 8);
+return 0;
+}
+
 int ff_h264_sei_decode(H264SEIContext *h, GetBitContext *gb,
const H264ParamSets *ps, void *logctx)
 {
@@ -437,6 +445,9 @@ int ff_h264_sei_decode(H264SEIContext *h, GetBitContext *gb,
 case SEI_TYPE_GREEN_METADATA:
 ret = decode_green_metadata(>green_metadata, gb);
 break;
+case SEI_TYPE_ALTERNATIVE_TRANSFER:
+ret = decode_alternative_transfer(>alternative_transfer, gb);
+break;
 default:
 av_log(logctx, AV_LOG_DEBUG, "unknown SEI type %d\n", type);
 }
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index da3b391860..5f5d895e89 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -32,7 +32,8 @@ typedef enum {
 SEI_TYPE_RECOVERY_POINT = 6,   ///< recovery point (frame # to 
decoder sync)
 SEI_TYPE_FRAME_PACKING  = 45,  ///< frame packing arrangement
 SEI_TYPE_DISPLAY_ORIENTATION= 47,  ///< display orientation
-SEI_TYPE_GREEN_METADATA = 56   ///< GreenMPEG information
+SEI_TYPE_GREEN_METADATA = 56,  ///< GreenMPEG information
+SEI_TYPE_ALTERNATIVE_TRANSFER   = 147, ///< alternative transfer
 } SEI_Type;
 
 /**
@@ -144,6 +145,11 @@ typedef struct H264SEIGreenMetaData {
 uint16_t xsd_metric_value;
 } H264SEIGreenMetaData;
 
+typedef struct H264SEIAlternativeTransfer {
+int present;
+int preferred_transfer_characteristics;
+} H264SEIAlternativeTransfer;
+
 typedef struct H264SEIContext {
 H264SEIPictureTiming picture_timing;
 H264SEIAFD afd;
@@ -154,6 +160,7 @@ typedef struct H264SEIContext {
 H264SEIFramePacking frame_packing;
 H264SEIDisplayOrientation display_orientation;
 H264SEIGreenMetaData green_metadata;
+H264SEIAlternativeTransfer alternative_transfer;
 } H264SEIContext;
 
 struct H264ParamSets;
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 4e7eba4adb..ebff7b33e3 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1287,6 +1287,12 @@ static int h264_export_frame_props(H264Context *h)
 h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
+if (h->sei.alternative_transfer.present &&
+
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
 &&
+h->sei.alternative_transfer.preferred_transfer_characteristics != 
AVCOL_TRC_UNSPECIFIED) {
+h->avctx->color_trc = cur->f->color_trc = 
h->sei.alternative_transfer.preferred_transfer_characteristics;
+}
+
 return 0;
 }
 
-- 
2.13.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel