This fixes the speed regression from 20626f53e9
and still checks sufficiently to prevent out of allocated memory accesses
due to the index
Before:
1823 decicycles in mpeg2_fast_decode_block_non_intra, 8388493 runs, 115 skips
After:
1808 decicycles in mpeg2_fast_decode_block_non_intra, 8388494 runs, 114 skips
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes the speed regression from 20626f53e9
and still checks sufficiently to prevent out of allocated memory accesses
due to the index
Before:
1681 decicycles in mpeg2_fast_decode_block_intra, 4194238 runs, 66 skips
After:
1658 decicycles in mpeg2_fast_decode_block_intra, 4194248 runs, 56 skips
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
XvMC has long ago been superseded by newer acceleration APIs, such as
VDPAU, and few downstreams still support it. Furthermore XvMC is not
implemented within the hwaccel framework, but requires its own specific
code in the MPEG-1/2 decoder, which is a maintenance burden.
This reverts commit bf36dc50ea, reversing
changes made to b7fc2693c7.
Conflicts:
libavcodec/h264.c
Keeping support for the old VDPAU API has been requested by our VDPAU maintainer
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Slice threading does not work with hardware acceleration, as decoding
is per-picture. This fixes Bugzilla #542.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The decoder did not start predicted frames with missing references but
called the end of frame handling on them anyway. This caused an
assertion in the VA API HW accelorator since it tried to render a
picture with uninitialized buffers.
Just like get_buffer, get_format should not be called from a different
thread if thread_safe_callbacks is not set.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also move the declaration to internal.h, and add restrict qualifiers
to the declaration (as in the implementation).
Signed-off-by: Martin Storsjö <martin@martin.st>
The total frame size is a combination of the 12 bits in the sequence
header and 2 more bits in the the sequence extension. While the
specification explicitly forbids the dimensions from the sequence header
from being 0 (thus ruling out multiples of 4096), such videos
apparrently exist in the wild so we should attempt to decode them.
Based on a patch by Michael Niedermayer <michaelni@gmx.at>
Fixes Bug 416.