To change pixel aspect ratio from DAR to PAR, the necessary scaling factor
is DAR/PAR, not DAR*PAR.
For good measure, add debug output similar to the fixed-width and
fixed-height cases.
https://bugzilla.gnome.org/show_bug.cgi?id=766711
Instead of relying on the default colorimetry chosen by
gst_video_info_set_format(), set info.colorimetry from the
values returned by G_FMT. This allows decoders to propagate
their input colorimetry downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=766383
Move the extraction of colorimetry parameters from struct v4l2_format and the
setting of the identity matrix for RGB formats into the function to avoid code
duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=766383
gst_v4l2_probe_caps() returns the coded size, not the visible size. Subtract
the known padding from probed caps with the coded size before using them as
filter for caps negotiation with downstream elements.
https://bugzilla.gnome.org/show_bug.cgi?id=766382
The gst_v4l2_object_acquire_format() function is used by v4l2videodec to obtain
the currently set capture format. Since G_FMT returns the coded size, the
visible size needs to be obtained from the compose rectangle in order to
negotiate it with downstream elements. The G_CROP call hasn't worked on mem2mem
capture queues for a long time. Instead use the G_SELECTION call to obtain the
compose rectangle and only fall back to G_CROP for ancient kernels.
https://bugzilla.gnome.org/show_bug.cgi?id=766381
On modern kernels, the G/S_FMT ioctls will always fail using
V4L2_BUF_TYPE_VIDEO_OVERLAY with VFL_DIR_TX (e.g. real overlay out drivers)
since this is not the intented use (rather rx, according to v4l2 API doc).
Probably this is why the Video Output Overlay interface was created, so if
the driver advertises it we might as well use.
For old kernels (pre 2012) the old way might still work so keeping this for
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=761165
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 GetStatus() fails, the status itself won't be very meaningful but we also
have to look at its return value. This fixes blocking pipelines when removing
sound devices or during other errors, where we wouldn't notice the error and
then wait forever.
https://bugzilla.gnome.org/show_bug.cgi?id=734098
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.
