avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int')

Fixes: 2005/clusterfuzz-testcase-minimized-5744226438479872

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

avcodec/snowdec: Fix runtime error: signed integer overflow: 1404 * 8388608 cannot be represented in type 'int'

Fixes: 2004/clusterfuzz-testcase-minimized-5533262866808832

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

The current upstreamed code has been written and tested for Little Endian systems.
We do have plans to add the Big Endian support in near future, but till that time, need to disable all to avoid its usage and failures.
Signed-off-by: Shivraj Patil <shivraj.patil@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

hw accelerated transcode (h264_cuvid -> h264_nvenc with -hwaccel cuvid) was
broken after the filtergraph initialization was changed to intialize decoder
first followed by encoder (commit af1761f7).
During initialzing encoder with bframes, local buffers are allocated
internally in encoder which fails since no cuda context is available. Now
pushing the correct cuda context before encoder initialization fixes the issue.
Also adding push/pop cuda ctx during create/destroy/map/unmap resources and
destroy encoder session.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

About 2x faster than the c version.
Signed-off-by: James Almer <jamrial@gmail.com>

Variables pertaining to the main video are now available when
using the scale2ref filter. This allows, as an example, scaling a
video with another as a reference point while maintaining the
original aspect ratio of the primary/non-reference video.

Consider the following graph: scale2ref=iw/6:-1 [main][ref]
This will scale [main] to 1/6 the width of [ref] while maintaining
the aspect ratio. This works well when the AR of [ref] is equal to
the AR of [main] only. What the above filter really does is
maintain the AR of [ref] when scaling [main]. So in all non-same-AR
situations [main] will appear stretched or compressed to conform to
the same AR of the reference video. Without doing this calculation
externally there is no way to scale in reference to another input
while maintaining AR in libavfilter.

To make this possible, we introduce eight new constants to be used
in the w and h expressions only in the scale2ref filter:

 * main_w/main_h: width/height of the main input video
 * main_a: aspect ratio of the main input video
 * main_sar: sample aspect ratio of the main input video
 * main_dar: display aspect ratio of the main input video
 * main_hsub/main_vsub: horiz/vert chroma subsample vals of main
 * mdar: a shorthand alias of main_dar

Of course, not all of these constants are needed for maintaining the
AR, but adding additional constants in line of what is available for
in/out allows for other scaling possibilities I have not imagined.

So to now scale a video to 1/6 the size of another video using the
width and maintaining its own aspect ratio you can do this:

scale2ref=iw/6:ow/mdar [main][ref]

This is ideal for picture-in-picture configurations where you could
have a square or 4:3 video overlaid on a corner of a larger 16:9
feed all while keeping the scaled video in the corner at its correct
aspect ratio and always the same size relative to the larger video.

I've tried to re-use as much code as possible. I could not find a way
to avoid duplication of the var_names array. It must now be kept in
sync with the other (the normal one and the scale2ref one) for
everything to work which does not seem ideal. For every new variable
introduced/removed into/from the normal scale filter one must be
added/removed to/from the scale2ref version. Suggestions on how to
avoid var_names duplication are welcome.

var_values has been increased to always be large enough for the
additional scale2ref variables. I do not forsee this being a problem
as the names variable will always be the correct size. From my
understanding of av_expr_parse_and_eval it will stop processing
variables when it runs out of names even though there may be
additional (potentially uninitialized) entries in the values array.
The ideal solution here would be using a variable-length array but
that is unsupported in C90.

This patch does not remove any functionality and is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.

The applicable documentation has also been updated.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout
Fixes: 2001/clusterfuzz-testcase-minimized-6187599389523968

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

Fixes: 1967/clusterfuzz-testcase-minimized-5757031199801344

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

avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int'

Fixes: 1925/clusterfuzz-testcase-minimized-5564569688735744

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: Paul B Mahol <onemda@gmail.com>

Should prevents future conflicts with the similarly named floatdsp tests

AVCodecContext::refs is used to control the DPB size to be used by the
encoder. The default value for AVCodecContext::refs as set in
libavcodec/options_table.h is 1.

This patch sets AVCodecContext::refs to 0 for h264_nvenc and hevc_nvenc in
order to let the driver take the decision of the correct DPB size to use in
all cases.
Signed-off-by: Srinath K R <skr@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

It's an AVColorSpace value since 82ad9cbd.
Signed-off-by: James Almer <jamrial@gmail.com>

avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int'

Fixes: 1922/clusterfuzz-testcase-minimized-5561194112876544

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

Reduces time spend decoding 1917/clusterfuzz-testcase-minimized-5023221273329664

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

avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int'

Fixes: 1909/clusterfuzz-testcase-minimized-6732072662073344

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

avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int'

Fixes: 1908/clusterfuzz-testcase-minimized-5392712477966336

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

Fixes: OOM
Fixes: 1906/clusterfuzz-testcase-minimized-4599315114754048

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

avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int'

Fixes: 1903/clusterfuzz-testcase-minimized-5359318167715840

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

This helps to visualize how the send/receive API works.

This was actually broken when committed in 46e3936f; the
test never succeeded, and thus, _aligned_malloc wasn't actually
used on legacy mingw.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 427f7a1f)

With the new decode API, you can't handle errors directly in the API
user - you only know that the hwaccel did not initialize at all.

Add some approximate logging.

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

This prevents part of one exploit leading to an information leak

Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: subtitle.avi from vlc/ticket/1162
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float'

Fixes: 1902/clusterfuzz-testcase-minimized-4762451407011840

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 40 is too large for 32-bit type 'unsigned int'
Fixes: 1898/clusterfuzz-testcase-minimized-5970744880136192

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

avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int'

Fixes: 1894/clusterfuzz-testcase-minimized-4716739789062144

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

The library has stopped being developed and Debian has removed it
from its repositories citing security issues.
The native Dirac decoder supports everything the library has and basic
encoding support is still provided via the native vc2 (Dirac Pro, intra
only version of Dirac) encoder. Hence, there's no reason to still support
linking to the library and potentially leading users into security issues.

libnut is outdated and not developed anymore, all nut developments
happens in this repo, so users are getting mislead