The powf builtin causes crashes on older clang, so manually implement
the (faster) intrinsic.
The code it spawns is identical to that of nvcc.

It reduces typing: Before this patch, there were 11 callbacks
that exceeded the 80 char line length limit; now there are zero.
It also allows to remove ONLY_IF_THREADS_ENABLED() in
libavutil/internal.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It has been deprecated in b4f59bee,
but the attribute_deprecated was not set and there was no entry
in APIchanges. This commit adds these and schedules it for removal.
Given that the reason behind the deprecation is exactly the same
as in av_fopen_utf8(), reuse its FF_API_AV_FOPEN_UTF8.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is not used by the large majority of files that include
lavu/internal.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is used almost nowhere, so it needn't be auto-included
almost everywhere.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

They are unused since d63443b9.
Furthermore, they were always in the wrong header:
libavutil/internal.h is auto-included almost everywhere, but
FF_SYMVER would only ever be used at a few places, so a proper
header of its own would be appropriate for it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

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

Currently, the frame-threaded decoding API still supports thread-unsafe
callbacks. If one uses a thread-unsafe get_buffer2() callback,
calls to av_frame_unref() by the decoder are serialized, because
it is presumed that the underlying deallocator is thread-unsafe.

The frame-threaded encoder seems to have been written with this
restriction in mind: It always serializes unreferencing its AVFrames,
although no documentation forces it to do so.

This commit schedules to change this behaviour as soon as thread-unsafe
callbacks are removed. For this reason, the FF_API_THREAD_SAFE_CALLBACKS
define is reused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

ff_thread_video_encode_frame() already returns blank frames.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

GSoC 2022
Signed-off-by: Mohamed Khaled <mohamed.elbassiony00@eng-st.cu.edu.eg>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.

Normally, so far, this is achieved when linking shared libraries
in two ways; we have a version script (libavcodec/libavcodec.v) which
marks all symbols that don't start with av* as local. Additionally,
we try to add -Wl,-Bsymbolic to the linker options if supported,
making sure that such symbol references are resolved fully at link
time, instead of making them interposable.

When the libavcodec static library is linked into another shared
library, there's no guarantee that it uses similar options (even though
that would be favourable), which would end up requiring text relocations
in the AArch64 assembly.

Explicitly mark the symbols that are accessed from AArch64 assembly
as hidden, so that they are resolved fully at link time even without
the version script and -Wl,-Bsymbolic.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes building for arm targets with optimizations disabled.
Signed-off-by: Martin Storsjö <martin@martin.st>

These were missed when h264_chroma_mc_func was changed in
e4a94d8b.
Signed-off-by: Martin Storsjö <martin@martin.st>

This was missed in db544269.
Signed-off-by: Martin Storsjö <martin@martin.st>

It makes no sense here, as flac_parse_block_header()
is not even supposed to advance the caller's pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

(The FLAC parser currently ignores the streaminfo block;
therefore some of this is decoder-only. Given that the FLAC
parser should probably use the streaminfo block, this stuff
is moved to flac_parse.h.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

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

format is write-only.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is its only user.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

This field is not really used by the decoder at all:
It is only output in some debug log message, but this debug
log message should better use the value read from the streaminfo
instead of a second-guessed value from the decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

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

Possible since 38f5a266.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

This avoids including mpegvideo.h in mpeg4_unpack_bframes_bsf.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

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

The HEVC code currently uses an array of arrays of NALUs; one such array
contains all the SPS NALUs, one all PPS NALUs etc. The array of arrays
is grown dynamically via av_reallocp_array(), but given that the latter
function automatically frees its buffer upon reallocation error,
it may only be used with PODs, which this case is not. Even worse:
While the pointer to the arrays is reset, the counter for the number
of arrays is not, leading to a segfault in hvcc_close().

Fix this by avoiding the allocations of the array of arrays altogether.
This is easily possible because their number is bounded (by five).
Furthermore, as a byproduct we can ensure that the code always
produces the recommended ordering of VPS-SPS-PPS-SEI (which was
not guaranteed before).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Fixes: out of array access
Fixes: 47911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-6194020855971840

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes ticket #9514.

Fixes Coverity issue #1512413.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

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

This is designed to improve and unify error handling for
allocation failures for the many (often small) allocations that we have
in the fftools. These typically either don't return an error message
or an error message that is not really helpful to the user
and can be replaced by a generic error message without loss of
information.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

The threshold of 5 is arbitrary, both smaller and larger should work fine

Fixes: Stack overflow
Fixes: 50603/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-6049302564175872

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

Fixes lavc version output in ass, regression since f2da2e14

Fixes lavf version output in SDP, regression since 4eb9232c

update_video_stats() currently uses OutputStream.data_size to print the
total size of the encoded stream so far and the average bitrate.
However, that field is updated in the muxer thread, right before the
packet is sent to the muxer. Not only is this racy, but the numbers may
not match even if muxing was in the main thread due to bitstream
filters, filesize limiting, etc.

Introduce a new counter, data_size_enc, for total size of the packets
received from the encoder and use that in update_video_stats(). Rename
data_size to data_size_mux to indicate its semantics more clearly.

No synchronization is needed for data_size_mux, because it is only read
in the main thread in print_final_stats(), which runs after the muxer
threads are terminated.

It is only used within new_video_stream(), so make it a local variable
there.