[Bug 759624] v4l2: Exposes colorimetry for RGB format which confuses videoconvert

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759624

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #17 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Had some more feedback from Hans. It does not fully clarify my mind about what
those colorimetry value really means for the RGB data we received. Some
statement in the doc seems to be in favour the the R'G'B component found in the
frames could even be in limited range. That would indicate a partial color
conversion having taken place. I have no idea if this is actually supported by
GStreamer. Hans is then making a guess on what GStreamer should do, though I'm
adding Wim in CC here, as I'm missing information. Note that the change I just
did still holds since it fixes the regression by bringing back the old
behaviour.

Wim, if you feel this is incorrectly fixed, let me know, and I'll re-open and
revisit this.

On 01/19/2016 07:00 PM, Nicolas Dufresne wrote:
> Hi Hans,
> 
> we are having issues in GStreamer with the colorspace in V4L2. The API
> does not provide any encoding for RGB formats.

Which API? GStreamer or V4L2?

> The encoding matrix for
> those is usually the identity matrix, anything else makes very little
> sense to me.

While normally RGB formats use the sRGB colorspace, this is by no means
always the case. HDMI for example also supports AdobeRGB and BT2020 RGB.

> For example, vivid will declare a stream with RGB based
> pixel format as having the default for sRGB colorspace, which lead to
> non-identity syCC encoding.

I don't follow. sYCC is for YCbCr formats. RGB formats do not contain any
information about YCbCr (i.e. the ycbcr_enc field should be ignored).

If gstreamer wants to convert RGB formats to YCbCr formats, then it can
choose whatever RGB->YCbCr conversion it wants.

The colorspace (i.e. the chromaticities), xfer_func and quantization fields
as reported by V4L2 are all still valid for RGB pixelformats.

You need those as well: take an HDMI receiver that converts Y'CbCr to R'G'B'
(let's be precise here and use the quote). If the input is HDTV using
Rec.709, then the colorspace is set to V4L2_COLORSPACE_REC709 and the other
fields are all 0 (DEFAULT). These map to XFER_FUNC_709 for the transfer
function, QUANTIZATION_FULL_RANGE for the quantization and ycbcr_enc is
ignored since there is nothing to do here (the Y'CbCr to R'G'B' conversion
is already done in hardware using the Rec. 709 Y'CbCr encoding).

If you would just ignore all fields and use COLORSPACE_SRGB, then you
would be using the wrong transfer function (XFER_FUNC_SRGB instead of
XFER_FUNC_709).

> Shall we simply ignore the encoding set by drivers when the pixel
> format is RGB based ? To me it makes very little sense, but the code in
> GStreamer is very generic and this wrong information lead to errors
> when the data is converted to YUV and back to RGB.

It seems to me that for RGB formats GStreamer should just set cinfo->matrix
(which I assume is the Y'CbCr to R'G'B' matrix) to the unity matrix and
everything else follows the normal rules.

Regards,

        Hans

====

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.