[Bug 784847] omxvideodec: add dmabuf support for zynqultrascaleplus

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #12 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Guillaume Desmottes from comment #9)
> I think I fixed all your comments. The two remaining open questions are:
> - Do we want the allocators as a soft dep or not?

The DMABuf allocator won't compile on Windows or any non-posix system because
it uses the posix API directly (like mmap()). libgstallocators compile out that
allocator on non-linux which forces pretty much all the users to out-compile it
too.

So far gst-omx has only bee deployed on Linux I think, but still, we could at
least check the OS before doing the include. In current case it's easy, if we
have Allegro's DMABuf extension, we include it, otherwise we ifdef it out. One
suggestion, to make it easier for other platform that would like to adopt
Allegro proposed API, would be to keep that code under a single ifdef (removing
the if ZINQ...).

> - Should we fallback to the classic mode if DMA failed?

If we negotiate SystemMemory, we should, since classic mode is able to copy the
frames to fix the alignment. Though, if we negotiate DMABuf caps feature, we
can't, we'll have to error out if importation failed. Until we can figure-out a
way to negotiate more stuff through DMABuf caps feature. Remains that this is
embedded, were the allocation is well controlled, so I would not be worried
either way. I would not even make it a blocker if we have no fallback.

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