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
It makes the gst_v4l2_object_set_format() slightly simplier and will make that
logic reusable. Note that gst_v4l2_object_has_mplane() will always return the
same value for one device. There is no need to check against the caps as this
has already been done by _open.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
We set the dimensions just in case but don't validate them
afterwards. For some codecs the dimensions are *not* in the
bitstream, IIRC VC1 in ASF mode for example.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
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
gst_video_info_from_caps() always extract width, height, interlace mode and
framerate now. It is no longer necessary to do it again for encoded
formats.
https://bugzilla.gnome.org/show_bug.cgi?id=703399
Instead of just assuming a aspect ratio of 1/1 use VIDIOC_CROPCAP to ask
the device.
This also add a pixel-aspect-ratio property to overwrite the value from the
driver and a force-aspect-ratio property to ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=700285
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
This can happen if other parts of the pipeline are reconfigured.
Stop streaming even for a short amount of time can be quite visible, so it
should be avoided if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=700503
In the past gst_video_info_from_caps() only video/x-raw. Now it also
supports other video/* and image/* formats.
With this patch the format won't be GST_VIDEO_FORMAT_UNKOWN and
gst_v4l2_buffer_pool_set_config() handles strides correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=699570
The existence of a GstVideoFormatInfo does not guarantee, that
the buffer contains video frames, so the format must be checked.
Also, for encoded buffers the length is variable and must be set.
https://bugzilla.gnome.org/show_bug.cgi?id=698949
If TRY_FMT is not implemented, gst_v4l2_object_get_nearest_size will
use S_FMT and will change the device's operation mode. To save the
old device mode we need to set the type field or else it will fail
to save the previous format.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=685209
v4l has add a new IOCTL to export a buffer by using dmabuf.
This patch allow to use this new IOTCL if it has been defined in videodev2.h
I introduce a new IO mode (GST_V4L2_IO_DMABUF) to enable this way of working.
https://bugzilla.gnome.org/show_bug.cgi?id=693826
UVC devices are never interlaced, and doing VIDIOC_TRY_FMT on them
causes expensive and slow USB IO, so don't probe them for interlaced.
This shaves 2 seconds of the startup time of cheese with a Logitech
Webcam Pro 9000.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=677722
