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 <ceyusa@gmail.com> a écrit :
On Mon, Jan 24, 2011 at 2:16 PM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> 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
> Gstreamer-openmax@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
>
>