Extensions in AAC USAC can be stored across multiple frames (mainly to keep CBR compliance).
This means that we need to reallocate a buffer when new data is received, accumulate the bitstream data,
and so on until the end of extension flag is signalled and the extension can be decoded.
This is made more complicated by the way in which the AAC channel layout switching is performed.
After decades of evolution, our AAC decoder evolved to double-buffer its entire configuration.
All changes are buffered, verified, and applied, on a per-frame basis if required, in often
random order.
Since we allocate the extension data on heap, this means that if configuration is applied,
in order to avoid double-freeing, we have to keep track of what we've allocated.
It should be noted that extensions which are spread in multiple frames are generally rare,
so an optimization to introduce av_refstruct_realloc() wouldn't generally be useful across the codebase.
Therefore, a copy is good enough for now.
Thanks to Michael Niedermayer for additional fixing.
Fixes: double free
Fixes: 393523547/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6740617236905984
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
The issue is that state->cur[] is 8-bits, but a+b+1 can overflow
before being clipped to 0xF in the following line, causing an incorrect
state to be saved for the next symbol.
This solves numerous bitstream desyncs, particularly when coefficients
with magnitude greater than 127 are sent.
The aim of this is twofold: a) Clang warns when setting a deprecated
field in a definition and because several of the widely set
AVCodec fields are deprecated, one gets several hundred warnings
from Clang for an ordinary build. Yet fortunately Clang (unlike GCC)
allows to disable deprecation warnings inside a definition, so
that one can create simple macros to set these fields that also suppress
deprecation warnings for Clang. This has already been done in
fdff1b9cbf for AVCodec.channel_layouts.
b) Using macros will allow to easily migrate these fields to internal ones.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's not possible to put USAC into ADTS due to exceeding the
field size (4 bits) for ADTS profile. As such cases where
the frame starts with 0xfff shouldn't be checked.
This ensures the sample at https://crbug.com/396190942 is
properly detected as USAC content.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
The limit is based on later code storing 32bits
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 393164866/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4606798354513920
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
types and SFO become confused for a USAC stream
Fixes: out of array access
Fixes: 383854203/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4996677847547904.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The array in ff_aac_usac_mdst_filt_cur that is passed to that has a size
of 7 elements, not 6 and the code in the function accesses the array at
index 6, which would be out of bounds if the size was actually 6.
Fixes: CID1603196
ff_aac_usac_config_decode() needs AACDecContext to be set but some callers
pass NULL.
Happens only when the LATM decoder is used, and USAC is not supported in
LATM
Fixes: member access within null pointer of type 'AACDecContext' (aka 'struct AACDecContext')
Fixes: 69435/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5733527483121664
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The issue is that if a frame has no complex stereo prediction,
the alpha values must all be assumed to be zero if the next frame
has complex prediction and uses delta coding.
The LC part of the decoder combines scalefactor application with
spectrum decoding, and this was the plan here, but that's not possible,
so change the function name.
The issue here is that the spec implied that the offset is done
on the dequantized scalefactor, but in fact, it is done on the
scalefactor offset. Delay dequantizing the scalefactors until
after noise synthesis is performed, and change to apply the
offset onto the offset.
Require that there is a valid layout with a valid number of channels
before accepting nb_elems.
The value is required when flushing.
Thanks to kasper93 for figuring it out.
The issue is that AOT 45 isn't defined anywhere, and looking at the git
blame, it seems to have sprung up through a reordering of the enum,
and adding a hole.
The spec does not define an explicit AOT for SBR and no SBR, and only
uses AOT 42 (previously AOT_USAC_NOSBR), so just rename AOT_USAC to
it and replace its use everywhere.
