[Gstreamer-openmax] gst-openmax performance

[Felipe Contreras]

On Sat, May 16, 2009 at 2:46 AM, pl bossart <bossart.nospam at gmail.com> wrote:
> Bear with me if this is a known issue, it's been 5 years since I last
> looked at OpenMAX IL. Not sure if my ex-colleagues Diego and Giulio
> are still in the loop.
>
> I am trying to quantify the overhead due to gst-openmax, compared to
> plain old existing gstreamer elements. On an Atom/Ubuntu platform in
> ST/GV3off, I get the following residencies:
> madplay: 13% C0
> gst-launch filesrc ! mad ! audioconvert ! alsasink: 16% C0 (fine)
> gst-launch filesrc ! omx_mp3dec ! omx_audiosink: 63% C0 (not good)
>
> Any idea what's happening? All the three configurations rely on the
> same libmad and the same test file.

I assume you are using bellagio omxil. First of all I think you should
measure the overhead of bellagio mp3dec component. I have a simple
test application that you might want to use[1].

Second, I wouldn't recommend to use omx_audiosink, I focus only on
encoders/decoders so I don't know how well performing the rest of the
wrappers are, if they work at all.

Third, it's better if you use mp3parse before omx_mp3dec.

And forth, you can enable zero-copy by turning on
share_{input,output}_buffer flags internally. It's a hack because it's
against the OpenMAX IL standard, but there's no other way to achieve
zero-copy on certain scenarios. You might even need to disable some
checks in bellagio for that to work.

For reference, I've been able to decode MP3's on OMAP3 platform using
~1% of CPU. It was an experimental omx component; TI's component uses
more CPU on ARM side.

Cheers.

[1] http://people.freedesktop.org/~felipec/omx/

-- 
Felipe Contreras