[Mplayer-cvslog] CVS: main/mp3lib decode_MMX.c,1.8,1.9

Arpi arpi at thot.banki.hu
Mon Oct 27 10:44:56 CET 2003


Hi,

> > > > > reverting my last change as buggy gcc 3.x fails with it :(
> > > >
> > > > gcc addresses local variables by ebp or esp, and push/pop change esp
> > > > so it cant work (the correct solution would be to make some free space
> > > > manually on the stack and use that instead)
> > >
> > > Strange is that it worked on 2.95.x
> > >
> > > Actually the whole code could be rewritten..it's crappy
> >
> > Actually optims should be ported/redone for ffmp3 and finally rm -rf mp3lib
> > its just broken in many ways, not worth to fix.
> I'm no mp3lib fan either, but keep in mind that it is still a lot faster on 
> older systems (eg. Pentium II. tested that recently).

It's still a lot faster on any x86 systems, maybe on others too.
I was trying to find bottlenecks of ffmp3, and optimize it but failed.
The 3 most critical functions of ffmp3:
  compute_antialias
  compute_imdct
  synth_fv

they are slow for 2 reasons:
- no SIMD optims at all
- uses integer (fixedpoint) only, which seems to be slower on intel x86 than float

it's like ffmpeg12 vs. libmpeg2 was, but that situation improved a lot
thanks to Michael.

btw i have a mpegaudiodec.c version with optional float support, but
it doesnt work and after 3 days i gave it up to found the 100l.
probably the bitstream parsing and dequantization should be done in
fixed point, then convert to float, and do antialias + imdct in float,
using code from mp3lib. converting the parser+equant to float seems
horrible, the code is full of bit shifting tricks and int lookup tables.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



More information about the MPlayer-cvslog mailing list