Ported from arm NEON and added vector_dmul_scalar.
Functions between 1.5 and 5 times faster than the C implementations
using Apple's clang-503.0.19 on A7.
Based on the aarch64 asm. CPU cycle counts on cortex-a9 compared to
gcc 4.8.2:
before: 475 decicycles in get_cabac_noinline, 67106035 runs, 2829 skips
after: 393 decicycles in get_cabac_noinline, 67106474 runs, 2390 skips
Overall speedup is above 2%. Code generated by clang 3.4 is slower on
the same hardware and the relative change is a little larger.
Based on the x86 branchless get_cabac asm. get_cabac_noinline() gets
approximately 20% faster (no cycle counts available) compared to clang
from Xcode 5.1 beta5. More than 6% faster overall. A part of the overall
speedup might be explained by additional inlining of get_cabac().
The overread avoidance fix in cbddee1cca
broke the computation for the last row since it prevented the safe
reading from the height+1-th row.
CC: libav-stable@libav.org
Based on a patch from Christophe Gisquet.
Unrolling of the m == 0 case avoids a possible use of the uninitilized
value sum when s->predictor_history is not set. I failed to find a
sample for it. It also reduced the cycle count from 220 to 150 on
sandy bridge, x86_64 linux, gcc 4.8.2 compared to his patch.
Moving cpunop from the HAVE_LIST to the ARCH_EXT_LIST_X86 has the side
effect of enabling it. The semantics of the check have to be changed
from enable if successful to disable if unsuccessful. This was missing
in 2b0bb69997 causing build errors with
nasm.
Makes fate-h264 pass under valgrind --undef-value-errors=yes with
-cpuflags none. {avg,put}_h264_chroma_mc8_8 approximately 5% faster,
{avg,put}_h264_chroma_mc4_8 2% faster both on x86 and arm.
Altivec can only load naturally aligned vectors. To handle possibly
unaligned data a second vector is loaded from an offset of the original
location and the data is recovered through a vector permutation.
Overreads are minimal if the offset for second load points to the last
element of data. This is 7 for loading eight 8-bit pixels and overreads
are reduced from 16 bytes to 8 bytes if the pixels are 64-bit aligned.
For unaligned pixels the overread is reduced from 23 bytes to 15 bytes
in the worst case.
User data is usually coded before slice data. That means the frame
the user data belongs to is not available while parsing the user data.
The stereo3D side data has to use the same indirection over the private
context as pan scan information and A53 captions.
Bug-Id:632
The original test without a forced idct is still useful since it tests
the switching of the idct algorithm/permutation on x86 with MMX. MMXext
or SSE2. Make sure the test runs only if MMX inline asm is available and
force -cpuflags to all.
Add the required bitexact flag for both tests.
Fixes dependency file generation with gas-preprocessor.pl and clang.
Flags copied from GCC and tested with Apple's clang from Xcode 5 and
5.1 and clang 3.2, 3.3, 3.4 on Linux.
This handles macroblock edges for the chroma components in the same way
as for the luma compoment for 4:4:4 streams. The Spec explicitly states
that the deblocking filter is not applied to edges at the boundary of
the picture.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
NEON and VFP are currently mandatory for all ARMv8 profiles. Both are
handled as extensions as far as cpuflags are concerned. This is
consistent with handling x86_64 which always has SSE2, but still
handles it as an extension.
Stack is always 16 byte aligned and clz, 64bit operations and unaligned
memory access are fast in aarch64 mode on ARMv8.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The to_free AVframe must be freed just like the other ones.
Indeed, the calling application may expect all frames to be
released.
(This regression caused use-after-free in VLC with hwaccel.)
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
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.
ff_mpeg_unref_picture clears the flag indicating that the frame needs to
be reallocated after a frame size change. Since we have now reference
counted buffers we can unref the buffers immediately.
Allows decoding with only three frame buffers with frame reference
counting. Fixes VAAPI based decoding in vlc which uses only three
frame buffers for the mpegvideo-based codecs.
Cells starting at a position aligned to 8 pixels but wider than
4 blocks are copied with 3 blocks per loop. This creates problems on the
next loop iterations since the routine copying 2 blocks requires the
same alignment on some architectures like ARM NEON.
Intra codecs do not need an update_thread_context() function and never
call ff_thread_finish_setup(). They rely on ff_thread_get_buffer()
calling it. So call it even if the get_buffer2 function pointer is
avcodec_default_get_buffer2 and it has not been called before.
Allows use of AVHWAccel based decoders with frame based multithreading.
The decoders will be forced into an non-concurrent mode by delaying
ff_thread_finish_setup() calls after decoding of the current frame
is finished.
This wastes memory by unnecessarily using multiple threads and thus
copies of the decoder context but allows seamless switching between
hardware accelerated and frame threaded software decoding when the
hardware decoder does not support the stream.
Since c977039e58 plane count for
PIX_FMT_HWACCEL pixel formats is 0 instead of 1. The created dummy
AVBuffers are still bogus since AVFrame does not hold frame data when
AVHWAccels are used.
AVCodecContext.bits_per_raw_sample is updated from the previous thread
in the generic update function before the codec specific update_thread
function is called. The check for reinitialization of dsp functions uses
bits_per_raw_sample. When called from update_thread_context it will be
already at the current value and the dsp functions aren't updated if
only the bit depth changes.
AVCodecContext release_buffer() shall be NULL for audio codecs using
get_buffer. The backward compatibility code hence have to check before
calling it.
libavutil/arm/asm.S sets '.arch' depending on HAVE_ARMV5TE so that
assembling armv5te code will always succeed even if the default -march
flag does not support it. HAVE_ARMV5TE_EXTERNAL tests assembling code
with the default arch.
Fixes the missing symbol ff_prefetch_arm with --cpu= not including
armv5te.
CC: libav-stable@libav.org
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.
The sample in https://bugzilla.libav.org/show_bug.cgi?id=393 and
samples/F4V/H263_NM_f.mp4 both have codec_tag H263 for different
codecs. H263 is apparently used by Flash Media Server for Sorensen
Spark videos.
Patch based on commit 5442083b1c by
Carl Eugen Hoyos. Fixes bug 393.
The VC1 decoder uses edge_emu_buffer simultaneously for luma and chroma
and needs more space. That was not a problem before f1d8763a02
since the size for edge_emu_buffer was always calculated with 2 byte per
pixel since the linesize was not known.
Fixes occasionally fate errors in vc1_sa10143.
Janne Grunau
