Fixes Ticket1075
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 6f9803e5e02c557e1003cface9f3084a7e1e43e4)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This bug might have been exploitable (out of HEAP buffer writes)
Bug introduced by libav
commit a55d5bdc6e28a2cfefc440d792de5cc4f02377e2
Date: Tue Mar 6 15:15:42 2012 -0800
algmm: convert to bytestream2 API.
(cherry picked from commit c2e3b564b32d596f5a66d47409f9e07a067a3084)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Forgot to add the equivalent amount to the incoming sample pointer as the output pointer.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit 2e626dd5136f4daa244b37284e22483cdc7df1ac)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
10l: Forgot to adjust deinterleave for new location of incoming samples in 7946a5a.
This produced incorrect, but surprisingly listenable results.
Thanks to Justin Ruggles for the report.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit dc7e7d4dd96eebd430e7bfa847b751add0e126ab)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Interlaced images can have 32 references (16 per field), so limiting the
array size to 16 leads to invalid writes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 48cbe4b092113eae0b3e5d6a08b59027f913a884)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Progressive images can have only 16 references, error out if there are
more, since the data is almost certainly corrupt, and the invalid value
will lead to random crashes or invalid writes later on.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit e0febda22d0e0fab094a9c886b0e0f0f662df1ef)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Parsing the entire NAL as SPS fixes decoding of some AVC bitstreams
with broken escaping. Since the size of the NAL unit is known and
checked against the buffer end we can parse it entirely without buffer
overreads.
Fixes playback of
http://streams.videolan.org/streams/mp4/Mr_MrsSmith-h264_aac.mp4
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
(cherry picked from commit 3aa661ec561d7a20812b84b353b0d7855ac346c8)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Protects against overreads in the input buffer.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 4c25269cedd042abcb823c42d33609564861c374)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The safe bitstream reader broke it since the buffer size was specified
in bytes instead of bits.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
CC: libav-stable@libav.org
(cherry picked from commit a1c036e961a32f7208e7315dabfa0ee99d779edb)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
x264 always opens the file itself with fopen, so we cannot use the
standard lavc stats mechanism.
CC: libav-stable@libav.org
(cherry picked from commit d533e395e14d403948ca2424efbcee92429ef8e1)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This reverts commit 729ebb2f185244b0ff06d48edbbbbb02ceb4ed4e.
There was an off-by-one error in the bit mask calculation clearing
actually the last valid bit and causing
http://bugzilla.libav.org/show_bug.cgi?id=227
The broken sample (Mr_MrsSmith-h264_aac.mp4) the commit was fixing
does not work after correcting the off-by-one error.
CC: libav-stable@libav.org
(cherry picked from commit 8a6037c3900875ccab8d553d2cc659bdef2c9d0e)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
MPC8 allows indices of mpc_CC up to -1, and mpc_SCF up to -6, thus pad
the tables by that much on the left end.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit d7eabd50425a61b31e90c763a0c3e4316a725404)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
We slightly overread the input buffer, so we require
padding at the end of the buffer, as is documented in the
get_bits API. Without padding, we'll read uninitialized
data or beyond the end of the .rodata, which may crash.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 4ffe5e2aa5241f8da9afd2c8fbc854dcc916c5f9)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The codec would keep returning the last decoded frame if the stream
contains B-frames, since it wouldn't clear that frame from the list of
frames to be returned to the user.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 83f15a1228895434a982c840b09edccd1c64e800)
Conflicts:
libavcodec/cavsdec.c
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This way, it protects against overreads for 4bpp/2bpp content also.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit cc5dd632cecc5114717d0b90f8c2be162b1c6ee8)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Results of IDCT can by far outreach the range of ff_cropTbl[], leading
to overreads and potentially crashes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit c23acbaed40101c677dfcfbbfe0d2c230a8e8f44)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
