[FFmpeg-devel] Fwd: Fixpoint FFT optimization, with MDCT and IMDCT wrappers for audio optimization

Marc Hoffman mmhoffm
Thu Aug 16 16:18:06 CEST 2007


On 8/15/07, Mike Giacomelli <giac2000 at hotmail.com> wrote:
> > From: mmh at pleasantst.com
> > Date: Wed, 15 Aug 2007 11:57:20 -0400
> > To: ffmpeg-devel at mplayerhq.hu
> > Subject: [FFmpeg-devel]  Fixpoint FFT optimization,   with MDCT and IMDCT wrappers for audio optimization
> >
> > Mike Giacomelli writes:
> >  > Sorry for the hotmail nonsense.  I will try my gmail account.  Hopefully it
> >  > will behave better.
> >  >
> >  > >On Mon, Jul 30, 2007 at 10:33:16PM -0400, Marc Hoffman wrote:
> >  > > I will do it if it makes sense right now I don't see it being the most
> >  > > efficient. Lets get through the basic acceptance and when you and I
> >  > > decide to move forward we can talk about more efficient mechanisms for
> >  > > general machines. (I'm not going anywhere so even if you accept this
> >  > > we can change it in the future).
> >  > >
> >  > > The split radix is not the most efficient way to do things on the
> >  > > BlackFin machine. It has to do with all the extra pointer stuff you
> >  > > need to maintain. On other machines this is more efficient. Not to
> >  > > go into this too much anyways I agreed earlier to implement this for
> >  > > us (ffmpeg-devel) and I will just not right now. I really want to see
> >  > > if I/we can get one audio codec to work in fixEDpoint and achieve high
> >  > > quality I think this is what you/we really care about anyways.
> >  >
> >  > Marc,  I've implemented a the ffmpeg wma decoder in fixed point for Rockbox
> >  > while you were discussing this.  Sadly I didn't see your mailings until
> >  > now.  The code is a huge mess, but quite functional on several portable mp3
> >  > players.  I converted the MDCT/FFT to fixed point in a very similar way as
> >  > above, and got very good results (typically 15 bits identical to the fp
> >  > version) and good playback (needs about 40MHz on my iPod).
> >  >
> >  > Please feel free to take a look at the code:
> >  > http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libwma/
> >  >
> >  > Though once again, the code is extremely messy, and I'm still tracking down
> >  > a handful of remaining bugs.
> >
> > Mike,
> >
> > I will take a look at it, I guess its identical to the existing
> > reference FFT.  Maybe thats a better place to start, considering I had
> > to put this project aside for the rest of the month.  I think I will use
> > yours to start when I pick it up again.
> >
> > Thanks
> > Marc
>
> I've tweaked the MDCT code a tiny bit to use less memory, the stock
> code is in one of the earlier commits, but it used too much memory for
> some of our audio players.  The iFFT is just the stock FFMPEG one with
> the CMULs rewritten in asm/c to do fixed point ops on ARM and Coldfire
> using Q16.16 format for samples and Q1.31 for trig operations.
>
> Anyway, we're very interested in this idea.  Right now the iMDCTs used
> by Rockbox for WMA, AAC and probably Ogg are not particularly fast.  A
> faster algorithm would do nice things for our battery life, and since
> it could be reused, we'd speed up all 3 formats.

I'm thinking that it might be better to define a fix point fft based
on the reference float version like you have done.  And then hook
optimizations via dsputils DSPContext, then you can just override the
default behavior how ever you want for what ever platform you desire.

What do you think?

Marc




More information about the ffmpeg-devel mailing list