Up until now, ff_h263_rl_inter was initialized by both ituh263dec and
ituh263enc; this is an obstacle in making the codecs that use this code
init-threadsafe.
This obstacle is eliminated by only initializing this RLTable from
a single place that is guarded by a dedicated AVOnce.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RLTable ff_rl_intra_aic is only used by ituh263dec and ituh263enc;
the former only uses the RLTable's VLC, the latter only index_run,
max_level and max_run. Yet ituh263dec also initializes the latter.
This commit stops doing so.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is easy now that the H.261 encoder is the only user that
initializes the non-VLC parts of ff_h261_rl_tcoeff.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The H.261 decoder only uses an RLTable's VLC table, yet it also
initializes its index_run, max_level and max_run. This commit stops
doing so; it will also simplify making this decoder init-threadsafe,
as the H.261 decoder and encoder now initialize disjoint parts of their
common RLTable.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is a prerequisite for making any encoder that uses
ff_mpv_encode_init() init-threadsafe; it already makes the AMV,
the MJPEG and the MPEG-1/2 encoders init-threadsafe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
msmpeg4dec and ituh263dec both create VLCs with identical parameters out
of ff_mvtab. Given that ff_msmpeg4_decode_init() always (indirectly) calls
ff_h263_decode_init_vlc(), the VLC initialized by the latter can be
directly used by msmpeg4dec. Doing so saves a bit more than 2KB from the
.bss segment as well as the code to initialize a VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Some of the RLTables used by msmpeg4dec actually coincide with other
RLTables: ff_rl_table[5] coincides with ff_h263_rl_inter (and
ff_rl_table[2] with ff_mpeg4_rl_intra). Given that ff_h263_rl_inter is
always initialized before msmpeg4dec's RLTables are initialized, one can
just reuse the VLC tables by copying the pointers; after all, there are
no ownership issues for static data. This saves 70912B from the .bss
segment, translating into actual memory savings when this decoder is
actually used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ff_rl_intra_aic RLTable is only used by ituh263dec and ituh263enc;
the former is the only user of its RL VLC tables. It uses only the very
first one of these VLC tables, but up until now all 32 are initialized,
wasting 68696B from the .bss segment (or that amount of memory if this
decoder has actually been used). This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RLTables whose VLC tables are only used for intra blocks only use
the very first VLC table; yet all 32 have been initialized. This commit
stops this by switching to INIT_FIRST_VLC_RL. This saves 201624B from
the .bss segment; in case the decoder is actually used, this translates
into less memory used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For the RLTables ff_rl_table[0..2] only the very first VLC is only ever
used, so it makes no sense to create 32 of them. This saves 285200B from
the .bss segment; this amount of memory is actually saved when this
decoder is used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The H.261 decoder uses only the very first VLC of ff_h261_rl_tcoeff,
so only initialize this one. Saves 68448B from the .bss segment; in case
the decoder is actually used, this amount of memory is saved.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is not uncommon that only the first one is used; this is similar to
ff_init_2d_vlc_rl().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
FFmpeg does not support POST, so there is no difference between a
308 and 301 request (see [RFC7538] section 3).
Signed-off-by: Josh Dekker <josh@itanimul.li>
Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
Signed-off-by: Josh Dekker <josh@itanimul.li>
Since c737f6edce prescreening is
nevertheless run because of a wrong check: "if (s->prescreen > 0)".
s->prescreen is an array of two function pointers that is contained in
the context and comparing it with 0 (i.e. NULL) is actually undefined
behaviour, because NULL and s->prescreen do not point to the same
object (NULL after all never points to any object). Nevertheless both
Clang as well as GCC compile this to code that treat s->prescreen > 0 as
true, leading to segfaults, because the code then tries to access the
-1th member of an array.
This commit fixes the check as well as another such check a few lines
below.
(Found via compiler warnings enabled by -pedantic:
"ordered comparison between pointer and zero is an extension".)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is a private field that is unused since
44f660e7e7.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Forgotten in 6197453761 (notice that
RTPDynamicProtocolHandler is not a public struct, so one can remove
the linked-list pointer immediately (unlike in most other patches of
this kind)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fix atoi() overflow for large EXT-X-MEDIA-SEQUENCE.
The spec says the type of sequence number is uint64_t. Use int64_t
here since current implementation requires it to be signed integer,
and hlsenc use int64_t too.
The patch changes the init function to initialize block dimensions to fixed
64x64 instead of the previously used image width/height based value.
This should not cause any actual change in behaviour because block dimensions
are recalculated on every keyframe in optimum_block_width() and
optimum_block_height() functions and in the current code the result is always
64x64 regardless of the image dimensions used.
Signed-off-by: Marton Balint <cus@passwd.hu>
