[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

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at coaxion.net

--- Comment #20 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-09-05 07:25:59 UTC ---
(In reply to comment #19)
> (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 ?

Yes, buffer pool and you need to pre-allocate. And if you want to change
anything you need to deallocate all buffers and allocate new ones.

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

You can only check this by trying to set the maximum btw

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