[Gstreamer-openmax] gst-openmax performance

[Felipe Contreras]

On Mon, May 18, 2009 at 10:13 PM, pl bossart <bossart.nospam at gmail.com> wrote:
> 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?

The main reason is so you can seek :)

But also you'll get proper timestamps which are required if you want
to play nice with GStreamer. This is required if you want to use
native GStreamer sinks. This is described somewhat in the wiki:

    For MP3 you'll also need the mp3parse element, otherwise you'll get:
    GStreamer-CRITICAL **: gst_segment_clip: assertion
`segment->format == format' failed

If you really don't want to use mp3dec you can still play with
pulsesink/alsasink by doing this:
omx_mp3dec use-timestamps=false

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

Yeap, but it works fine :)

It's the only real issue I've found with the OpenMAX IL spec,
unfortunately nobody cares =/

The good thing is that I haven't found an implementation where this
hack doesn't 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.
>
> I guess the MP3 decoder does not run on the ARM, unless you run it at 700+MHz?

Heh, nope I forgot to mention that it runs on the DSP side. Just to
prove the point that gst-openmax overhead can't be _that_ big.

-- 
Felipe Contreras