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>

libavutil/mem.h is unneeded since 33d18982,
the commit that introduced the new packet-based bsf API, because with
this switch the allocations were no longer performed directly, but by
av_new_packet().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

With 33d18982, the commit introducing
the new packet-based bsf API, a new buffer was no longer allocated
directly, but via av_new_packet(), so that libavutil/mem.h was no longer
needed.

Moreover since commit dc99ee6b
av_packet_make_writable() is employed which copies the data in case it
is unavoidable so that string.h is no longer used (it was used for
memcpy()).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Since 33d18982 (the commit that
introduced the new bsf API) allocating an enlarged buffer in case
extradata needs to be added to a packet is done via av_new_packet(),
so that libavutil/mem.h is no longer needed.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This bsf never needed libavutil/mem.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This bsf never needed internal.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This bsf doesn't have any options, so including libavutil/opt.h is
unnecessary.
Reviewed-by: Peter Ross <pross@xvid.org>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>