[Bug 759358] Add GST_CAPS_FEATURE_MEMORY_DMABUF "memory:DMABuf"

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759358

Julien Isorce <julien.isorce at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benjamin.gaignard at gmail.com
                   |                            |, daniel at fooishbar.org,
                   |                            |george.kiagiadakis at collabor
                   |                            |a.com, slomo at coaxion.net

--- Comment #7 from Julien Isorce <julien.isorce at gmail.com> ---
Here is the draft I am suggesting to describe how this caps feature should be
used. That would be great if we can build from that. (even if we change all of
it in the end). I.e., let try to refine the following logic:

1- General idea:
The exporter element either the sink (wldmabufsink) or decoder
(gstvaapidecodebin / gstv4l2videodec), should try to map the first buffer. If
it fails then it adds the caps feature, otherwise it does not add it.
That logic could be implemented in the src / decoder / transformer / sink bases
classes or somewhere else if more appropriate.

2: Customizable
The idea is to assume the mmap is not expensive by default. Cases where it is
known to be slow or known to fail to mmap, should be treated as a special case
(platform dependent or so) in the derived gst element itself (example
wldmabufsink ?).
Same note for the other way around, i.e. disable this first mmap if it is knows
to succeeds or it is a requirement. This should treated as a special case.
We should have helpers to turn these ON/OFF easily.

3: the case where the user explicitly does:
... elem1 ! video/x-raw(memory:DMABuf) ! elem2 ...
should always be accepted between an exporter and an importer (or reverse
case).
The pipeline should always try to run this way even if it fails to import or
so.
(In other word exporter / importer should not reject the caps feature if
someone provide it explicitly)

4: There is no negotiation of any allocator. By default an exporter will always
try to push its buffers. In-place transformers element will succeeds according
to that first "try map buffer". Then if importer fails the exporter should fall
back to raw/software.
Again this default behavior should be customizable from the derived classes if
needed.

Note:
At first glance the "confirmation" mmap might add an overhead during caps
negotiation. But it should be compensated by the fact it will be already in the
cache for processing by downstream elements. Also as said above it can be
disabled if necessary, so it will only apply to the default behavior.

Do not hesitate to comment on any point, thx!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.