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

[Michael Niedermayer]

Hi

On Mon, Aug 14, 2006 at 09:57:20PM +0300, Siarhei Siamashka wrote:
> 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.

yes
arm opimizations are very welcome ...


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

the license is GPL compatible in the sense that you can link GPL code to it
if all authors of the GPL code explicitly agreed to it, otherwise it is not
so its about as GPL compatible as any other random non free license, IANAL!

note, debian has also rejected the RPSL as non free

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is