[FFmpeg-devel] [PATCH] activate ac3 decoder

[Siarhei Siamashka]

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.

Would it be wise to just optimize current FFT from ffmpeg? It looks quite
simple and straightforward. If not, what is the expected timeframe for the
introduction of a better FFT algorithm to ffmpeg so that it could be optimized
instead?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-djbfft-support.diff
Type: text/x-diff
Size: 4780 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080219/3184b9de/attachment.diff>