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>
This separation allows these functions to be used in a cleaner
fashion from other codecs (e.g. qdm2) and simplifies creating
optimised versions of them.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Andreas Rheinhardt
Hendrik Leppkes
Michael Niedermayer
Paul B Mahol
Luca Barbato
Diego Biurrun
Alexandra Hájková
Vittorio Giovara
Clément Bœsch
Anton Khirnov
Justin Ruggles
Kostya Shishkov
Michael Niedermayer
Carl Eugen Hoyos
Martin Storsjö
Laurent Aimar
Mans Rullgard