[FFmpeg-devel] [PATCH] activate ac3 decoder
Wed Feb 20 14:51:42 CET 2008
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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel