[Gstreamer-openmax] gst-openmax performance

pl bossart bossart.nospam at gmail.com
Mon May 18 12:13:52 PDT 2009


Thanks Felipe for your reply.

> 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].

Yes this is after having installed bellagio and gst-openmax as per
your freedesktop web site. Thanks for the pointer, will give it a try.

> 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.

Well, I tried to use alsasink or pulsesink instead, no luck. Cannot
mix gstreamer elements with omx ones. Not sure if this is a Bellagio
issue or an gst-openmax one...

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

Not sure why, this relies on libmad which does not need pre-parsing?

> 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.

Sounds ugly....

> 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.

I guess the MP3 decoder does not run on the ARM, unless you run it at 700+MHz?




More information about the Gstreamer-openmax mailing list