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
Without this, a queued buffer may be required, filled and queued before it
is dequeued.
Calling gst_buffer_pool_acquire_buffer() ensures that the buffer is set up
correctly and gst_buffer_unref() calls buffer_release().
https://bugzilla.gnome.org/show_bug.cgi?id=700781
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
When queuing a buffer for a sink, bytesused must contain the actual
amount of data.
For a source, the driver must overwrite this, so it doesn't matter
what is set here.
https://bugzilla.gnome.org/show_bug.cgi?id=699598
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
If max_buffers is 0 then an arbitrary number of buffers (currently 4) is
allocated. If this is not enough v4l2src starts copying buffers.
With this patch VIDIOC_CREATE_BUFS is used to allocate a new buffer. If
this fails v4l2src falls back to copying buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=699447
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
Don't just loop over the first num_queued buffers but loop over
all the buffers and check if they need to be freed. It is possible that
not all buffers are queued and then the entry in our array will be NULL.
Those buffers that are not queued were freed in stop().
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=696651
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
With the port to gstreamer 1.0 the prepare-format signal stopped being
emitted. Start emitting this again for use in uvch264src. While there
change the emission to include the caps for extra flexibility instead of
fource, width, height.
https://bugzilla.gnome.org/show_bug.cgi?id=692042
Need to explicitly link against -lrt for clock_gettime(), which
we don't get in the libs any more, because core moved the
gmodule-no-export-2.0 bit into Requires.Private.
Not required for newer glibc, but for older ones, so check for that.
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>
This was unused apparently and removed in the kernel in commit:
From 2b719d7baf490e24ce7d817c6337b7c87fda84c1 Mon Sep 17 00:00:00 2001
From: Sakari Ailus <sakari.ailus@iki.fi>
Date: Wed, 2 May 2012 09:40:03 -0300
Subject: [PATCH] [media] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
Remove input field in struct v4l2_buffer and flag V4L2_BUF_FLAG_INPUT which
tells the former is valid. The flag is used by no driver currently.
https://bugzilla.gnome.org/show_bug.cgi?id=681491
Conflicts:
sys/v4l2/gstv4l2bufferpool.c
