The JPEG-2000 decoder and encoder share common luts; the decoder
initializes them once, guarded by a dedicated AVOnce, whereas
the encoder initializes them always during init. This means that
the decoder is not init-threadsafe; in fact there is a potential
data race because these luts can be initialized while an active
decoder/encoder is using them.
Fix this and make the decoder init-threadsafe by making the
initialization function guard initialization itself with a dedicated
AVOnce.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mqc currently initializes three arrays at runtime; each of them
has 2 * 47 elements, one is uint16_t, two are uint8_t, so that their
combined size is 8 * 47. The source data for these initializations
is contained in an array of 47 elements of size six. Said array is
only used in order to initialize the other arrays, so the savings
are just 2 * 47B. Yet this is dwarfed by the size of the code for
performing the initializations: It is 109B (GCC 10.2, x64, -O3 albeit
in an av_cold function); this does not even include the size of the
code in the callers. So just hardcode these tables.
This also fixes a data race, because the encoder always initialized
these tables during init, although they might already be used at the
same time by already running encoder/decoder instances.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Vorbis encoder has an array of a structure containing all
the ingredients for a codebook; this includes a pointer to
the actual codebook and some even have a pointer to an array
containing quant values. Each of these real codebooks is
an array of its own.
These pointers lead to relocations and therefore the array will
be placed in .data.rel.ro and not in .rodata.
This commit avoids the pointers altogether by combining all the actual
codebooks into one big array; the actual codebooks are now accessed
consecutively by incrementing the pointer used to access them by the
length of the actual codebook that has just been dealt with (said length
is contained in the structure describing the codebook). There is
no downside to this given that these codebooks are already only used
once during init.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Vorbis encoder allocates several arrays destined to contain pointers
to separately allocated arrays; yet these arrays are allocated without
initializing them: They are uninitialized until their final values
are stored in them; so if allocating one of the earlier subarrays fails,
all of the remaining pointers to subarrays are still uninitialized.
But they are used for freeing, resulting in crashes.
Fix this by zero-initializing the arrays with subarrays.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_wma_init() can fail without freeing everything it has allocated;
so add the FF_CODEC_CAP_INIT_CLEANUP to the codecs using it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The address of this variable never leaks, so it cannot be modified
by anyone else at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise decoding will crash lateron; e.g. because dct_tokens
is never set or because a VLC that has not been allocated is used.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The DNXHD encoder's context contains an array of 32 pointers to
DNXHDEncContexts used in case of slice threading; when trying
to use more than 32 threads with slice threading, the encoder's init
function errors out, but the close function takes avctx->thread_count
at face value and tries to free inexistent elements of the array,
leading to potential crashes.
Fix this by modifying the check used to decide whether the slice
contexts should be freed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Initializing zlib in the way we do here is threadsafe, see
https://www.zlib.net/zlib_faq.html#faq21
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case this actually fixes a potential data race: The static VLC
tables were reinitialized every time an AVCodecContext has been
initialized; while the mutex in avcodec_open2() ensured that the VLCs
could not be initialized concurrently by multiple threads, nothing
guaranteed that these VLCs are not read concurrently (when decoding a
packet with an already initialized AVCodecContext) while another thread
initializes them. This is undefined behaviour despite the values being
written coinciding with the earlier values.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Initializing zlib in the way we do here is threadsafe, see
https://www.zlib.net/zlib_faq.html#faq21
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented to be safe to call inflateEnd() on a z_stream
that has not been successfully initialized via inflateInit(); so
record whether it has been successfully initialized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Initializing zlib in the way we do here is threadsafe, see
https://www.zlib.net/zlib_faq.html#faq21
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The split into vp9_decode_init() and init_frames() is a remnant
of using init_thread_copy() for frame-threading; the latter has
been removed, so there is no reason for init_frames() not be part
of vp9_decode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_mallocz() is superfluous as get_packet_defaults() is called immediately
after it's allocated, which will initialize the entire struct to default
values.
Signed-off-by: James Almer <jamrial@gmail.com>
If a copy callback is provided by the caller, the packet passed to it
was zeroed instead of initialized with default values.
Signed-off-by: James Almer <jamrial@gmail.com>
The SVQ1 decoder does not need mpegvideo or rl.c, but it uses stuff
from h263data.c. But since 61fe481586
h263data.c called ff_rl_init() and this of course led to build errors
when the SVQ1 decoder is enabled and mpegvideo disabled.
Fix this by moving ff_h263_init_rl_inter() to h263.c.
Fixes ticket #9224.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
