MPV_decode_mb_internal needs 3 * 16 * linesize bytes of scratch buffer
For interlaced content, linesize is multiplied by two after the allocation
of the scratch buffer, and the dest_cr pointer ends past the buffer.
This patch makes ff_mpv_frame_size_alloc allocate a total of
(aligned line_size) * 2 * 16 * 3 bytes, which suffices even for the
interlaced case.
CC:libav-stable@libav.org
Signed-off-by: Jindrich Makovicka <makovick@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit 259af1b923)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
When JPEG-LS support is disabled the decoder would feed the
data to the JPEG Lossless decode_*_scan function resulting in
faulty decoding.
CC: libav-stable@libav.org
(cherry picked from commit b25e49b187)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Set interlaced to false if we don't have an interlaced frame
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 0881cbf314)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Broken bitstreams could report a larger than specified number of
channels and cause outbound writes.
CC:libav-stable@libav.org
(cherry picked from commit a943a132f3)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
They can be different if the last keyframe failed to decode correctly.
Fixes possible invalid reads in such a case.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit b1bb8fb860)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Also add an additional sanity check to the alt_quant table.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 66531d634e)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The data offsets are relative to the bistream header, which is 16 bytes
after the start of the data.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 34e6af9e20)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This can happen when the number of skipped lines is not consistent with
the number of coded lines.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 3623589edc)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
It can be 0 or -1 for invalid files, which may result in invalid memory
access.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit b88f902125)
Conflicts:
libavcodec/bmv.c
When `off' is 0, `0x537F6103 << 32' in the following expression invokes
undefined behavior, the result of which is not necessarily 0.
(0x537F6103 >> (off * 8)) | (0x537F6103 << (32 - (off * 8)))
Avoid oversized shifting.
CC: libav-stable@libav.org
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit eba1ff3130)
get_uint returns an unsigned value, use an unsigned to store
blocksize to make sure the comparison logic is correct and report
correctly the error for the channel count not supported.
CC: libav-stable@libav.org
(cherry picked from commit 5cf7c72757)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Prevent the loop shorten_decode_close from writing and freeing out of
the array boundary.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
CC: libav-stable@libav.org
(cherry picked from commit c10da30d84)
Avoids an infinite loop in the calling programs with decoder not
consuming any input and not returning output.
CC:libav-stable@libav.org
(cherry picked from commit cacad1c058)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The loop a few lines below the xan_unpack() call accesses up to
dec_size * 2 bytes into y_buffer, so dec_size must be limited to
buffer_size / 2.
CC:libav-stable@libav.org
(cherry picked from commit 8a49d2bcbe)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Avoids an infinite loop in the calling programs with decoder not
consuming any input and not returning output.
CC:libav-stable@libav.org
(cherry picked from commit ea1136baaf)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
When there is just 1 byte remanining in the buffer, nothing will be read
and the loop will continue forever. Check that there are at least 8
bytes, which are always read at the beginning.
CC:libav-stable@libav.org
(cherry picked from commit 3e2f200237)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit eae0879d96)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Returning 0 may result in an infinite loop in valid calling programs. A
decoder should never return 0 without producing any output.
CC:libav-stable@libav.org
(cherry picked from commit 4c0080b7e7)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The decoder assumes a single bit depth for all the planes
while the specification allows different bit depths for luma
and chroma.
Avoid the possible problems described in CVE-2013-2277
CC: libav-stable@libav.org
(cherry picked from commit 4987faee78)
Conflicts:
libavcodec/h264.c
Since decode_slice_header() returns before the reference lists are
constructed, there are zero valid references.
CC:libav-stable@libav.org
(cherry picked from commit 668e16a0dd)
Conflicts:
libavcodec/h264.c
The specification does not prevent an encoder to write the amplitude 0
as 0 amplitude_bits.
Our get_bits() implementation might not support a zero sized read
properly, thus the additional branch.
(cherry picked from commit 23bd9ef4b2)
Conflicts:
libavcodec/vorbisdec.c
Rate and order must not be 0 even if the specification does not say that
explicitly.
(cherry picked from commit 5b47c19bfd)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Damaged frames can lead to a mismatch, which can cause a segfault
due to using an incorrect channel mapping.
CC:libav-stable@libav.org
(cherry picked from commit d7c450436f)
Conflicts:
libavcodec/ac3dec.c
