Codecs that can read/write ICC profiles deserve a special capability so
the common logic in encode.c/decode.c can decide whether or not there
needs to be any special handling for ICC profiles. The motivation here
is to be able to use it to decide whether or not an ICC profile needs to
be generated in the encode path, but it might as well get added to
decoders as well for purely informative reasons.
It's not entirely clear to me whether the "thp" and "smvjpeg" variants
of "mjpeg" should have this capability set or not, given that the code
technically supports it but I somehow doubt these files may contain
them. In either case, this cap is purely informative for decoders so it
doesn't matter too much either way.
It's also not entirely clear whether the "amv" encoder should signal ICC
profile support, but again erring on the side of caution, we probably
*shouldn't* be generating (and encoding!) ICC profiles for this type of
media file.
Signed-off-by: Niklas Haas <git@haasn.dev>
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>
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 exif.h header doesn't use anything from tiff.h. We also just need
to include tiff_common.h in .c files where it actually used.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are seven MJPEG-tables, five small (1x12, 4x17) and two
not small (2x162). These are all avpriv, despite this not being
worthwhile due to the overhead of exporting a symbol: The total
overhead for each symbol consists of two entries in .dynsym (24B each),
one entry in the importing library's .rela.dyn (24B) and one in .got
(8B) as well as 2x2B for symbol versions and 4B for symbol hashes
in the exporting library; in addition to that, the name of the symbol
is included in both exporting and importing libraries, using 2x210 bytes
in this case.
(The above numbers are for a x64 Elf/Linux/GNU system. Other platforms
will give different numbers.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The cases in which there was flipping together with a rotation
that is not a multiple of the identity were wrong.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A zero value in the quantization matrix is invalid but in practice will
just set the transform coefficient to zero after inverse quantization.
Try to continue decoding if the AV_EF_EXPLODE flag is not set.
Fixes ticket #9287.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Fixes: out of array access
Fixes: 33960/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5052852809629696
Fixes: 34163/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-6123678099177472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This simply performs a 2nd pass if a LSE is encountered with GRAY8
Fixes: tickets/3933/128.jls
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For frames decoded with skip_frame == AVDISCARD_ALL, a picture is not allocated
and got_picture is never set to 1 even if a SOF and SOS were parsed.
The existing check in EOI only cares if a SOF was parsed, not if a picture
allocated, so change it and add a new check to explicitly ensure a picture was
allocated when skip_frame != AVDISCARD_ALL.
Fixes probing and decoding when skip_frame is AVDISCARD_ALL.
Signed-off-by: James Almer <jamrial@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>
With JPEG-LS PAL8 samples, the JPEG-LS extension parameters signaled with
the LSE marker show up after SOF but before SOS. For those, the pixel format
chosen by get_format() in SOF is GRAY8, and then replaced by PAL8 in LSE.
This has not been an issue given both pixel formats allocate the second data
plane for the palette, but after the upcoming soname bump, GRAY8 will no longer
do that. This will result in segfauls when ff_jpegls_decode_lse() attempts to
write the palette on a buffer originally allocated as a GRAY8 one.
Work around this by calling ff_get_buffer() after the actual pixel format is
known.
Signed-off-by: James Almer <jamrial@gmail.com>
Before 9b3c46a081 every call to
ff_jpegls_decode_picture() allocated and freed a JLSState. This commit
instead put said structure into the context of the JPEG-LS decoder to
avoid said allocation. But said function can also be called from other
MJPEG-based decoders and their contexts doesn't contain said structure,
leading to segfaults. This commit fixes this: The JLSState is now
allocated on the first call to ff_jpegls_decode_picture() and stored in
the context.
Found-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If only one of the two arrays used for the ICC profile could be
successfully allocated, it might be overwritten and leak when
the next ICC entry is encountered. Fix this by using a common struct,
so that one has only one array to allocate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When using external Huffman tables fails during init, the decoder
reverts back to using the default Huffman tables; and when doing so,
the current VLC tables leak because init_default_huffman_tables()
doesn't free them before overwriting them.
Sample:
samples.ffmpeg.org/archive/all/avi+mjpeg+pcm_s16le++mjpeg-interlace.avi
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVID streams - currently handled by the AVRN decoder - can be (depending
on extradata contents) either MJPEG or raw video. To decode the MJPEG
variant, the AVRN decoder currently instantiates a MJPEG decoder
internally and forwards decoded frames to the caller (possibly after
cropping them).
This is suboptimal, because the AVRN decoder does not forward all the
features of the internal MJPEG decoder, such as direct rendering.
Handling such forwarding in a full and generic manner would be quite
hard, so it is simpler to just handle those streams in the MJPEG decoder
directly.
The AVRN decoder, which now handles only the raw streams, can now be
marked as supporting direct rendering.
This also removes the last remaining internal use of the obsolete
decoding API.
While just at it, remove the nb_codes parameter: It is redundant
(the number of codes is implicitly contained in the array containing how
many entries of a specific size there are) and for this reason it might
even be wrong, so it is better to check what is actually used instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
MJPEG does not have a single quantiser scale, so this does not fit into
the intended API use.
This removes the last use of the long-deprecated QP table API.
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also allows to omit the check whether the codes
are already properly ordered (they are).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This affected all decoders that used ff_mjpeg_decode_init() as init
function; and it also affected decoders that open jpeg decoders via
ff_codec_open2_recursive() as well as MxPEG.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that the correct number of codes is used, it is no longer necessary
to initialize the lengths of the codes at all any more as the length of
the actually used codes is set later anyway.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is always zero; it referred to the INIT_VLC_USE_STATIC flag which has
been removed in 595324e143.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit bbc0d0c1fe made the mjpeg decoder
use default Huffman tables when none are given, yet when initializing
the default Huffman tables, it did not use the correct number of entries
of the arrays used to initialize the tables, but instead it used the
biggest entry + 1 (as if it were a continuous array 0..biggest entry).
This worked because the ff_init_vlc_sparse() (and its predecessors)
always skipped entries with a length of zero and the length of the
corresponding elements was always initialized to zero with only the
sizes of the actually existing elements being set to a size > 0 lateron.
Yet since commit 1249698e1b this is no
longer so, as build_vlc() actually read the array containing the values
itself. This implies that the wrong length now leads to a read beyond
the end of the given array; this could lead to crashs (but usually
doesn't); it is detectable by ASAN* and this commit fixes it.
*: AddressSanitizer: global-buffer-overflow on address xy
...
xy is located 0 bytes to the right of global variable 'avpriv_mjpeg_val_ac_luminance'
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1249698e1b made
ff_mjpeg_decode_dht() call build_vlc() with a wrong (too hight)
number of codes. The reason it worked is that the lengths of the extraneous
entries is initialized to zero and ff_init_vlc_sparse() ignores codes
with a length of zero. But using a too high number of codes was
nevertheless bad, because a) the assert in build_vlc() could have been
triggered (namely if the real amount of codes is 256) and b) the loop in
build_vlc() uses initialized data (leading to Valgrind errors [1]).
Furthermore, the old code spend CPU cycles in said loop although the
result won't be used anyway.
[1]: http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20201008025137
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has been forgotten in d5a3a20d.
Found via PVS-Studio (see ticket #8156).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array write
Fixes: 17088/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5654877765632000
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>
Niklas Haas
Andreas Rheinhardt
Martin Storsjö
Andreas Schneider
James Almer
Michael Niedermayer
Andriy Gelman
Andreas Rheinhardt
Carl Eugen Hoyos
Anton Khirnov
Paul B Mahol
Mark Thompson