[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 #19 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-09-04 16:40:24 UTC ---
(In reply to comment #18)
> (In reply to comment #17)
> > I think we should fail at this point. Otherwise the corrected (but not
> > acceptable) config will be set on line 2619, which will pretty much always
> > succeed, and lead to pipeline that most of the time will stall rather then
> > fail.
> 
> In fact, I don't think so, because omxvideodec always use OMX buffers. If
> provided pool doesn't suit, instead of giving its internal buffer, it will
> acquire one from pool and copy frame to it. See comment #12 for more details.

Oh I see. Do OMX uses a buffer pool ? can it allocate buffers on the fly or do
it need to pre-allocate everything ?

In such case, we should see something like:

Check if omx internal buffers require video meta and if downstream support
video meta. If we do need video meta to be added, and downstream don't support
it, enable copy mode.

Check if oxm internal pool min/max can be adjusted to fit downstream min + omx
min. If it cannot be adjusted, copy mode.

If not in copy mode, replace the pool in the query with your own, otherwise
downstream pool maybe initialized for no reason.

If in copy mode, set the config with value from downstream (you don't need
extras) and leave it in the query. You'll have to initialize your own pool
yourself. Whenever you get buffers from you own pool ready, acquire from
downstream pool, copy, and push the copy.

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