Re: [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/03/2018 12:23 PM, Andrzej Hajda wrote:
> On 30.11.2018 15:48, Hans Verkuil wrote:
>> On 11/30/18 15:29, Ville Syrjälä wrote:
>>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
>>>> Hi Ville,
>>>>
>>>> As Christoph cannot respond till middle next week I can try to respond
>>>> in his absence, as I am familiar with the subject.
>>>>
>>>> On 30.11.2018 14:25, Ville Syrjälä wrote:
>>>>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am looking for a way to export the color encoding and range selection
>>>>>> to user space. I came across those properties and am wondering, why
>>>>>> they are meant only for non RGB color encodings. Would it be okay, to
>>>>>> modify them and use with RGB formats as well?
>>>>> What you trying to do? Input limited range RGB data and expand to full
>>>>> range?
>>>>
>>>> For example. But there are two more general questions, which
>>>> surprisingly we have not found answer for.
>>>>
>>>> 1. What color encoding and range drm should expect on its input RGB
>>>> buffers by default?
>>> RGB is just RGB. There is no encoding. 
> 
> 
> OK, Now I see I have confused encoding with colorspace, Hans thanks for
> the documentation.
> 
> As I understand drm by default should expect sRGB colorspace, also for
> Y'CbCr buffers, and currently there are no standard ways to specify
> buffer colorspace.
> 
> Looking at current users of drm_plane_create_color_properties for Y'CbCr
> buffers it seems default range should be LIMITED.

Right. There is support for YCbCr quantization range signaling in HDMI,
but that is for all intents and purposes broken in the standard. Don't
use it, just output limited range YCbCr.

On the other hand, RGB Quantization range signaling should *always* be
used if the EDID signals support for it. I believe that's what drm does
today already (this certainly works for i915).

> 
> But default encoding is different: mali, armada, nouveau use
> DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this
> be somehow standardized?

According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for
everything else. So this is resolution dependent.

Although strictly speaking it is only userspace that knows the right
encoding, since it depends on the source material. You can have SDTV
video encoded with 709, or HDTV encoded with 601. But in the absence
of any information, the default rule above is what should be used.

> 
> 
> What I still do not understand is colorspace conversion(not encoding!) -
> between pipeline input (framebuffers) and output (HDMI connector for
> example):
> 
> 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost
> identical in coverage' (according to wikipedia[1]) no colorspace
> conversion is performed at all.

That's correct. There is a slight difference between SMPTE170M and
sRGB/Rec709, but basically invisible to the naked eye unless you see
it side-by-side, and even then it's is hard to detect.

However, sRGB uses a different transfer function compared to SMPTE170M
and Rec709, and that difference *is* quite visible. Not all hardware
(certainly not video capture hardware) is capable of converting between
different transfer functions, though. I gather that this is more common
for HDMI output hardware.

> 
> 2. It is performed somewhere by HW, just my IP documentation is not
> clear about it.
> 
> 
> Another thing which still bothers me is RGB range in case of HDMI -
> CEA-861 expects than on CEA modes limited RGB range should be sent, but
> the pipeline on the particular hardware I have do not perform any
> conversion of input buffers. So only limited range RGB buffers are
> displayed correctly. In such case property describing plane with limited
> RGB would be useful.

Are you sure? Usually the same block that does YCbCr encoding conversion
(601 to 709 or vice versa), also deals with limited/full range conversion.

It is typically a 3x3 matrix + a vector adding the needed offsets. It is
dead cheap to implement in hardware, so it would be very unusual if there
is no support for this.

> 
> 
> [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities
> 
> 
>> It's assumed to be full range 
>>> because no one really uses anything else.
>> For simple desktop usage that's true. When dealing with video inputs,
>> this becomes much more complicated.
> 
> 
> As I said earlier there are cases where output stream should be limited
> RGB, and no conversion in pipeline - thus framebuffers also should be
> 'limited RGB'.

Whether RGB output should be full or limited range depends entirely on
the resolution and the EDID. I have tested i915 w.r.t. RGB quantization
range, and that does it right.

The reality with RGB Quantization Range handling is that 50% of all
devices do this wrong. So if the EDID signals selectable quantization range
support, then use it and signal full range RGB.

If it is not available, then the i915 implementation is one I can point
to that does it 100% correct. (This might be based on core drm code, I'm
not sure if it is i915 specific or not)

Kudos to the i915 driver developers: the linux implementation is the
only one that handles this correctly. The Windows implementation doesn't
honor RGB Selectable Quantization and the macos driver seems to always
output full range.

The only way to support all three variants in an HDMI receiver is to
enable YCbCr support in the EDID: the macos driver will now output
YCbCr, while all the others output RGB (Windows using default RGB
Quantization rules and Linux explicitly signaling the RGB range).

It's insane.

Regards,

	Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux