[FFmpeg-devel] [PATCH] activate ac3 decoder

[Michael Niedermayer]

On Wed, Feb 20, 2008 at 09:32:50AM +0200, Siarhei Siamashka wrote:
> On 19 February 2008, Michael Niedermayer wrote:
> [...]
> > > > 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.
> 
> Fair enough. Except that I don't quite understand your opinion regarding the
> fixed point FFT submission that was rejected (or at least ignored) earlier. If
> it works and the implementation is well hidden behind FFTContext, then who
> cares if it is not efficient (yet)? Provided that it is acknowledged that it
> is not the best one and plans for painlessly upgrading it in the future exist.

As long as i reject some code people work on getting it approved. If i say ok
people stop working on it. So approving some known suboptimal code is not a
good idea. If someone really wants to use it the patches are around. If someone
wants to improve it they can use the patches as well ...


[...]
> So far I like how DJBFFT performs :) It is quite faster than FFmpeg C FFT
> implementation on ARM11 (tested it both standalone and as part of ffvorbis
> decoder). I'm not providing the numbers yet, as I'll try to check various
> variants of code (generic, pentium, sparc, ..) and various optimization
> settings first.
> 
> Benchmarks from other platforms are welcome (the patch I provided in the
> previous post makes it easy to build ffmpeg/mplayer with djbfft support).
> 
> By the way, I also tried to benchmark FFTW3 (support for it can be also
> added to FFTContext very easily), but the results were not too good. My guess
> is that FFTW might be mostly optimized for scientific use, performing FFT on
> huge sets of data which is not the case and overkill for just multimedia
> decoding.

I suspect FFTW is always slower than djbfft. Thats just my gut feeling
though. I didnt benchmark them, and the benchmarks from the FFTW authors
look dubious to me.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/20080220/39c99590/attachment.pgp>