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

Michael Niedermayer michaelni
Thu Aug 16 23:37:30 CEST 2007


Hi

On Thu, Aug 16, 2007 at 11:11:51PM +0200, Guillaume POIRIER wrote:
> Hi,
> 
> On 8/16/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Aug 16, 2007 at 04:41:21PM +0200, Guillaume POIRIER wrote:
> > > Well, don't forget that according to Michael, FFmpeg's FFT sucks, so
> > > writing a fixed-point version of a sucky implementation may not be so
> > > wise :-(
> >
> > dont fear ill revert any cooley tukey fixed point FFTs which get commited
> 
> Hehe :)
> 
> > which brings us back to what i already said ... someone should implement
> > a split radix fft (changing the current float fft to split radix would
> > surely be nice as well...)
> 
> I have a question regarding the API of FFTs:
> 
> When I made my review of the state of the art, I noted that FFTW, IPP
> and MKL seemed to offer only a pair of Real and Imaginary arrays to be
> passed to their computation functions, whereas FFmpeg's API supports
> only an array of pair of Real, Imaginary numbers.
> So it looks like this:
> fft_mkl(double *real_array, double *imaginary, int size)
> fft_ffmpeg(struct_complex *pair, int size)
> 
> Michael, do you have any strong opinion about this?

yes i do
first implement a split radix fft
second try to optimize it, (try different ways to pass arguments to it
and so on)

dont try to optimize code before you wrote it, that leads to long
discussions greatly exceeding the time it would have taken to implement
all possibilities and benchmarking them
while you still at the end know as much as you did before, that is you
dont know which order is better
maybe SIMD benefits from this partitioning, C almost certainly does not
but that doesnt awnser which order is better or if we should somehow support
both ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070816/331d1e10/attachment.pgp>



More information about the ffmpeg-devel mailing list