[FFmpeg-devel] [PATCH] activate ac3 decoder

[Michael Niedermayer]

On Tue, Feb 19, 2008 at 04:43:38AM +0200, Siarhei Siamashka wrote:
> On 16 February 2008, Siarhei Siamashka wrote:
> > On 10 August 2007, Michael Niedermayer wrote:
> > > > > 2. implement djbfft support (this should be trivial considering that
> > > > > liba52 needs something like 5 lines of code for it)
> > > >
> > > > According to the website djbfft uses a split-radix-2/4 FFT. This looks
> > > > like what you are after isn't it?
> > > > Why don't we just cannibalize the relevant parts of djbfft and make do
> > > > without step 1 of your checklist (1. implement a plain C split radix
> > > > fft)? I couldn't figure out what's the license of djbfft so I don't
> > > > know if that's possible though :-(
> > >
> > > djbfft has no proper license AFAIK it just says
> > > on http://cr.yp.to/djbfft/faq.html
> > >
> > > "Can I use djbfft in my own code?
> > >
> > > Yes. Please tell me what programs you're using it in so that I can let
> > > NSF know."
> > >
> > > maybe someone should _politely_ ask the author if he would mind the code
> > > to be used in ffmpeg (requireing LGPL)
> > >
> > > but before asking we should benchmark the code, it would be silly to ask
> > > and then realize that some other code which is under LGPL/BSD is faster
> >
> > According to the following link, looks like djbfft is supposed to be
> > public domain now:
> > http://linux.slashdot.org/article.pl?sid=07/11/30/0430201
> >
> > Is it a good time to reconsider the "cannibalizing" plan again? Has anybody
> > benchmarked it already?
> 
> A proof of concept patch that adds djbfft support to ffmpeg (IFFT only) is
> attached. Below are some benchmark results using fft-test utility 
> (tested on AMD Athlon-XP 2400+, 2.0GHz):
> 
> IFFT             256   512  1024  2048   4096   8192
> ----------------------------------------------------
> fft ffmpeg(SIMD) 3.9   8.4  18.2  39.8  100.5  268.8
> fft ffmpeg(C)    8.2  18.4  40.4  89.4  200.8  499.4
> djbfft           6.3  14.2  32.1  72.8  159.7  380.2
> 
> I can try to do benchmarks on ARM11 later (actually these are the most
> interesting for me).
> 
> So what next? Are there still any plans regarding FFT/IMDCT improvements?
> I would like to start adding some ARM VFP optimizations to FFT in the near
> future, so it would be nice to know current situation.

The current situatio is the same as it was. I review patches, and if they
improve speed, are optimal (split radix), clean, simple, ...
i approve them else i reject them.


[...]
> +    if (s->tmp_buf) {
> +        /* TODO: handle DJBFFT permute in a more optimal way, probably in-place */
> +        for(j=0;j<np;j++) s->tmp_buf[revtab[j]] = z[j];
> +        memcpy(z, s->tmp_buf, np * sizeof(FFTComplex));
> +        return;
> +    }
> +
>      /* reverse */
> -    np = 1 << s->nbits;
>      for(j=0;j<np;j++) {
>          k = revtab[j];
>          if (k < j) {

This looks odd, are you duplicating the bit reverse code?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- 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/20080219/adcaac9f/attachment.pgp>