There is no point in delaying the check and it avoids bugs with a
half-initialized context.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
If it was set before then we can end up trying to decode a slice without
a valid slice header, which can lead to invalid memory access.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Avoid a division by 0 in ff_mpeg4_set_one_direct_mv.
Sample-Id: 00000168-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
(cherry picked from commit 9514440337875e0c63b409abcd616b68c518283f)
(cherry picked from commit 5df52b0131d3d4d804ad6e221bc9a2cd8b201ef2)
(cherry picked from commit aa2a3ca27a3269e2b975686652204607fad8bc49)
The overread avoidance fix in cbddee1cca0ebd01e8c5aa694d31228eb4de4b41
broke the computation for the last row since it prevented the safe
reading from the height+1-th row.
Fixes invalid writes on pixel format changes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 4c3e1956ee35fdcc5ffdb28782050164b4623c0b)
(cherry picked from commit bd57e783437f990c3ac4747eeebe20332e103980)
For left HFYU prediction, we predict from the buffer buf+1 using 8- or
16-byte reads. This means that aligning the buffer by 16 bytes is in
itself not sufficient, because if the width itself is 16- or 8-byte
aligned, the buffer will not be padded, and thus a read of size 16 at
buf+1 will overflow boundaries at the right edge. Padding the buffer by
1 byte is sufficient to not overflow its boundaries.
Fixes bug 342.
(cherry picked from commit 98d0d19208959766a58f13dd6a678d1f765a26ac)
f777504f640260337974848c7d5d7a3f064bbb45 changed a - in +
CC: libav-stable@libav.org
(cherry picked from commit d922c5a5fbaf0b6c73bd8c81ae059bc6e406961c)
(cherry picked from commit 3ce77e04c2ca4b9e7fa6b94b51e8d7c5f188da86)
(cherry picked from commit 8cba6f58c8acaa0ca6749110a2746bbe60ff2dab)
And use the value from the specification.
Sample-Id: 00000451-google
Found-by: Mateusz j00ru Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit f777504f640260337974848c7d5d7a3f064bbb45)
(cherry picked from commit 5bd083d0216d9ee649039c84999fb61386536ac1)
Conflicts:
libavcodec/h264.c
(cherry picked from commit 41380e017afcca3119acb560c08a60a97d416c3c)
Conflicts:
libavcodec/h264.c
Fixes an issue where the B-frame coding mode switches from interlaced
fields to interlaced frames, causing incorrect decisions in the motion
compensation code and resulting in visual artifacts.
CC: libav-stable@libav.org
Signed-off-by: Tim Walker <tdskywalker@gmail.com>
(cherry picked from commit dd2d0039b6405dc724e4fef0d5b8f49530eea3aa)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 3cc8d9bc1ffc6c0888960fb009f12fa3047bb663)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
An invalid VUI is not considered a fatal error, so the SPS containing it
may still be used. Leaving an invalid value of num_reorder_frames there
can result in writing over the bounds of H264Context.delayed_pic.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 9ecabd7892ff073ae60ded3fc0a1290f5914ed5c)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Conflicts:
libavcodec/h264_ps.c
(cherry picked from commit 299c5dcfb0cd3debdf07943edfb46f4aeb02ca91)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Too much code relies in having init_get_bits fed with a valid
buffer and set its dimension to 0.
Check for NULL buffer instead.
(cherry picked from commit 4603ec85ed620e585fc6e2e072c99858ed421855)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Apparently gcc-4.8.2 miscompiles enums resulting in a lucky fpe soon
after it.
Passing the enum value as integer makes the ftype == FT_PPC condition
evaluates correctly.
pthread_wait_cond can wake up unexpectedly (Wikipedia: Spurious_wakeup).
The FF_THREAD_SLICE thread mechanism could spontaneously execute
jobs or allow the caller of avctx->execute to return before all
jobs were complete.
Test both cases to ensure the wakeup is real.
Signed-off-by: Ben Jackson <ben@ben.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 311583e7798237be5cc531d672a9e37f8c729d83)
Sometimes, if pthread_create() failed, then pthread_cond_wait() could
accidentally be called in the worker threads after the uninit function
had already called pthread_cond_broadcast(), leading to a deadlock.
Don't call pthread_cond_wait() if c->done is set.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
(cherry picked from commit 1a5a6ac01b0ad2cf3d2128372ea41f3c1cfc2d3f)
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>
If the height is zero, the decompression will probably end up
failing due to not fitting into the allocated buffer later
anyway, so this doesn't need any more elaborate check.
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 601c2015bc16f0b281160292a6a760cbbbb0eacb)
This is required, since invalid parameters actually could
pass the switch check below.
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 c77d409bf95954aceb762dd800d1ee2868c4b0d4)
(cherry picked from commit 9b9aee27f4e43b4a6b0884f8a6f49eb0289d7c09)
This fixes reads out of bounds.
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 d1d99e3befea5d411ac3aae72dbdecce94f8b547)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/pcx.c
(cherry picked from commit 7e350b7ddd19af856b55634233d609e29baab646)
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>
(cherry picked from commit 7ba0cedbfeff5671b264d1d7e90777057b5714c6)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit f06e39fe6b272a11782c023c31eec43bfce3138d)
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>
(cherry picked from commit aa0dd52434768da64f1f3d8ae92bcf980c1adffc)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
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>
(cherry picked from commit 9fb0de86b49e9fb0709a8ad1e1875e35da841887)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 812955a12b190012c134be33a93f27308953eb2f)
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>
(cherry picked from commit a81cad8f86d1feb7e4bfae29e43f3e994935a5c7)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit a63e83cd4b43c3dcef38f7fefe41c002a263af0f)
Previously, s->context_initialized was left set to 1
if ff_vc1_decode_init_alloc_tables failed, skipping the
initialization completely on the next decode call.
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 b772b0e28eba6abf76d86ee8c6e459a86642db5a)
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>
(cherry picked from commit bacf5db1962a6955ce80eea6bbc86c6970d7d360)
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>
