[Bug 759624] videoconvert: Odd behaviour between videoconvert and v4l2src
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Jan 19 09:58:27 PST 2016
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.
More information about the gstreamer-bugs
mailing list