The only use case of it was the selftest code, and there the slightly more
complex indexing that is needed after its removial doesnt matter.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cab8c5f8e140c96ba3725ab709d823abfd1e31a5':
h264: do not reinitialize the global cabac tables at each slice header
See: 1e2e2c8095
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '71cabb521ac397db3903011d2de7afd3e0fc7ab6':
h264: do not discard NAL_SEI when skipping frames
Conflicts:
libavcodec/h264.c
See: 7d75fb381b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5f24fe82e5fcf227abb5ebf62aa9bc246fda8c0d':
mpegvideo: Initialize chroma_*_shift and codec_tag even if the size is 0
Conflicts:
libavcodec/mpegvideo.c
The chroma_*_shift and codec_tag code was not under a size!=0 check in ffmpeg
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes breakage in a few fate tests on certain setups
(that for some reason didn't break on OS X) after the previous
commit (8812a8057). Currently, some video streams are initialized
in ff_MPV_common_init with width/height set at 0 and only changed
to a proper video size with ff_MPV_common_frame_size_change later.
The breakage was diagnosed by Anton Khirnov.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
h263dec: Remove a hack that can cause infinite loops
Conflicts:
libavcodec/h263dec.c
See: d2981b8ef1
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This may improve compatibility of lgpegs generated by libavcodec
also encoded ljpegs become slightly smaller
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The actual usefulness of the hack is not known, and it does cause
infinite loops with some broken input files.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '5e25fdbfe01635cfc650ac4adc27d434b2df0d64':
vc1dec: Make sure last_picture is initialized in vc1_decode_skip_blocks
See: 09de0ffeab
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ede508443e4bf57dc1e019fac81bf6244b88fbd3':
vc1dec: Fix leaks in ff_vc1_decode_init_alloc_tables on errors
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '91be1103fd1f79d381edf268c32f4166b6c3b6d8':
wnv1: Make sure the input packet is large enough
Conflicts:
libavcodec/wnv1.c
See: f23a2418fb
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Remove can_safely_read() as its not really needed with
checked bitstream reader.
Fixes#2984.
Reported-by: Piotr Bandurski <ami_stuff@o2.pl>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Previously, s->context_initialized was left set to 1
if ff_vc1_decode_init_alloc_tables failed, skipping the
initialization completely on the next decode call.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
For codecs where decoding of a whole plane can simply
be skipped, we should offer applications to not decode
alpha for better performance (ca. 30% less CPU usage
and 40% reduced memory bandwidth).
It also means applications do not need to implement support
(even if it is rather simple) for YUVA formats in order to be
able to play these files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Issues with the code:
1) The skip_bits_long breaks packed B-frames since we skip
of the packed frame, even for VDPAU.
2) Calling ff_h263_find_resync_marker_reverse is nonsense for MPEG-4,
and for H.263 the only code using this (vaapi_mpeg4) explicitly reverts
this change!
3) mb_x/mb_y are always 0 when vaapi_mpeg4_decode_slice, so doing
computations with them is just obfuscation
4) due to not updating mb_y the code would always go into the error
resilience case, causing nonsense error messages and maybe further
issues.
While tested to fix the data provided to the decoder in case of
VDPAU so it is the same as for the non-hwaccel code, the VA-API code
was not tested to still work, and adding regression testing even
as a quick hack is much more complicated for it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
