[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 #12 from Aurélien Zanelli <aurelien.zanelli at parrot.com> 2014-07-30 16:47:50 UTC ---
Yes, goto config_failed here will lead decide_allocation to return FALSE and
videodec baseclass returns in error leading to a negotiation failure.

But omxvideodec, for now, only use its internal buffers which are allocated by
the OMX component. So if buffer pool don't suit it, it will not push its
buffer. Instead it will acquire buffer from pool and copy frame to it,

Since I don't know if I'm really clear and because I have some difficulties to
understand the whole picture, you can take a look at these pieces of code:

gst_omx_video_dec_allocate_output_buffers()
http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n545
we will check current videodecoder pool and if it's good create an internal
bufferpool
http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n624

gst_omx_video_dec_loop()
http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n1436
If we have the internal pool (out_port_pool), we will push GstOMXBuffer, else
we will try to allocate an output frame.

However, in case of gst_buffer_pool_config_validate_params failure, it could be
better to create a GstVideoBufferPool.

A better approach may be to refactor/rework the omxvideodec pool management.
For instance, omxvideodec can always have a internal buffer pool and decide to
push buffer from it at decide_allocation time based on what downstream support,
like the v4l2 plugins. However, they can be some issue with OMX layer, so it
can be intersting to know why it has been done in such way.

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