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

[Daniel Charles]

Hi,

AFAIK the Khronos people are putting together what it is going to be
the 2.0 OpenMAX spec and they want to know the challenges GStreamer is
going to face for the proper interaction between layers.  If they are
still receiving inputs it is a good time to ask them to consider the
sharing buffer capabilities more precisely with the output port
buffers. So far, I understand that they have put some effort on
creating an appropriate way  to use the OpenMAX clock at the GStreamer
level.

Thanks,

Daniel.

On Dec 6, 2007 7:46 AM, Giulio URLINI <giulio.urlini at st.com> wrote:
> 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?
> >
> >
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Gstreamer-openmax mailing list
> Gstreamer-openmax at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
>