1) I use bellagio only for the first tests on my desktop before going on "real" world (I mean on the ARM device from TI, STE or Freescale or anyother with openmax components).
2) Most of the ARM devices don't have hw decoder/encoder with MMU capabilities (and yes it is a shame) so we have to take of that, and the "share buffer" hack doesn't in this case.
3) about gst_pad_alloc_buffer: you are right is it a problem with ring buffer, and Rob comments also suggest that isn't a good idea...
2011/1/26 Felipe Contreras <firstname.lastname@example.org>
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:
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.