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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Wim Taymans <wim.taymans at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #17)
> 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.
> 

It looks incorrect. colorimetry for RGB is needed to get the range, transfer
function and primaries right. You should ignore the YUV->RGB function because
it is unused.

The bug is that videoconvert does not ignore the matrix for RGB formats. I'll
have a look at that.

I see some things that probably also need to be done to make things nicer:

1) Always try to set the matrix function to RGB when dealing with RGB
   colorimetry. This should probably be done in gst_video_info_to_caps()
2) set the matrix function in the colorimetry to RGB when parsing RGB caps in
   gst_video_info_from_caps()

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