It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.

Set these default values to -1 to check whether it's specified
by user explicitly.

Use 2Mbps bitrate as nvenc sugguested, and leave gop size
untouched in libopenh264.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Clip iMinQp/iMaxQp to (1, 51) for user specified qp range.

If not set, leave iMinQp/iMaxQp untouched and use the values (0, 51)
initialized in FillDefault(), and the QP range would be adjusted to the
defaults inside libopenh264 library according to the iUsageType, (12, 42)
for iUsageType == CAMERA_VIDEO_REAL_TIME which is default.

<https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/encoder_ext.cpp#L375>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Remove any usage of padding for this format.

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Because not every user know about in_pad and out_pad reasonable value range
so maybe try to set 1.0, but setting 1.0 is so hugh to get an fatal error.
Suggested-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>

The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").

However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.

Since libx264 has correctly parsed the level to int
(x4->params.i_level_idc), we should rely on this value instead of
attempting to parse the level string on our own.
Signed-off-by: Josh Brewster <josh.brewster@protonmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>

Follow the http://id3.org/ID3v1, setting the year metadata
for ID3v1.

fix #8623
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Without this setting, bitrate and qmin/qmax options have no
effect on the s5p-mfc hardware encoder.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

Currently the user gets unhelpful warnings when some default parameters
are not supported by the device. The verbosity of these log messages has
been changed to AV_LOG_DEBUG.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

libswscale/vscale.c makes extensive use of function pointers and in
doing so it converts these function pointers to and from a pointer to
void. Yet this is actually against the C standard:
C90 only guarantees that one can convert a pointer to any incomplete
type or object type to void* and back with the result comparing equal
to the original which makes pointers to void generic pointers to
incomplete or object type. Yet C90 lacks a generic function pointer
type.
C99 additionally guarantees that a pointer to a function of one type may
be converted to a pointer to a function of another type with the result
and the original comparing equal when converting back.
This makes any function pointer type a generic function pointer type.
Yet even this does not make pointers to void generic function pointers.

Both GCC and Clang emit warnings for this when in pedantic mode.

This commit fixes this by using a union that can hold one member of any
of the required function pointer types to store the function pointer.
This works even for C90.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Current muxers only use a single bitstream filter, so there is no need to
maintain code which operates on a list of bitstream filters. When multiple
bitstream filters are needed muxers can simply use a list bitstream filter.

If there is a use case in the future when different bitstream filters should be
added at subsequent packets then a new API possibly involving reconfiguring the
list bitstream filter can be added knowing the exact requirements.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Martin Storsjö <martin@martin.st>

These tests are also in the same size range as the previously
skipped 2k and 4k tests.
Signed-off-by: Martin Storsjö <martin@martin.st>

The ad-hoc libmfx setup code is the only place its still used, so move it
into that file.

This can support encoders which want frames and/or device contexts.  For
the device case, it currently picks the first initialised device of the
desired type to give to the encoder - a new option would be needed if it
were necessary to choose between multiple devices of the same type.

Also move it into a dedicated function in the hardware file.

These encoders all accept VAAPI surfaces in a hardware frames context.

All of these encoders can accept libmfx surfaces directly in a hardware
frames context, or they can accept software frames if a suitable device
is supplied to use.

This already applied to decoders as well as hwaccels, and adding encoder
support was going to make the name even more inaccurate.

avcodec/cbs_h265_syntax_template: Check num_negative/positive_pics when inter_ref_pic_set_prediction_flag is set

Fixes: out of array access
Fixes: 20446/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5707770718584832

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

Fixes: Timeout (105sec -> 1sec)
Fixes: 20479/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5769846937878528

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: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int32_t' (aka 'int')
Fixes: 21245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5683334274613248

Change to int16_t suggested by Lynne

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

Also set state to ready if there is any inlink with queued frame.

Signed-off-by: Peter Ross <pross@xvid.org>
Reviewed-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Peter Ross <pross@xvid.org>
Reviewed-by: James Almer <jamrial@gmail.com>

bump minor version for DOVI sidedata, because added the dovi_meta.h
as lavu API part. Also update APIchanges.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This fixes tests on 32 bit x86 mingw with clang, which uses x87
fpu by default.

In this setup, while the get_expected function is declared to
return float, the compiler is (especially given the optimization
flags set) free to keep the intermediate values (in this case,
the return value from the inlined function) in higher precision.

This results in the situation where 7.28 (which actually, as
a float, ends up as 7.2800002098), multiplied by 100, is
728.000000 when really forced into a 32 bit float, but 728.000021
when kept with higher intermediate precision.

For the multiplication case, a more suitable epsilon would e.g.
be 2*FLT_EPSILON*fabs(expected_output), but just increase the
current hardcoded threshold for now.
Signed-off-by: Martin Storsjö <martin@martin.st>