This patch fixes the following error when compiling mplayer with libopus.

libavcodec/libopusdec.c: In function 'libopus_decode_init':
libavcodec/libopusdec.c:130:27: error: implicit declaration of function 'ff_exp10'; did you mean 'ff_exp2fi'? [-Werror=implicit-function-declaration]
         double gain_lin = ff_exp10(gain_db / (20.0 * 256));
                           ^~~~~~~~
                           ff_exp2fi
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Use correct index into streams
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: 刘歧 <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 2147483598 + 64 cannot be represented in type 'int'
Fixes: 4337/clusterfuzz-testcase-minimized-6192658616680448

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: James Almer <jamrial@gmail.com>

nvdec will not produce odd width/height output, and while this is
basically never an issue with most codecs, due to internal alignment
requirements, you can get odd sized jpegs.

If an odd-sized jpeg is encountered, nvdec will actually round down
internally and produce output that is slightly smaller. This isn't
the end of the world, as long as you know the output size doesn't
match the original image resolution.

However, with an hwaccel, we don't know. The decoder controls
the reported output size and the hwaccel cannot change it. I was
able to trigger an error in mpv where it tries to copy the output
surface as part of rendering and triggers a cuda error because
cuda knows the output frame is smaller than expected.

To fix this, we can round up the configured width/height passed
to nvdec so that the frames are always at least as large as the
decoder's reported size, and data can be copied out safely.

In this particular jpeg case, you end up with a blank (green) line
at the bottom due to nvdec refusing to decode the last line, but
the behaviour matches cuviddec, so it's as good as you're going to
get.

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

This is a bit more robust in case of OOM.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

2LL << (wrap_bits=64 - 1) does not fit in int64_t; change the
code to use a uint64_t (2ULL) and add an av_assert2() to
ensure wrap_bits <= 64.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
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>

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

Fixes: memleak
Found-by: <jamrial>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Signed-off-by: Lou Logan <lou@lrcd.com>

Explain how to achieve infinite looping with the loop / aloop filters.
Signed-off-by: Werner Robitza <werner.robitza@gmail.com>

speed seems to be similar, but simplify code

This was an mplayer-specific hack.

This reverts commit a4f94f24.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

This was added in early 2013 and abandoned several months later; as far as
I can tell, there are no external users.  Future OpenCL use will be via
hwcontext, which requires neither special OpenCL-only API nor global state
in libavutil.

All internal users are also deleted - this is just the unsharp filter
(replaced by unsharp_opencl, which is more flexible) and the deshake filter
(no replacement).

To match creation on a newly-derived device.  (This was missed earlier
because the mode is only used in some cases.)

Intended to replace existing opencl mode of the unsharp filter.
Supports many more pixel formats and works without immediate upload
and download of frame data.  The options are compatible with the
existing filter.

Input and output formats must be the same, the overlay format must be
the same as the input except possibly with an additional alpha component.

Using cl_arm_import_memory.  Unfortunately, despite this not being a
standard extension, the function clImportMemoryARM() is not accessible
via clGetExtensionFunctionAddressForPlatform().  This means that it has
to be linked directly to the ARM OpenCL binary, so making a portable
binary is not possible as it is with all other mapping extensions.

Using cl_khr_d3d11_sharing and cl_intel_d3d11_nv12_media_sharing.

Using cl_khr_dx9_media_sharing.

Uses the cl_intel_va_api_media_sharing extension, which supports only
NV12 surfaces and only mapping from QSV to OpenCL.

Supports all surface formats in common between the two.

Add two FAQs about running FFmpeg in the background.
The first explains the use of the -nostdin option in
a straightforward way. Text revised based on review.

The second FAQ starts from a confusing error message,
and leads to the solution, use of the -nostdin option.
The purpose of the second FAQ is to attract web searches
from people having the problem, and offer them a solution.

Add an anchor to the Main Options section of the ffmpeg
documentation, so that the FAQs can link directly there.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>