Adds type compatiblity with other OS like BSD. This uses types mapping macro to
avoid conflict with existing defined types. We resuse glib types as these are
already available on supported platforms. This is GCC only because of the
le32 type that uses bitwise attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=726453
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
For each videoCdevice probe it input/output capabilities
if it match with video decoder requirement register a new element.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
https://bugzilla.gnome.org/show_bug.cgi?id=722128
We correctly indicate the field ordering on interlaced buffers, but fail to
flag them as containing interlaced video, which we need to do here because
we signal interlace-mode=mixed in our caps. This means that downstream
elements (like vaapipostproc from gstreamer-vaapi) don't recognise these
buffers as in need of deinterlacing.
Fix this by setting the interlaced flag on all interlaced buffers.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=724899
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.
Don't enforce having width, height and framerate in template caps for encoded
formats. These don't always need to be exposed and may break negotiation for
decoder and decoding sink. If needed, these field will be automatically added
when probed caps are known.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
STREAMOFF set all v4l2buffers to DEQUEUE state.
Then for CAPTURE we call QBUF on each buffer.
For OUTPUT the buffers are just push back in the GstBufferPool
base class 's queue.
But the loop actually looks like the same.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
If there is nothing that seems to force a certain framerate on output device, it is
preferable to simply not set that feild. This allow negotiation with tsdemux in a
decoder for example.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
Also add a FIXME in gst_v4l2_object_setup_format
to note that the whole function has to be improved
in order to support ENCODED formats.
It requires to have an encoder device which we do not
have right now.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
This method allow setting up the object from the currently configured format on the
device. This is useful for M2M element where input data decides the format that will
be set on capture side.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
The number of plane, and the stride does not represent a capability change. Same caps
can have different stride from the default GstVideoInfo and the number of planes will
never change for 1 format.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
