Also remove unused AVX cruft.

TBM and BMI1 are supported by Trinity/Piledriver.
The others (and BMI1) will probably appear in Intel's upcoming Haswell.
Also update x86inc with AVX2 stuff.

Broke register preservation in x264_cpu_cpuid and x264_cpu_xgetbv.
Did not cause any problems.

Broke if the first macroblock in the slice exceeded the set slice-max-size.

BGR/BGRA input was correct.

x264_cavlc_init needs to be stack-aligned now.

Some x264 asm assumed that the high 32 bits of registers containing "int" values would be zero.
This is almost always the case, and it seems to work with gcc, but it is *not* guaranteed by the ABI.
As a result, it breaks with some other compilers, like Clang, that take advantage of this in optimizations.
Accordingly, fix all x86 code by using intptr_t instead of int or using movsxd where neccessary.
Also add checkasm hack to detect when assembly functions incorrectly assumes that 32-bit integers are zero-extended to 64-bit.

Not necessary for x264, as -m amd64 already does the right thing, but used by external users of x86inc.

Not necessary with the CAVLC lookup table for zero run codes.

Helps avoid VBV predictors going nuts with very low-cost MBs.
One particular case this fixes is zero-cost MBs: adaptive quantization decreases the QP a lot, but (before this patch), no cost penalty gets factored in for this, because anything times zero is zero.

Required for row re-encoding.

