libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
/*
|
|
|
|
|
* This file is part of FFmpeg.
|
|
|
|
|
*
|
|
|
|
|
* FFmpeg is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* FFmpeg is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with FFmpeg; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "avassert.h"
|
|
|
|
|
#include "cpu.h"
|
|
|
|
|
#include "qsort.h"
|
|
|
|
|
#include "bprint.h"
|
|
|
|
|
|
|
|
|
|
#include "tx_priv.h"
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
#define TYPE_IS(type, x) \
|
|
|
|
|
(((x) == AV_TX_FLOAT_ ## type) || \
|
|
|
|
|
((x) == AV_TX_DOUBLE_ ## type) || \
|
|
|
|
|
((x) == AV_TX_INT32_ ## type))
|
|
|
|
|
|
|
|
|
|
/* Calculates the modular multiplicative inverse */
|
|
|
|
|
static av_always_inline int mulinv(int n, int m)
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
{
|
|
|
|
|
n = n % m;
|
|
|
|
|
for (int x = 1; x < m; x++)
|
|
|
|
|
if (((n * x) % m) == 1)
|
|
|
|
|
return x;
|
|
|
|
|
av_assert0(0); /* Never reached */
|
|
|
|
|
return 0;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Guaranteed to work for any n, m where gcd(n, m) == 1 */
|
|
|
|
|
int ff_tx_gen_compound_mapping(AVTXContext *s, int n, int m)
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
{
|
|
|
|
|
int *in_map, *out_map;
|
|
|
|
|
const int inv = s->inv;
|
|
|
|
|
const int len = n*m; /* Will not be equal to s->len for MDCTs */
|
|
|
|
|
int m_inv, n_inv;
|
|
|
|
|
|
|
|
|
|
/* Make sure the numbers are coprime */
|
|
|
|
|
if (av_gcd(n, m) != 1)
|
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
|
|
|
|
|
|
m_inv = mulinv(m, n);
|
|
|
|
|
n_inv = mulinv(n, m);
|
|
|
|
|
|
|
|
|
|
if (!(s->map = av_malloc(2*len*sizeof(*s->map))))
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
return AVERROR(ENOMEM);
|
|
|
|
|
|
|
|
|
|
in_map = s->map;
|
|
|
|
|
out_map = s->map + len;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
/* Ruritanian map for input, CRT map for output, can be swapped */
|
|
|
|
|
for (int j = 0; j < m; j++) {
|
|
|
|
|
for (int i = 0; i < n; i++) {
|
|
|
|
|
in_map[j*n + i] = (i*m + j*n) % len;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
out_map[(i*m*m_inv + j*n*n_inv) % len] = i*m + j;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Change transform direction by reversing all ACs */
|
|
|
|
|
if (inv) {
|
|
|
|
|
for (int i = 0; i < m; i++) {
|
|
|
|
|
int *in = &in_map[i*n + 1]; /* Skip the DC */
|
|
|
|
|
for (int j = 0; j < ((n - 1) >> 1); j++)
|
|
|
|
|
FFSWAP(int, in[j], in[n - j - 2]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Our 15-point transform is also a compound one, so embed its input map */
|
|
|
|
|
if (n == 15) {
|
|
|
|
|
for (int k = 0; k < m; k++) {
|
|
|
|
|
int tmp[15];
|
|
|
|
|
memcpy(tmp, &in_map[k*15], 15*sizeof(*tmp));
|
|
|
|
|
for (int i = 0; i < 5; i++) {
|
|
|
|
|
for (int j = 0; j < 3; j++)
|
|
|
|
|
in_map[k*15 + i*3 + j] = tmp[(i*3 + j*5) % 15];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int split_radix_permutation(int i, int len, int inv)
|
|
|
|
|
{
|
|
|
|
|
len >>= 1;
|
|
|
|
|
if (len <= 1)
|
|
|
|
|
return i & 1;
|
|
|
|
|
if (!(i & len))
|
|
|
|
|
return split_radix_permutation(i, len, inv) * 2;
|
|
|
|
|
len >>= 1;
|
|
|
|
|
return split_radix_permutation(i, len, inv) * 4 + 1 - 2*(!(i & len) ^ inv);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ff_tx_gen_ptwo_revtab(AVTXContext *s, int invert_lookup)
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
{
|
|
|
|
|
int len = s->len;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
if (!(s->map = av_malloc(len*sizeof(*s->map))))
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
return AVERROR(ENOMEM);
|
|
|
|
|
|
|
|
|
|
if (invert_lookup) {
|
|
|
|
|
for (int i = 0; i < s->len; i++)
|
|
|
|
|
s->map[i] = -split_radix_permutation(i, len, s->inv) & (len - 1);
|
|
|
|
|
} else {
|
|
|
|
|
for (int i = 0; i < s->len; i++)
|
|
|
|
|
s->map[-split_radix_permutation(i, len, s->inv) & (len - 1)] = i;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ff_tx_gen_ptwo_inplace_revtab_idx(AVTXContext *s)
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
{
|
|
|
|
|
int *src_map, out_map_idx = 0, len = s->len;
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
|
|
|
|
|
if (!s->sub || !s->sub->map)
|
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
|
|
|
|
|
|
if (!(s->map = av_mallocz(len*sizeof(*s->map))))
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
return AVERROR(ENOMEM);
|
|
|
|
|
|
|
|
|
|
src_map = s->sub->map;
|
|
|
|
|
|
|
|
|
|
/* The first coefficient is always already in-place */
|
|
|
|
|
for (int src = 1; src < s->len; src++) {
|
|
|
|
|
int dst = src_map[src];
|
|
|
|
|
int found = 0;
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
|
|
|
|
|
if (dst <= src)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* This just checks if a closed loop has been encountered before,
|
|
|
|
|
* and if so, skips it, since to fully permute a loop we must only
|
|
|
|
|
* enter it once. */
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
do {
|
|
|
|
|
for (int j = 0; j < out_map_idx; j++) {
|
|
|
|
|
if (dst == s->map[j]) {
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
found = 1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
dst = src_map[dst];
|
|
|
|
|
} while (dst != src && !found);
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
|
|
|
|
|
if (!found)
|
|
|
|
|
s->map[out_map_idx++] = src;
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
s->map[out_map_idx++] = 0;
|
lavu/tx: support in-place FFT transforms
This commit adds support for in-place FFT transforms. Since our
internal transforms were all in-place anyway, this only changes
the permutation on the input.
Unfortunately, research papers were of no help here. All focused
on dry hardware implementations, where permutes are free, or on
software implementations where binary bloat is of no concern so
storing dozen times the transforms for each permutation and version
is not considered bad practice.
Still, for a pure C implementation, it's only around 28% slower
than the multi-megabyte FFTW3 in unaligned mode.
Unlike a closed permutation like with PFA, split-radix FFT bit-reversals
contain multiple NOPs, multiple simple swaps, and a few chained swaps,
so regular single-loop single-state permute loops were not possible.
Instead, we filter out parts of the input indices which are redundant.
This allows for a single branch, and with some clever AVX512 asm,
could possibly be SIMD'd without refactoring.
The inplace_idx array is guaranteed to never be larger than the
revtab array, and in practice only requires around log2(len) entries.
The power-of-two MDCTs can be done in-place as well. And it's
possible to eliminate a copy in the compound MDCTs too, however
it'll be slower than doing them out of place, and we'd need to dirty
the input array.
4 years ago
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void parity_revtab_generator(int *revtab, int n, int inv, int offset,
|
|
|
|
|
int is_dual, int dual_high, int len,
|
|
|
|
|
int basis, int dual_stride, int inv_lookup)
|
|
|
|
|
{
|
|
|
|
|
len >>= 1;
|
|
|
|
|
|
|
|
|
|
if (len <= basis) {
|
|
|
|
|
int k1, k2, stride, even_idx, odd_idx;
|
|
|
|
|
|
|
|
|
|
is_dual = is_dual && dual_stride;
|
|
|
|
|
dual_high = is_dual & dual_high;
|
|
|
|
|
stride = is_dual ? FFMIN(dual_stride, len) : 0;
|
|
|
|
|
|
|
|
|
|
even_idx = offset + dual_high*(stride - 2*len);
|
|
|
|
|
odd_idx = even_idx + len + (is_dual && !dual_high)*len + dual_high*len;
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < len; i++) {
|
|
|
|
|
k1 = -split_radix_permutation(offset + i*2 + 0, n, inv) & (n - 1);
|
|
|
|
|
k2 = -split_radix_permutation(offset + i*2 + 1, n, inv) & (n - 1);
|
|
|
|
|
if (inv_lookup) {
|
|
|
|
|
revtab[even_idx++] = k1;
|
|
|
|
|
revtab[odd_idx++] = k2;
|
|
|
|
|
} else {
|
|
|
|
|
revtab[k1] = even_idx++;
|
|
|
|
|
revtab[k2] = odd_idx++;
|
|
|
|
|
}
|
|
|
|
|
if (stride && !((i + 1) % stride)) {
|
|
|
|
|
even_idx += stride;
|
|
|
|
|
odd_idx += stride;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
parity_revtab_generator(revtab, n, inv, offset,
|
|
|
|
|
0, 0, len >> 0, basis, dual_stride, inv_lookup);
|
|
|
|
|
parity_revtab_generator(revtab, n, inv, offset + (len >> 0),
|
|
|
|
|
1, 0, len >> 1, basis, dual_stride, inv_lookup);
|
|
|
|
|
parity_revtab_generator(revtab, n, inv, offset + (len >> 0) + (len >> 1),
|
|
|
|
|
1, 1, len >> 1, basis, dual_stride, inv_lookup);
|
|
|
|
|
}
|
|
|
|
|
|
x86/tx_float: implement inverse MDCT AVX2 assembly
This commit implements an iMDCT in pure assembly.
This is capable of processing any mod-8 transforms, rather than just
power of two, but since power of two is all we have assembly for
currently, that's what's supported.
It would really benefit if we could somehow use the C code to decide
which function to jump into, but exposing function labels from assebly
into C is anything but easy.
The post-transform loop could probably be improved.
This was somewhat annoying to write, as we must support arbitrary
strides during runtime. There's a fast branch for stride == 4 bytes
and a slower one which uses vgatherdps.
Zen 3 benchmarks for stride == 4 for old (av_imdct_half) vs new (av_tx):
128pt:
2811 decicycles in av_tx (imdct),16775916 runs, 1300 skips
3082 decicycles in av_imdct_half,16776751 runs, 465 skips
256pt:
4920 decicycles in av_tx (imdct),16775820 runs, 1396 skips
5378 decicycles in av_imdct_half,16776411 runs, 805 skips
512pt:
9668 decicycles in av_tx (imdct),16775774 runs, 1442 skips
10626 decicycles in av_imdct_half,16775647 runs, 1569 skips
1024pt:
19812 decicycles in av_tx (imdct),16777144 runs, 72 skips
23036 decicycles in av_imdct_half,16777167 runs, 49 skips
2 years ago
|
|
|
int ff_tx_gen_split_radix_parity_revtab(AVTXContext *s, int len, int inv,
|
|
|
|
|
int inv_lookup, int basis, int dual_stride)
|
|
|
|
|
{
|
|
|
|
|
basis >>= 1;
|
|
|
|
|
if (len < basis)
|
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
|
|
x86/tx_float: implement inverse MDCT AVX2 assembly
This commit implements an iMDCT in pure assembly.
This is capable of processing any mod-8 transforms, rather than just
power of two, but since power of two is all we have assembly for
currently, that's what's supported.
It would really benefit if we could somehow use the C code to decide
which function to jump into, but exposing function labels from assebly
into C is anything but easy.
The post-transform loop could probably be improved.
This was somewhat annoying to write, as we must support arbitrary
strides during runtime. There's a fast branch for stride == 4 bytes
and a slower one which uses vgatherdps.
Zen 3 benchmarks for stride == 4 for old (av_imdct_half) vs new (av_tx):
128pt:
2811 decicycles in av_tx (imdct),16775916 runs, 1300 skips
3082 decicycles in av_imdct_half,16776751 runs, 465 skips
256pt:
4920 decicycles in av_tx (imdct),16775820 runs, 1396 skips
5378 decicycles in av_imdct_half,16776411 runs, 805 skips
512pt:
9668 decicycles in av_tx (imdct),16775774 runs, 1442 skips
10626 decicycles in av_imdct_half,16775647 runs, 1569 skips
1024pt:
19812 decicycles in av_tx (imdct),16777144 runs, 72 skips
23036 decicycles in av_imdct_half,16777167 runs, 49 skips
2 years ago
|
|
|
if (!(s->map = av_mallocz((inv_lookup == -1 ? 2 : 1)*len*sizeof(*s->map))))
|
|
|
|
|
return AVERROR(ENOMEM);
|
|
|
|
|
|
|
|
|
|
av_assert0(!dual_stride || !(dual_stride & (dual_stride - 1)));
|
|
|
|
|
av_assert0(dual_stride <= basis);
|
x86/tx_float: implement inverse MDCT AVX2 assembly
This commit implements an iMDCT in pure assembly.
This is capable of processing any mod-8 transforms, rather than just
power of two, but since power of two is all we have assembly for
currently, that's what's supported.
It would really benefit if we could somehow use the C code to decide
which function to jump into, but exposing function labels from assebly
into C is anything but easy.
The post-transform loop could probably be improved.
This was somewhat annoying to write, as we must support arbitrary
strides during runtime. There's a fast branch for stride == 4 bytes
and a slower one which uses vgatherdps.
Zen 3 benchmarks for stride == 4 for old (av_imdct_half) vs new (av_tx):
128pt:
2811 decicycles in av_tx (imdct),16775916 runs, 1300 skips
3082 decicycles in av_imdct_half,16776751 runs, 465 skips
256pt:
4920 decicycles in av_tx (imdct),16775820 runs, 1396 skips
5378 decicycles in av_imdct_half,16776411 runs, 805 skips
512pt:
9668 decicycles in av_tx (imdct),16775774 runs, 1442 skips
10626 decicycles in av_imdct_half,16775647 runs, 1569 skips
1024pt:
19812 decicycles in av_tx (imdct),16777144 runs, 72 skips
23036 decicycles in av_imdct_half,16777167 runs, 49 skips
2 years ago
|
|
|
|
|
|
|
|
parity_revtab_generator(s->map, len, inv, 0, 0, 0, len,
|
x86/tx_float: implement inverse MDCT AVX2 assembly
This commit implements an iMDCT in pure assembly.
This is capable of processing any mod-8 transforms, rather than just
power of two, but since power of two is all we have assembly for
currently, that's what's supported.
It would really benefit if we could somehow use the C code to decide
which function to jump into, but exposing function labels from assebly
into C is anything but easy.
The post-transform loop could probably be improved.
This was somewhat annoying to write, as we must support arbitrary
strides during runtime. There's a fast branch for stride == 4 bytes
and a slower one which uses vgatherdps.
Zen 3 benchmarks for stride == 4 for old (av_imdct_half) vs new (av_tx):
128pt:
2811 decicycles in av_tx (imdct),16775916 runs, 1300 skips
3082 decicycles in av_imdct_half,16776751 runs, 465 skips
256pt:
4920 decicycles in av_tx (imdct),16775820 runs, 1396 skips
5378 decicycles in av_imdct_half,16776411 runs, 805 skips
512pt:
9668 decicycles in av_tx (imdct),16775774 runs, 1442 skips
10626 decicycles in av_imdct_half,16775647 runs, 1569 skips
1024pt:
19812 decicycles in av_tx (imdct),16777144 runs, 72 skips
23036 decicycles in av_imdct_half,16777167 runs, 49 skips
2 years ago
|
|
|
basis, dual_stride, inv_lookup != 0);
|
|
|
|
|
if (inv_lookup == -1)
|
|
|
|
|
parity_revtab_generator(s->map + len, len, inv, 0, 0, 0, len,
|
|
|
|
|
basis, dual_stride, 0);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void reset_ctx(AVTXContext *s)
|
|
|
|
|
{
|
|
|
|
|
if (!s)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (s->sub)
|
|
|
|
|
for (int i = 0; i < s->nb_sub; i++)
|
|
|
|
|
reset_ctx(&s->sub[i]);
|
|
|
|
|
|
|
|
|
|
if (s->cd_self->uninit)
|
|
|
|
|
s->cd_self->uninit(s);
|
|
|
|
|
|
|
|
|
|
av_freep(&s->sub);
|
|
|
|
|
av_freep(&s->map);
|
|
|
|
|
av_freep(&s->exp);
|
|
|
|
|
av_freep(&s->tmp);
|
|
|
|
|
|
|
|
|
|
memset(s, 0, sizeof(*s));
|
|
|
|
|
}
|
|
|
|
|
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
av_cold void av_tx_uninit(AVTXContext **ctx)
|
|
|
|
|
{
|
|
|
|
|
if (!(*ctx))
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
reset_ctx(*ctx);
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
av_freep(ctx);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static av_cold int ff_tx_null_init(AVTXContext *s, const FFTXCodelet *cd,
|
|
|
|
|
uint64_t flags, FFTXCodeletOptions *opts,
|
|
|
|
|
int len, int inv, const void *scale)
|
|
|
|
|
{
|
|
|
|
|
/* Can only handle one sample+type to one sample+type transforms */
|
|
|
|
|
if (TYPE_IS(MDCT, s->type) || TYPE_IS(RDFT, s->type))
|
|
|
|
|
return AVERROR(EINVAL);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Null transform when the length is 1 */
|
|
|
|
|
static void ff_tx_null(AVTXContext *s, void *_out, void *_in, ptrdiff_t stride)
|
|
|
|
|
{
|
|
|
|
|
memcpy(_out, _in, stride);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const FFTXCodelet ff_tx_null_def = {
|
|
|
|
|
.name = NULL_IF_CONFIG_SMALL("null"),
|
|
|
|
|
.function = ff_tx_null,
|
|
|
|
|
.type = TX_TYPE_ANY,
|
|
|
|
|
.flags = AV_TX_UNALIGNED | FF_TX_ALIGNED |
|
|
|
|
|
FF_TX_OUT_OF_PLACE | AV_TX_INPLACE,
|
|
|
|
|
.factors[0] = TX_FACTOR_ANY,
|
|
|
|
|
.min_len = 1,
|
|
|
|
|
.max_len = 1,
|
|
|
|
|
.init = ff_tx_null_init,
|
|
|
|
|
.cpu_flags = FF_TX_CPU_FLAGS_ALL,
|
|
|
|
|
.prio = FF_TX_PRIO_MAX,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const FFTXCodelet * const ff_tx_null_list[] = {
|
|
|
|
|
&ff_tx_null_def,
|
|
|
|
|
NULL,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#if !CONFIG_SMALL
|
|
|
|
|
static void print_flags(AVBPrint *bp, uint64_t f)
|
|
|
|
|
{
|
|
|
|
|
int prev = 0;
|
|
|
|
|
const char *sep = ", ";
|
|
|
|
|
av_bprintf(bp, "flags: [");
|
|
|
|
|
if ((f & FF_TX_ALIGNED) && ++prev)
|
|
|
|
|
av_bprintf(bp, "aligned");
|
|
|
|
|
if ((f & AV_TX_UNALIGNED) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%sunaligned", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & AV_TX_INPLACE) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%sinplace", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & FF_TX_OUT_OF_PLACE) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%sout_of_place", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & FF_TX_FORWARD_ONLY) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%sfwd_only", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & FF_TX_INVERSE_ONLY) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%sinv_only", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & FF_TX_PRESHUFFLE) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%spreshuf", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & AV_TX_FULL_IMDCT) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%simdct_full", prev > 1 ? sep : "");
|
|
|
|
|
if ((f & FF_TX_ASM_CALL) && ++prev)
|
|
|
|
|
av_bprintf(bp, "%sasm_call", prev > 1 ? sep : "");
|
|
|
|
|
av_bprintf(bp, "]");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void print_type(AVBPrint *bp, enum AVTXType type)
|
|
|
|
|
{
|
|
|
|
|
av_bprintf(bp, "%s",
|
|
|
|
|
type == TX_TYPE_ANY ? "any" :
|
|
|
|
|
type == AV_TX_FLOAT_FFT ? "fft_float" :
|
|
|
|
|
type == AV_TX_FLOAT_MDCT ? "mdct_float" :
|
|
|
|
|
type == AV_TX_FLOAT_RDFT ? "rdft_float" :
|
|
|
|
|
type == AV_TX_DOUBLE_FFT ? "fft_double" :
|
|
|
|
|
type == AV_TX_DOUBLE_MDCT ? "mdct_double" :
|
|
|
|
|
type == AV_TX_DOUBLE_RDFT ? "rdft_double" :
|
|
|
|
|
type == AV_TX_INT32_FFT ? "fft_int32" :
|
|
|
|
|
type == AV_TX_INT32_MDCT ? "mdct_int32" :
|
|
|
|
|
type == AV_TX_INT32_RDFT ? "rdft_int32" :
|
|
|
|
|
"unknown");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void print_cd_info(const FFTXCodelet *cd, int prio, int print_prio)
|
|
|
|
|
{
|
|
|
|
|
AVBPrint bp = { 0 };
|
|
|
|
|
av_bprint_init(&bp, 0, AV_BPRINT_SIZE_AUTOMATIC);
|
|
|
|
|
|
|
|
|
|
av_bprintf(&bp, "%s - type: ", cd->name);
|
|
|
|
|
|
|
|
|
|
print_type(&bp, cd->type);
|
|
|
|
|
|
|
|
|
|
av_bprintf(&bp, ", len: ");
|
|
|
|
|
if (cd->min_len != cd->max_len)
|
|
|
|
|
av_bprintf(&bp, "[%i, ", cd->min_len);
|
|
|
|
|
|
|
|
|
|
if (cd->max_len == TX_LEN_UNLIMITED)
|
|
|
|
|
av_bprintf(&bp, "∞");
|
|
|
|
|
else
|
|
|
|
|
av_bprintf(&bp, "%i", cd->max_len);
|
|
|
|
|
|
|
|
|
|
av_bprintf(&bp, "%s, factors: [", cd->min_len != cd->max_len ? "]" : "");
|
|
|
|
|
for (int i = 0; i < TX_MAX_SUB; i++) {
|
|
|
|
|
if (i && cd->factors[i])
|
|
|
|
|
av_bprintf(&bp, ", ");
|
|
|
|
|
if (cd->factors[i] == TX_FACTOR_ANY)
|
|
|
|
|
av_bprintf(&bp, "any");
|
|
|
|
|
else if (cd->factors[i])
|
|
|
|
|
av_bprintf(&bp, "%i", cd->factors[i]);
|
|
|
|
|
else
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
av_bprintf(&bp, "], ");
|
|
|
|
|
print_flags(&bp, cd->flags);
|
|
|
|
|
|
|
|
|
|
if (print_prio)
|
|
|
|
|
av_bprintf(&bp, ", prio: %i", prio);
|
|
|
|
|
|
|
|
|
|
av_log(NULL, AV_LOG_VERBOSE, "%s\n", bp.str);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void print_tx_structure(AVTXContext *s, int depth)
|
|
|
|
|
{
|
|
|
|
|
const FFTXCodelet *cd = s->cd_self;
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i <= depth; i++)
|
|
|
|
|
av_log(NULL, AV_LOG_VERBOSE, " ");
|
|
|
|
|
|
|
|
|
|
print_cd_info(cd, cd->prio, 0);
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < s->nb_sub; i++)
|
|
|
|
|
print_tx_structure(&s->sub[i], depth + 1);
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_SMALL */
|
|
|
|
|
|
|
|
|
|
typedef struct TXCodeletMatch {
|
|
|
|
|
const FFTXCodelet *cd;
|
|
|
|
|
int prio;
|
|
|
|
|
} TXCodeletMatch;
|
|
|
|
|
|
|
|
|
|
static int cmp_matches(TXCodeletMatch *a, TXCodeletMatch *b)
|
|
|
|
|
{
|
|
|
|
|
return FFDIFFSIGN(b->prio, a->prio);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We want all factors to completely cover the length */
|
|
|
|
|
static inline int check_cd_factors(const FFTXCodelet *cd, int len)
|
|
|
|
|
{
|
|
|
|
|
int all_flag = 0;
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < TX_MAX_SUB; i++) {
|
|
|
|
|
int factor = cd->factors[i];
|
|
|
|
|
|
|
|
|
|
/* Conditions satisfied */
|
|
|
|
|
if (len == 1)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
/* No more factors */
|
|
|
|
|
if (!factor) {
|
|
|
|
|
break;
|
|
|
|
|
} else if (factor == TX_FACTOR_ANY) {
|
|
|
|
|
all_flag = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (factor == 2) { /* Fast path */
|
|
|
|
|
int bits_2 = ff_ctz(len);
|
|
|
|
|
if (!bits_2)
|
|
|
|
|
return 0; /* Factor not supported */
|
|
|
|
|
|
|
|
|
|
len >>= bits_2;
|
|
|
|
|
} else {
|
|
|
|
|
int res = len % factor;
|
|
|
|
|
if (res)
|
|
|
|
|
return 0; /* Factor not supported */
|
|
|
|
|
|
|
|
|
|
while (!res) {
|
|
|
|
|
len /= factor;
|
|
|
|
|
res = len % factor;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return all_flag || (len == 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
av_cold int ff_tx_init_subtx(AVTXContext *s, enum AVTXType type,
|
|
|
|
|
uint64_t flags, FFTXCodeletOptions *opts,
|
|
|
|
|
int len, int inv, const void *scale)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
AVTXContext *sub = NULL;
|
|
|
|
|
TXCodeletMatch *cd_tmp, *cd_matches = NULL;
|
|
|
|
|
unsigned int cd_matches_size = 0;
|
|
|
|
|
int nb_cd_matches = 0;
|
|
|
|
|
#if !CONFIG_SMALL
|
|
|
|
|
AVBPrint bp = { 0 };
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Array of all compiled codelet lists. Order is irrelevant. */
|
|
|
|
|
const FFTXCodelet * const * const codelet_list[] = {
|
|
|
|
|
ff_tx_codelet_list_float_c,
|
|
|
|
|
ff_tx_codelet_list_double_c,
|
|
|
|
|
ff_tx_codelet_list_int32_c,
|
|
|
|
|
ff_tx_null_list,
|
|
|
|
|
#if HAVE_X86ASM
|
|
|
|
|
ff_tx_codelet_list_float_x86,
|
lavu/tx: implement aarch64 NEON SIMD FFT
The fastest fast Fourier transform in not just the west, but the world,
now for the most popular toy ISA.
On a high level, it follows the design of the AVX2 version closely,
with the exception that the input is slightly less permuted as we don't have
to do lane switching with the input on double 4pt and 8pt.
On a low level, the lack of subadd/addsub instructions REALLY penalizes
any attempt at writing an FFT. That single register matters a lot,
and reloading it simply takes unacceptably long.
In x86 land, vendors would've noticed developers need this.
In ARM land, you get a badly designed complex multiplication instruction
we cannot use, that's not present on 95% of devices. Because only
compilers matter, right?
Future optimization options are very few, perhaps better register
management to use more ld1/st1s.
All timings below are in cycles:
A53:
Length | C | New (lavu) | Old (lavc) | FFTW
------ |-------------|-------------|-------------|-----
4 | 842 | 420 | 1210 | 1460
8 | 1538 | 1020 | 1850 | 2520
16 | 3717 | 1900 | 3700 | 3990
32 | 9156 | 4070 | 8289 | 8860
64 | 21160 | 9931 | 18600 | 19625
128 | 49180 | 23278 | 41922 | 41922
256 | 112073 | 53876 | 93202 | 101092
512 | 252864 | 122884 | 205897 | 207868
1024 | 560512 | 278322 | 458071 | 453053
2048 | 1295402 | 775835 | 1038205 | 1020265
4096 | 3281263 | 2021221 | 2409718 | 2577554
8192 | 8577845 | 4780526 | 5673041 | 6802722
Apple M1
New - Total for len 512 reps 2097152 = 1.459141 s
Old - Total for len 512 reps 2097152 = 2.251344 s
FFTW - Total for len 512 reps 2097152 = 1.868429 s
New - Total for len 1024 reps 4194304 = 6.490080 s
Old - Total for len 1024 reps 4194304 = 9.604949 s
FFTW - Total for len 1024 reps 4194304 = 7.889281 s
New - Total for len 16384 reps 262144 = 10.374001 s
Old - Total for len 16384 reps 262144 = 15.266713 s
FFTW - Total for len 16384 reps 262144 = 12.341745 s
New - Total for len 65536 reps 8192 = 1.769812 s
Old - Total for len 65536 reps 8192 = 4.209413 s
FFTW - Total for len 65536 reps 8192 = 3.012365 s
New - Total for len 131072 reps 4096 = 1.942836 s
Old - Segfaults
FFTW - Total for len 131072 reps 4096 = 3.713713 s
Thanks to wbs for some simplifications, assembler fixes and a review
and to jannau for giving it a look.
3 years ago
|
|
|
#endif
|
|
|
|
|
#if ARCH_AARCH64
|
|
|
|
|
ff_tx_codelet_list_float_aarch64,
|
|
|
|
|
#endif
|
|
|
|
|
};
|
|
|
|
|
int codelet_list_num = FF_ARRAY_ELEMS(codelet_list);
|
|
|
|
|
|
|
|
|
|
/* We still accept functions marked with SLOW, even if the CPU is
|
|
|
|
|
* marked with the same flag, but we give them lower priority. */
|
|
|
|
|
const int cpu_flags = av_get_cpu_flags();
|
|
|
|
|
const int slow_mask = AV_CPU_FLAG_SSE2SLOW | AV_CPU_FLAG_SSE3SLOW |
|
|
|
|
|
AV_CPU_FLAG_ATOM | AV_CPU_FLAG_SSSE3SLOW |
|
|
|
|
|
AV_CPU_FLAG_AVXSLOW | AV_CPU_FLAG_SLOW_GATHER;
|
|
|
|
|
|
|
|
|
|
static const int slow_penalties[][2] = {
|
|
|
|
|
{ AV_CPU_FLAG_SSE2SLOW, 1 + 64 },
|
|
|
|
|
{ AV_CPU_FLAG_SSE3SLOW, 1 + 64 },
|
|
|
|
|
{ AV_CPU_FLAG_SSSE3SLOW, 1 + 64 },
|
|
|
|
|
{ AV_CPU_FLAG_ATOM, 1 + 128 },
|
|
|
|
|
{ AV_CPU_FLAG_AVXSLOW, 1 + 128 },
|
|
|
|
|
{ AV_CPU_FLAG_SLOW_GATHER, 1 + 32 },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Flags the transform wants */
|
|
|
|
|
uint64_t req_flags = flags;
|
|
|
|
|
|
|
|
|
|
/* Flags the codelet may require to be present */
|
|
|
|
|
uint64_t inv_req_mask = AV_TX_FULL_IMDCT | FF_TX_PRESHUFFLE | FF_TX_ASM_CALL;
|
|
|
|
|
|
|
|
|
|
/* Unaligned codelets are compatible with the aligned flag */
|
|
|
|
|
if (req_flags & FF_TX_ALIGNED)
|
|
|
|
|
req_flags |= AV_TX_UNALIGNED;
|
|
|
|
|
|
|
|
|
|
/* If either flag is set, both are okay, so don't check for an exact match */
|
|
|
|
|
if ((req_flags & AV_TX_INPLACE) && (req_flags & FF_TX_OUT_OF_PLACE))
|
|
|
|
|
req_flags &= ~(AV_TX_INPLACE | FF_TX_OUT_OF_PLACE);
|
|
|
|
|
if ((req_flags & FF_TX_ALIGNED) && (req_flags & AV_TX_UNALIGNED))
|
|
|
|
|
req_flags &= ~(FF_TX_ALIGNED | AV_TX_UNALIGNED);
|
|
|
|
|
|
|
|
|
|
/* Loop through all codelets in all codelet lists to find matches
|
|
|
|
|
* to the requirements */
|
|
|
|
|
while (codelet_list_num--) {
|
|
|
|
|
const FFTXCodelet * const * list = codelet_list[codelet_list_num];
|
|
|
|
|
const FFTXCodelet *cd = NULL;
|
|
|
|
|
|
|
|
|
|
while ((cd = *list++)) {
|
|
|
|
|
int max_factor = 0;
|
|
|
|
|
|
|
|
|
|
/* Check if the type matches */
|
|
|
|
|
if (cd->type != TX_TYPE_ANY && type != cd->type)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Check direction for non-orthogonal codelets */
|
|
|
|
|
if (((cd->flags & FF_TX_FORWARD_ONLY) && inv) ||
|
|
|
|
|
((cd->flags & (FF_TX_INVERSE_ONLY | AV_TX_FULL_IMDCT)) && !inv))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Check if the requested flags match from both sides */
|
|
|
|
|
if (((req_flags & cd->flags) != (req_flags)) ||
|
|
|
|
|
((inv_req_mask & cd->flags) != (req_flags & inv_req_mask)))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Check if length is supported */
|
|
|
|
|
if ((len < cd->min_len) || (cd->max_len != -1 && (len > cd->max_len)))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Check if the CPU supports the required ISA */
|
|
|
|
|
if (cd->cpu_flags != FF_TX_CPU_FLAGS_ALL &&
|
|
|
|
|
!(cpu_flags & (cd->cpu_flags & ~slow_mask)))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Check for factors */
|
|
|
|
|
if (!check_cd_factors(cd, len))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Realloc array and append */
|
|
|
|
|
cd_tmp = av_fast_realloc(cd_matches, &cd_matches_size,
|
|
|
|
|
sizeof(*cd_tmp) * (nb_cd_matches + 1));
|
|
|
|
|
if (!cd_tmp) {
|
|
|
|
|
av_free(cd_matches);
|
|
|
|
|
return AVERROR(ENOMEM);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cd_matches = cd_tmp;
|
|
|
|
|
cd_matches[nb_cd_matches].cd = cd;
|
|
|
|
|
cd_matches[nb_cd_matches].prio = cd->prio;
|
|
|
|
|
|
|
|
|
|
/* If the CPU has a SLOW flag, and the instruction is also flagged
|
|
|
|
|
* as being slow for such, reduce its priority */
|
|
|
|
|
for (int i = 0; i < FF_ARRAY_ELEMS(slow_penalties); i++) {
|
|
|
|
|
if ((cpu_flags & cd->cpu_flags) & slow_penalties[i][0])
|
|
|
|
|
cd_matches[nb_cd_matches].prio -= slow_penalties[i][1];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Prioritize aligned-only codelets */
|
|
|
|
|
if ((cd->flags & FF_TX_ALIGNED) && !(cd->flags & AV_TX_UNALIGNED))
|
|
|
|
|
cd_matches[nb_cd_matches].prio += 64;
|
|
|
|
|
|
|
|
|
|
/* Codelets for specific lengths are generally faster */
|
|
|
|
|
if ((len == cd->min_len) && (len == cd->max_len))
|
|
|
|
|
cd_matches[nb_cd_matches].prio += 64;
|
|
|
|
|
|
|
|
|
|
/* Forward-only or inverse-only transforms are generally better */
|
|
|
|
|
if ((cd->flags & (FF_TX_FORWARD_ONLY | FF_TX_INVERSE_ONLY)))
|
|
|
|
|
cd_matches[nb_cd_matches].prio += 64;
|
|
|
|
|
|
|
|
|
|
/* Larger factors are generally better */
|
|
|
|
|
for (int i = 0; i < TX_MAX_SUB; i++)
|
|
|
|
|
max_factor = FFMAX(cd->factors[i], max_factor);
|
|
|
|
|
if (max_factor)
|
|
|
|
|
cd_matches[nb_cd_matches].prio += 16*max_factor;
|
|
|
|
|
|
|
|
|
|
nb_cd_matches++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#if !CONFIG_SMALL
|
|
|
|
|
/* Print debugging info */
|
|
|
|
|
av_bprint_init(&bp, 0, AV_BPRINT_SIZE_AUTOMATIC);
|
|
|
|
|
av_bprintf(&bp, "For transform of length %i, %s, ", len,
|
|
|
|
|
inv ? "inverse" : "forward");
|
|
|
|
|
print_type(&bp, type);
|
|
|
|
|
av_bprintf(&bp, ", ");
|
|
|
|
|
print_flags(&bp, flags);
|
|
|
|
|
av_bprintf(&bp, ", found %i matches%s", nb_cd_matches,
|
|
|
|
|
nb_cd_matches ? ":" : ".");
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* No matches found */
|
|
|
|
|
if (!nb_cd_matches)
|
|
|
|
|
return AVERROR(ENOSYS);
|
|
|
|
|
|
|
|
|
|
/* Sort the list */
|
|
|
|
|
AV_QSORT(cd_matches, nb_cd_matches, TXCodeletMatch, cmp_matches);
|
|
|
|
|
|
|
|
|
|
#if !CONFIG_SMALL
|
|
|
|
|
av_log(NULL, AV_LOG_VERBOSE, "%s\n", bp.str);
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < nb_cd_matches; i++) {
|
|
|
|
|
av_log(NULL, AV_LOG_VERBOSE, " %i: ", i + 1);
|
|
|
|
|
print_cd_info(cd_matches[i].cd, cd_matches[i].prio, 1);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
if (!s->sub) {
|
|
|
|
|
s->sub = sub = av_mallocz(TX_MAX_SUB*sizeof(*sub));
|
|
|
|
|
if (!sub) {
|
|
|
|
|
ret = AVERROR(ENOMEM);
|
|
|
|
|
goto end;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Attempt to initialize each */
|
|
|
|
|
for (int i = 0; i < nb_cd_matches; i++) {
|
|
|
|
|
const FFTXCodelet *cd = cd_matches[i].cd;
|
|
|
|
|
AVTXContext *sctx = &s->sub[s->nb_sub];
|
|
|
|
|
|
|
|
|
|
sctx->len = len;
|
|
|
|
|
sctx->inv = inv;
|
|
|
|
|
sctx->type = type;
|
|
|
|
|
sctx->flags = cd->flags | flags;
|
|
|
|
|
sctx->cd_self = cd;
|
|
|
|
|
|
|
|
|
|
s->fn[s->nb_sub] = cd->function;
|
|
|
|
|
s->cd[s->nb_sub] = cd;
|
|
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
|
if (cd->init)
|
|
|
|
|
ret = cd->init(sctx, cd, flags, opts, len, inv, scale);
|
|
|
|
|
|
|
|
|
|
if (ret >= 0) {
|
|
|
|
|
s->nb_sub++;
|
|
|
|
|
goto end;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
s->fn[s->nb_sub] = NULL;
|
|
|
|
|
s->cd[s->nb_sub] = NULL;
|
|
|
|
|
|
|
|
|
|
reset_ctx(sctx);
|
|
|
|
|
if (ret == AVERROR(ENOMEM))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!s->nb_sub)
|
|
|
|
|
av_freep(&s->sub);
|
|
|
|
|
|
|
|
|
|
end:
|
|
|
|
|
av_free(cd_matches);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
av_cold int av_tx_init(AVTXContext **ctx, av_tx_fn *tx, enum AVTXType type,
|
|
|
|
|
int inv, int len, const void *scale, uint64_t flags)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
AVTXContext tmp = { 0 };
|
|
|
|
|
const double default_scale_d = 1.0;
|
|
|
|
|
const float default_scale_f = 1.0f;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
if (!len || type >= AV_TX_NB || !ctx || !tx)
|
|
|
|
|
return AVERROR(EINVAL);
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
if (!(flags & AV_TX_UNALIGNED))
|
|
|
|
|
flags |= FF_TX_ALIGNED;
|
|
|
|
|
if (!(flags & AV_TX_INPLACE))
|
|
|
|
|
flags |= FF_TX_OUT_OF_PLACE;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
if (!scale && ((type == AV_TX_FLOAT_MDCT) || (type == AV_TX_INT32_MDCT)))
|
|
|
|
|
scale = &default_scale_f;
|
|
|
|
|
else if (!scale && (type == AV_TX_DOUBLE_MDCT))
|
|
|
|
|
scale = &default_scale_d;
|
|
|
|
|
|
|
|
|
|
ret = ff_tx_init_subtx(&tmp, type, flags, NULL, len, inv, scale);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
*ctx = &tmp.sub[0];
|
|
|
|
|
*tx = tmp.fn[0];
|
|
|
|
|
|
|
|
|
|
#if !CONFIG_SMALL
|
|
|
|
|
av_log(NULL, AV_LOG_VERBOSE, "Transform tree:\n");
|
|
|
|
|
print_tx_structure(*ctx, 0);
|
|
|
|
|
#endif
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
|
|
|
|
|
return ret;
|
libavutil: add an FFT & MDCT implementation
This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.
A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...
The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".
Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
22353 decicycles in fftwf_execute, 1024 runs, 0 skips
21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips
128:
22003 decicycles in fftwf_execute, 1024 runs, 0 skips
23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
384:
75939 decicycles in fftwf_execute, 1024 runs, 0 skips
73973 decicycles in compound_fft_3x128, 1024 runs, 0 skips
640:
104354 decicycles in fftwf_execute, 1024 runs, 0 skips
149518 decicycles in compound_fft_5x128, 1024 runs, 0 skips
768:
109323 decicycles in fftwf_execute, 1024 runs, 0 skips
164096 decicycles in compound_fft_3x256, 1024 runs, 0 skips
960:
186210 decicycles in fftwf_execute, 1024 runs, 0 skips
215256 decicycles in compound_fft_15x64, 1024 runs, 0 skips
1024:
163464 decicycles in fftwf_execute, 1024 runs, 0 skips
199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips
With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.
The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
New code throughout the project should use this API.
The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical with ATRAC9 as well.
6 years ago
|
|
|
}
|
