This improves performance: For msvideo1, the performance improved by
4.8% when encoding the sample from the fate-vsynth1-msvideo1 test;
when encoding the sample from fate-vsynth1-cinepak, performance
improved by 2%. The compiler user was GCC 10 and the calls to encode2
have been timed.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is currently unused and it is only added to enable changes
while maintaining ABI compatibility. The type is uintptr_t in order
to potentially accept a pointer argument.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the number of elements needed in each
recursion step decreases geometrically, so the geometric series
provides an upper bound for the sum of number of elements of
the needed buffers.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: index 128 out of bounds for type 'uint16_t [128]'
Fixes: 38651/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6296416058736640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, each call to avpriv_elbg_do() would result
in at least six allocations. And this function is called a lot:
A typical FATE run results in 52213653 calls to av_malloc; of these,
34974671 originate from av_malloc_array and from these 34783679
originate from avpriv_elbg_do; the msvideo1 encoder tests are behind
most of these.
This commit changes this by keeping the buffers and only reallocating
them when needed. E.g. for the encoding part of fate-vsynth1-msvideo1
total heap usage went down from 11,407,939 allocs and frees with
468,106,207 bytes allocated to 3,149 allocs and frees with 13,181,847
bytes allocated. The time for one encode2-call went down by 69%.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This affects all the arguments that don't change during a call
to avpriv_elbg_do(); doing so makes it easily recognizable which
arguments change upon recursive calls.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will be used in future commits to avoid having to allocate and free
all the buffers used.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is in line with our naming conventions for types.
Also change numCB to num_cb for the same reason.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions are always called directly after another with
the exact same arguments. This avoids exporting a symbol;
it also avoids having to perform two calls for every caller.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will avoid a forward declaration later.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
silk_lsp2poly()'s declaration contained arrays with array sizes;
yet these array sizes exceeded the number of actually accessed array
elements (which is related to another parameter) and this leads to
-Wstringop-overflow= warnings from GCC 11, because the arrays provided
by callers are only large enough for the actually used elements.
So replace the incorrect array sizes with comments containing
the correct array sizes. Given that these sizes are not compile-time
constants, they can only be communicated via a comment.
Reported by Paul B Mahol.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unused since 1f63665ca5.
Found-by: Soft Works <softworkz@hotmail.com>
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is supported only by a few decoders (h263, h263p, mpeg(1|2|)video
and mpeg4) and is entirely redundant with parsers. Furthermore, using
it leads to missing frames, as flushing the decoder at the end does not
work properly.
Co-authored-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: 38603/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSNSIREN_fuzzer-5741847809490944.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: error: 1.66789e+11 is outside the range of representable values of type 'int'
Fixes: Ticket8201
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: NULL pointer dereference
Fixes: 38125/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XMA1_fuzzer-5151909422432256
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>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 559334865 * 4 cannot be represented in type 'int'
Fixes: 37929/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-6751932295806976
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Defined in spec 5.9.8. When superres is enabled, SuperresDenom equals
"coded_denom + SUPERRES_DENOM_MIN" instead of coded_denom.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
Fixes: signed integer overflow: 7020950083487072256 * 2 cannot be represented in type 'long long'
Fixes: 37523/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5133634955771904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 37664/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5893420460146688
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>
The documentation does not require the packet to be blank in this case
(i.e. it can now contain opaque_ref), but it does contain that the
contents will be reset upon success.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When an empty list bsf is used for passthrough, there is a check
for every packet in bsf_list_filter() before ff_bsf_get_packet_ref()
is called. Directly using the null bsf avoids that.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes trac issue #7473.
Removes encoder delay (skip samples) and writes remaining frame samples after EOF to get correct sample count.
Output is now accurate vs players that use Microsoft's codecs (Windows Media Format Runtime).
Tested vs encode>decode WMAv2 with MS's codecs and most sample rate/bit rate/channel/mode combinations in ASF/XWMA.
WMAv1 appears to use the same delay, from FFmpeg samples.
Signed-off-by: bnnm <bananaman255@gmail.com>
This bug flew under the radar because, in practice, these values are
0-initialized for the first invocation. But for subsequent invocations
(with different h/v values), reading from the uninitialized parts of
`out` is undefined behavior.
Avoid this by simply adjusting the iteration range of the following
loops. Has the added benefit of being a minor speedup.
Signed-off-by: James Almer <jamrial@gmail.com>
fixes#8857
If we do not clear the enc_ctrl, we will reuse previous frames' data like FrameType.
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
