[PATCH] unstable: add HDR Mastering Meta-data Protocol

Nautiyal, Ankit K ankit.k.nautiyal at intel.com
Thu Feb 28 10:16:12 UTC 2019


Hi,

On 2/27/2019 2:28 PM, Erwin Burema wrote:
> Hi,
>
> On Wed, 27 Feb 2019 at 05:47, Nautiyal, Ankit K
> <ankit.k.nautiyal at intel.com> wrote:
>> From: Ankit Nautiyal <ankit.k.nautiyal at intel.com>
>>
>> This protcol enables a client to send the hdr meta-data:
>> MAX-CLL, MAX-FALL, Max Luminance and Min Luminance as defined by
>> SMPTE ST.2086.
>> The clients get these values for an HDR video, encoded for a video
>> stream/file. MAX-CLL (Maximum Content Light Level) tells the brightest
>> pixel in the entire stream/file in nits.
>> MAX-FALL (Maximum Frame Average Light Level) tells the highest frame
>> average brightness in nits for a single frame. Max and Min Luminance
>> tells the max/min Luminance for the mastering display.
>> These values give an idea of the brightness of the video which can be
>> used by displays, so that they can adjust themselves for a better
>> viewing experience.
>>
> This does sound quite good for video players (and in the future image
> viewers), but might have something missing for HDR content generation
> (Blender, Krita, Natron, etc) since you do not always know these
> values in advance (it is effectively before mastering), most of these
> work in scene linear with the convention that 0.18 is middle grey
> (although this is just a convention). So I think that in these cases
> we might need to get info from the display system on what luminance
> levels its supports.
>
> Hope this makes sense since at the way to busy with other obligations
> so not much time to look into this.

Yes you are right, there would be cases where HDR content-does not have 
these values.
The HDR luminance levels for a display are exposed to the compositor 
through the edid from the kernel.
We can have a discussion whether a displays luminance level can be 
exposed by the compositor to the client and also how to do it.
But currently, the present patch is focused more for HDR video players, 
as it will be difficult to implement and
review all the scenarios/requirements at one go. Once the things set and 
agreed upon for this case,
we can add the support to expose these luminance values too as per 
discussions.
Does that make sense?

Regards,
Ankit

