Anton Khirnov [Fri, 22 May 2020 13:59:46 +0000 (15:59 +0200)]
avcodec: deprecate thread_safe_callbacks
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-safe, so deprecate this option.
avformat/mpc8: correct integer overflow in mpc8_parse_seektable()
Fixes: signed integer overflow: -4683718486770919638 * 2 cannot be represented in type 'long' Fixes: 26704/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6327056939614208 Fixes: 27550/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6259212652642304 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 65536 by 15 places cannot be represented in type 'int' Fixes: 26801/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-5164313092030464 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/flacenc: Fix memleak when writing attached pictures fails
The FLAC muxer currently stores an attached picture corresponding to an
AVStream in AVStream.priv_data. The AVPacket contained therein is
unreferenced after it has been written. The AVPacket structure itself is
then freed generically as AVStream.priv_data.
And this can lead to memleaks if an attached picture is not written:
It might be because the trailer is never written or because writing
a previous attached picture failed in case error_recognition is set
to explode.
Therefore free the packets properly (i.e. with av_packet_free())
in the muxer's deinit function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Niklas Haas [Wed, 25 Nov 2020 11:50:33 +0000 (12:50 +0100)]
hwcontext_vulkan: optionally enable more functionality
These two extensions and two features are both optionally used by
libplacebo to speed up rendering, so it makes sense for libavutil to
automatically enable them as well.
Lynne [Tue, 24 Nov 2020 23:20:06 +0000 (00:20 +0100)]
hwcontext_vulkan: always attempt to map host memory when transferring
This relies on the fact that host memory is always going to be required
to be aligned to the platform's page size, which means we can adjust
the pointers when we map them to buffers and therefore skip an entire
copy. This has already had extensive testing in libplacebo without
problems, so its safe to use here as well.
Speeds up downloads and uploads on platforms which do not pool their
memory hugely, but less so on platforms that do.
We can pool the buffers ourselves, but that can come as a later patch
if necessary.
Lynne [Sun, 22 Nov 2020 22:08:33 +0000 (23:08 +0100)]
lavfi/vulkan: allow calling glslang_uninit without a prior init
Allows us to uninit cleanly.
This assert was also somewhat pointless as we assert every other
function, so another assert would be triggered long before this
one is.
Lynne [Thu, 12 Nov 2020 11:48:20 +0000 (12:48 +0100)]
libdav1d: use film grain export flag to export AVFilmGrainParams side data
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it interacts with AV_CODEC_EXPORT_DATA_FILM_GRAIN is as follows:
If filmgrain is unset and AV_CODEC_EXPORT_DATA_FILM_GRAIN is
present, disable film grain application and export side data.
If filmgrain is set to 0, disable film grain and export side data.
If filmgrain is set to 1, apply film grain but export side data if
the AV_CODEC_EXPORT_DATA_FILM_GRAIN flag is set. This may result in
double film grain application, but the user has requested it by setting
both.
avcodec/mpeg12enc: Always initialize MPEG-2 intra VLC table lengths
The MPEG-1/2 encoders initialize several tables once during the first
time one of the encoders is initialized; the table for MPEG-2 intra VLC
lengths is only initialized if it is used for this encoder instance.
This implies that if the first MPEG-1/2 encoder to be initialized does
not use it, it will never be initialized even if a later encoder
instance makes use of them. Fix this by initializing this table
unconditionally.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Musee Ullah [Mon, 23 Nov 2020 19:52:01 +0000 (13:52 -0600)]
avfilter/vf_xfade: ensure metadata is copied to transition frames
I was having an issue where, using a filter chain of xfade -> ass, the
colors on the subtitles were incorrect only on the frames where xfade
was being used. This resolves that issue for me.
avcodec/aac*: Make initializing ff_aac_pow*sf_tab thread-safe
This table is currently initialized up to three times: Once by the
encoder and twice by the decoders (once by the fixed and once by the
floating-point decoder); each of these initializations is guarded by an
AVOnce, yet the fact that there are three of them implies that there
might be data races (the fact that each entry is only written to once
(to its final value) when initializing means that this is safe in
practice, yet it is still undefined behaviour). Fix this by only
initializing the table from one place that is guarded by a single AVOnce.
This also avoids unnecessary duplications of the init code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/atrac9dec: Don't confuse max_depth of VLC with max codelength
The whole point of VLCs with their tables is to read more than one bit
at a time; therefore max_depth, the number of times one has to
(maximally) read further bits is given by ceil(max_code_length / table_bits)
which in the case of ATRAC9's coefficient VLCs gives an upper bound of
two. Instead the maximum length of a code of the given VLC has been used
(which is not even a compile-time constant). Use two instead.
Furthermore, given that this was the only usage of the field containing
the maximum of all the code lengths of a given VLC the field has been
removed from its containing struct.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/mpegaudiodsp: Make initializing synth windows thread-safe
These arrays are used by the Musepack decoders, the MPEG audio decoders
as well as qdm2 and up until now, these arrays might be initialized more
than once, leading to potential data races as well as unnecessary
initializations. Therefore this commit ensures that each array will only
be initialized once.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/mpegaudiodsp: Make ff_mpadsp_init() thread-safe
The only thing missing for this is to make ff_mpadsp_init_x86()
thread-safe; it currently isn't because a static table is initialized
every time ff_mpadsp_init() is called (when ARCH_X86 is true). Solve
this by initializing this table only once, namely together with the
ordinary not-arch specific tables. This also allows to reuse their AVOnce.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/fft_template, fft_init_table: Make ff_fft_init() thread-safe
Commit 1af615683e4a1a858407afbaa2fd686842da7e49 put initializing
the ff_fft_offsets_lut (which is typically used if FFT_FIXED_32)
behind an ff_thread_once() to make ff_fft_init() thread-safe; yet
there is a second place where said table may be initialized which
is not guarded by this AVOnce: ff_fft_init_mips(). MIPS uses this LUT
even for ordinary floating point FFTs, so that ff_fft_init() is not
thread-safe (on MIPS) for both 32bit fixed-point as well as
floating-point FFTs; e.g. ff_mdct_init() inherits this flaw and
therefore initializing e.g. the AAC decoders is not thread-safe (on
MIPS) despite them having FF_CODEC_CAP_INIT_CLEANUP set.
This commit fixes this by moving the AVOnce to fft_init_table.c and
using it to guard all initializations of ff_fft_offsets_lut.
(It is not that bad in practice, because every entry of
ff_fft_offsets_lut is never read during initialization and is only once
ever written to (namely to its final value); but even these are
conflicting actions which are (by definition) data races and lead to
undefined behaviour.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/motionpixels: Be more strict when parsing Huffman trees
This ensures that the number of leafs in the Huffman tree equals the
number it is supposed to be and therefore ensures that the VLC tree is
complete, allowing us to remove checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/motionpixels: Only create VLC iff it is going to be used
If the Huffman tree consists of only one entry (which has length zero),
no tree is used at all for parsing as the VLC API currently can't handle
this. So it makes no sense to create a VLC in this case.
Commit 41b7389cade702383e59343561776f83bb26e17f added a check for
whether creating the VLC should be skipped, but it also skipped decoding
the packet and it used the wrong check: It checked max_codes_bits,
the maximum length of a code; but this value is only updated iff there is
more than one Huffman entry. So if there is only one Huffman entry, and
there was a previous frame with more than one entry, then a VLC was
created unnecessarily; yet if there was no previous frame with more than
one entry, then this frame will be skipped which is probably
spec-incompliant. I have no sample for the latter.
This commit improves the check to create a VLC iff it is going to be
used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Jan Ekström [Mon, 23 Nov 2020 15:36:20 +0000 (17:36 +0200)]
avcodec/av1{dec,parser}: move to ff_cbs_read_extradata_from_codec
This lets us re-utilize the extradata-related checks in the CBS
to add support for passing the AV1CodecConfigurationRecord
as extradata as-is without further filtering.
avcodec/exr: skip bottom clearing loop when its outside the image
Fixes: signed integer overflow: 1633771809 * 32960 cannot be represented in type 'int' Fixes: 26532/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5613925708857344 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access Fixes: 26532/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5613925708857344 Fixes: 27443/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5631239813595136 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/avs: Use 64bit for the avio_tell() output
Fixes: signed integer overflow: 9223372036854775807 - -1 cannot be represented in type 'long' Fixes: 26549/clusterfuzz-testcase-minimized-ffmpeg_dem_AVS_fuzzer-4844306424397824 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
projects / ffmpeg / log