There is no point in delaying the check and it avoids bugs with a
half-initialized context.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
They end up overwriting past the line end.
Partially based on a patch by Michael Niedermayer <michaelni@gmx.at>
Bug-Id: vlc/9700
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The decoder currently sets CODEC_FLAG_EMU_EDGE and relies on
get_buffer2() to always provide buffers with linesize == 2 * width.
This is wrong, since we place no such restriction on get_buffer2()
implementations.
Fix this by decoding into internal buffers and copying them to output
frames. Since this is a very obscure decoder, the performance hit should
not be an issue.
The decoder currently sets CODEC_FLAG_EMU_EDGE and relies on
get_buffer2() to always provide buffers with linesize == 2 * width.
This is wrong, since we place no such restriction on get_buffer2()
implementations.
Fix this by decoding into internal buffers and copying them to output
frames. Since this is a very obscure decoder, the performance hit should
not be an issue.
When downmixing 2.1 to 2-channel, if the 2.0 portion is Lt/Rt, sum-difference or dual mono, the actual output will be the same (with the LFE either mixed-in or discarded).
Also, when downmixing an arbitrary layout to 2-channel, if the bitstream contains custom downmix coefficients targeting Lt/Rt, then the output will be Lt/Rt rather than regular Stereo.
New versions of FreeType have moved the location of their API
header(s) and hide the location behind a macro.
Since the location changes between versions and no other way
to know the location exists, this workaround becomes necessary.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Specifically, when the corresponding input channel exists and its matrix
column is all-zero (which is necessary for zeroing the output), the
matrix column must be removed from the matrix.
This is not done currently, so the mixing code would end up using
uninitialized pointers from stack.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
This should make it easier to catch problems where some of those
pointers are used uninitialized, since reading from NULL should always
crash, while random numbers from stack can turn out to be valid
pointers, so random memory may be silently overwritten.
If it was set before then we can end up trying to decode a slice without
a valid slice header, which can lead to invalid memory access.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
The code cannot handle there being none, but that should not happen for
valid files.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
It has been checking the number of bits in the offset instead of the
actual offset.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Otherwise the generic code will unref them, which can then result in
last_picture_ptr == current_picture_ptr, which causes deadlocks at least
in rv40.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Anton Khirnov
Kostya Shishkov
Guillaume Martres
Johan Andersson
Tim Walker
Diego Biurrun
Martin Storsjö
Alex Converse
Luca Barbato