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>
If allows us to directly store the deltas in the VLC table and therefore
avoids a level of indirection.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The algorithm used here always creates a complete VLC, so it is
unnecessary to check this again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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>
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 41b7389cad 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>
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.
