[Bug 759624] v4l2: Exposes colorimetry for RGB format which confuses videoconvert
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Jan 20 00:40:26 PST 2016
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.
More information about the gstreamer-bugs
mailing list