[Bug 583890] v4l2: Implement V4L2_MEMORY_USERPTR support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=583890
  GStreamer | gst-plugins-good | git

--- Comment #58 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-04-03 15:46:44 UTC ---
I'm currently working on implementing a GstV4l2Allocator, as right now in
master we randomly loose buffers (they don't come back into our pool) for
various reason. This is a bit incompatible with this branch, USERPTR support
will need a new design. What I have in mind:

What's new:
GstV4l2Allocator
  GstV4l2MemoryGroup
  GstV4l2Memory

the method we care for userptr (just drafting here):
GstV4l2MemoryGroup *gst_v4l2_allocator_alloc_userptr (allocator, mem[],
stride[], offset[], user_data);

For capture:
Pool would fill the allocator from downstream pool using that method. Mem being
extracted and reffed from the buffer. The pool would create an internal buffer
with that, rather then pooling the downstream buffer. When dqbuf, the pool will
be able to get back the original buffer using the user_data; The pool will be
responsible for correct recounting of that buffer.

For output:
Pool would try and fill the internal pool the same way, with buffers as they
come. And will ensure to keep at least two (of min buffers for output). Unlike
previous attempt, a pool need to always be offered on propose_allocation, and
pool that has been started/stop should not affect the decision. This remains
risky mode, as we need to trust upstream for respecting the requirement we have
exposed in propose_allocation. Also, it's not possible to fallback after first
buffer has been enqueued, hence we'll fail completly if second buffer is
incompatible (will nearly never happen), and reused what we have queued
afterward.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.