If that is the case, the loop setting predictor_state in
sonic_decode_frame causes out of bounds reads of int_samples, which has
only frame_size number of elements.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
exp2 suffices here. Some trivial speedup is done in addition here by
reusing results.
This retains accuracy, and in particular results in identical values
with GNU libm + gcc/clang.
sample benchmark (Haswell, GNU/Linux):
proposed : 424160 decicycles in pow_table, 512 runs, 0 skips
exp2 only: 1262093 decicycles in pow_table, 512 runs, 0 skips
old : 2849085 decicycles in pow_table, 512 runs, 0 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit 'e02de9df4b218bd6e1e927b67fd4075741545688':
lavc: export Dirac parsing API used by the ogg demuxer as public
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f0b769c16daafa64720dcba7fa81a9f5255e1d29':
lavc: add a packet side data type for VBV-like parameters
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '31c51f7441de07b88cfea2550245bf1f5140cb8f':
avpacket: add a function for wrapping existing data as side data
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b09ad37c83841c399abb7f2503a2ab214d0c2d48':
h264: derive the delay from the level when it's not present
Merged without changing the strict_std_compliance check, as it breaks FATE
and changes decoding behavior.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '792b9c9dfcf44b657d7854368d975b5ca3bc22ca':
h264: set frame_num in start_frame(), not decode_slice_header()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Due to this typo max_center can be too large, causing nlsf to be set to
too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to
overflow to a negative value, which is not allowed for nlsf and can
cause an out of bounds read in silk_lsf2lpc.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also correct the check to reject log < 7, because UPDATE_CACHE only
guarantees 25 meaningful bits.
This fixes undefined behavior:
runtime error: shift exponent is negative
Testing with START/STOP timers in get_ue_golomb, one for the first
branch (A) and one for the second (B), shows that there is practically no
slowdown, e.g. for the cavs decoder:
With the check in the B branch:
629 decicycles in get_ue_golomb B, 4194260 runs, 44 skips
433 decicycles in get_ue_golomb A,268434102 runs, 1354 skips
Without the check:
624 decicycles in get_ue_golomb B, 4194273 runs, 31 skips
433 decicycles in get_ue_golomb A,268434203 runs, 1253 skips
Since the B branch is executed far less often than the A branch, this
change is negligible, even more so for the h264 decoder, where the ratio
B/A is a lot smaller.
Fixes: mozilla bug 1230239
Fixes: fbeb8b2c7c996e9b91c6b1af319d7ebc/asan_heap-oob_195450f_2743_e8856ece4579ea486670be2b236099a0.bit
Found-by: Tyson Smith
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
PSNR doesn't change as expected. The AAC spec doesn't really say
anything about how exactly to generate noise.
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>
The transpose_4x4H is wrong which cost me much time to find this bug. The orders of r2 and r3 are wrong,
this bug waste me much time while I make aarch64 arm instruction which used the function.
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>
