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>
By using ff_init_vlc_from_lengths(), we do not have to keep track of the
codes themselves, but can offload this to ff_init_vlc_from_lengths().
Furthermore, the old code presumed sizeof(int) == 4; this is no longer
so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If allows us to directly store the deltas in the VLC table and therefore
avoids a level of indirection.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The algorithm used here always creates a complete VLC, so it is
unnecessary to check this again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This ensures that the number of leafs in the Huffman tree equals the
number it is supposed to be and therefore ensures that the VLC tree is
complete, allowing us to remove checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the Huffman tree consists of only one entry (which has length zero),
no tree is used at all for parsing as the VLC API currently can't handle
this. So it makes no sense to create a VLC in this case.
Commit 41b7389cad added a check for
whether creating the VLC should be skipped, but it also skipped decoding
the packet and it used the wrong check: It checked max_codes_bits,
the maximum length of a code; but this value is only updated iff there is
more than one Huffman entry. So if there is only one Huffman entry, and
there was a previous frame with more than one entry, then a VLC was
created unnecessarily; yet if there was no previous frame with more than
one entry, then this frame will be skipped which is probably
spec-incompliant. I have no sample for the latter.
This commit improves the check to create a VLC iff it is going to be
used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Some decoders may not need a writable buffer in some specific cases, but only
a reference to the existing buffer with updated frame properties instead, for
the purpose of returning duplicate frames. For this, the
FF_REGET_BUFFER_FLAG_READONLY flag is added, which will prevent potential
allocations and buffer copies when they are not needed.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: 15246/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOTIONPIXELS_fuzzer-5168534407086080
Fixes: runtime error: index -1 out of bounds for type 'HuffCode [16]'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
reusing the last would use uninitialized data, this should be
impossible currently, but better to check by assert.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
I am not sure these new values are correct, not am I sure
the semantics are a good idea since we do not seem to make any
use of them but they caused a lot of confusion, but this
seems to make things closer to matching the documentation.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Andreas Rheinhardt
Andreas Rheinhardt
Michael Niedermayer
James Almer
Luca Barbato
Diego Biurrun
Alexandra Hájková
Vittorio Giovara
Peter Meerwald
Michael Niedermayer
Anton Khirnov
Paul B Mahol
Piotr Bandurski
Clément Bœsch
Alex Converse
Martin Storsjö
Reimar Döffinger
Laurent Aimar