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
so that the buffer informations can be retrieved the same way
in both MPLANE and non-MPLANE mode.
Here "emulating" means "manually fill in the plane".
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=712754
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
On some systems (E.G. uClibc and older Glibc versions), O_CLOEXEC is only
defined when _GNU_SOURCE is specified, so do so.
_GNU_SOURCE needs to be defined before any system headers are included,
so move the fcntl.h section up.
https://bugzilla.gnome.org/show_bug.cgi?id=709423
If the pool is stopped while gst_v4l2_buffer_pool_dqbuf() waits for a
buffer then the return value is GST_FLOW_FLUSHING. In this case the buffer
to queue must also be released. Otherwise is will never be deleted or
returned to its pool.
https://bugzilla.gnome.org/show_bug.cgi?id=703764
The pool accesses data from the v4l2object so it must exist at least
as long as the pool. Refcount the element which controls the object
live-time.
https://bugzilla.gnome.org/show_bug.cgi?id=701650
Without this the following sequence fails:
- set_caps()
- object_stop() (does nothing)
- set_format() -> VIDIOC_S_FMT
- set_config() -> VIDIOC_REQBUFS with count = N
- set_caps()
- object_stop()
- pool_finalize()
- set_format() -> VIDIOC_S_FMT => EBUSY
Usually the pool is started after set_config(), in which case object_stop()
will result in a pool_stop and therefore VIDIOC_REQBUFS with count = 0 but
that is not guaranteed.
Also calling VIDIOC_REQBUFS with count = 0 in pool_finalize() if necessary
fixes this problem.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701543
This is a followup patch for #700781, which is not quite correct.
The buffer handling is quite complicated here.
The original code intended to the the following:
- gst_v4l2_buffer_pool_process() calls QBUF and adds the buffer to the
local list.
- The sink calls gst_buffer_unref() which returns the buffer to the pool
but not the 'free list'.
- Some time later DQBUF returns the buffer and
gst_v4l2_buffer_pool_release_buffer() puts in on the 'free list'.
If the buffer must be copied then (parent_class)->acquire_buffer() is
called directly to keep the buffer in the pool.
This has two problems:
1. If gst_v4l2_buffer_pool_release_buffer() is called before the buffer is
returned to the pool, then the buffer is put on the 'free list' twice.
This can happen if a reference to the buffer is kept outside the sink,
of if DQBUF returns the buffer, that was just queued with QBUF.
2. If buffers are copied, then all buffers are in the pool at all times. As
a result gst_v4l2_buffer_pool_stop() and gst_v4l2_buffer_pool_dqbuf()
can access pool->buffers at the same time, which can lead to memory
corruption.
The patch for #700781 fixes those problems, but with the side effect that
there are always buffers outside the pool (because they are queued) and
the pool is never stopped.
This patch fixes this by releasing the reference to the buffer after
handling it (to avoid problem 2.) so it can be returned to the pool.
gst_v4l2_buffer_pool_release_buffer() is only called if the buffer is
already in the pool (to avoid problem 1.).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701375
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
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
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
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
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
Query the amount of available buffers when doing set_config(). This allows us to
configure the parent bufferpool with the number of buffers to preallocate.
Keep track of the provided allocator and use it when we need to allocate a
buffer in RW mode.
When we are can not allocate the requested max_buffers amount of buffers, make
sure we keep 2 buffers around in the pool and copy them into an output buffer.
This makes sure that we always have a buffer to capture into. We also need to
detect those copied buffers and unref them when they return to the pool.
Only free the queued buffers that we keep track of in our buffer array. for rw
io-mode, we do allocate buffers but we don't keep track of them in the buffer
array.
