[PATCH] activate ac3 decoder
Hi, The AC-3 decoder is at a point where it can be activated. Really it has been working for a while, but I wanted to get downmixing correct before activating it. This patch works for me, but I'm not absolutely sure that it's the correct way to do it. I'm definitely not done with the changes to the decoder...I just think it has enough working features now to be fully included in FFmpeg. For now it's still licensed as GPL. I'm about 95% confident that the parts derived from liba52 are now gone, but I'm not 100% sure. Once the E-AC3 decoder is added and if Michel Lespinasse gives his blessing, then it can be changed to LGPL at that time. -Justin
Hi On Sat, Aug 04, 2007 at 09:36:05PM -0400, Justin Ruggles wrote:
Hi,
The AC-3 decoder is at a point where it can be activated. Really it has been working for a while, but I wanted to get downmixing correct before activating it. This patch works for me, but I'm not absolutely sure that it's the correct way to do it.
I'm definitely not done with the changes to the decoder...I just think it has enough working features now to be fully included in FFmpeg.
iam ok with enabling it, mans/diego? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
On Sat, Aug 04, 2007 at 09:36:05PM -0400, Justin Ruggles wrote:
The AC-3 decoder is at a point where it can be activated. Really it has been working for a while, but I wanted to get downmixing correct before activating it. This patch works for me, but I'm not absolutely sure that it's the correct way to do it.
I'm definitely not done with the changes to the decoder...I just think it has enough working features now to be fully included in FFmpeg.
For now it's still licensed as GPL. I'm about 95% confident that the parts derived from liba52 are now gone, but I'm not 100% sure. Once the E-AC3 decoder is added and if Michel Lespinasse gives his blessing, then it can be changed to LGPL at that time.
You could also just ask Michel if he thinks they are gone. If he gives his blessing, all would be well.
--- configure (revision 9911) +++ configure (working copy) @@ -1594,6 +1595,9 @@
+# disable the native AC-3 decoder if liba52 is enabled +enabled liba52 && disable ac3_decoder
Possibly we should remove liba52 support, same as we did for libdca/libdts. The patch is fine, commit anytime. Diego
Diego Biurrun wrote:
On Sat, Aug 04, 2007 at 09:36:05PM -0400, Justin Ruggles wrote:
--- configure (revision 9911) +++ configure (working copy) @@ -1594,6 +1595,9 @@
+# disable the native AC-3 decoder if liba52 is enabled +enabled liba52 && disable ac3_decoder
Possibly we should remove liba52 support, same as we did for libdca/libdts.
Right now it's a bit slower. For straight channel-for-channel decoding it's about 3%-per-channel slower on my machine. With downmixing 5.1 to stereo it's closer to 30% slower. I'm working on better downmixing though. Basically I need to work out how to downmix before the IMDCT, not after. I've got papers on the subject, but I need to delve into the math to implement it properly.
The patch is fine, commit anytime.
applied. -Justin
Hi, On 8/7/07, Justin Ruggles <justinruggles at bellsouth.net> wrote:
Diego Biurrun wrote:
On Sat, Aug 04, 2007 at 09:36:05PM -0400, Justin Ruggles wrote:
--- configure (revision 9911) +++ configure (working copy) @@ -1594,6 +1595,9 @@
+# disable the native AC-3 decoder if liba52 is enabled +enabled liba52 && disable ac3_decoder
Possibly we should remove liba52 support, same as we did for libdca/libdts.
Right now it's a bit slower. For straight channel-for-channel decoding it's about 3%-per-channel slower on my machine. With downmixing 5.1 to stereo it's closer to 30% slower. I'm working on better downmixing though. Basically I need to work out how to downmix before the IMDCT, not after. I've got papers on the subject, but I need to delve into the math to implement it properly.
Does it take advantage of existing DSP functions of FFmpeg? Does it take advantage of SIMD-optimized code? What's the slowest part of AC3 decoding currently? Guillaume -- A soldier will fight long and hard for a bit of colored ribbon. -- Napoleon Bonaparte
Guillaume POIRIER wrote:
Hi,
On 8/7/07, Justin Ruggles <justinruggles at bellsouth.net> wrote:
--- configure (revision 9911) +++ configure (working copy) @@ -1594,6 +1595,9 @@
+# disable the native AC-3 decoder if liba52 is enabled +enabled liba52 && disable ac3_decoder Possibly we should remove liba52 support, same as we did for
On Sat, Aug 04, 2007 at 09:36:05PM -0400, Justin Ruggles wrote: libdca/libdts. Right now it's a bit slower. For straight channel-for-channel decoding it's about 3%-per-channel slower on my machine. With downmixing 5.1 to stereo it's closer to 30% slower. I'm working on better downmixing
Diego Biurrun wrote: though. Basically I need to work out how to downmix before the IMDCT, not after. I've got papers on the subject, but I need to delve into the math to implement it properly.
Does it take advantage of existing DSP functions of FFmpeg? Does it take advantage of SIMD-optimized code?
yes, and yes.
What's the slowest part of AC3 decoding currently?
I haven't profiled it yet, but my best guess is the 512-point IMDCT. -Justin
Hi On Tue, Aug 07, 2007 at 06:14:59AM -0400, Justin Ruggles wrote: [...]
What's the slowest part of AC3 decoding currently?
I haven't profiled it yet, but my best guess is the 512-point IMDCT.
official liba52 has a split radix FFT writen in C it doesnt have a SSE one, it also supports djbfft (which itself neither supports SSE AFAIK) our fft is crap, all of it ... the C fft is a very slow cooley tukey fft our SSE fft contains unneeded instructions (see MPlayer-svn/mplayer/liba52/imdct.c for anonther inefficit cooley tukey SSE fft but at least with fewer SSE instructions, note this one was writen by me ...) so to solve this and make our code faster 1. implement a plain C split radix fft 2. implement djbfft support (this should be trivial considering that liba52 needs something like 5 lines of code for it) 3. fix the SSE code so it doesnt do redundant moves 4. implement a split radix SSE FFT [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle
Hello, Michael Niedermayer wrote:
On Tue, Aug 07, 2007 at 06:14:59AM -0400, Justin Ruggles wrote: [...]
What's the slowest part of AC3 decoding currently? I haven't profiled it yet, but my best guess is the 512-point IMDCT.
official liba52 has a split radix FFT writen in C it doesnt have a SSE one, it also supports djbfft (which itself neither supports SSE AFAIK)
It indeed doesn't look like djbfft has SSE-optimized code.
our fft is crap, all of it ... the C fft is a very slow cooley tukey fft our SSE fft contains unneeded instructions (see MPlayer-svn/mplayer/liba52/imdct.c for anonther inefficit cooley tukey SSE fft but at least with fewer SSE instructions, note this one was writen by me ...)
so to solve this and make our code faster 1. implement a plain C split radix fft
You seem to be putting a very big focus on getting the FFT that has the fewest number of computations. Indeed, split-radix is the most efficient in terms of using the fewest number of add and mul. However, after reading some different papers on FFTs and googling around, I'm not that convinced. This paper: http://www.fftw.org/fftw-paper-icassp.pdf by FFTW people show that in practice, there are other things to take into account (e.g. CPU cache) than just the number of computations. There seem to be so many FFT libs out there that I wonder if we really need to write our own, except, of course if there aren't any decent that's LGPL-compatible. Heck, if we didn't care about the license, Intel's IPP is clearly the best choice out there ;-) J/K
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 :-( Guillaume
Guillaume Poirier skrev:
Hello,
[...]
You seem to be putting a very big focus on getting the FFT that has the fewest number of computations. Indeed, split-radix is the most efficient in terms of using the fewest number of add and mul.
However, after reading some different papers on FFTs and googling around, I'm not that convinced. This paper: http://www.fftw.org/fftw-paper-icassp.pdf by FFTW people show that in practice, there are other things to take into account (e.g. CPU cache) than just the number of computations.
There seem to be so many FFT libs out there that I wonder if we really need to write our own, except, of course if there aren't any decent that's LGPL-compatible.
Agree on that.
Heck, if we didn't care about the license, Intel's IPP is clearly the best choice out there ;-) J/K
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 :-(
Guillaume
Don't forget KISS FFT. It's BSD (the good BSD) licenced. MvH Benjamin Larsson
Hi On Fri, Aug 10, 2007 at 10:14:27AM +0200, Guillaume Poirier wrote: [...]
our fft is crap, all of it ... the C fft is a very slow cooley tukey fft our SSE fft contains unneeded instructions (see MPlayer-svn/mplayer/liba52/imdct.c for anonther inefficit cooley tukey SSE fft but at least with fewer SSE instructions, note this one was writen by me ...)
so to solve this and make our code faster 1. implement a plain C split radix fft
You seem to be putting a very big focus on getting the FFT that has the fewest number of computations. Indeed, split-radix is the most efficient in terms of using the fewest number of add and mul.
However, after reading some different papers on FFTs and googling around, I'm not that convinced. This paper: http://www.fftw.org/fftw-paper-icassp.pdf by FFTW people show that in practice, there are other things to take into account (e.g. CPU cache) than just the number of computations.
if you search for fftw and djbfft you find that: http://cr.yp.to/djbfft/bench-notes.html which doesnt strengthen my trust in the benchmarks by the fftw authors though its kinda old ... also when you read http://cr.yp.to/djbfft/faq.html you will see that djbfft has been designed with cache and such in mind and yes, the operation counts are not the only thing whic matters but here 1. fact is liba52 with a split radix fft is faster then our code with cooley tukey fft 2. fewer operations does not neccessarily mean that other things like the memory accesses would be more random/slower
There seem to be so many FFT libs out there that I wonder if we really need to write our own, except, of course if there aren't any decent that's LGPL-compatible.
Heck, if we didn't care about the license, Intel's IPP is clearly the best choice out there ;-) J/K
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
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?
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?
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
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.
[...]
+ 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?
DJBFFT is not using bit reverse code, but a different type of permutation (it is not a simple case of swapping just pairs of values). So the old code is not directly applicable to it. Technically, DJBFFT permutation should be possible to be efficiently done in-place, but 'ff_fft_permute' performance is not important for most audio codecs (and the others can be tweaked not to use it), that's why I went with an easy way of adding a temporary buffer for now. This is not a final patch, but some test code which shows that djbfft can be relatively painlessly integrated into FFmpeg FFT framework. 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. On the other hand, I find these links quite interesting: http://lists.xiph.org/pipermail/vorbis-dev/2003-May/016206.html http://lists.xiph.org/pipermail/vorbis-dev/2003-June/016217.html I also wonder how would split-radix perform with SIMD optimizations in order to directly compare it with the current ffmpeg FFT. Looks like liba52 from mplayer should have some 3DNOW optimizations for split-radix though it is a huge mess. I'll try to extract something from it to do benchmarks (fortunately I have AMD processor :)). What other FFT implementations can be also considered, before making a decision what FFT implementation to use in ffmpeg? If DJBFFT would be the final choice, it still needs SIMD optimizations. But somebody needs to confirm its current legal status to be completely sure. And if DJBFFT is really public domain now, can it be relicensed to LGPL?
On Feb 20, 2008 9:32 AM, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: [...]
If DJBFFT would be the final choice, it still needs SIMD optimizations. But somebody needs to confirm its current legal status to be completely sure. And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Yes that would be legal, see GNU's Gnash project it uses relicensed code from public domain. Regards, ismail
On Wed, Feb 20, 2008 at 09:32:50AM +0200, Siarhei Siamashka wrote:
And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Yes. Diego
Diego Biurrun <diego at biurrun.de> writes:
On Wed, Feb 20, 2008 at 09:32:50AM +0200, Siarhei Siamashka wrote:
And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Yes.
IMHO, relicensing code is rude. Incorporating PD code in a larger work is of course fine, but the relevant parts should be marked as PD, even if there is no legal obligation to do so. -- M?ns Rullg?rd mans at mansr.com
M?ns Rullg?rd wrote:
Diego Biurrun <diego at biurrun.de> writes:
On Wed, Feb 20, 2008 at 09:32:50AM +0200, Siarhei Siamashka wrote:
And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Yes.
IMHO, relicensing code is rude. Incorporating PD code in a larger work is of course fine, but the relevant parts should be marked as PD, even if there is no legal obligation to do so.
Agree. We should keep the original license as long as we can. MvH Benjamin Larsson
On Wed, Feb 20, 2008 at 09:24:56AM +0000, M?ns Rullg?rd wrote:
Diego Biurrun <diego at biurrun.de> writes:
On Wed, Feb 20, 2008 at 09:32:50AM +0200, Siarhei Siamashka wrote:
And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Yes.
IMHO, relicensing code is rude. Incorporating PD code in a larger work is of course fine, but the relevant parts should be marked as PD, even if there is no legal obligation to do so.
If the code is significantly modified to fit in the ffmpeg framework and improved with simd optimizations, I see no reason these improvements should not be LGPL-only. Rich
Siarhei Siamashka wrote:
[...]
I also wonder how would split-radix perform with SIMD optimizations in order to directly compare it with the current ffmpeg FFT. Looks like liba52 from mplayer should have some 3DNOW optimizations for split-radix though it is a huge mess. I'll try to extract something from it to do benchmarks (fortunately I have AMD processor :)).
I'll do some benchmarks on a Geode processor.
What other FFT implementations can be also considered, before making a decision what FFT implementation to use in ffmpeg?
Kiss FFT should be tested also.
If DJBFFT would be the final choice, it still needs SIMD optimizations. But somebody needs to confirm its current legal status to be completely sure. And if DJBFFT is really public domain now, can it be relicensed to LGPL
MvH Benjamin Larsson
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
On Wed, Feb 20, 2008 at 02:51:42PM +0100, Michael Niedermayer wrote:
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 ...
Is Loren optimizing unapproved code all the time? Diego
On Thu, Feb 21, 2008 at 10:12:50AM +0100, Diego Biurrun wrote:
On Wed, Feb 20, 2008 at 02:51:42PM +0100, Michael Niedermayer wrote:
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 ...
Is Loren optimizing unapproved code all the time?
no, some people do improve code in svn too. I still think most patch submitters are more likely to work on their unapproved patch then on it after it has been approved. But as you pointed out yes there are certainly exceptions ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
Siarhei Siamashka wrote:
On 19 February 2008, Michael Niedermayer wrote: [...]
[...]
What other FFT implementations can be also considered, before making a decision what FFT implementation to use in ffmpeg?
If DJBFFT would be the final choice, it still needs SIMD optimizations. But somebody needs to confirm its current legal status to be completely sure. And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Hi, we got permission to use djbfft under the LGPL in FFmpeg. So I propose that we start working on merging it. Fixed point ports would be nice also :) MvH Benjamin Larsson
On 27 February 2008, Benjamin Larsson wrote:
Siarhei Siamashka wrote:
On 19 February 2008, Michael Niedermayer wrote: [...]
[...]
What other FFT implementations can be also considered, before making a decision what FFT implementation to use in ffmpeg?
If DJBFFT would be the final choice, it still needs SIMD optimizations. But somebody needs to confirm its current legal status to be completely sure. And if DJBFFT is really public domain now, can it be relicensed to LGPL?
Hi, we got permission to use djbfft under the LGPL in FFmpeg.
That's a good news (http://cr.yp.to/distributors.html now also mentions DJBFFT as public domain).
So I propose that we start working on merging it. Fixed point ports would be nice also :)
Well, unless Michael stops you saying that he will revert any commit with split-radix FFT ;) Split-radix is not the FFT with the lowest computational complexity anymore.
participants (10)
-
banan＠ludd.ltu.se -
dalias＠aerifal.cx -
diego＠biurrun.de -
gpoirier＠mplayerhq.hu -
ismail＠namtrac.org -
justinruggles＠bellsouth.net -
mans＠mansr.com -
michaelni＠gmx.at -
poirierg＠gmail.com -
siarhei.siamashka＠gmail.com