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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
