[MPlayer-dev-eng] Re: [a52-dev] libac3/liba52 - sse/3dnow?

Michel LESPINASSE walken at zoy.org
Mon Nov 12 12:19:56 CET 2001


On Mon, Nov 12, 2001 at 12:10:39PM +0100, Dag B wrote:
> I understand that the mplayer guys got some assembly in their ac3 decoder.
> http://www.mplayerhq.hu/homepage/info.html
> 
> Are there any plans to merge this in to the current liba52, for the benefit
> of all the projects using this library? 

I think it is clear that the IMDCT code is the least optimized part of
liba52 right now. So it would be nice to improve it.

It is built around an FFT transformation, which right now is
implemented as a radix-2 algorithm. It would probably be best to
switch it to use either a radix-4 algorithm or a split-radix. Dan
Bernstein's djbfft code is probably a good place to look at, but for
me it was only understandable up to version 0.50 or 0.55 - after that
there is so much architecture-dependant changes (and
compiler-dependant too, dan recommends that we build his code with -O
not -O2 so we dont defeat his clever hand-scheduling) trying to get
gcc to compile faster code that it becomes really really hard to
follow.

If I had some free time, this is what I'd like to do:

1- look at earlier djbfft versions again, probably 0.50 or 0.55, and
make a simple adaptation of it in liba52. The ideal here is to get it
as simple as possible - the c optimizations in later versions of
djbfft are so compiler-specific and architecture-specific that they
dont really justify the code obfuscation.

2- look at the optimized sse versions around and check these in too

> Unless I am mistaken, Michel L. hopes for a patch from Arpi & friends.
> I don't know if Arpi or Nick got any incentives to make such a patch, other
> than being the Good Guys (TM)?

I have had a quick (well, about one evening still) look at the mplayer
changes but I was a bit confused about how it all worked, and I dont
like to just check in things that I dont understand at all :) I
suppose it is based on newer versions of djbfft code that I wasnt able
to understand either.

If someone in the mplayer team was willing to feed me a subset of the
mplayer changes, with an unsophisticated (easier to read) c version of
the algorithm, that would drive me 75% of the path. Once the
infrastructure is in place merging the asm versions will be easy.

> Anyone else got the 'itch' and the capabilities to do this? And would the
> Mplayer guys be offended by this?

If someone wants to help on the c part of this I would appreciate this
a lot. I know if I had time I could probably do it (based on djbfft
0.50 or 0.55) but its not really the case right now... If someone
sends me patches I will still seriously look at these though.

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.



More information about the MPlayer-dev-eng mailing list