The specification says the value is expressed in 10 bits including
the 4-byte CRC.
(cherry picked from commit 694b7cd873f8b06af109036eff1ccd741afdd28e)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavformat/mpegtsenc.c
The input data must remain constant, make a copy instead. This is in
theory a performance hit, but since I failed to find any samples
using this feature, this should not matter in practice.
Also, check the size of the header, avoiding invalid reads on truncated
data.
CC:libav-stable@libav.org
(cherry picked from commit 7b588bb691644e1b3c168b99accf74248a24e3cf)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Conflicts:
libavcodec/svq1dec.c
0 means no data consumed, so it can trigger an infinite loop in the
caller.
CC:libav-stable@libav.org
(cherry picked from commit c7d9b473e28238d4a4ef1b7e8b42c1cca256da36)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Conflicts:
libavcodec/cdgraphics.c
Fixes possible invalid memory accesses on corrupted data.
CC:libav-stable@libav.org
Bug-ID: CVE-2013-3674
(cherry picked from commit a1599f3f7ea8478d1f6a95e59e3bc6bc86d5f812)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Bug-Id: CVE-2013-0868
inspired by a patch from Michael Niedermayer <michaelni@gmx.at>
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
(cherry picked from commit 744b406ff3474e77543bcf86125a2f7bc7deaa18)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Conflicts:
libavcodec/huffyuvdec.c
ModeTab.fmode has only 3 elements, so indexing it with ftype
in the initialier for 'size' is invalid when ftype == FT_PPC.
This fixes crashes with gcc 4.8.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 4bf2e7c5f1c0ad3997fd7c9859c16db8e4e16df6)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Fixes errors in slice based multithreading introduced in 0b300daad2f5.
CC: libav-stable@libav.org
(cherry picked from commit 5945c7b35d9169caf9ecef1c419eebdebb909e60)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Properly address CVE-2011-3946 and parse bitstream as described in the spec.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Make sure the buffer size does not exceed the expected
RLE size.
Prevent an out of array bound write.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Bug-Id: CVE-2013-0852
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 00915d3cd2ce61db3d6dc11f63566630a9aff4ec)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Some optimized template functions reference optimized symbols, so they
must be explicitly disabled when those symbols are unavailable.
(cherry picked from commit ec36aa69448f20a78d8c4588265022e0b2272ab5)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This fixes compilation with libswscale disabled.
(cherry picked from commit ab799664755c8bc2c439c428ff5b538c105a5c38)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This avoids a segfault in avconv_opt.c:opt_target when trying to
determine the norm.
(cherry picked from commit dc71f1958846bb1d96de43a4603983dc8450cfcc)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This is safer and possibly fixes invalid reads on truncated data.
(cherry-picked from commit 541427ab4d5b4b6f5a90a687a06decdb78e7bc3c)
CC:libav-stable@libav.org
Conflicts:
libavcodec/eamad.c
(cherry picked from commit f9204ec56a4cf73843d1e5b8563d3584c2c05b47)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
get_len can overflow for specially crafted payload.
Reported-By: Don A. Baley <donb@securitymouse.com>
CC: libav-stable@libav.org
(cherry picked from commit ccda51b14c0fcae2fad73a24872dce75a7964996)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavutil/lzo.c
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>
Prevent a division by zero down the codepath.
Sample-Id: 00001721-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Only consume an AVPacket when all the samples have been read.
When the rate of samples output is limited (by the default value
of max_samples), consuming the first packet immediately will cause
timing problems:
- The first packet with PTS 0 will output 4608 samples and be
consumed entirely
- The second packet with PTS 64 will output the remaining samples
(typically, a lot, that's why max_samples exist) until the decoded
samples of the first packet have been exhausted, at which point the
samples of the second packet will be decoded and output when
av_decode_frame is called with the next packet).
That means there's a PTS jump since the first packet is 'decoded'
immediately, which can be seen with avplay or mplayer: the timing
jumps immediately to 6.2s (which is the size of a packet).
Sample: http://streams.videolan.org/issues/6348/Goldwave-MAClib.ape
Bug-Debian: http://bugs.debian.org/744901
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
(cherry picked from commit 91d4cfb8127f1de6c4ad173a30fffe584700046d)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
It is my understanding that "Unless otherwise stated, all data in a
QuickTime movie is stored in big-endian byte ordering" [1] in MOV files.
I have a couple of thousand files, which technically are invalid because
their sound sample description element 4CC is 'lpcm' but its version is
0 - and "Version 0 supports only uncompressed audio in raw ('raw ') or
twos-complement ('twos') format" [2]
Because isom.c only contains a mapping for 4CC 'lpcm' to
AV_CODEC_ID_PCM_S16LE, these files have their audio decoded as LE when
it is actually BE.
This commit adds AV_CODEC_ID_PCM_S16BE as the first match for 4CC 'lpcm'.
[1]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 21
[2]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 178
Reviewed-by: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>
The correct point that seperates ISO and MAC language codes is 0x400
according to the current QT spec. Old QT specs did not list where this
seperation is but apparently only defined the meaning of the first 137.
(cherry picked from commit 9e71cc81f3655cacf0f91860fba3043f13b64059)
(cherry picked from commit 7940306a47df602be4f57a62175706265bbfd0aa)
Additional fixes by Nigel Touati-Evans <nigel.touatievans@gmail.com>.
Check the index for streams with a time drift of 2s or a buffer drift
of 64MB.
Bug-Id: 666
CC: libav-stable@libav.org
Sample-Id: yet-another-broken-interleaved-avi.avi
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
In case start_frame() fails, this potentially invalid frame can still be
output to the caller.
Bug-Id: 672
Bug-Id: debian/741240
Bug-Id: ubuntu/1288206
This is basically an overread/overwrite-safe memcpy between a
GetByteContext and a PutByteContext.
CC:libav-stable@libav.org
(cherry picked from commit 5748faf291fec297ef25d81962b52b3438f54278)
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
CC:libav-stable@libav.org
(cherry picked from commit de9d2705f61ef569487ec5f8974a9c7ce34ec783)
Otherwise the generic code will unref them, which can then result in
last_picture_ptr == current_picture_ptr, which causes deadlocks at least
in rv40.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Prevents using GetBitContexts with data from previous calls.
Fixes access to freed memory.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Otherwise the ER code might try to use some already freed references.
Fixes possible access to freed memory.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
In this case we may not have a current frame, while first_field being
set implies we do.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Higher modes are not allowed for 16x16/chroma, which is what this
function is used for. Otherwise this function would return 0 (vertical
prediction) for invalid higher modes, which could result in invalid
reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
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
