[FFmpeg-devel] [PATCH] split-radix FFT

[Robert Swain]

2008/8/5 Siarhei Siamashka <siarhei.siamashka at gmail.com>:
> On Mon, Aug 4, 2008 at 10:27 PM, matthieu castet
> <castet.matthieu at free.fr> wrote:
>> M?ns Rullg?rd wrote:
>>> Loren Merritt <lorenm at u.washington.edu> writes:
>>>
>>>> $subject, vaguely based on djbfft.
>>>> Changed from djb:
>>>> * added simd.
>>>> * removed the hand-scheduled pentium-pro code. gcc's output from
>>>> simple C is better on all cpus I have access to.
>>>> * removed the distinction between fft and ifft. they're just
>>>> permutations of eachother, so the difference belongs in revtab[] and
>>>> not in the code.
>>>> * removed the distinction between pass() and pass_big(). C can always
>>>> use the memory-efficient version, and simd never does because the
>>>> shuffles are too costly.
>>>> * made an entirely different pass_big(), to avoid store->load aliasing.
>>>
>>> Any progress on this?  IMDCT is taking 84% time decoding Vorbis on
>>> ARM, and SIMD-optimising the FFT in svn seems silly.
>>>
>> Shouldn't fixed point stuff should help a lot on arm ?
>
> Yes, fixed point stuff should help on low end arm cores without fpu.
> If you are interested in audio decoding on such cores, you are better
> to use rockbox (http://www.rockbox.org/) and not FFmpeg at the moment.

What license is the RockBox stuff? Could it be ported to FFmpeg?

> Modern arm cores have hardware fpu which is reasonably fast, so it is
> quite questionable if fixed point decoder would be better for such
> cores. The same happened for x86 in the past and floating point audio
> decoders are now better for modern x86 cores.
>
>> IRRC there was post about wma and cook fixed point implementation that
>> were lot's of faster on such cpu.
>
> Yes, there was some activity trying to add fixed point audio decoding
> support to FFmpeg (merge some stuff from rockbox). But fixed point
> code contributors were required to also implement split-radix FFT for
> FFmpeg as a payload. This kind of 'blackmail' did not work well that
> time, so FFmpeg is still absolutely horrible at decoding audio on old
> fpu-less arm cores. Anyway, with split-radix FFT finally getting
> implemented, there may be some hope for FFmpeg to get fixed point
> audio decoding too

Aren't the FFT routines modular? Why wouldn't fixed-point only
implementations using split-radix be allowed without floating point?

Rob