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 9514440337)
(cherry picked from commit 5df52b0131)
Fixes invalid writes on pixel format changes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 4c3e1956ee)
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 f777504f64)
(cherry picked from commit 5bd083d0216d9ee649039c84999fb61386536ac1)
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 dd2d0039b6)
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 9ecabd7892)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Conflicts:
libavcodec/h264_ps.c
And manage the reallocation failure path.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 5e992a4682)
Fixes out of array accesses and integer overflows.
(cherry picked from commit d1916d13e2)
Adresses: CVE-2013-7010, CVE-2013-7014
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Also add an error message an return a more suitable error code
(INVALIDDATA, not EINVAL);
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit c453723ad7)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
It has been checking the number of bits in the offset instead of the
actual offset.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit a6a2282c25)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Fix writing over the end
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Addresses: CVE-2013-0845
(cherry picked from commit 2a0fb7286d)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
They are used when decoding the frame header.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The function requires increasing the fuzz factor for the ac3/eac3 encode
tests and even so makes fate fail. It only provides a slight encoding
speedup for legacy CPUs that do not support SSE2. Thus its benefit is not
worth the trouble it creates and fixing it would be a waste of time.
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>
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>
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>
(cherry picked from commit 8812a8057f)
Signed-off-by: Martin Storsjö <martin@martin.st>
