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
In the fraction 1 / 2. 1 is the numerator and 2 is the denominator.
The arguments of fraction gst_value_set_fractions() are value,
numerator and denominator.
Also, gst_value_set_fraction() fails if denominator is 0 for obvious
reasons.
As soon a the alpha component can be set, we can expose the RGB32 and BGR32
format as ARGB and BGRA as long we can deterministically set the alpha padding
value.
With years the amount of ifdef have grown up and we are not even sure if the
old code path compiles. Each time we need to update the v4l2 framework to add
the new feature, we break compilation on older kernel. With exception of two
controls in the video orientation control, this patch get rid of all ifdef by
including the latest version of videodev2.h inside GStreamer.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=723446
V4L2 kernel drivers allow configuration of the hardware settings via a
mechanism called controls. These can be referred to by name such as
"Brightness" and "White Balance Temperature". The user-space command line
client for setting these controls (v4l2-ctl) normalises these names such
that they only contain lower case alphanumeric characters and the
underscore '_'. e.g:
Kernel v4l2-ctl
----------------------------------------------------
Brightness brightness
White Balance Temperature white_balance_temperature
Focus (absolute) focus_absolute
GStreamer seems to want to follow this pattern but failed for controls with
more than one consecutive non-alphanum character. e.g. GStreamer would
produce "focus__absolute_" rather than "focus_absolute".
This commit fixes that issue. Backwards compatibility is preserved by
normalising all control names before comparison.
https://bugzilla.gnome.org/show_bug.cgi?id=725632
This may not be defined. Since the previous version used
only the other define (V4L2_CAP_VIDEO_OUTPUT_MPLANE), fall
back on this only when not available.
This api is in linux kernel since version 2.6.39,
and present in all version 3.
The commit that adds the API in master branch of the
linux kernel source is:
f8f3914cf9
v4l2 doc: "Some devices require data for each input
or output video frame to be placed in discontiguous
memory buffers"
There are newer structures 'struct v4l2_pix_format_mplane'
and 'struct v4l2_plane'.
So the pixel format is not setup with the same API when using
multi-planar.
Also for gst-v4l2, one of the difference is that in GstV4l2Meta
there are now one mem pointer for each maped plane.
When not using multi-planar, this commit takes care of keeping
the same code path than previously. So that the 2 cases are
in two different blocks triggered from V4L2_TYPE_IS_MULTIPLANAR.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=712754
In v2.6.18 control classes where added to the v4l2 API.
Iterating over CIDs starting with V4L2_CID_BASE will only find controls for
the first control class.
By iterating with V4L2_CTRL_FLAG_NEXT_CTRL all controls are found.
This is necessary to make controls from other control classes available in
the extra-controls property.
If V4L2_CTRL_FLAG_NEXT_CTRL is not defined at compile time or not supported
at runtime then the old mechanism for iterating is used.
https://bugzilla.gnome.org/show_bug.cgi?id=701540
This makes it possible to set any controls that can be set with
VIDIOC_S_CTRL.
The controls are set when the property is set (if the device is open)
and when the device is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=698837
When do v4l2_ioctl() with VIDIOC_ENUMINPUT fails on some devices,
kernels before 3.3.0 return EINVAL, but newer kernels return ENOTTY.
This patch make those devices work well on kernel 3.3+.
Related kernel commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=07d106d0a33d6063d2061305903deb02489eba20
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Rui Wang <wangr@lemote.com>
Signed-off-by: Jie Chen <chenj@lemote.com>
input.std is of type v4l2_std_id which is defined as 64-bit unsigned integer.
Casting to uint means the higher bits, wich are used for the private video
standards of the TI video capture/display driver for example, are lost.
Don't post a (fatal) error message on the bus just because we
failed to query some control. Fixes issue with built-in
Suyin Corp webcam for HP notebook (usbid 064e:e28a) on
OpenSuse 12.1, where querying red/blue balance fails.
https://bugzilla.gnome.org/show_bug.cgi?id=670197
Based on a patch by Guennadi Liakhovetski.
v2: updates because I forgot to add GstTuner interface to v4l2sink
v3: update to add all possible values to norm enum
This reverts commit 9e1d419d07.
Reverting this since it adds unreviewed and bad API to v4l2src
(property of type enum, with seemingly random and unsorted values).
output devices should use get/set output, and in either case we should
not print a warning message if the ioctl fails but the device does not
claim to support the tuner interface
The compiler wants a cast here even though the type is already
typedefed as 64-bit integer (presumably because glib has typedefed
guint64 to unsigned long here).
This also does the following changes:
(1) pull the bufferpool code out into gstv4l2bufferpool.c, and make a
bit more generic so it can be used both for v4l2src and v4l2sink
(2) move some of the device probing/configuration/caps stuff into
gstv4l2object.c so it does not have to be duplicated between
v4l2src and v4l2sink
Fixes bug #590280.
The v4l2 driver for USB webcams on OpenSolaris does not support select()
calls. Detect when select() fails, and skip polling the device afterward,
which restores the pre 0.10.14 behaviour on OpenSolaris.
Signed-off-by: Jan Schmidt <thaytan@noraisin.net>
