Support for the updated V4L2_PIX_FMT_XRGB555 was added in commit
2538fee2fd however, when setting the format
for use in v4l2 ioctls, the old deprecated format is still used. Convert
this to the new accepted format type, as the preferred format.
https://bugzilla.gnome.org/show_bug.cgi?id=767300
v4l2src can cause an "infinite message loop" when a base control exposed as a
property is not provided by the device. In these cases, if in the warning message
handling for the bus, the GST_DEBUG_BIN_TO_DOT_FILE* category of functions are used,
the src lookup causes a new warning to be posted on the bus, causing a loop.
This patch changes the warning for these controls so they are not posted on the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=758703
A device can support more than one colorspace for a given image
dimension and pixel format. So we have to probe all the supported
colorspace and not only rely on the default one. Otherwise we could end
up with negotiation failure if the caps colorimetry field don't match
the v4l2 device default one even if the v4l2 could support such
colorimetry.
This patch enable probing if colorspace for both capture and output
device. It really makes sense for output device since the colorspace
shall be set by the application and a little less for capture device
which, at the moment, shall provide the colorspace; ie: the v4l2
specification seems to not take into account the fact that a capture
device could do colorspace conversion.
As a side effet, probing takes some times and so sligthly delay v4l2
initialization. Note that this patch only probe colorspace and not all
colorspace, matrix, transfer and range combination to avoid taking too
much time, especially with low-speed devices as full probing do 1782
ioctl.
https://bugzilla.gnome.org/show_bug.cgi?id=755937
gst_v4l2_object_get_caps_info() always return V4L2_PIX_FMT_SBGGR8
for all bayer formats. This is obviously broken if the device use
another ordering. Fix this by properly reading the format parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=763318
Replicate V4L2_MAP_QUANTIZATION_DEFAULT macro behavior.
At #v4l it was described that documentation might be wrong and that
we should trust this macro instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762529
Didn't know which one to choose between queuing and queueing, so I picked
the one with the biggest amount of vowels in a row ;-P (both are
acceptable apparently)
This time, check if it's an RGB format and sets the transformation
matrix to identity. The rest of the colorimetry information is
meaningfull and shall be kept.
https://bugzilla.gnome.org/show_bug.cgi?id=759624
Use the new primaries and transfer function for Adobe RGB.
Explicitly list the colorimetry instead of using the default GStreamer
ones. The defaults for BT2020, for example, do not match.
Explicitly set the matrix of SRGB to RGB.
Add properties to the device with exactly the same keys and sematics
as what pulseaudio uses as property keys.
Also handle the case when a device is probed manually and not through gudev.
https://bugzilla.gnome.org//show_bug.cgi?id=759780
This change add all the new RGB based format. Those format removes the
ambiguity with the ALPHA channel. Some other missing multiplanar format
has been added with some additional cleanup.
If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.
https://bugzilla.gnome.org/show_bug.cgi?id=758085
There was some miss-match in the implementation. This makes it
concistent, though functionally it worked, except the video decoder
output-io-mode getter.
This fixes wrong mapping for sRGB as in GStreamer sRGB correctly
apply to RGB formats, while in V4L2 it's an alias for sYCC. Also
add support for the new quantization (range), ycbcr_encoding (matrix)
and xfer_func (transfer) enumeration.
This is the latest from media tree. This should enable more development
of the v4l2 elements. This includes new flags requires to fix draining
path in decoder, colorimetry and much more.
The v4l2 device restarts the sequence counter in case of streamoff/streamon,
the GST offset values are supposed to increment strictly monotonic, so
adjust the sequence counter/offset values in case of caps
renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=745441
In case of v4l2 driver filled offset/sequence values add frame
loss detection (and write a warning message).
Move offset meta data setting and frame loss checking after the
timestamp adjustment code to get proper timestamps for the
warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=745441
