The lowest supported VAAPI version is 0.34 (checked at configure
time), so this test is no longer needed.

If no string argument is supplied when av_hwdevice_ctx_create() is
called to create a VAAPI device, we currently only try the default
X11 display (that is, $DISPLAY) to find a device, and will therefore
fail in the absence of an X server to connect to.  Change the logic
to also look for a device via the first DRM render node (that is,
"/dev/dri/renderD128"), which is probably the right thing to use in
most simple configurations which only have one DRM device.

Unbreak `avconv -filter_complex testsrc`.

Regression introduced in a3a0230a

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This will be needed for frame threading.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

We need more information from last/cur_frame than from reference
buffers, so we can use a simplified structure for reference buffers,
and then store mvs and segmentation map information in last/cur.

This prepares the decoder for frame threading support.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Not from the underlying frame. Fixes races with frame threading in
field-coded files, where decoding would wait for the wrong field (e.g.
random failures in mixed-nal-coding).

Bug-Id: 954

Fixes memory leaks in some FATE tests.

A non-existent av_buffer_pool_can_uninit() function is mentioned instead
of av_buffer_pool_uninit(). Also, this function is to be called by the
caller, not the pool itself.

Bug-Id: 660

The frame dimensions are 16bit, so the mv bounds can easily overflow
int16 for large videos.

Bug-Id: Handbrake/46
CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>

In such a case behave as if the buffer was not reallocatable -- allocate a
new one and copy the data (preserving just the part described by the
reference passed to av_buffer_realloc).

CC: libav-stable@libav.org
Reported-By: wm4 <nfxjfg@googlemail.com>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Also a slight change to the ssse3 code, which prevents a theoretical
overflow in the sharp filter.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Roughly 25% faster MC than ssse3 for blocksizes 32 and 64.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

pavgb is an sse integer instruction, so the mmxext flag is enough
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

It only contains the MC SIMD, other SIMD will go into different files.

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Fixes hwaccel decoding of files with multiple slices.
Found-By: Mark Thompson <sw@jkqxz.net>

This makes the m4v detection less trigger-happy.

Bug-Id: 949
Signed-off-by: Diego Biurrun <diego@biurrun.de>

This reverts commit 014773b6.

Since 230b1c07, the bytewise AV_W*() macros only expand their
argument once, i.e. doing exactly the same change as was done
in the AV_COPY*U macros, so this change is no longer necessary.
Signed-off-by: Martin Storsjö <martin@martin.st>

This reverts commit 25bacd0a.

Since 230b1c07, the bytewise AV_W*() macros only expand their
argument once, so revert to the more readable version of these.
Signed-off-by: Martin Storsjö <martin@martin.st>

AV_WN64 is meant for unaligned data, but the existing av_alias* unions
(without a definition for the av_alias attribute - we don't have one
for MSVC) indicate to the compiler that they would have sufficient
alignment for normal access, i.e. the compiler is free to assume
8 byte alignment.

On ARM, this makes sure that AV_WN64 (or two consecutive AV_WN32) is
done with two str instructions instead of one strd.
Signed-off-by: Martin Storsjö <martin@martin.st>

This avoids issues with expanding the argument multiple times,
and makes sure that it is of the right type for the following shifts.

Even if the caller of a macro could be expected not to pass parameters
that have side effects if expanded multiple times, these fallback
codepaths are rarely, if ever, tested, so it is expected that such
issues can arise.

Thefore, for safety, make sure the fallback codepaths only expand
the arguments once.
Signed-off-by: Martin Storsjö <martin@martin.st>