[Bug 733614] Zero copy path between omxvideodec and v4l2sink

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=733614
  GStreamer | gst-omx | git

--- Comment #24 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2014-09-16 13:25:59 UTC ---
(In reply to comment #22)
> OMX_UseBuffer() is completely useless API, like the USERPTR API in v4l2. You
> can pass any type of memory in there but the port can reject it, and you have
> no idea what kind of memory the port actually wants.
> 
> I also some OpenMAX implementations where no system memory pointer was passed
> to OMX_UseBuffer() but handles (think of file descriptors).

I must say this is a slight contradiction. Julien and I have used USERPTR
successfully on the Cotton Candy with the exact same approach (except we had
v4l2videodec instead of OMX dec). It obviously depends on the driver being able
to handle the type of memory produced by previous element, hence is dedicated
to controlled environment.

What I understand of this bug is that omx decide_allocation is broken, and
similarly to v4l2, this is really complex as there is many details that need to
be considered. In this mode, v4l2 should probably not offer a pool, but omx dec
should read the pool configuration as a something to be added to it's own
requirement. I think my last review described this well.

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