[maemo-developers] Python and GStreamer

[From: Siarhei Siamashka]

On 30 August 2007, Jesse Guardiani wrote:
> Koen Kooi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jesse Guardiani schreef:
> >>>     And the related question is: given an existing program that sends
> >>>     stuff out to ALSA and doesn't use gstreamer, how difficult is it
> >>>     generally to port it so that it works properly?
> >>
> >> No porting necessary, really. mplayer comes with a decoder called
> >> libmp3. It's not optimized for ARM or anything, and it compiles without
> >> any problems. We don't use it in Kagu for A2DP though because there is
> >> another decoder out there called ffmp3 which doesn't use floating point
> >> math, so it's a little more efficient on ARM.
> >
> > use libmad (-ac mad), that works great on arm and x86.
>
> Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3
> is the best choice on ARM.

Just for the sake of correctness, I did not quite say that :) This is what 
I replied to you earlier when we were discussing A2DP performance issues:

"Software MP3 (-ac ffmp3) and OGG/Vorbis (don't remember exact '-ac' option
for it, but you don't need it anyway as this decoder is used by default)
decoders are already enabled in mplayer. If we want the best MP3 decoding
performance, libmad (-ac mad) is the best choice, but it is an external
dependency and is not used right now. The worst option for software MP3
decoding on ARM is mp3lib (-ac mp3), it uses floating point math and is a lot
slower than other (fixed point) MP3 decoders even on N800 which supports
floating point math in hardware.

You can try to test all these decoders yourself to figure out which one 
works the best for you."


Just ffmp3 is a part of ffmpeg library and is bundled with mplayer by default
and libmad is an external dependency which may make packaging a bit more
complicated. That's the only reason why libmad support is not enabled in 
maemo build of mplayer yet.