also add GET_TMP2() macro
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit fc35df8931)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The mb address fits in int
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 592ba6ec10)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is probably unneeded and normal int would be fine, but its
safer to use LL and this isnt speed relevant
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit b4ad2853c5)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The <<31 case needs LL
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit c77cc2c176)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
all values before 2.5 seem to be filled in now
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 8c8ee17e8d)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
also add deprecation note for avcodec_get_pix_fmt_loss(), avcodec_find_best_pix_fmt_of_2()
Found-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit f7a1c5e4d2)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The vec_ste calls were mistakenly changed to vec_vsx_st in c5ca76a, which
caused stack smashing.
Changing them back fixes crashes on ppc64el, when configured with
--toolchain=hardened.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 840c3c0531)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes: misdetection of test2.mp3
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit e15b29bb18)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If we throw away the buffered incomplete frame, make sure to also
throw away the buffered bits of an incomplete byte at the same
time.
(cherry picked from commit df07c07b3d)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The frame_rate update was missing leaving the output frame rate
wrong.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit a46a23d30f)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is required as the location of this field could change and is
specified in libavformat not avdevice
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit ba97cf2c45)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Check memory earlier, check one more allocation and clean up on error.
CC: libav-stable@libav.org
Bug-Id: CID 1257773
(cherry picked from commit 014b6b416f)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The altivec optimizations on little endian ppc64 don't work without vsx.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 6108485cf7)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If refdata was NULL, the memcpy() ended up copying the same memory
block onto itself, which is not only pointless, but also undefined
behavior.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 921706691a)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The parser must always set the out_size and out_data pointers. The API
seems to require it, and the common code in parser.c also relies on it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit b88e80589b)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This avoids printing uninitialized bytes if no error message is set
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 6d1a2efb8a)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
dvdsub_decode() can call append_to_cached_buf() 2 times, the second time
with ctx->buf as argument. If the second append_to_cached_buf() reallocs
ctx->buf, the argument will be a pointer to the previous, freed block.
This can cause invalid reads at least with some fuzzed files - and
possibly with valid files.
Since packets can apparently not be larger than 64K (even if packets are
combined), just use a fixed size buffer. It will be allocated as part of
the DVDSubContext, and although some memory is "wasted", it's relatively
minimal by modern standards and should be acceptable.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 816577716b)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Attemtping to decode them could lead to invalid writes with some fuzzed
samples.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit bcaa9099b3)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The previous code assumed if an atom was marked with a 64-bit
size extension, it actually had that data available. The new
code verfies there's enough data in the atom for this to be
done.
Failure to verify causes total_size > atom.size which will
result in negative size calculations later on.
Found-by: Paul Mehta <paul@paulmehta.com>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 3ebd76a9c5)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Under abnormal conditions the item_count may exceed the max
allocation size on 32-bit systems, this causes the allocated
size to overflow and become too small for the given count.
Additionally, if av_reallocp() fails its allocation, the
fragment_index_count is not correctly decremented.
Ensuring further havoc may be wrought, the error code for
read_tfra() is not checked upon return.
Found-by: Paul Mehta <paul@paulmehta.com>
positive return code and use of _array functions by commiter
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit db42d93a61)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The code previously added 1 to len without checking its size,
resulting in an overflow which can corrupt value[-1] -- which
may be used to store unaligned ptr information for certain
allocators.
Found-by: Paul Mehta <paul@paulmehta.com>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