>> The protocol depends on the Color Management Protocol which is still
>> under review. There are couple of propsed protocols by Neils Ole [1],
>> and Sebastian Wick [2], which allow a client to select a color-space
>> for a surface, via ICC color profile files.
>> The client is expected to set the color space using the icc files and
>> the color-management protocol.
>>
>> [1] https://patchwork.freedesktop.org/patch/134570/
>> [2] https://patchwork.freedesktop.org/patch/286062/
>>
>> Co-authored-by: Harish Krupo <harish.krupo.kps at intel.com>
>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal at intel.com>
>> ---
>>   Makefile.am                                        |  1 +
>>   unstable/hdr-mastering-metadata/README             |  5 ++
>>   .../hdr-mastering-metadata-unstable-v1.xml         | 95 ++++++++++++++++++++++
>>   3 files changed, 101 insertions(+)
>>   create mode 100644 unstable/hdr-mastering-metadata/README
>>   create mode 100644 unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 345ae6a..c097080 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -23,6 +23,7 @@ unstable_protocols =                                                          \
>>          unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
>>          unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
>>          unstable/primary-selection/primary-selection-unstable-v1.xml            \
>> +       unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml  \
>>          $(NULL)
>>
>>   stable_protocols =                                                             \
>> diff --git a/unstable/hdr-mastering-metadata/README b/unstable/hdr-mastering-metadata/README
>> new file mode 100644
>> index 0000000..b567860
>> --- /dev/null
>> +++ b/unstable/hdr-mastering-metadata/README
>> @@ -0,0 +1,5 @@
>> +HDR-MASTERING-META-DATA-PROTOCOL
>> +
>> +Maintainers:
>> +Ankit Nautiyal <ankit.k.nautiyal at intel.com>
>> +Harish Krupo <harish.krupo.kps at intel.com>
>> diff --git a/unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml b/unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml
>> new file mode 100644
>> index 0000000..aeddf39
>> --- /dev/null
>> +++ b/unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml
>> @@ -0,0 +1,95 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<protocol name="hdr_mastering_metadata_unstable_v1">
>> +
>> +  <copyright>
>> +    Copyright © 2019 Intel
>> +
>> +    Permission is hereby granted, free of charge, to any person obtaining a
>> +    copy of this software and associated documentation files (the "Software"),
>> +    to deal in the Software without restriction, including without limitation
>> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> +    and/or sell copies of the Software, and to permit persons to whom the
>> +    Software is furnished to do so, subject to the following conditions:
>> +
>> +    The above copyright notice and this permission notice (including the next
>> +    paragraph) shall be included in all copies or substantial portions of the
>> +    Software.
>> +
>> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> +    DEALINGS IN THE SOFTWARE.
>> +  </copyright>
>> +
>> +  <description summary="hdr mastering meta data protocol">
>> +    This protocol provides the ability to specify the mastering color volume
>> +    metadata for an HDR video, for a given surface.
>> +    These values give an idea of the brightness of the video, which can be
>> +    used by the display so that it can adjust itself for a better viewing
>> +    experience.
>> +
>> +    The hdr-metadata values are enocoded in the video and the client can
>> +    retreive these values and provide them to the compositor.
>> +
>> +    A client need to first get the color-space interface for the HDR
>> +    color-space using the color-manager protocol, via ICC profile.
>> +    Then it needs to get the hdr_mastering_surface using
>> +    hdr_mastering_metadata interface. The get_hdr_surface(), provides the
>> +    hdr_surface interface which can be used to set the hdr mastering meta-data.
>> +  </description>
>> +
>> +  <interface name="zwp_hdr_mastering_metadata_v1" version="1">
>> +    <description summary="hdr mastering metadata">
>> +      The hdr matering metadata is a singleton global object that provides
>> +      the extenstion hdr_surface for a given surface.
>> +    </description>
>> +
>> +    <enum summary="error">
>> +      <entry name="hdr_surface_exists" value="0"
>> +             summary="The hdr surface exists for given surface."/>
>> +    </enum>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="destroy the hdr_mastering_metadata object">
>> +        Destroy the HDR mastering metadata object.
>> +      </description>
>> +    </request>
>> +
>> +    <request name="get_hdr_surface">
>> +      <description summary="get the interface for hdr_surface">
>> +        This interface is created for a surface and the hdr mastering metadata
>> +       should be attached to this surface.
>> +      </description>
>> +      <arg name="hdr_surface" type="new_id" interface="zwp_hdr_surface_v1"/>
>> +      <arg name="surface" type="object" interface="wl_surface"/>
>> +    </request>
>> +
>> +  </interface>
>> +
>> +  <interface name="zwp_hdr_surface_v1" version="1">
>> +    <description summary="an interface to add hdr mastering metadata">
>> +      An interface to add the hdr mastering metadata like MAX-CLL and MAX-FALL,
>> +      for a given surface.
>> +    </description>
>> +
>> +    <request name="set_hdr_mastering_metadata">
>> +      <description summary="set the hdr mastering metadata for the surface.">
>> +        This request is double buffered and it will be applied to the surface
>> +       on wl_surface::commit.
>> +      </description>
>> +      <arg name="max_cll" type="uint" summary="MAX Content Light Level"/>
>> +      <arg name="max_fall" type="uint" summary="MAX Frame Average Light Level"/>
>> +      <arg name="max_lum" type="uint" summary="MAX Luminance"/>
>> +      <arg name="min_lum" type="uint" summary="MIN Luminance"/>
>> +    </request>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="destroy the hdr mastering surface object">
>> +        Destroy the hdr_surface.
>> +      </description>
>> +    </request>
>> +  </interface>
>> +</protocol>
>> --
>> 2.7.4
>>



More information about the wayland-devel mailing list