ff_rl_init() initializes RLTable.(max_level|max_run|index_run);
max_run is unused by the SpeedHQ encoder (as well as MPEG-1/2).
Furthermore, it initializes these things twice (for two passes),
but the second half of this is never used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will allow to remove ff_rl_mpeg2 soon and remove
all uses of RLTable in MPEG-1/2/SpeedHQ later.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Renaming the decoder to speedhqdec.c makes sense since
we have an encoder in speedhqenc.c. Given that ff_rl_speedhq
is also used by the encoder, it is kept in speedhq.c
and a proper header for it is created to replace the ad-hoc
declaration in speedhqenc.c. This also allows to remove
the check for CONFIG_SPEEDHQ_DECODER, as it is always true
when speedhqdec.c is compiled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is better place for these declarations than
mpeg12data.h as RL VLC are just a variant of VLCs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and remove FF_CODEC_CAP_INIT_THREADSAFE
All our native codecs are already init-threadsafe
(only wrappers for external libraries and hwaccels
are typically not marked as init-threadsafe yet),
so it is only natural for this to also be the default state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Our code for writing optimal huffman tables is incompatible
with using multiple slices and hence commit
884506dfe2 that implemented this
also added an assert that slice_context_count is always 1.
Yet this was always wrong: a) The MJPEG-encoder has (and had)
the AV_CODEC_CAP_SLICE_THREADS capability, so asserting that
it always uses one slice context is incorrect.
b) This commit did not add any proper checks that ensured that
optimal huffman tables are never used together with multiple slices.
This only happened with 03eb0515c1.
c) This assert is at the wrong place: ff_mjpeg_encode_init() is
called before the actual slice_context_count is set. This is
the reason why this assert was never triggered.
Therefore this commit removes this assert.
Also remove an assert from the SpeedHQ encoder sharing b) and c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
The child_class_next API relied on different AVCodecs to use
different AVClasses; yet this API has been replaced by
child_class_iterate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The SpeedHQ encoder currently reverses the entries of two small tables
and stores them in other tables. These other tables have a size of 48
bytes, yet the code for their initialization takes 135 bytes (GCC 9.3,
x64, O3 albeit in an av_cold function). So remove the runtime
initialization and hardcode the tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SpeedHQ decoder uses and initializes a RLTable's VLC, yet it also
initializes other parts of the RLTable that it does not use. This has
downsides besides being wasteful: Because the SpeedHQ encoder also
initializes these additional fields, there is a potential for data races
(and therefore undefined behaviour). In fact, removing the superfluous
initializations from the decoder automatically makes both the decoder
and the encoder init-threadsafe. This commit does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, the SpeedHQ encoder called a wrong function for init:
void ff_init_uni_ac_vlc(const uint8_t huff_size_ac[256],
uint8_t *uni_ac_vlc_len);
Yet the first argument actually used is of type RLTable; the size of
said struct is less than 256 if the size of a pointer is four, leading
to an access beyond the end of the RLTable.
This commit fixes this by calling the actually intended function:
init_uni_ac_vlc() from mpeg12enc.c. It was intended to use this
function [1], yet doing so was forgotten when the patch was actually
applied.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/266187.html
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
