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>
Also, ensure no false positives when determining DNG bayer images, by
setting them in tiff.c instead of relying on a heuristic. There's no
way to determine this just from the JPEG data, so we have to pass this
information from outside the MJPEG decoder.
Signed-off-by: Nick Renieris <velocityra@gmail.com>
Main image data in DNGs is usually comprised of tiles, each of which is a Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris <velocityra@gmail.com>
These may be used by hwaccel decoders when the standard tables are not
otherwise available. At the same time, clean up that code into an array
so it's a little less repetitive.
Fixes: out of array access
Fixes: 9225/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5684770334834688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Michael Niedermayer
James Almer
Andreas Rheinhardt
Andreas Rheinhardt
Carl Eugen Hoyos
Anton Khirnov
Paul B Mahol
Mark Thompson
Nick Renieris
Zhong Li
Vittorio Giovara