[MPlayer-dev-eng] [PATCH] Optimized libmpeg2 routines for ARM/Xscale

Siarhei Siamashka siarhei.siamashka at gmail.com
Sun May 20 10:24:11 CEST 2007


On Wednesday 16 May 2007 13:45, Diego Biurrun wrote:
> On Mon, May 14, 2007 at 11:58:51AM +0200, Guillaume POIRIER wrote:
> > On 5/14/07, Diego Biurrun <diego at biurrun.de> wrote:
> > > On Sun, May 13, 2007 at 04:16:52PM +0300, Siarhei Siamashka wrote:
> > > > The patch is attached. This code is used in maemo builds since
> > > > revision 28:
> > > > https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayer&view
> > > >=rev&rev=28
> > > >
> > > > It passed my '-vo md5sum' tests. Also it reduces decoding time to
> > > > ~105 seconds for the video file that was used for older benchmarks:
> > > > http://article.gmane.org/gmane.comp.video.mplayer.devel/43038
> > >
> > > What about optimizing FFmpeg instead?  libmpeg2 has been orphaned.  I
> > > don't know about ARM, but FFmpeg should be faster at decoding MPEG-1/2
> > > on x86 and PPC...

Can anybody confirm this information with benchmarks? My benchmarks on x86
(Athlon XP) show the following results (used mplayer 1.0rc1-r2 from gentoo for
tests, all MMX/3DNOW/SSE optimizations enabled):

mpeg1:

mplayer -vo null -vc mpeg12 -nosound -quiet -benchmark -loop 5 test.mpg | grep 
BENCHMARKs
BENCHMARKs: VC:   6.037s VO:   0.937s A:   0.000s Sys:   0.510s =    7.485s
BENCHMARKs: VC:   6.011s VO:   0.946s A:   0.000s Sys:   0.526s =    7.483s
BENCHMARKs: VC:   6.042s VO:   0.942s A:   0.000s Sys:   0.525s =    7.509s
BENCHMARKs: VC:   6.000s VO:   0.959s A:   0.000s Sys:   0.521s =    7.480s
BENCHMARKs: VC:   6.031s VO:   0.948s A:   0.000s Sys:   0.523s =    7.502s

mplayer -vo null -vc ffmpeg1 -nosound -quiet -benchmark -loop 5 test.mpg | 
grep BENCHMARKs
BENCHMARKs: VC:   6.337s VO:   0.950s A:   0.000s Sys:   0.578s =    7.866s
BENCHMARKs: VC:   6.346s VO:   0.983s A:   0.000s Sys:   0.579s =    7.908s
BENCHMARKs: VC:   6.339s VO:   0.976s A:   0.000s Sys:   0.575s =    7.889s
BENCHMARKs: VC:   6.327s VO:   0.976s A:   0.000s Sys:   0.575s =    7.878s
BENCHMARKs: VC:   6.373s VO:   0.974s A:   0.000s Sys:   0.573s =    7.919s

mpeg2:

mplayer -vo null -vc mpeg12 -nosound -quiet -benchmark -loop 5 test.avi | grep 
BENCHMARKs
BENCHMARKs: VC:  10.731s VO:   1.963s A:   0.000s Sys:   0.316s =   13.010s
BENCHMARKs: VC:  10.738s VO:   1.976s A:   0.000s Sys:   0.317s =   13.030s
BENCHMARKs: VC:  10.750s VO:   1.964s A:   0.000s Sys:   0.317s =   13.031s
BENCHMARKs: VC:  10.704s VO:   1.975s A:   0.000s Sys:   0.315s =   12.994s
BENCHMARKs: VC:  10.748s VO:   1.966s A:   0.000s Sys:   0.315s =   13.029s

mplayer -vo null -vc ffmpeg2 -nosound -quiet -benchmark -loop 5 test.avi | 
grep BENCHMARKs
BENCHMARKs: VC:  10.928s VO:   1.954s A:   0.000s Sys:   0.326s =   13.208s
BENCHMARKs: VC:  10.929s VO:   1.957s A:   0.000s Sys:   0.324s =   13.211s
BENCHMARKs: VC:  10.935s VO:   1.957s A:   0.000s Sys:   0.326s =   13.219s
BENCHMARKs: VC:  10.942s VO:   1.957s A:   0.000s Sys:   0.327s =   13.226s
BENCHMARKs: VC:  10.938s VO:   1.950s A:   0.000s Sys:   0.325s =   13.212s

> > I wouldn't be surprised that it's because libmpeg2 has already
> > received some attention by ARM hackers, and is quite fast, when
> > FFmpeg's hasn't (yet). So from a purely library user viewpoint, it
> > makes more sense to further optimize libmpeg2....
> > Maybe I'm wrong. If I am, I'm sure Siarhei will correct me... :)
>
> That's a very short-term view.  In the long run it makes sense to work
> with the library that is maintained and developed.

These libmpeg2 optimizations existed even before I started trying to compile
mplayer for ARM, so it required almost zero effort to use them :) As for
FFmpeg, it gets some optimizations for ARM and may become faster than 
libmpeg2 some day. I have some unfinished code for faster ARMv5TE 
optimized IDCT, also mpeg1/mpeg2 ARM optimized dequantizers should 
help.

Also libmpeg2 is much smaller than FFmpeg. I may try (or may not) to
experiment with porting it to C55x DSP later (DSP core in Nokia 770/N800 
which is currently underused and which has a fast hardware IDCT according 
to docs). So I still don't give up on libmpeg2 completely.



More information about the MPlayer-dev-eng mailing list