Both gnu as and clang treat lines starting with '#' as comments if they
aren't consumed by the C-style preprocessor.
Using '//' does not work with clang since comments are removed before
macro expansion.
avcodec might depend on avresample and with --as-needed required symbols
might be get removed if avresample is linked before avcodec.
Fixes link failures of avprobe and avplay on aarch64 with
--enable-neon-clobber-test.
avctx->coded_{height,width} will always equal h->{height,width} since
init_dimensions() does that explicitly, Size changes are detected by
changes in mb_{height,width} earlier and propagated through the
needs_reinit variable.
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.
Janne Grunau
