Sandy Bridge, Ivy Bridge and Bulldozer cores don't support FMA3.

Should fix compilation on MacOS

Signed-off-by: James Almer <jamrial@gmail.com>

Note that the motion information includes subpel motion information

This was likely forgotten in 56bdf61b.

Tested:
```
$ make examples -j
...
$ doc/examples/extract_mvs in.264 | head -40 | \
    csvcut -C framenum,source,flags |csvlook
| blockw | blockh |  srcx | srcy |  dstx | dsty | motion_x | motion_y | motion_scale |
| ------ | ------ | ----- | ---- | ----- | ---- | -------- | -------- | ------------ |
|     16 |     16 |    20 |   26 |     8 |    8 |       49 |       72 |            4 |
|     16 |     16 |   152 |   15 |   136 |    8 |       65 |       28 |            4 |
|     16 |      8 |   360 |    3 |   360 |    4 |        1 |       -6 |            4 |
|     16 |      8 |   360 |   13 |   360 |   12 |       -1 |        4 |            4 |
|     16 |     16 |   440 |   10 |   440 |    8 |        3 |       10 |            4 |
|      8 |     16 |   829 |    7 |   836 |    8 |      -31 |       -6 |            4 |
|      8 |     16 |   844 |    7 |   844 |    8 |       -1 |       -4 |            4 |
|     16 |     16 | 1,004 |   14 | 1,048 |    8 |     -177 |       24 |            4 |
|     16 |     16 | 1,096 |    8 | 1,096 |    8 |       -1 |        0 |            4 |
|     16 |      8 | 1,417 |   24 | 1,416 |    4 |        7 |       82 |            4 |
|     16 |      8 | 1,416 |   13 | 1,416 |   12 |        0 |        6 |            4 |
|     16 |      8 |    87 |   20 |    88 |   20 |       -7 |        0 |            4 |
|     16 |      8 |    99 |   44 |    88 |   28 |       45 |       66 |            4 |
...
```

Also:
```
$ make fate -j
...
```

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This could be improved further by not allocating the buffers
that won't be needed lateron in the first place.

Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

That way the SAR will be automatically set on the AVFrame.

Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Fixes compilation with yasm.

Signed-off-by: James Almer <jamrial@gmail.com>

Fixes compilation with old assemblers.

Signed-off-by: James Almer <jamrial@gmail.com>

Fixes assertion failures after avcodec_flush_buffers(), where
stashed hwaccel state is present, but prev_thread is NULL.

Found-by: Wang Bin <wbsecg1@gmail.com>

Fix suggested by Mark Harris. Fixes ticket #9890

Simplified after feedback from Anton Khirnov.

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

The position does not exist anymore.

Michael has not been doing much work on it in the last few years and I
have by far the most commits.

It was somewhat hacky and unnecessary.

To support non-aligned buffers during the post-transform step, just iterate
backwards over the array.

This allows using the 15xN-point FFT, with which the speed is 2.1 times
faster than our old libavcodec implementation.

~4x faster than the C version.
The shuffles in the 15pt dim1 are seriously expensive. Not happy with it,
but I'm contempt.

Can be easily converted to pure AVX by removing all vpermpd/vpermps
instructions.

There are many ways to go about it, and this one seems optimal for both
MDCTs and PFA FFTs without requiring excessive instructions or stack usage.

As it happens, some still need their contexts.

There are two issues here. Firstly, the floating-point comparison
is always true. Seconly, the code depends on the default value of
min_hard_comp implicitly, which can be dangerous.

Partially fixes ticket 9859.

Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

Results weren't signed.

This is more similar to its regular use, and prevents inaccuracies
of huge float*float multiplications from failing the tests.

Will help debugging.

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Simplifies the test, while trying more values and preventing pointlessly
running benchmarks in a loop.

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

According to the HEIF specification (ISO/IEC 23008-12) Section
7.5.3.1, tracks with handler_type 'auxv' must contain a 'auxi' box
in its SampleEntry to notify the nature of the auxiliary track to the
decoder.

The content is the same as the 'auxC' box. So parameterize and re-use
the existing function.

Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>

this maps to the vpxenc argument with the same name and the
VP9E_SET_MIN_GF_INTERVAL codec control

Signed-off-by: James Zern <jzern@google.com>
Reviewed-by: Vignesh Venkatasubramanian <vigneshv@google.com>

This replace the sse3 version, which was not really faster than the sse one.

Signed-off-by: James Almer <jamrial@gmail.com>

Inspired by the optimization done to the C version by Rémi Denis-Courmont.

Signed-off-by: James Almer <jamrial@gmail.com>

The input complex factors are constant for each iterations. This
substitudes 4 loads, 2 additions and 2 subtractions per iteration of
the inner-loop with another 4 loads. Thus effectively 4 arithmetic
operations per iteration of the inner loop are avoided, i.e. 24
operations per iteration of the outer loop, or 24 * (n - 1) operations
in total.

If the inner loop is not unrolled by the compiler, this also might
also save some pointer arithmetic as most instruction sets do not
have addressing modes with negated register offsets (12 - j). Unless
the compiler is optimising for code size, this is unlikely though.

Fixes: signed integer overflow: 538976288 * 4 cannot be represented in type 'int'
Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_ICO_fuzzer-6690068904935424

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg


Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 3 * -2147483648 cannot be represented in type 'int'
Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-6668935979728896

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg


Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 3 * -2147483648 cannot be represented in type 'int'
Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-6668935979728896

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg


Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

offsets suggested by Tomas Härdin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Suggested-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 9223372036854775807 - -2146905566 cannot be represented in type 'long'
Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-6570996594769920

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg


Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: out of array access
Fixes: 51462/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-662559341582745

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg


Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>