This avoids divisions by zero later.
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 82e266c6d3fbf3cc74e515b883e66543381a0f2c)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is similar to the fix in 35cbc98b.
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 e9d61de96c113ee0ef8082833c7e682df0e23eec)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The init function reads one byte of extradata.
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 f50803354c6acb4575379d7c54ca48ec5d36dd61)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Since the number of channels is multiplied by 36 and assigned to
to a uint16_t, make sure this calculation didn't overflow. (In
certain cases the calculation could overflow leaving the
truncated block_align at 0, leading to divisions by zero later.)
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 d4c2a3740fb95f952a87ba320d2bf31f126bdf68)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This avoids crashes when initializing the range coder for
the first slice context.
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 b1db33159fdc2da4bdd8c75e4ff9a7dd0ef2f0c2)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is similar to an existing check for the second-last frame
from 062421e3.
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 ea78a348d86a3a733f6c1e0a65cfdd8283d924b9)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/eacmv.c
This avoids a potential division by zero.
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 f875a732e36786d49f3650e3235272891a820600)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some files have the duration set to -1 in the mdhd atom, more
or less legitimately. (We produce such files ourselves, for the
initial duration in fragmented mp4 files.)
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 7f8d41eb097e8d4223c9caf97dd332a2fdb29d52)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Also pass on any returned error code.
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 1115689d54ea95a084421f5a182b8dc56cbff978)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/svq3.c
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>
