Needs a CountedElement in order to distinguish the case of the element
not being present and the element being present with a value of zero.
(It has been argued by Ridley Combs that one should only ever use the
AV_DISPOSITION_DUB field for audio tracks. Yet given that there is no
definition for the disposition flags, one can also interpret it to mean
that e.g. a subtitle track is meant to be used with the dubbed audio
track or the original audio track. This commit interprets this flag in
this sense, which also allows to maintain it on remuxing.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -2147483634 - 16 cannot be represented in type 'int'
Fixes: 28322/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5711888402612224
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: -2147483648 - 4 cannot be represented in type 'int'
Fixes: 28127/clusterfuzz-testcase-minimized-ffmpeg_dem_VOC_fuzzer-4880586455646208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is possible because their size is known at compile-time; so they
can be put directly into the context and don't need to be allocated for
every frame.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In case of the cel evaluators it even allows to perform the
initialization of the source coordinates only once instead of for each
frame.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the RoQ video decoder and encoder used the same context;
and said context contained several fields that are only used by the
encoder. This commit changes this and uses a dedicated context for the
encoder; it contains the common context as first element in order to use
functions common to the de- and encoder.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: left shift of negative value -128
Fixes: 30746/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXTORY_fuzzer-5906271469436928
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>
x264 versions >= 153 can support multiple bitdepths; they also don't
export x264_bit_depth any more. The actual check whether a bitdepth
is supported is therefore performed at runtime in x264_encoder_open.
Ergo it is unnecessary to use init_static_data for these versions:
One can already set ff_libx264_encoder.pix_fmts to the value that
X264_init_static always sets it to.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also make the macro used for the demuxers spec-compliant. The earlier
macro was not, because the ... argument of a variadic macro must not be
left out. GCC and Clang warn about this when using -pedantic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only affects the old and deprecated avcodec_decode_(video2|audio4)
API which is no longer used here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Memory for auxillary_info was not freed after usage.
Leak can be reproduced with following commands:
Optionally, generate input video:
ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 input.mp4
Run ffmpeg with valgrind:
valgrind --leak-check=full --show-leak-kinds=all \
ffmpeg -y -i input.mp4 -vcodec copy -acodec copy \
-encryption_scheme cenc-aes-ctr \
-encryption_key 00000000000000000000000000000000 \
-encryption_kid 00000000000000000000000000000000 \
ffmpeg_encrypted.mp4
For test video which has duration of 10 sec, leak is 4 Kb.
For 100 sec video, leak will be 33 Kb. Most likely,
leaked memory will grow linearly to the number of input frames.
Signed-off-by: Vadym Bezdushnyi <vadim.bezdush@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
av_gettime_relative() is using the monotonic clock therefore more suitable for
elapsed time calculations. Packet timestamps are still kept absolute, although
that should be configurable in the future.
Related to ticket #9089.
Signed-off-by: Marton Balint <cus@passwd.hu>
av_gettime_relative() is using the monotonic clock therefore more suitable for
relative time calculations.
Signed-off-by: Marton Balint <cus@passwd.hu>
AVFrame hasn't been a struct defined in libavcodec for a decade now, when
it was moved to libavutil.
Found-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This code was written when the allocation functions used parameters of
type unsigned. This is no longer true today and therefore we only need
to check whether the multiplication of the array's size stays within
a size_t -- and this can be offloaded to av_realloc_array.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the wav muxer used a reallocation of the form ptr =
av_realloc(ptr, size); that leaks upon error. Furthermore, if a
failed reallocation happened when writing the trailer, a segfault
would occur due to avio_write(NULL, size) because the muxer only
prints an error message upon allocation error, but does not return
the error.
Moreover setting the pointer to the buffer to NULL on error seems to
be done on purpose in order to record that an error has occured so that
outputting the peak values is no longer attempted. This behaviour has
been retained by simply disabling whether peak data should be written
if an error occurs.
Finally, the reallocation is now done once per peak block and not once
per peak block per channel; it is also done with av_fast_realloc and not
with a linear size increase.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
out[lut[i]] = in[i] lookups were 4.04 times(!) slower than
out[i] = in[lut[i]] lookups for an out-of-place FFT of length 4096.
The permutes remain unchanged for anything but out-of-place monolithic
FFT, as those benefit quite a lot from the current order (it means
there's only 1 lookup necessary to add to an offset, rather than
a full gather).
The code was based around non-power-of-two FFTs, so this wasn't
benchmarked early on.
