* commit '9bd4561d74a46dd6557140e286228e09e380674c':
tiff: Check the check_size() return value and forward it
Conflicts:
libavcodec/tiffenc.c
See: d50aa006fb
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cbf31d5f15774b3ffd1e2009159dc7154a767b09':
rtpdec_h263_rfc2190: Clear the stored bits if discarding buffered data
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The input packets are always assumed to be padded and
the av_fast_ family of function takes a pointer to a pointer.
Thanks to Nicolas Dufresne <nicolas.dufresne@collabora.com> for
a similar patch.
Introduced in 7b588bb691.
Bug-Id: 766
CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fix linking when only a subset of vaapi decoders is enabled.
Bug-Id: 760
CC: libav-stable@libav.org
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Also use the same type for add_entry and check_size.
Bug-Id: CID 700699
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Vittorio Giovara <vittorio.giovarao@gmail.com>
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.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit df07c07b3d)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
ff_mpv_common_init sets s->context_initialized.
This fixes decoding of h261 in the cases where the demuxer
hasn't already set the frame size.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 3bb465245f)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
These have a DXSA tag and contain alpha in addition to
color values for palette.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 5a1addd7c1)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A failure in segment_end() or segment_start() would lead to freeing
a dangling pointer and in general further calls to seg_write_packet()
or to seg_write_trailer() would have the same faulty behaviour.
CC: libav-stable@libav.org
Reported-By: luodalongde@gmail.com
(cherry picked from commit b3f0465736)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
It uses at least sin().
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit f97f2a3527)
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>
Found-by: Paul Mehta <paul@paulmehta.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 3859868c75)
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>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The code blindly trusted buffer offsets read from the file in the RLE
decoder. Explicitly check the offset. Also error out on other RLE
decoding errors.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit c9151de7c4)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
