We read 2 bytes for 15 out of 16 pixels, therefore we need to
have at least 30 bytes, not 16.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Decoded data is always written in pairs within this decoder.
This fixes writes out of bounds.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, we returned 0, meaning successful decoding but 0
bytes consumed, leading to an infinite loop.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the input buffer contains more data after the deflate stream,
the loop previously left running infinitely, with inflate returning
Z_STREAM_END.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
In lpc_prediction(), we write up to array element 'lpc_order' in
an array allocated to hold 'max_samples_per_frame' elements.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The le argument is passed so the function has the same prototype as the
other similar functions. It is otherwise unused
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This allows supporting files for which the image stride is smaller than
the max. block size + number of subpel mc taps, e.g. a 64x64 VP9 file
or a 16x16 VP8 file with -fflags +emu_edge.
The only use case of it was the selftest code, and there the slightly more
complex indexing that is needed after its removial doesnt matter.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cab8c5f8e140c96ba3725ab709d823abfd1e31a5':
h264: do not reinitialize the global cabac tables at each slice header
See: 1e2e2c8095de2d9ea3259305cfeff28f40e4ca12
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '71cabb521ac397db3903011d2de7afd3e0fc7ab6':
h264: do not discard NAL_SEI when skipping frames
Conflicts:
libavcodec/h264.c
See: 7d75fb381ba774a8d2fa7de0c12140cd465c0255
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5f24fe82e5fcf227abb5ebf62aa9bc246fda8c0d':
mpegvideo: Initialize chroma_*_shift and codec_tag even if the size is 0
Conflicts:
libavcodec/mpegvideo.c
The chroma_*_shift and codec_tag code was not under a size!=0 check in ffmpeg
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes breakage in a few fate tests on certain setups
(that for some reason didn't break on OS X) after the previous
commit (8812a8057). Currently, some video streams are initialized
in ff_MPV_common_init with width/height set at 0 and only changed
to a proper video size with ff_MPV_common_frame_size_change later.
The breakage was diagnosed by Anton Khirnov.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
h263dec: Remove a hack that can cause infinite loops
Conflicts:
libavcodec/h263dec.c
See: d2981b8ef191fc7876e3486e42222ab6a8777c24
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This may improve compatibility of lgpegs generated by libavcodec
also encoded ljpegs become slightly smaller
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The actual usefulness of the hack is not known, and it does cause
infinite loops with some broken input files.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
