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 1a5a6ac01b)
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 601c2015bc)
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 c77d409bf9)
(cherry picked from commit 9b9aee27f4)
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 d1d99e3bef)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/pcx.c
(cherry picked from commit 7e350b7ddd)
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 7ba0cedbfe)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit f06e39fe6b)
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 aa0dd52434)
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 9fb0de86b4)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 812955a12b)
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 a81cad8f86)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit a63e83cd4b)
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 b772b0e28e)
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 e9d61de96c)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit bacf5db196)
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 f50803354c)
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 b1db33159f)
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 ea78a348d8)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/eacmv.c
(cherry picked from commit 2e12af4587)
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 f875a732e3)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit c8c93795e4)
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 1115689d54)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/svq3.c
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 0d61f26001)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
q4-q7/d8-d15 are supposed to not be clobbered by the callee.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit d307e408d4)
Signed-off-by: Martin Storsjö <martin@martin.st>
The function accidentally uses mmxext instructions, so it causes sigill
on mmx-only CPUs and provides no benefit on CPUs with mmxext available.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some code paths can call it with invalid length.
CC: libav-stable@libav.org
(cherry picked from commit 71953ebcf9)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A packet larger than cin->bitmap_size does not make sense.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit fd81899321)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/dsicinav.c
Fix at least a memory leak.
CC: libav-stable@libav.org
(cherry picked from commit ca488ad480)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/alsdec.c
