[FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

Neil Birkbeck neil.birkbeck at gmail.com
Fri Feb 5 03:05:08 CET 2016


According to the ITU-T H.265 v3, in Table D - 1, the persistence scope
of the mastering display metadata is "The Coded Video Sequence (CVS)
containing the SEI message". So I guess we want to clear when we start
the next CVS, so I guess when we see the next IDR frame.

Given that the SEI comes before the IDR, I don't see a great way to do
this aside from initializing the flag to 2 and decrementing (when > 0)
when we see an IDR.

On Tue, Feb 2, 2016 at 7:13 AM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Mon, Feb 01, 2016 at 12:11:10PM -0800, Neil Birkbeck wrote:
>> Please see updated patch.
>>
>> On Mon, Jan 25, 2016 at 11:39 PM, Neil Birkbeck <neil.birkbeck at gmail.com> wrote:
>> > I guess png is another example; 100000 is the denominator for the 32-bit
>> > integer:
>> > https://github.com/FFmpeg/FFmpeg/blob/b58cfa616c169c90166938608e7135cdab5820e0/libavcodec/pngenc.c#L290
>> >
>> > In the standards, the primaries and white point coords are usually only
>> > referenced in 2-4 significant figures (ISO/IEC 23001-8:2013(E) has them all
>> > in one doc). The display primaries can be different from these, but I don't
>> > think you'd see them measured with any more precision (more precision is
>> > unlikely to matter for this metadata anyway).
>> >
>> > It seems that most are in favor of AVRational, so I'll change the avutil
>> > struct float internal fields to rational.
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Jan 25, 2016 at 1:43 PM, Hendrik Leppkes <h.leppkes at gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Jan 25, 2016 at 10:37 PM, Michael Niedermayer
>> >> <michael at niedermayer.cc> wrote:
>> >> > On Fri, Jan 22, 2016 at 02:54:21PM -0800, Neil Birkbeck wrote:
>> >> >> Hmm. I don't have a good idea of how likely it is for this conversion
>> >> >> to
>> >> >> float (by dividing a constant) to not be bit-exact on different
>> >> >> architectures (compilers?) when there should not be any other math
>> >> >> transforming the metadata (other than the conversion back to the
>> >> >> integer
>> >> >> coding for cases like hevc, which for a given architecture is possible
>> >> >> without loss). The fact that this could happen at all does make it
>> >> >> annoying
>> >> >> in terms of bit-exact test expectations across arch, and this is the
>> >> >> main
>> >> >> concern, right? (for this type of metadata, it is really a hint to
>> >> >> TVs/algorithms, and some will ignore it altogether)
>> >> >
>> >> > bitexactness is one concern, also theres the issue with what is ideally
>> >> > correct.
>> >> > that is what are the ideal values dictated by various standards
>> >> > that hardware (cammeras, ...) aim at ?
>> >> > are these rational or float or what can represent them better ?
>> >> >
>> >>
>> >> Both HEVC and the HDMI Info Frames use fixed-point integers (the same
>> >> scales too, apparently), I do not know of the formats anything else
>> >> uses.
>> >> Maybe we should be using AVRationals?
>> >>
>> >> I would argue that MKV storing floats is a terrible idea, and someone
>> >> should bonk them over the head and store fixed point as well.
>> >>
>> >> - Hendrik
>> >> _______________________________________________
>> >> ffmpeg-devel mailing list
>> >> ffmpeg-devel at ffmpeg.org
>> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>> >
>
>>  hevc.c     |   46 ++++++++++++++++++++++++++++++++++++++++++++++
>>  hevc.h     |    7 +++++++
>>  hevc_sei.c |   22 ++++++++++++++++++++++
>>  version.h  |    2 +-
>>  4 files changed, 76 insertions(+), 1 deletion(-)
>> a1660d647add89f41e8ed85f8bc26eb4fb36379b  0001-lavc-hevc-Parse-SEI_TYPE_MASTERING_DISPLAY_INFO-and-.patch
>> From 345db2caf7cac5c0acfb74501b6db9bd57e66f7d Mon Sep 17 00:00:00 2001
>> From: Neil Birkbeck <neil.birkbeck at gmail.com>
>> Date: Thu, 21 Jan 2016 10:56:50 -0800
>> Subject: [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate
>>  content into the AVMasteringDisplayMetadata side data.
>>
>> Add support for parsing SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into
>> the AVMasteringDisplayMetadata side data. Primaries are ordered in RGB order and
>> the values are converted to rationals ([0,1] for CEI 1931 Chroma coords,
>> and cd/m^2 for luma).
>>
>> Signed-off-by: Neil Birkbeck <neil.birkbeck at gmail.com>
>> ---
>>  libavcodec/hevc.c     | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>>  libavcodec/hevc.h     |  7 +++++++
>>  libavcodec/hevc_sei.c | 22 ++++++++++++++++++++++
>>  libavcodec/version.h  |  2 +-
>>  4 files changed, 76 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
>> index c245d3b..e475f94 100644
>> --- a/libavcodec/hevc.c
>> +++ b/libavcodec/hevc.c
>> @@ -28,6 +28,7 @@
>>  #include "libavutil/common.h"
>>  #include "libavutil/display.h"
>>  #include "libavutil/internal.h"
>> +#include "libavutil/mastering_display_metadata.h"
>>  #include "libavutil/md5.h"
>>  #include "libavutil/opt.h"
>>  #include "libavutil/pixdesc.h"
>> @@ -2580,6 +2581,51 @@ static int set_side_data(HEVCContext *s)
>>                                 s->sei_hflip, s->sei_vflip);
>>      }
>>
>> +    if (s->sei_mastering_display_info_present) {
>> +        // HEVC uses a g,b,r ordering, which we convert to a more natural r,g,b
>> +        const int mapping[3] = {2, 0, 1};
>> +        const int chroma_den = 50000;
>> +        const int luma_den = 10000;
>> +        int i;
>> +        AVMasteringDisplayMetadata *metadata =
>> +            av_mastering_display_metadata_create_side_data(out);
>> +        if (!metadata)
>> +            return AVERROR(ENOMEM);
>> +
>> +        for (i = 0; i < 3; i++) {
>> +            const int j = mapping[i];
>> +            metadata->display_primaries[i][0].num = s->display_primaries[j][0];
>> +            metadata->display_primaries[i][0].den = chroma_den;
>> +            metadata->display_primaries[i][1].num = s->display_primaries[j][1];
>> +            metadata->display_primaries[i][1].den = chroma_den;
>> +        }
>> +        metadata->white_point[0].num = s->white_point[0];
>> +        metadata->white_point[0].den = chroma_den;
>> +        metadata->white_point[1].num = s->white_point[1];
>> +        metadata->white_point[1].den = chroma_den;
>> +
>> +        metadata->max_luminance.num = s->max_mastering_luminance;
>> +        metadata->max_luminance.den = luma_den;
>> +        metadata->min_luminance.num = s->min_mastering_luminance;
>> +        metadata->min_luminance.den = luma_den;
>> +        metadata->has_luminance = 1;
>> +        metadata->has_primaries = 1;
>> +
>> +        av_log(s->avctx, AV_LOG_DEBUG, "Mastering Display Metadata:\n");
>> +        av_log(s->avctx, AV_LOG_DEBUG,
>> +               "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f)\n",
>> +               av_q2d(metadata->display_primaries[0][0]),
>> +               av_q2d(metadata->display_primaries[0][1]),
>> +               av_q2d(metadata->display_primaries[1][0]),
>> +               av_q2d(metadata->display_primaries[1][1]),
>> +               av_q2d(metadata->display_primaries[2][0]),
>> +               av_q2d(metadata->display_primaries[2][1]),
>> +               av_q2d(metadata->white_point[0]), av_q2d(metadata->white_point[1]));
>> +        av_log(s->avctx, AV_LOG_DEBUG,
>> +               "min_luminance=%f, max_luminance=%f\n",
>> +               av_q2d(metadata->min_luminance), av_q2d(metadata->max_luminance));
>> +    }
>> +
>
> should sei_mastering_display_info_present be reset to 0 somewhere ?
>
> [...]
>
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I am the wisest man alive, for I know one thing, and that is that I know
> nothing. -- Socrates
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list