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.
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.
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.
This patch introduces a new frame side data type AVFilmGrainParams for use
with video codecs which support it.
It can save a lot of memory used for duplicate processed reference frames and
reduce copies when applying film grain during presentation.
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>
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.
Signed-off-by: Musee Ullah <lae@lae.is>
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>
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>
The longest AC codes of the standard JPEG tables are 16 bits long; for
the DC tables, the maximum is 11, so using max_depth of two is
sufficient.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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>
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>
Commit 1af615683e 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>
This avoids code duplication in the functions used to initialize them
and allows to remove an AVOnce.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Lynne
Paul B Mahol
Andreas Rheinhardt
Musee Ullah