Recent kernels allow REQBUFS(0) on a queue that still has buffers in
use (mmapped or exported via dmabuf), orphaning all buffers on the queue.
Orphaning the allocator causes it to release all buffers with
REQBUFS(0), even if they are still in use. An orphaned allocator can
only be stopped. It can not be restarted or create new buffers.
The library has started preventing a lot of interesting use cases,
like CREATE_BUFS, DMABuf, usage of TRY_FMT. As the libv4l2 is totally
inactive and not maintained, we decided to disable it. As a convenience
we added a run-time environment that let you enable it for testing.
GST_V4L2_USE_LIBV4L2=1
This of course only works if you have enabled libv4l2 at build time.
Offset are relative to the buffer and there is no guarantee substracting
them will give us the plane size. So we let bufferpool make the math as
it is more aware of video info than allocator and pass a size array to
allocator import function.
Pointed out by Nicolas Dufresne <nicolas.dufresne@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=738013
As the buffer array is fixed size and small, it's safer to simply
use this static size to cleanup the buffers. This is also more
consistent with the rest. The associated method is no longer
required and can be dropped.
Parenting V4l2Memory to DmabufMemory was in conflict with recent
optimization in DmabufMemory to avoid dup(), and didn't work with
memory sharing. Instead, use a qdata and it's destroy notify.
https://bugzilla.gnome.org/show_bug.cgi?id=730441
All enum that has REQBUFS and CREATE_BUFS where missing S, which was
confusing since they are supposed to match with associcated ioctl name. This
also fixes the yet unused CAN_REQUEST flag check.
This goal of this allocator is mainly to allow tracking the memory.
Currently, when a buffer memory has been modified, the buffer and it's
memory is disposed and lost until the stream is restarted.
