Fixes: Infinite loop
Fixes: 34751/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-5439330800762880
Fixes: 34774/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-5851571660390400

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

Fixes: invalid shifts
Fixes: Ticket 8221
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Instead return the dictionary in the state it is at the time the error
occurred. This is more in line with the description of this parameter
and allows to notify the user of unrecognized options if an error
happens lateron (which might very well be due to e.g. misspelled
options).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Besides being unnecessary it is also safer: If the error for an
unrecognized option were triggered (which seems to be impossible right
now), it might be that the stream whose codecpar is accessed is NULL.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

The user should not rely on all options always being recognized
(in particular not on error).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is no longer necessary now that ff_frame_thread_encoder_init()
no longer receives an options dictionary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

av_dict_copy() returned void when this code was written.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

In case the underlying AVCodec has no private class, the private data
of both the main as well as each worker AVCodecContext is just zeroed
(the codec's init function has not been called on any of them and
without a private class there is no way to legitimately set anything
before the aforementioned init function).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

avcodec_open2() allows to provide options via an AVDictionary;
but it is also allowed to set options by simply setting the value
of the AVCodecContext or via the AVOptions API if the codec has
a private class. Any options provided via an AVDictionary have already
been applied before ff_frame_thread_init(), so in order to copy
all the options from the main AVCodecContext and its private context,
it is enough to av_opt_copy() these options.

The current code does this, but it does more: It also copies the
user-provided AVDictionary and uses it for the initialization of
each of the worker-AVCodecContexts. This is completely unnecessary,
because said options have already been copied from the main context.

Furthermore, these options were also examined to decide if frame
threading should be used for huffman encoding in case this would incur
nondeterminism. This is wrong, because options not set via
an AVDictionary are ignored. Instead inspect the values stored in the
contexts directly. (In order to maintain the current behaviour, the
default value of the "non_deterministic" option has been changed to false,
because the absence of an entry with said key in the AVDictionary
had the consequence of disallowing nondeterminism.)

Finally, the AVDictionary has been removed from the signature of
ff_frame_thread_encoder_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Up until now, ff_alloc_packet2() has a min_size parameter:
It is supposed to be a lower bound on the final size of the packet
to allocate. If it is not too far from the upper bound (namely,
if it is at least half the upper bound), then ff_alloc_packet2()
already allocates the final, already refcounted packet; if it is
not, then the packet is not refcounted and its data only points to
a buffer owned by the AVCodecContext (in this case, the packet will
be made refcounted in encode_simple_internal() in libavcodec/encode.c).
The goal of this was to avoid data copies and intermediate buffers
if one has a precise lower bound.

Yet those encoders for which precise lower bounds exist have recently
been switched to ff_get_encode_buffer() (which automatically allocates
final buffers), leaving only two encoders to actually set the min_size
to something else than zero (namely aliaspixenc and hapenc). Both of
these encoders use a very low lower bound that is not helpful in any
nontrivial case.

This commit therefore removes the min_size parameter as well as the
codepath in ff_alloc_packet2() for the allocation of final buffers.
Furthermore, the function has been renamed to ff_alloc_packet() and
moved to encode.h alongside ff_get_encode_buffer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Its documentation described the way user-supplied buffers worked
before 93016f5d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Also combine two if blocks that check for the same condition
and don't check had_partial if we already have a complete packet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

There are no preallocated buffer packets any more; this feature only
worked with the old encode API and only until said API was turned into
a wrapper for the new API in 93016f5d.
So remove its remnants.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data; this also makes it easy
to allow user-supplied buffers. Only one thing needed to be changed:
The earlier code relied on the buffer having been initially zeroed
by av_fast_padded_malloc(), so one now needs to zero the packet at
first.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

fix problem when set x to odd number in nv12 by cuda

test step:
1. ffmpeg -f lavfi testsrc2=s=176x144 -pix_fmt nv12 -t 1 output_overlay.yuv
2. ffmpeg -f lavfi testsrc2=s=352x288 -pix_fmt nv12 -t 1 output_main.yuv
before this patch:
overlay_cuda=x=0:y=0 will right,
overlay_cuda=x=3:y=0 will wrong,

both will right after patch.
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

With these triggering a lot of crashes recently, an option to globally
disable all of them is added as a tool to work around those crashes in
case the SEI data is not needed by the user.

Also re-enables s12m for hevc_nvenc, since the issue is not specifically
with that, but it affects all SEI data.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

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

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

Fixes: signed integer overflow: 777777776 * 4 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-6726188921913344

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>

CID 1484955:  Memory - corruptions  (ARRAY_VS_SINGLETON)

They should not be accessed outside of libavformat.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Brad Hards <bradh@frogmouth.net>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Signed-off-by: Brad Hards <bradh@frogmouth.net>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

The data width of gsldrc1/gsldlc1 should be 8 bytes wide.
Signed-off-by: Jin Bo <jinbo@loongson.cn>
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Clang is more strict on the type of asm operands, float or double
type variable should use constraint 'f', integer variable should
use constraint 'r'.
Signed-off-by: Jin Bo <jinbo@loongson.cn>
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Infinite loop
Fixes: 33958/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-6590264069193728
Fixes: 33981/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5343224173559808
Fixes: 33986/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-6598815122587648
Fixes: 34001/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-6171098111672320

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

Fixes: out of array access
Fixes: 33960/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5052852809629696
Fixes: 34163/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-6123678099177472

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

Fixes: Assertion failure
Fixes: Ticket8202
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Avoids floating point division by 0

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

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

Avoids Floating point division by 0

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

This mostly reverts 785bfb1d.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170 uses BT.601 derived from BT.470
System M (yes, with Illuminant C) a.k.a. NTSC 1953. Some nits too.
Reviewed-by: Reto Kromer <lists@reto.ch>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

hldr -> hdlr

With audio/video HLS playlists, audio chunklists are treated as
alternative renditions for video chunklists. This is wrong for
audio-only HLS playlists.

fixes: 9252