Fixes out of array accesses
Fixes: asan_heap-oob_25bcd7e_3783_cov_3553517262_utvideo_rgba_median.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_heap-oob_2573085_3783_utvideo_rgba_median.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes a regression since fb3e380 similar to ticket #2661,
reported by fluffrabbit at aol dot com.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Also prevents an error since the native decoder (if enabled) is
always used to probe Ut Video-encoded files, even if the user
forces libutvideo to be the decoder. Without this patch, the probe
would fail, and the video wouldn't get properly handed over,
resulting in failure to set codec parameters. When the native
decoder is disabled, libutvideo can probe and initialize decoding
without issues.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Put the zero length check in place of code that was never used
during decoding, as zero-length slices were generally refused
in decode_frame().
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
General cosmetics, such as keeping lines under 80 characters,
fixing a couple of typos (predition -> prediction) and a
general style fix that was pointed out by Derek when I was having
my sliced multithreading patch in review by him.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
>> time ./avconv -i file.avi -f null -
Before : real 0m7.784s
After : real 0m3.662s
Tested on a Intel Core i3 Processor (2 cores, 4 threads).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
I am not sure these new values are correct, not am I sure
the semantics are a good idea since we do not seem to make any
use of them but they caused a lot of confusion, but this
seems to make things closer to matching the documentation.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
If the frame is filled with the same colour, encoder may produce no data
and the fill value is indicated by zero code length (the rest of symbols
will have 0xFF for code length, meaning invalid). So such Huffman trees
should be treated specially.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Luma slices in YUV420 colourspace should have height in multiple of two since
they have the same line of chrominance data corresponding to pair of them.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>