[Gstreamer-openmax] Proposal of new implementation

[Clark, Rob]

2011/1/25 Victor Manuel Jáquez Leal <ceyusa at gmail.com>:
> 2011/1/25 Benjamin Gaignard <benjamin.gaignard at linaro.org>:
>> you are right, the operation flow are very similar but we create an
>> overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph
>
> Aha, the same strategy used in gst-goo [1]. There was a reason why
> Felipec didn't use it, but I don't recalled it right know :s
>
> 1. https://github.com/mrchapp/gst-goo/blob/master/src/gstgoobuffer.c
>


it is similar.. but not really intended for "ghost buffers" (tunneling)..

I guess for most common scenario's Felipec was not using an omx based
sink element.. and also didn't have the same constraints about
physically contiguous buffers in the decoder/encoder elements.  And
also not the same complications of reference counting when sharing
buffers with the decoder.

Benjamin's proposal helps, I think.. at least when there is an omx
based sink element.  Although there are edge cases to think through..
pad_alloc() can fail when downstream element is still flushing, for
example.  Or do you want to (or can you at all) support dynamically
switching sink elements in a pipeline.  GStreamer is quite flexible..
making that flexibility coexist with OpenMAX is sometimes challenging
;-)

BR,
-R

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