This is achieved by using function pointers for AAC SBR functions.
This unfortunately necessitated to use void* in
ff_aac_sbr_apply(_fixed).
Fixes ticket #10999.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code was written in 2012, but seems to have been broken
for just as long. Compilation is broken on every MIPS/MIPS64
system with an FPU (which the code depends on).
sizeof(PredictorState) is different for the floating-point and
the fixed-point AAC decoders; this is an obstacle for deduplicating
code between these decoders. So don't include this array in
SingleChannelElement, instead add a union of pointers to the
fixed-point PredictorState and the floating-point PredictorState.
The actual arrays are part of the extended ChannelElement
to be allocated by ff_aac_sbr_ctx_alloc_init(); it also
sets the pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AAC fixed-point and floating-point decoders have
a lot of duplicated code; the main obstacle to
deduplicating it is that several structures with the
same name are actually different types, because
they contain INTFLOATs (int or float) and AAC_FLOATs
(SoftFloat or float). SoftFloat and float typically
have different sizes, so dealing with it is the more
complicated of the two.
AAC_FLOAT is mainly used in the sbr code and structures,
so one can still deduplicate the code by only exposing
the common part of ChannelElement (without SBR context)
to the common decoder part. One prerequisite of this
is to move allocating the whole ChannelElement to
code that will stay unduplicated. It is most natural
to move said allocation to ff_aac_sbr_ctx_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each ChannelElement contains exactly one SpectralBandReplication
structure; the latter structure contains lots of buffers
whose size depend upon USE_FIXED (i.e. AAC_FLOAT arrays).
This complicates deduplicating the parts of the AAC decoder
that are duplicated between the fixed-point and the floating
point decoder.
In order to fix this, the SpectralBandReplication structure
will be moved from the part of ChannelElement visible to
the common code. Therefore the ff_aac_sbr_* functions
are ported to accept a ChannelElement*; they will then have
to translate that to the corresponding SpectralBandReplication*
themselves (which is possible, because there are floating-point
and fixed-point versions of these functions).
While just at it, also ensure that these functions are properly
namespaced.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is decoder-only; furthermore, there is already
an AACContext in use by libfdk-aacenc.
Also make aacdec.h provide the typedef for AACContext;
up until now, this has been done by sbr.h.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For all VLCs here, the number of bits of the VLC is
write-only, because it is hardcoded at the call site.
Therefore one can replace these VLC structures with
the only thing that is actually used: The pointer
to the VLCElem table.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The VLCs, their init code and the tables used for initialization
are currently duplicated for the floating- and fixed-point decoders.
This commit stops doing so and moves this stuff to aacdec_common.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since this behavior is intentional, use the VERBOSE level instead of WARNING as
it's nothing the user should worry about.
Signed-off-by: James Almer <jamrial@gmail.com>
In C, qualifiers for arrays are broken:
const VLC_TYPE (*foo)[2] is a pointer to an array of two const VLC_TYPE
elements and unfortunately this is not compatible with a pointer
to a const array of two VLC_TYPE, because the latter does not exist
as array types are never qualified (the qualifier applies to the base
type instead). This is the reason why get_vlc2() doesn't accept
a const VLC table despite not modifying the table at all, as
there is no automatic conversion from VLC_TYPE (*)[2] to
const VLC_TYPE (*)[2].
Fix this by using a structure VLCElem for the VLC table.
This also has the advantage of making it clear which
element is which.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is more spec-compliant because it does not rely
on dead-code elimination by the compiler. Especially
MSVC has problems with this, as can be seen in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
or
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html
This commit does not eliminate every instance where we rely
on dead code elimination: It only tackles branching to
the initialization of arch-specific dsp code, not e.g. all
uses of CONFIG_ and HAVE_ checks. But maybe it is already
enough to compile FFmpeg with MSVC with whole-programm-optimizations
enabled (if one does not disable too many components).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sbr_qmf_window_us array is basically symmetric around its middle
element and therefore the latter half is currently initialized from the
first half at runtime. Yet because the first half is initialized, the
array can't be placed in .bss at all, so that one gains nothing from not
already initializing the whole array statically. Therefore this commit
does exactly this.
(There are two exceptions to the symmetry: Elements 384 and 512 are the
negations of their mirror element; for the fixed-point decoder, Q31(-x)
does not equal -Q31(x). In order to keep the array exactly the same, the
latter form has been used for these two elements.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
move the the function aacsbr_tableinit definition from header file
to .c file to fix make checkheaders warning.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Fixes: 1489/clusterfuzz-testcase-minimized-5075102901207040
Fixes: out of array access
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.
Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
All HE-AAC samples with an LFE channel make this warning get spammed on
every frame. Turning off SBR for LFE channels makes sense (since it has
much less coefficients than normal channels do), so this error print is
of no value in this case.
It makes sense to keep the error in other cases, hence why it's still
around, degraded to warning severity since the decoder will still
attempt to decode without SBR.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The limit is a conservative guess, the spec does not seem to specify a limit
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also removes a #ifdef and special case for the fixed point case
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the input contains too many too large values, the imdct can overflow.
Even if it didn't, the output would be larger than the valid range of 29
bits.
Note that this is a very delicate limit: Allowing values up to 1<<25
does not prevent input larger than 1<<29 from arriving at
sbr_sum_square, while limiting values to 1<<23 breaks the
fate-aac-fixed-al_sbr_hq_cm_48_5.1 test.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Doing that doesn't make sense, because the only purpose of sbr_dequant
is to process the data from read_sbr_data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This allows removing a special case for the fixed point decoder and will
make error checks simpler
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When sbr->reset is set in encode_frame, a bunch of qsort calls might get made.
Thus, there is the potential of calling qsort whenever the spectral
contents change.
AV_QSORT is substantially faster due to the inlining of the comparison callback.
Thus, the increase in performance should be worth the increase in binary size.
Tested with FATE.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Move the existing code to a new template file.
Signed-off-by: Nedeljko Babic <nedeljko.babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array access
Fixes: signal_sigsegv_3670fc0_2818_cov_2307326154_moon.mux
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some files contain a few additional, all-0 bits.
Check for that case and don't print incorrect "not supported"
message.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Alex Converse <alex.converse@gmail.com>
Andreas Rheinhardt
Lynne
James Almer
Andreas Rheinhardt
Jun Zhao
Michael Niedermayer
Alex Converse
Rostislav Pehlivanov
Andreas Cadhalpun
Ganesh Ajjanagadde
Djordje Pesut
Michael Niedermayer
Vittorio Giovara
Reimar Döffinger