If we really want to support parameter changes, they need to be
signalled along with the AVPackets as parameter change side data,
not just changing the AVCodecContext parameters when a packet
is demuxed (since there may be other earlier packets yet undecoded).
Something similar was already done for the sample rate in 0883109b2,
but some parameters were left changeable.
This avoids having to recheck the channel count for validity for
each decoded frame in (ad)pcm decoders, unless the decoders
explicitly say that they accept parameter changes.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 5bbfe193a0a41bd2adb648c8c3f6901a575734a2)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Limit the size to INT_MAX/2 (for simplicity) to be sure that
size + BYTES_PER_FRAME_RECORD won't overflow.
Also factorize other existing error return paths.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 0ef1660a6365ce60ead8858936b6f3f8ea862826)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Limit the size to INT_MAX/2 (for simplicity) to be sure that
size + FF_INPUT_BUFFER_PADDING_SIZE won't overflow.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 459f2b393a3f89ed08d10fbceb4738d1429f268e)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Also don't pointlessly set the buffer size to 1 after copying
one packet.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 0d61f260010707f3028b818e8b24598e1a83d696)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The seektable is required for filling in ape->frames[i].pos
further down.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 183b9d843a9533774fabd3984a52f3987001acbc)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This will allow using rc_max_rate if no bit_rate is specified (on remuxing).
Reviewed-by: Matthieu Bouron
(cherry picked from commit 52cf08b4c8859f7cac010a7a59f7aa369384ad85)
* qatar/release/9:
Update Changelog
Prepare for 9.9 RELEASE
lavf: fix the comparison in an overflow check
dv: Add a guard to not overread the ppcm array
nuv: check ff_rtjpeg_decode_frame_yuv420 return value
Conflicts:
Changelog
RELEASE
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit a4e70918316c6d1423e559aad15823a5e0453fcf)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 164b67ca281fa5a47b965a858c7783aa547091b8)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently all uses of the emu edge code as well as the code itself
assume int linesize
changing some but not changing all would introduce a security issue
once all use this typedef a simple search and replace can be
done to switch them all to ptrdiff_t
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 2ffead98ddd384f61cdf6b1cb3f36592f54cd34a)
Conflicts:
libavcodec/videodsp.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/release/9:
mpegvideo: Avoid 32-bit wrapping of linesize multiplications
mjpegb: Detect changing number of planes in interlaced video
alac: Check that the channels fit at the given offset
4xm: Check that the read track value is non-negative
Conflicts:
libavcodec/alac.c
libavcodec/mjpegdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The check added in df33a58e5311ee9a64a573889b883a80e981af7b does not work
at all, rather it broke the summing of bitrates completely.
The comparission was wrong way around.
This commit replaces it by a simpler and hopefully clearer check
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit a5d67bc796e1f9a2b99b43ea807166b655e4bdbc)
Conflicts:
libavformat/utils.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'aade60ab165716523788cd11caf03ae61b40144a':
matroskadec: Check that .lang was allocated and set before reading it
alac: Limit max_samples_per_frame
ape demuxer: check for EOF in potentially long loops
4xm: check that bits per sample is strictly positive
lavf: avoid integer overflow when estimating bitrate
pictordec: pass correct context to avpriv_request_sample
Conflicts:
libavcodec/pictordec.c
libavformat/matroskadec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8dc4b2c92e492aa172327d10c926d5ca3a04371c':
pictordec: break out of both decoding loops when y drops below 0
vcr1: add sanity checks
Conflicts:
libavcodec/pictordec.c
libavcodec/vcr1.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
These prevent the rgb ljpeg code from being run on parameters that it doesnt
support. No testcase available but it seems possible to trigger these.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 61c68000eda643dfce96dc46b488d39fd5c4e309)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes Ticket2905
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit cdd5df8189ff1537f7abe8defe971f80602cc2d2)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure that linesize * start_y doesn't overflow, so that
emulated_edge_mc can get back the original value if needed.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit a711a2cb473dc95708f371a82c85c97fe789b5c2)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The code tries to decode a number of channels at the
offset given by the ff_alac_channel_layout_offsets table.
Even if the number of channels decoded so far doesn't
exceed the total number of channels, we need to check that
we actually can decode that number of channels at this offset
as well.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 35cbc98b720db95b923cb2d745f77bb2ee4363dc)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Otherwise buffer size calculations in allocate_buffers could
overflow later, making the code think a large enough buffer
actually was allocated.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit f7c5883126f9440547933eefcf000aa78af4821c)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
