[Bug 759624] videoconvert: Odd behaviour between videoconvert and v4l2src

[GStreamer (GNOME Bugzilla)]

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

Ricardo Ribalda <ricardo.ribalda at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ricardo.ribalda at gmail.com

--- Comment #6 from Ricardo Ribalda <ricardo.ribalda at gmail.com> ---
Just some more information. This is the output from vivid driver:

root at qt5022:~# v4l2-ctl -V -d /dev/video0
Format Video Capture:
Width/Height      : 640/360
Pixel Format      : 'RGB3'
Field             : None
Bytes per Line    : 1920
Size Image        : 691200
Colorspace        : sRGB
Transfer Function : Default
YCbCr Encoding    : Default
Quantization      : Default
Flags             :


On gstv4l2object.c I found the following lines:

    case V4L2_COLORSPACE_SRGB:
    case V4L2_COLORSPACE_JPEG:
      /* This is in fact sYCC */
      cinfo->range = GST_VIDEO_COLOR_RANGE_0_255;
      cinfo->matrix = GST_VIDEO_COLOR_MATRIX_BT601;
      cinfo->transfer = GST_VIDEO_TRANSFER_SRGB;
      cinfo->primaries = GST_VIDEO_COLOR_PRIMARIES_BT709;

are we sure that we need to set the matrix value to bt601 for srgb colorspace?


I have contacted also the vivid developer (Thanks Hans!) and he has replied the
following:

"""
Just to be clear, the ycbcr_encoding value is only valid for YCbCr formats and
should be ignored for others. I actually think vivid returns
V4L2_XFER_FUNC_DEFAULT
whenever the format isn't YCbCr, but I'm not 100% certain of that.

The ycbcr_encoding obviously makes no sense if the format isn't YCbCr.
"""

I dont think that this is the issue here, but I believe that this is not
handled properly in the code neither.

Thanks!

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