Wavpack format documentation mentions that 131072 is
max number of samples.
This fixes huge memory allocations in sample from ticket #1889.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Integer Overflow Checker detected an integer
overflow while FATE was running.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since we are clipping before we shift the values to
16 or 32 bits, we should not shift the min/max clip
values to compensate.
Fixes 8 and 24 bit lossy decoding.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This reverts e6e7bfc1 and 365e1ec2.
The code may be incorrect both before and after the revert, but we
do not have any samples that were fixed by the original commits.
Fixes ticket #871.
Reference decoder clips data before shifting it to final range and also
forces 32-bit lossy mode to be actually 24-bit lossy mode in order to be
able to perform proper clipping.
In the case that (frame_flags & 0x03) == 3, hybrid_maxclip
may have had a signed integer overflow.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It doesn't make much sense to clip pre-shift,
nor is it correct for proper decoding.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When decoding lossy WavPack samples, they are supposed
to be clipped, in order to be decoded correctly.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
wavpack_decode_block() supposes that it is called back with the exact
same buffer unless it has returned with an error. With multi-channels
files, wavpack_decode_frame() was breaking this assumption.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
wavpack_decode_block() supposes that it is called back with the exact
same buffer unless it has returned with an error. With multi-channels
files, wavpack_decode_frame() was breaking this assumption.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This function should return number of samples decoded, not number of bytes
decoded.
Spotted by Uoti Urpala.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes improper flushing in the cases when the same frame is decoded in
several iterations (for being too large to fit into output buffer) and flush is
called mid-decoding and it also resets context in case of decoding errors.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
None of these symbols should be accessed directly, so declare them as
hidden.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit d36beb3f69)
Michael Niedermayer
Anton Khirnov
Justin Ruggles
Paul B Mahol
Hendrik Leppkes
Derek Buitenhuis
Carl Eugen Hoyos
Kostya Shishkov
Diego Biurrun
Laurent Aimar
Alex Converse
Mans Rullgard
Reinhard Tartler
Diego Elio Pettenò