In C, qualifiers for arrays are broken:
const VLC_TYPE (*foo)[2] is a pointer to an array of two const VLC_TYPE
elements and unfortunately this is not compatible with a pointer
to a const array of two VLC_TYPE, because the latter does not exist
as array types are never qualified (the qualifier applies to the base
type instead). This is the reason why get_vlc2() doesn't accept
a const VLC table despite not modifying the table at all, as
there is no automatic conversion from VLC_TYPE (*)[2] to
const VLC_TYPE (*)[2].
Fix this by using a structure VLCElem for the VLC table.
This also has the advantage of making it clear which
element is which.
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>
This increases type-safety by avoiding conversions from/through void*.
It also avoids the boilerplate "AVFrame *frame = data;" line
for non-subtitle decoders.
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>
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>
The decoders in this set either have a fixed channel count, or read it
from the bitstream, and thus do not require the channel count as
external information.
Fixes various regressions since
81503ac58a, which requires a valid channel
count for decoders which do not set this capability.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
Up until now, VLCs that were part of an array of VLCs were often not
initialized in a loop, but separately. The probable reason for this
was that these VLCs differed slightly in the parameters to be used for
them (i.e. the number of codes or the number of bits to be used
differs), so that one would have to provide these parameters e.g. via
arrays.
Yet these problems have actually largely been solved by now: The length
information is contained in a run-length encoded form that is the same
for all VLCs and both the number of codes as well as the number of bits
to use for each VLC can be easily derived from them.
There is just one problem to be solved: When the underlying tables have
a different number of elements, putting them into an array of arrays
would be wasteful; using an array of pointers to the arrays would
also be wasteful. Therefore this commit combines the tables into bigger
tables. (Given that all the length tables have the same layout this
applies only to the symbols tables.)
Finally, the array containing the offset of the VLC's buffer in the big
buffer has also been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several of the quantisation VLCs come in pairs and up until now the
number of bits used for each VLC was set to the same value for both VLCs
in such a pair even when one of the two required only a lower number.
This is a waste given that the get_vlc2() call is compatible with these
two VLCs using a different number of bits (it uses vlc->bits).
Given that the code lengths are descending it is easily possible to know
the length of the longest code for a given VLC: It is the length of the
first one. With this information one can easily use the least amount of
bits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting both length, code as well as symbol tables so that
the codes are ordered from left to right in the tree, it became apparent
that the length of the codes decreases from left to right. Therefore one
can run-length encode the lengths to save space. This commit implements
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can make a table of
codes of type uint8_t superfluous, saving space.
Other VLCs (those without dedicated symbols table and with codes of
type uint8_t) have been made to use ff_init_vlc_from_lengths(), too,
because it reduces codesize (ff_init_vlc_from_lengths() has two
parameters less than ff_init_vlc_sparse()) and because it allows to
use the offset parameter in future commits.
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>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 15817/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC8_fuzzer-5636626409062400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -456
Fixes: 15561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC8_fuzzer-5758130404720640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Suggested-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In Musepack SV8 codec property tell the maximum nonzero band, but every
frame codes maximum band as a limit (i.e. strictly less than given value).
Synthesis also expects maximum nonzero band, so there's a need to convert
frame maximum band limit value.
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
Andreas Rheinhardt
Anton Khirnov
Andreas Rheinhardt
Hendrik Leppkes
Michael Niedermayer
Paul B Mahol
Luca Barbato
Diego Biurrun
Alexandra Hájková
Vittorio Giovara
Clément Bœsch
Justin Ruggles
Kostya Shishkov
Michael Niedermayer
Carl Eugen Hoyos
Martin Storsjö