[MPlayer-dev-eng] mp3 decoding performance on ARM

[Siarhei Siamashka]

On Monday 14 August 2006 01:29, Michael Niedermayer wrote:

> > > Have you tried ffmp3?  The MP3 decoder in FFmpeg is integer-only.  I'd
> > > be interested to know how it performs compared to libmad.
> >
> > Nokia 770, ARM926EJS 250MHz cpu
> >
> > 128kbit constant bitrate soundtrack, length 6:13
> > MPlayer 1.0pre8, libmad 0.15.1b
> >
> > time ./mplayer -quiet -ac mad -ao pcm:fast:file=/dev/null -vo null -vc
> > null test.mp3
> > ...
> > real    0m 46.92s
> > user    0m 46.22s
> > sys     0m 0.50s
> >
> > time ./mplayer -quiet -ac ffmp3 -ao pcm:fast:file=/dev/null -vo null -vc
> > null test.mp3
> > ...
> > real    1m 27.84s
> > user    1m 26.91s
> > sys     0m 0.64s
>
> please retry this with CONFIG_MPEGAUDIO_HP disabled, and dont forget
> make distclean, also ensure that the decoder uses integers for the
> antialias filter, theres also a float version of that ...

Thanks for the hint, done this test (and yes, I checked that no floating
point is used in antialias filter). Performance really improved , but not too
much to be really excited:
real    1m 15.40s
user    1m 14.61s
sys     0m 0.53s

After borrowing MULH implementation which uses ARM inline assembler from
Tremor (it is called MULT32 there), performance got a bit better even more:
real    1m 12.04s
user    1m 11.03s
sys     0m 0.64s

So I guess that replacing all the other performance critical macros with
optimized versions,  ffmp3 could probably get much faster and closer to
libmad. But that's probably outside of scope of this mailing list, maybe it
is better to subscribe to ffmpeg mailing list and submit any ffmpeg related
patches there.

Also tested performance on ordinary desktop athlon xp system, ffmp3 is faster
than libmad here, so looks like it is really asembler optimized code that
makes the difference. Also ffmp3 does not suffer from audio/video sync bug:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-August/045017.html
Though I still have plans to try fixing this libmad bug eventually as I have
some other audio decoder based on it suffering from the same problem.

And just for completeness sake, here is the result of benchmarking '-ac mp3'
(it is not even capable of decoding audio in realtime):
real    8m 22.73s
user    8m 20.30s
sys     0m 1.60s

> > But I also found the following link which is advertised to have fast
> > fixed point mp3 decoder (17MHz for decoding 128kbit soundtrack):
> > https://datatype.helixcommunity.org/mp3dec.html
> >
> > Using above statistics, libmad cpu requirements estimate is 31MHz, and it
> > is somewhat higher than helix decoder advertised numbers. Surely mplayer
> > itself adds some overhead in demuxing and buffering, but probably helix
> > decoder is worth trying. Now trying to figure out how to get its sources
> > from CVS and what is that RPSL license :-)
>
> something which probably has nothing to do with the word free or open ...

Well, it is presented as GPL compatible (did not have time to read the whole
text though): https://community.helixcommunity.org/content/rpsl

And this fixed point mp3 decoder sources are available as part of helix player
which can be downloaded here: 
http://forms.helixcommunity.org/helix/builds/?category=hxplay-stable

I had a quick look at it, API seems to be quite clean and simple, so wrapping
it into a decoder module for MPlayer and testing performance should be not too
hard. If it is really very fast, it would make sense reading its license more
carefully to check whether it can be legally used as an external decoder :-)