Before patch, fate test for dnn may fail in some Windows environment
while succeed in my Linux. The bug was caused by a wrong loop boundary.
After patch, fate test succeed in my windows mingw 64-bit.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
The RealMedia demuxer uses the priv_data of its streams to store a
structure containing an AVPacket. These packets are unreferenced in the
read_close function, yet said function simply presumed that the
priv_data has been successfully allocated. This implies that it mustn't
be called when an allocation of priv_data fails; but this can happen
since commit 35bbc1955a if one has a
stream with multiple substreams (also exported as AVStream) and if
allocating the priv_data for one of these substreams fails.
This has been fixed by making sure that read_close can handle the case
in which priv_data has not been successfully allocated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RealMedia demuxer's read_header function initially initializes ret,
the variable designated for the return variable to -1. Afterwards, chunks
of the file are parsed in a loop until an error happens or until the actual
frame data is encountered. If the first function whose return
value is put into ret doesn't fail, then ret contains a value >= 0
(actually == 0) and this is what will be returned if an error is
encountered afterwards.
This is a regression since 35bbc1955a.
Before that, ret had never been overwritten with a nonnegative value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from the
AVFloatDSPContext that is needed lateron. This also allows to remove the
decoders' close function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The lossless JPEG encoder allocates one buffer in its init function
and freeing said buffer is the only thing done in its close function.
Despite this the init function called the close function if allocating
said buffer fails, although there is nothing to free in this case.
This commit stops doing this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The JPEG2000 encoder did not clean up after itself on error.
This commit fixes this by modifying the cleanup function to be able to
handle only partially allocated structures and by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from
the AVFloatDSPContext that is needed lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The HNM 4 video decoder's init function claimed that an allocation
failed if the image dimensions are wrong. This is fixed in this commit:
The dimensions are checked before the allocations are attempted.
The check whether width * height is zero is redundant as
av_image_check_size() already checks for this; it has been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This encoder uses the compress2 utility function provided by zlib
instead of using a z_stream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the flashsv encoder tried to allocate two buffers in its
init function; if only one of these allocations succeeds, the other
buffer leaks. Fix this by making one of these buffers part of the
context (its size is a compile-time constant).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
According to the spec bits per sample should be used
Fix invalid shift with bpp=32
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 23507/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-4815432665268224
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 23760/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-604209011412172
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 0 - -2147483648 cannot be represented in type 'int'
Fixes: 23646/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5480991098667008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 61669b7c40.
This commit broke building with MSVC due to its spec-incompliant handling
of ',' in __VA_ARGS__: These are not treated as argument separators for
further macros, so that in our case the init_vlc2() macro is treated as
having only one argument whenever the init_vlc() macro is used. See [1]
for further details.
[1]: https://reviews.llvm.org/D69626
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AC-3 encoders (both floating- as well as fixed-point) as well as
the EAC-3 encoder share code: All use ff_ac3_encode_init() as well as
ff_ac3_encode_close(). Until ee726e777b
ff_ac3_encode_init() called ff_ac3_encode_close() to clean up on error.
Said commit removed this and instead set the FF_CODEC_CAP_INIT_CLEANUP
flag; but it did the latter only for the fixed-point AC-3 encoder and
not for the other two users of ff_ac3_encode_init(). This caused any
already allocated buffer to leak upon a subsequent error for the two
other encoders.
This commit fixes this by adding the FF_CODEC_CAP_INIT_CLEANUP flag
to the other two encoders using ff_ac3_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ac3 encoders (fixed- and floating-point AC-3 as well as the EAC-3
encoder) all allocate an array whose elements are pointers to other
buffers. The array is not zeroed initially so that if an allocation of
one of the subbuffers fails, the other pointers are uninitialized.
This causes problems when cleaning, so zero the array initially.
(Only the fixed-point AC-3 encoder was affected by this, because
the other two don't clean up at all in case of errors during init.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from
the AVFloatDSPContext that is needed lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Do this by only keeping the only function pointer from
the AVFloatDSPContext that is needed lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The init function of the ALAC encoder calls its own close function
if a call to ff_lpc_init() fails; yet nothing has been allocated before
that point (except extradata which is freed generically) and ff_lpc_init()
can be expected to clean up after itself on error (the documentation does
not say anything to the contrary and the current implementation can only
fail if the only allocation fails, so there is nothing to clean up on
error anyway), so this is unnecessary.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is already freed generically for encoders.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tiles have a size field with a length from one to four bytes. As such it
is not possible to read it all at once with a call to get_bits() as this
only allows to read up to 25 bits; this is guarded by an av_assert2. Yet
this is done by the AV1 decoder in get_tiles_info(). It has been done
despite said size fields being byte-aligned. This commit fixes this by
using the bytestream2 API instead.
Furthermore, it is now explicitly checked whether the data is
consistent, i.e. whether the data that is supposed to be there extends
beyond the end of the data actually present.
Reviewed-by: Wang, Fei W <fei.w.wang@intel.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Besides the obvious advantage of less code this also has a performance
impact: For GCC 9 the time spent on one call to smka_decode_frame() for
the sample from ticket #2425 decreased from 1693619 to 1498127
decicycles. For Clang 9, it decreased from 1369089 to 1366465
decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the Smacker decoder has pretended that the prediction
values are signed in code like 'pred[0] += (unsigned)sign_extend(val, 16)'
(the cast has been added to this code later to fix undefined behaviour).
This has been even done in case the PCM format is u8.
Yet in case of 8/16 bit samples, only the lower 8/16 bit of the predicition
values are ever used, so one can just as well just use unsigned and
remove the sign extensions. This is what this commit does.
For GCC 9 the time for one call to smka_decode_frame() for the sample from
ticket #2425 decreased from 1709043 to 1693619 decicycles; for Clang 9
it went up from 1355273 to 1369089 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
by using buffers on the stack instead. The fact that the effective
lifetime of most of the allocated buffers doesn't overlap enables one to
limit the stack space used to a fairly modest size (about 1.5 KiB).
That all the buffers used in HuffContexts have always the same number of
elements (namely 256) makes it possible to include the buffers directly
in the HuffContext. Doing so also makes the length field redundant; it has
therefore been removed.
This is beneficial for performance: For GCC 9 the time for one call to
smka_decode_frame() for the sample in ticket #2425 went down from
1794494 to 1709043 decicyles; for Clang 9 it decreased from 1449420 to
1355273 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the return value of get_vlc2() has been used as an index
in an array that contained the value one is really interested in. Yet
since b613bacca9 this is no longer
necessary, as one can store the value that is right now stored in the
array in the VLC internal table.
This also means that all the information from the eight bit Huffman trees
are now stored in the corresponding VLC table; this will enable us to
remove several allocations lateron.
This improved performance: For GCC 9 the time for one call of
smka_decode_frame() for the sample from ticket #2425 decreased from
1811706 to 1794494 decicycles; for Clang 9 the number went from 1471663
to 1449420 decicycles.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Xu Jun
Andreas Rheinhardt
Paul B Mahol
Zane van Iperen
Michael Niedermayer