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

[Giulio URLINI]

Hi Felipe,
    I agree that the potential issue is when an OpenMAX component uses 
the full features given with the offset and filled length values.
Other issues are possible, especially when an hardware component 
replaces the more flexible software library.
The spec does not clearly state that the pair buffer header - buffer is 
atomic, but it is implicit, I think. I've also discussed this topic with 
the OpenMAX Khronos members, and they agree about this point.
In any case I think that solving this issue is useful here, because the 
gst omx plugins can be a reference for developers about the correct way 
to use OpenMAX components.
Regarding a possible solution, I agree that it is not trivial. I'll go 
thought the other plugins used, and I'll check the various document, to 
find if something can be done in order to avoid the buffer copy.
Regards,
Giulio



Felipe Contreras wrote:
> 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?
>
>