Re: [Gstreamer-openmax] Buffer usage issue in gstreamer plugins for OpenMAX

[Felipe C. <fel...@no...>]

Hi Giulio,

On Wed, 2007-12-05 at 10:32 +0100, ext Giulio URLINI wrote:
> Hi all,
> 	using the 0.10.0.2 of gst-omx there is a problem with the buffer allocation.
> In OpenMAX all the buffers are allocated during the setup with either an
> OMX_UseBuffer or an OMX_AllocateBuffer call. These calls also create a buffer
> header, which is a structure whose pBuffer member points to the actual memory
> buffer. This member is read-only and should not be modified.
> During the processing inside gst-openmax plugins pBuffer is overwritten (see
> gstomx_base_filter.c line 500 of the latest release 0.10.0.2). 
> These buffers have different addresses and size compared to what has been
> declared with OMX_UseBuffer(). This behavior is against the OpenMAX spec, and
> can cause errors.

I have thought about this issue and I agree there are potential issues
with this usage of buffers. The way I think this is more clear is when
an OpenMAX component relying on the nOffset field; when the pBuffer is
modified extra steps are required to copy the left over data and update
nOffset accordingly. This is something gst-openmax is doing and I've not
seen any OpenMAX component relying on this behavior but it might happen.

On the other hand I don't see any part of the standard that specifies
that pBuffer should not be changed by the client. Could you point me to
some text that talks about that?

If indeed that's not allowed by the standard that makes zero-copy very
difficult in GStreamer. At least for output buffers usually an element
asks the next one in the pipeline for a buffer and then it fills the
data directly there.

Please read 2.3.1 in:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-basics-data.html

This approach can be changed for input buffers, but for output buffers I
don't see any other solution.

Any ideas?

-- 
Felipe Contreras