[Bug 711155] wayland: add wl_drm support to wayland sink
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Nov 24 10:44:01 PST 2015
https://bugzilla.gnome.org/show_bug.cgi?id=711155
--- Comment #74 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
In Fabien's patch, the caps feature implementation is not acceptable. The first
patch I would expect is to add a define with the caps feature name. So far,
everyone have use memory:dmabuf, which does not follow the usual convention
found in other caps feature where CamelCase is preferred. This define should be
part of the dmabuf allocator API imho (at least it's a good location for it as
we need that anyway). It's also an opportunity to write some documentation to
help ensuring that it's use will be consistent. I am still working myself on a
definition and method to use caps features to help solving the DMABuf
negotiation. Though, this is not simple and the fact that proper format list
are not available does not make it that interesting.
The main difference between the patch is unique sink vs specialized sink. The
main problem with the unique sink, is that the entire sink caps become a lie.
There is no way to use the sink and be guaranties it will work. A malloc buffer
could be received in an unsupported format, or an dmabuf that cannot be
imported, cannot be copied to SHM for the same reason. There is no fallback,
just frustration.
With the split between shm and dmabuf, you at least have one sink that you are
guarantied will work. It also gives a lot more control, as you can now solve
the fact DMABuf will not always work at a higher level. You can at the same
time have a very strict (DMABUF or fail) kind of pipeline, or implement a
higher level sink plugger that will try pushing puffers to it's prefered sink,
and if that fails choose the best fallback (most of the time this is not SHM
with software conversion but GL, specially that dmabuf support there is nearly
ready and does not require caps feature).
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list