Re: [Gstreamer-openmax] Proposal of new implementation

[Benjamin G. <ben...@li...>]

you are right, the operation flow are very similar but we create an
overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph

With gstomxbuffer the sequence is no more:
emptybufferdone -> memcpy in gst buffer -> fillthisbuffer -> pad push
gstbuffer
it becomes:
emptybufferdone -> pad push gstomxbuffer -> gstomxbuffer unref ->
fillthisbuffer
Benjamin
Le 25 janvier 2011 10:58, Victor Manuel Jáquez Leal <ce...@gm...> a
écrit :

> On Mon, Jan 24, 2011 at 2:16 PM, Benjamin Gaignard
> <ben...@li...> wrote:
> > Hi,
> >
> > For Linaro project I working on a new implementation of gst-openmax to
> allow
> > zero copy between OMX element in gstreamer.
>
> Glancing the diagrams, the operation flow is pretty much what
> gst-openmax does. Am I wrong? But if so, why another implementation?
> Forking is the only option?
>
> vmjl
>
> >
> > On this page:
> >
> https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor
> > I have put sequence diagrams of what we want to achieve.
> >
> > We are looking for feedbacks about this proposal and all comment are
> > welcome.
> >
> > Benjamin
> >
> ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better
> price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Gstreamer-openmax mailing list
> > Gst...@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
> >
> >
>