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 a1f7844a11)
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 dc71f19588)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This is safer and possibly fixes invalid reads on truncated data.
(cherry-picked from commit 541427ab4d)
CC:libav-stable@libav.org
Conflicts:
libavcodec/eamad.c
(cherry picked from commit f9204ec56a)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The actual predictor value, set by the trellis code, never
was written back into the variable that was written into
the block header. This was accidentally removed in b304244b.
This significantly improves the audio quality of the trellis
case, which was plain broken since b304244b.
Encoding IMA QT with trellis still actually gives a slightly
worse quality than without trellis, since the trellis encoder
doesn't use the exact same way of rounding as in
adpcm_ima_qt_compress_sample and adpcm_ima_qt_expand_nibble.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 0776e0ef6b)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This was broken in 095be4fb - samples+ch (for the previous
non-planar case) equals &samples_p[ch][0]. The confusion
probably stemmed from the IMA WAV case where it originally
was &samples[avctx->channels + ch], which was correctly
changed into &samples_p[ch][1].
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 3d79d0c93e)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
As indicated in the function documentation, the header MUST be
checked prior to calling it because no consistency check is done
there.
CC:libav-stable@libav.org
(cherry picked from commit f2f2e7627f)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fixes an invalid read past the end of avpriv_mpa_freq_tab.
Fixes divide-by-zero due to sample_rate being set to 0.
Bug-Id: 705
CC:libav-stable@libav.org
Conflicts:
libavcodec/mpegaudiodecheader.c
Hack partially based on a commit by Michael Niedermayer <michaelni@gmx.at>
Should fix (or work around) bug 458.
(cherry picked from commit 76d23f4031)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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
(cherry picked from commit 3a177a9cca)
(cherry picked from commit 0499f7809c1fcc33ed710cdf771a18b374702135)
Instead of using a fixed bitrate_idx, calculate a matching bitrate for
the XING header.
Using a fixed bitrate_idx causes tools such as file(1) and mediainfo(1)
to report wrong bitrate and bitrate mode when using CBR.
Bug-Id: https://bugs.debian.org/736088
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 617a1a98a6)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 0f6e309b97)
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 91d4cfb812)
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>
(cherry picked from commit 360022bd3b)
(cherry picked from commit d37fac6dbb)
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 9e71cc81f3)
(cherry picked from commit 7940306a47)
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
It should work best for debian stable and people not installing the .pc
file.
(cherry picked from commit aa80742539)
Conflicts:
configure
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The current release of version 1 uses libopenjpeg1.
(cherry picked from commit 4a8562394b)
Conflicts:
configure
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Previously, if read_connect failed, the ret variable was unmodified
and had the value 0, indicating success, which then was returned from
the rtmp_open function, even though it actually failed.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 6477139721)
This fixes cases where very few input samples (fewer than needed for one
output sample) are passed to lavr at the beginning.
CC:libav-stable@libav.org
(cherry picked from commit ac976ed91e)
This is basically an overread/overwrite-safe memcpy between a
GetByteContext and a PutByteContext.
CC:libav-stable@libav.org
(cherry picked from commit 5748faf291)
The correct "next" input sample is not the first sample of the
resampling buffer, but the center sample of the filter_length-sized
block at the beginning.
CC:libav-stable@libav.org
Arch specific calls should have an emms_c following to keep the cpu
state consistent.
Reported-By: wm4
CC: libav-stable@libav.org
(cherry picked from commit e995cf1bcc)
avcodec_flush_buffers() must release all internally held references
according to its documentation, for which all the threads need to be
flushed.
CC:libav-stable@libav.org
Bug-Id: vlc/9665
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
