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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Ricardo Ribalda <ricardo.ribalda at gmail.com> ---
Hello. 



I have been hyper busy lately, so I have not been able to dig further. But
maybe this is useful for you! I got this response from Hans the 5th of January:


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.

Regards,

        Hans

Since the pixelformat is RGB the ycbcr encoding is undefined (Default as
reported
by vivid). I don't know what gstreamer expects in that case.

Is the gstreamer code perhaps confusing pixelformat and colorspace? For
non-ycbcr
formats the matrix should be a unity matrix.

Anyway, what vivid reports looks OK to me: RGB pixelformat and sRGB colorspace
with the other colorspace-related values set to Default (there are
V4L2_MAP_*_DEFAULT
macros in videodev2.h to calculate how to map a Default value to the actual
format).

Regards,

        Hans

Can you check first if I am right in my assumption that gstreamer doesn't
handle the new colorspace fields? (i.e. the ycbcr_enc, quantization and
xfer_func
fields of v4l2_pix_format).

All I am basing it on is the code snippet you pasted in your mail and a
suspicion, but
I could be very wrong about that. A grep for those fields in the source code
would be
sufficient. Note that xfer_func was added last, so there is a chance that they
support
ycbcr_enc and quantization, but not yet xfer_func.


Anyway, feel free to add my mail to their bugzilla if I am right.



Thanks!

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