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.
avcodec_find_best_pix_fmt2 has been deprecated and replaced by
avcodec_find_best_pix_fmt_of_2 in 2a54ae9df8.
avcodec_find_best_pix_fmt_of_2 and avcodec_get_pix_fmt_loss meanwhile
were deprecated in 617e866e25 when these
functions were de facto moved to libavutil; this has been mentioned in
APIchanges in f7a1c5e4d2. Yet the
attribute_deprecated was never set for the latter two functions and they
were not wrapped in an FF_API define. This commit does this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec_find_best_pix_fmt_of_2 has been moved to libavutil in
617e866e25.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
1582e306a4 scheduled it for removal with
libavformat major version 58, but it was never removed.
Reviewed-by: Paul B Mahol <onemda@gmail.com
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Only lavfutils.c needs avformat.h, not lavfutils.h.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The whole old next API has been deprecated in commit
7e8eba2d87, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These functions were never deprecated. The merge from commit 6988cf2969
included them by mistake.
Found-by: mkver
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit 0191f2d29c.
These functions were never deprecated. The merge from commit 6988cf2969
included them by mistake.
Found-by: mkver
Signed-off-by: James Almer <jamrial@gmail.com>
GIF palette entries are not compressed, and writing 256 entries,
which can be up to every frame, uses a significant amount of
space, especially in extreme cases, where palettes can be very
small.
Example, first six seconds of Tears of Steel, palette generated
with libimagequant, 320x240 resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Andreas Rheinhardt
Paul B Mahol
Michael Niedermayer
Vadym Bezdushnyi
Marton Balint
James Almer
Lynne
Derek Buitenhuis