[Gstreamer-openmax] Proposal of new implementation

[Felipe Contreras]

Hi,

On Mon, Jan 24, 2011 at 3:16 PM, Benjamin Gaignard
<benjamin.gaignard at linaro.org> wrote:
> For Linaro project I working on a new implementation of gst-openmax to allow
> zero copy between OMX element in gstreamer.
>
> 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.

Here are my comments:

1) Why bellagio?

Bellagio is largely unmaintained and too complicated IMO. I have
contributed to the bellagio project, and although I think it has
contributed greatly to the OpenMAX ecosystem, I think I can write
something simpler that does the same in a short period of time. In
fact, I kind of did already:

https://github.com/felipec/libomxil-g

This is a good example of how simple an OpenMAX IL implementation can be.

Also, recently bellagio stopped working at all for me.

2) gst-openmax already has zero-copy support

Through the "share buffer" hacks, which is not ideal, but it works on
the implementations that support this. Any hardware that has an MMU
(all decent hw should) should have no trouble with it.

Your solution on the other hand would _not_ provide zero-copy support
for non-omx elements.

3) Your solution doesn't conform with GStreamer API

You can't just pad_buffer_alloc() and unref a buffer. If this buffer
comes from a sink that has a ring-buffer, like pulsesink, the sequence
would be screwed up.

This could be easily fixed by checking of the next element implements
the gst-openmax interface, and add some kind of query.

Cheers.

-- 
Felipe Contreras