(Cherry-picked from libav commit 3c0efbd0)
Signed-off-by: James Almer <jamrial@gmail.com>

None of them are specific to the YASM assembler.

(Cherry-picked from libav commit 39e208f4)
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

This was added in e3e3c825, probably
as a workaround for the fact that the quant table was not permutated
and the IDCT coefficients are, meaning that you'd only get correct
reconstruction if the IDCT permutation was an identity matrix, which
happens to be the case when you use the simple IDCT. The quant table
permutation bug was fixed in 42dd1434,
meaning this workaround is no longer necessary.

In practical terms, before 42dd1434,
the PSNR between decodes of the fate-mdec using simple (C) or simplemmx
IDCTs was 35. After 42dd1434, it's 90.

Properly use the b.eq form instead of the nonstandard form (which
both gas and newer clang accept though), and expand the register
lists that used a range (which the Xcode 6.2 clang, based on clang
3.5 svn, didn't support).
Signed-off-by: Martin Storsjö <martin@martin.st>

Properly use the b.eq/b.ge forms instead of the nonstandard forms
(which both gas and newer clang accept though), and expand the
register list that used a range (which the Xcode 6.2 clang, based
on clang 3.5 svn, didn't support).

This is cherrypicked from libav commit
a970f9de.
Signed-off-by: Martin Storsjö <martin@martin.st>

Reviewed-by: James Darnley <jdarnley@obe.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: left shift of negative value -1

Fixes: 2299/clusterfuzz-testcase-minimized-4843509351710720

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Fixes: runtime error: signed integer overflow: 262144 * -16120 cannot be represented in type 'int'
Fixes: 2292/clusterfuzz-testcase-minimized-6156080415506432

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: signed integer overflow: -1575818955 + -915383657 cannot be represented in type 'int'
Fixes: 2224/clusterfuzz-testcase-minimized-6208559949807616

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

The early check for inconsistent in-source vs out-of-source build
cannot generate a config.log otherwise.

(Cherry-picked from libav commit 0ee78020)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Use avci->last_pkt_props to get the side data. Using |pkt| doesn't work
when FF_API_MERGE_SD is set, as the compressed side data is expanded into
|tmp|, leaving the original |pkt| unchanged.
Signed-off-by: James Almer <jamrial@gmail.com>

Use named arguments for the functions so we can remove a define.  The
stride/linesize argument is now ptrdiff_t type so we no longer need to
sign extend the register.

(cherry picked from commit 2f792cb6)

It is wrong/incorrect in two aspects:
1. The pixel format is not enough to guarantee that the resulting file
   will be any more compatible with media players.
2. Media players not supporting higher profiles are not necessarily
   outdated (in fact this is simply an arrogant statement that
   libavcodec can handle these particular features).

You could add that there are plenty of other ways to produce widely
incompatible files with ffmpeg, and these don't show any warnings.

What we really want to do here is defaulting to codec profiles that
have wide compatibility, such as main/high for h264. Also, if an
encoder does not accept certain pixfmts, we should automatically
convert them to a pixfmt the encoder can accept. But the existing
message certainly is not appropriate.

It also works for 2 specific encoders only. Extending it for other
cases would result in a lot of special cases, so this is not the
right place.

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

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Use the correct ctxIdxInc calculation for coded_block_flag.
Keep old behavior for old versions of x264 for backward compatibility.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.

Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do something like "scale=0:ow/4" which one could
reasonably expect to work as well, but does not as ow is 0 not the
real value.

This change handles the 0 case for w/h immediately so the ow/oh
variables work as expected. Consequently, the rest of the code does
not need to handle 0 input. w/h will always be > 0 or < 0.

The second explicit (int) cast ensures that ow/oh appear as integers
as a user might expect when dealing with pixel dimensions.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

According to libavfilter/scale.c, if the width and height are both
less than or equal to 0 then the input size is used for both
dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which
is the same as -10:-42, etc.

if (w < 0 && h < 0)
    eval_w = eval_h = 0;

The documentation for the zscale filter has also been updated since the
behavior is identical.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 2291/clusterfuzz-testcase-minimized-5538453481586688

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: shift exponent -8 is negative
Fixes: 2286/clusterfuzz-testcase-minimized-5711764169687040

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

The new name more accuratly describes what the function does
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

When the hlsenc at BYTERANGE mode, it should not show the warning message:
"Duplicated segment filename detected:"
Reported-by: Marco <marco@worldcast.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>