Extremely accurate, possibly 100% so (I can't get it to fail even with difficult VBVs).
Does not yet support rows split on slice boundaries (occurs often with slice-max-size/mbs).
Still inaccurate with sliced threads, but better than before.

Intel was nice enough to make tzcnt equal to "rep bsf", which is backwards-compatible.
This means we don't actually have to add new functions to make it work.

Recent AMD CPUs' instruction decoders choke horribly on extremely long nops (i.e. with 4 prefixes).
Won't affect much, since we don't use ALIGN much.

Fully reconstruct frames even without dump-yuv.

Lowers encoding latency around 14% in sliced threads mode with preset superfast.
Additionally, even if there is no waiting time between frames, this improves parallelism, because hpel+deblock are done during the (singlethreaded) lookahead.
For ease of debugging, dump-yuv forces all of the threads to wait and finish instead of setting b_full_recon.

Regression in r2183.
Bizarrely seemed to work on many platforms, but crashed on win64 and may have been slower.
Only affected sliced threads during encoding, but could cause crashes on x264 encoder close even without sliced threads.

Was using qp instead of qscale; could cause NANs (not to mention less accurate results).

The code does, in fact, handle CAVLC+8x8dct correctly already.

MSVS requires exported variables to be declared with the DATA keyword, and requires that imported variables be declared with dllimport.
This does not fix x264 cli being unable to use a shared library built by ICL however.

Adds support for a bunch of targets, including:
aarch64 (armv8)
arm-linux-androideabi

Makes multilib compilation more convenient.

x264 never supported it and never will because nobody uses it.

New assembly function with SSE2, SSSE3 and XOP implementations for calculating absolute sum of differences.

Some use-cases of x264 involve encoding video with large constant areas of the frame.
Sometimes, the caller knows which areas these are, and can tell x264.
This API lets the caller do this and adds internal tracking of modifications to macroblocks to avoid problems.
This is really only suitable without B-frames.
An example use-case would be using x264 for VNC.

Split each lookahead frame analysis call into multiple threads.  Has a small
impact on quality, but does not seem to be consistently any worse.

This helps alleviate bottlenecks with many cores and frame threads. In many
case, this massively increases performance on many-core systems.  For example,
over 100% faster 1080p encoding with --preset veryfast on a 12-core i7 system.
Realtime 1080p30 at --preset slow should now be feasible on real systems.

For sliced-threads, this patch should be faster regardless of settings (~10%).

By default, lookahead threads are 1/6 of regular threads.  This isn't exacting,
but it seems to work well for all presets on real systems.  With sliced-threads,
it's the same as the number of encoding threads.

Fix some integer overflows and check input parameters better.
Also fix incorrect type specifiers for demuxer info printing.

Allow manual invocation of WIN64_SPILL_XMM even under INIT_MMX
SSE version of mova is movaps rather than movdqa.
YMM version of movnta.
Add mp size for named arguments.
Fix DEFINE_ARGS when used outside of a cglobal.
Define a few more cpuflags.
3-argument wrappers for a few more instructions.

Limits VBV mispredictions after long periods of relatively constant video.

Implement a basic separable bilinear filter to rescale the quantizer offsets.
Structure inspired by swscale, but floating-point instead of fixed-point.
Not as optimized as it could be, but it's quite fast already.

Example compression penalties on a 720p video game recording:
First pass with 720p and second as 480p: ~-1.5% (vs. same res)
First pass with 480p and second as 720p: ~-3% (vs. same res)

Turn off the sub8x8 partitions, try it, and turn them back on if it didn't help.
Small compression improvement with p4x4 on (~0.1-0.5%).
Also update related comments.

Fix a typo that made an early-skip less effective.
Avoid a relatively unpredictable branch.
Slightly changed output due to the typo-fix.
~50 cycles faster on Core i7.

People don't seem to like this so I'm just going to get rid of it.

This eliminates a memory leak when calling x264_encoder_close.

Backported from libav.

Previously it was policy to use -pthread, but OpenBSD now recommends -lpthread.
its been libpthread anyway and policy has changed to stop using -pthread.

Useful to judge the resulting quality of a frame when VBV is enabled.

Allow fast skipping even if the pskip MV isn't zero.

Add the input frame opaque pointer to the arguments.
This makes it easier to use with multiple simultaneous x264 encodes.

x264 would free mb_info before it was completely done using it.

This feature lets the callee know which decoded macroblocks have changed.

Prerequisite for another configure patch after this.
Idea copied from libpthread.

ICL's preprocessor doesn't handle it correctly.
This fix is similar to libav's fix in 0db2d9.

Lossless mode can't currently be enabled mid-stream.

The Apple A6 CPU doesn't support performance counters, so this test caused a crash.

This allows overriding the value from outside the file.
This can be useful if x86inc.asm is used outside of x264.

The name "3dnowext" is more common than "3dnow2". Doesn't affect x264.

Doesn't actually change encoding behavior, but makes it more correct.
Warning messages should now be accurate at higher bit depths and non-4:2:0.
Technically, since it redefines x264_level_t, this is an API version increment.

Use the first macroblock of each slice instead of the last of the previous.
Lets us pick a reasonable initial QP for the first slice too.
Slightly improved compression.

Small compression improvement; up to ~0.5% in extreme cases.
Helps more with small slice sizes (tiny resolutions or slice-max-size).
Note that this changes the 2-pass stats file format.

Fixes a possible regression in r2228.

Allocate AVFrames correctly with avcodec_alloc_frame().
This caused crashes with newer libavcodecs that try to free frame extradata.

Solaris responds correctly to the same value as Cygwin, so let's use that.

Slightly wrong numbers in level table.

Doesn't actually affect x264, but it's more correct.

GAS doesn't seem to like spaces in vld1 anymore, so remove those.

This is obviously bad user input, but x264 shouldn't crash if it happens.

Use this in 8-bit loopfilter functions so they can be used if
there is no aligned stack (e.g. x86-32 MSVC or ICC 10.x).

Now RET checks whether it immediately follows a branch, so the programmer dosen't have to keep track of that condition.
REP_RET is still needed manually when it's a branch target, but that's much rarer.
The implementation involves lots of spurious labels, but that's ok because we strip them.

Automatically use VEX-encoding in AVX/AVX2/XOP/FMA3/FMA4 functions for all instructions that exists in a VEX-encoded version.
This change makes it easier to extend existing code to use AVX2.
Also add support for AVX emulation of a few instructions that were missing before.

First AVX2 function for testing.
Bump yasm version to 1.2.0 for AVX2 support.

It is no longer needed now that we've bumped the version requirement of yasm to 1.2.0.

The "CentaurHauls family 6 model 9 stepping 8" family of CPUs (flags:
fpu vme de pse tsc msr cx8 sep mtrr pge mov pat mmx fxsr sse up rng
rng_en ace ace_en) SIGILLs on long nop codes.

Regression in r2145.
Assembly assumed array was [2][64] when it was actually [2][63].
Tiny (~0.1%) compression improvement.

Code assumed keyframe analysis would only pull one frame off the list; this
isn't true with open-gop.

Synced from libav.
The new name is more descriptive and will allow defining a separate public
prefix for externally visible library symbols.

This allows defining externally visible library symbols.

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

~4% faster PIC

WIN64:
~3% faster and 16 byte shorter cabac_encode_bypass
~8% faster cabac_encode_terminal
Benchmarked on Ivy Bridge

UNIX64:
One instruction less in cabac_encode_bypass

Reduces code size because movaps/movups is one byte shorter than movdqa/movdqu.
Also merge MMX and SSE versions of memcpy_aligned into a single macro.

Smarter decision to improve fast-first-pass performance in 2-pass encodes.
Dramatically improves CPU utilization on multi-core systems.

Tested on a quad-core Ivy Bridge (12 threads, 1080p):
Fast first pass:
veryfast:     ~7% faster
faster:      ~11% faster
fast/medium: ~15% faster
slow/slower: ~42% faster
veryslow:    ~55% faster
CRF/1-pass:
veryfast:     ~9% faster
(all others remained the same)