Fixes inconsistency that leads to out of array accesses with threads
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 5a9e3760495e8678ae87314670e3d9d5a1792c8d)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 11c3381ce3c353a4dadf9def6232e7604b0c5d2b)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes inconsistency ultimately leading to an out of array read
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 746016598d1885afd1fee976b6d315ed7eeefa68)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The not handling of frame gaps has lead to the lack of a dummy reference
frame, which has lead to the failure of decode_slice_header() which has
lead to one SEI recovery message being skiped which had introduced a
slightly suboptimal recovery point for at least 1 h264 file compared to
JM.
Found-by: Carl & BugMaster
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 9e5ef1c5c37208326c59d642e2dc7afd3f10b09b)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This ensures that frames do not get mixed on context reinits
Fixes Ticket2836
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 3c9dd93faa9f3c250428dd0548c075583aa07cc3)
This simplifies the code and fixes a deadlock
Fixes Ticket2927
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 29ffeef5e73b8f41ff3a3f2242d356759c66f91f)
Conflicts:
libavcodec/h264.c
This makes the decoder independent of mpegvideo.
This copy of the draw_horiz_band code is simplified compared to
the "generic" mpegvideo one which still has a number of special
cases for different codecs.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '5da51284937649a8ebb84fa951c235438fcbf8ae':
cavs: Add a dependency on h264chroma
lavc: Split out ff_hwaccel_pixfmt_list_420[] over individual codecs
Conflicts:
libavcodec/h263dec.c
libavcodec/h264.c
libavcodec/mpeg12.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c10da30d8426a1f681d99a780b6e311f7fb4e5c5':
shorten: set invalid channels count to 0
vorbisdec: check memory allocations
h264: check for luma and chroma bit dept being equal
Conflicts:
libavcodec/shorten.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Martin Storsjö <martin@martin.st>
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
The code is located in mpegvideo, and it's likely that in a minimal
config, we don't want to include debug info anyway.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '668e16a0dd1ff56d4beeff5c658d8a2a08dbfac8':
h264: on reference overflow, reset the reference count to 0, not 1.
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e671d3ad6cd7fe1d02e9b35b889a25d8c059fce9':
h264: do not copy ref count/ref2frm when updating per-frame context
flvdec: Check the return value of a malloc
Conflicts:
libavformat/flvdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is a regression introduced from the h264/mpegvideo split
Fixes out of array reads
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Instead, only extend edges on-demand when the motion vector actually
crosses the visible decoded area using ff_emulated_edge_mc(). This
changes decoding time for cathedral from 8.722sec to 8.706sec, i.e.
0.2% faster overall. More generally (VP8 uses this also), low-motion
content gets significant speed improvements, whereas high-motion content
tends to decode in approximately the same time.
Signed-off-by: Martin Storsjö <martin@martin.st>
These functions are mostly H264-specific (the only other user I can
spot is bink), and this allows us to special-case some functionality
for H264. Also remove the 16-bit-coeff with >8bpp versions (unused)
and merge the duplicate 32-bit-coeff for >8bpp (identical).
Signed-off-by: Martin Storsjö <martin@martin.st>
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700
to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb
(in the decode_slice loop) goes from 1759 to 1733 cycles on the clip
tested (cathedral), i.e. almost 30 cycles per mb faster.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Instead, only extend edges on-demand when the motion vector actually
crosses the visible decoded area using ff_emulated_edge_mc(). This
changes decoding time for cathedral from 8.722sec to 8.706sec, i.e.
0.2% faster overall. More generally (VP8 uses this also), low-motion
content gets significant speed improvements, whereas high-motion content
tends to decode in approximately the same time.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Instead, keep them in the bitstream buffer until we read them verbatim,
this saves a memcpy() and a subsequent clearing of the target buffer.
decode_cabac+decode_mb for a sample file (CAPM3_Sony_D.jsv) goes from
6121.4 to 6095.5 cycles, i.e. 26 cycles faster.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
Writing into uninitialized hw surfaces is not supported and triggers an assert inside avpriv_color_frame
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.
The nontrivial parts are:
1) extracting a simplified version of the frame management code from
mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
its own more complex system already and those were set only to appease
the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
for dxva, the draw_horiz_band() call is moved from
ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
because it's now different for h264 and MpegEncContext-based
decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
added some very simplistic frame management instead and dropped the
use of ff_h264_frame_start(). Because of this I also had to move some
initialization code to svq3.
Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>