[Bug 732281] new element: inteldmabufupload

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from George Kiagiadakis <george.kiagiadakis at collabora.com> 2014-07-01 10:00:58 UTC ---
(In reply to comment #2)
> I'm also a bit unhappy that this memory:dmabuf feature haven't been
> discussed/proposed anywhere else (like on the ML). 

I thought this was pretty much standard, i.e. using "memory:ALLOCATOR_NAME" to
negotiate buffers with memory coming only from a specific allocator.

> Negotation of DMABuf is
> currently undefined, we need to agree all together instead of doing our own.
> One problem with this approach is that dmabuf can often be mapped to userspace,
> hence can also have the default system memory feature. Will wayland sink
> correctly handle that ?

waylandsink can handle 3 things at the moment (in my dmabuf branch):

1) buffers with memory from its own allocator (which allocates memory on tmpfs
files and shares them with the compositor using wl_shm), in which case it just
informs the compositor that there is new content there

2) buffers with memory from the dmabuf allocator, in which case it just passes
the file descriptor to the compositor

3) any other kind of mappable buffers, in which case it copies contents into
new buffers from its own allocator and uses wl_shm again.

The fundamental problem that led me to use "memory:dmabuf" to separate it from
other kinds of buffers is that the compositor may accept different formats when
dmabuf is used and when wl_shm is used. So the caps need a way to express that
wl_shm accepts for example only ARGB and xRGB, but the sink will also accept
dmabuf with other formats.

In any case, I know this is a very primitive way of negotiating dmabuf because
there are also other restrictions (hardware-specific restrictions), which
GStreamer cannot negotiate. wl_dmabuf (or whatever it is going to be called) is
very far from being standarized and it needs work from various sides in order
to achieve automatic negotiation. At the moment, what we have is just a proof
of concept.

You can read various comments about this in the relevant wayland-devel thread:
http://lists.freedesktop.org/archives/wayland-devel/2014-June/015362.html


Now regarding inteldmabufupload, as I said in the description, it's just a
testing element. It obviously is a bad idea to have the application know about
the driver being used. There is also no generic interface for allocating
dmabuf, because dmabuf is in its early stages and it is tied with specific
hardware at the moment. It's a proof of concept from all sides. There are
plans, though, for a central allocator in the kernel (see the above thread).

Also, this code is not inside waylandsink, because it has nothing to do with
wayland. It could be used with another video sink that knows how to import
dmabuf buffers.


PS: I am happy if this element just dies. I only submitted it in case somebody
finds it useful, but I don't expect it to be merged.

-- 
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.