* commit '747fbe0c212b81952bb27ec7b99fa709081e2d63':
roqvideodec: fix a potential infinite loop in roqvideo_decode_frame().
mp3dec: Fix VBR bit rate parsing
wmaprodec: return an error, not 0, when the input is too small.
vmdaudio: fix invalid reads when packet size is not a multiple of chunk size
h264: check for luma and chroma bit dept being equal
Prepare for 9.4 Release
Conflicts:
RELEASE
libavcodec/vmdav.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The decoder assumes a single bit depth for all the planes
while the specification allows different bit depths for luma
and chroma.
Avoid the possible problems described in CVE-2013-2277
CC: libav-stable@libav.org
(cherry picked from commit 4987faee78b9869f8f4646b8dd971d459df218a5)
Conflicts:
libavcodec/h264.c
* qatar/release/9:
update Changelog
h264: set ref_count to 0 for intra slices.
h264: on reference overflow, reset the reference count to 0, not 1.
flvdec: Check the return value of a malloc
Conflicts:
Changelog
libavcodec/h264.c
libavformat/flvdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
CC:libav-stable@libav.org
(cherry picked from commit 437211ae73ef1ed8285b4fed7620502ea4999e11)
Fixes deadlocks waiting for non-existing references with some fuzzed files.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Since decode_slice_header() returns before the reference lists are
constructed, there are zero valid references.
CC:libav-stable@libav.org
(cherry picked from commit 668e16a0dd1ff56d4beeff5c658d8a2a08dbfac8)
Conflicts:
libavcodec/h264.c
Some applications do not like that.
Fixes VDA
Reduces noise for VDPAU
Tested-by: Guillaume POIRIER <poirierg@gmail.com>
Tested-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit dece584a639c9fd61a72e21800815e8397b3b617)
Conflicts:
libavcodec/h264.c
This prevents faulty increasing of has_b_frames
Should fix Ticket 2062
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit c230af9bccc3cadb373f9007ba14fffb6c2acc75)
Fixes out of array accesses
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 695af8eed642ff0104834495652d1ee784a4c14d)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Without any correctly decoded slices, there can be no frame.
Fixes out of array reads
Found-by: Rafaël Carré
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 60af6c3138dc501a647bc69b374d5d33d5d86ab5)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The existing checks are insufficient to detect a pixel format
changes in case of some damaged streams.
Fixes inconsistency and later out of array accesses
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 11c99c78bafa77f679a1a3ba06ad00984b9a4cae)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If the motion vector is at a subpixel position, we need 3 pixels below
the motion vector's wholepel position available, not 2, since the MC
filter is a sixtap filter for the hpel position, and then a bilin filter
for the qpel position.
This patch fixes highly irreproducible (0.1%) fate failures in frame 2
and 4 of h264-conformance-cama2_vtc_b (e.g. first P-frame, first field,
last line of MB x=40,y=2 and second field and last lines of MBs x=39-40,
y=3). These used pre-loopfilter instead of post-loopfilter data because
the await_progress() waited for one line too little in that field, and
the motion vector of these particular MBs happened to align exactly to a
position where that demonstrates the bug.
CC: libav-stable@libav.org
(cherry picked from commit fb845ffdd335a1efd6dfd43e8adeb530397b348e)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
It's been returning an error value since
bad446e251405dc250c3cbee199072e083a1e4b9
Also check for the errors it returns.
(cherry picked from commit ea382767ad2191acbe97e90624059723e15f0e4b)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Clobbering these tables will temporarily clobber the template used
as a basis for other threads to start decoding from. If the other
decoding thread updates from the template right at that moment,
subsequent threads will get invalid (or, usually, none at all) mmco
tables. This leads to invalid reference lists and subsequent decode
failures.
Therefore, instead, decode the mmco tables only for the first slice in
a field or frame. For other slices, decode the bits and ensure they
are identical to the mmco tables in the first slice, but don't ever
clobber the context state. This prevents other threads from using a
clobbered/invalid template as starting point for decoding, and thus
fixes decoding in these cases.
This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
frame-multithreading enabled.
(cherry picked from commit bad446e251405dc250c3cbee199072e083a1e4b9)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* qatar/master:
cmdutils: update copyright year to 2013
h264: check SPS entries directly to detect pixel format changes
forgotten changelogs for 9_beta2
Conflicts:
Changelog
cmdutils.c
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Comparing AVCodecContext.pix_fmt against the get_pixel_format() return
value has the side effect of calling the get_format() callback on each
slice. Users of the callback will probably handle hardware accelerator
initialization in the callback.
Comparing AVCodecContext.pix_fmt against the get_pixel_format() return
value has the side effect of calling the get_format() callback on each
slice. Users of the callback will probably handle hardware accelerator
initialization in the callback.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Move some functions from dsputil. The idea is that videodsp contains
functions that are useful for a large and varied set of video decoders.
Currently, it contains emulated_edge_mc() and prefetch().
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit 'f1d8763a02b5fce9a7d9789e049d74a45b15e1e8':
mpegvideo: allocate scratch buffers after linesize is known
Conflicts:
libavcodec/mpegvideo.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Since we can't know which stride a custom get_buffer() implementation is
going to use we have to allocate this scratch buffers after the linesize
is known. It was pretty safe for 8 bit per pixel pixel formats since we
always allocated memory for up to 16 bits per pixel. It broke hoever
with cmdutis.c's alloc_buffer() and high pixel bit depth since it
allocated larger edges than mpegvideo expected.
Fixes fuzzed sample nasa-8s2.ts_s244342.
* commit '61c6eef5456f2bc8b1dc49a0a759c975551cea29':
h264: prevent decoding of slice NALs in extradata
doxy: Clarify what avpriv_set_pts_info does
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It is not posible to call get_buffer during frame-mt codec
initialization. Libavformat might pass huge amounts of data as
extradata after parsing broken files. The 'extradata' for the fuzzed
sample sample_varPAR_s5374_r001-02.avi is 2.8M large and contains
multiple slices.
* commit '072be3e8969f24113d599444be4d6a0ed04a6602':
h264: set parameters from SPS whenever it changes
asyncts: cosmetics: reindent
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
