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>
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>
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>
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>
This option will disable the writing of the global palette in global
GIF header if it is set to 0, causing only the frame-level palette
to ever be written.
This will be useful later on when further frame-level palette
optimizations are introduced.
The default is 1, which maintains current default behavior.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.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.
Current code is very confused and confusing. It uses two different
reference frames - "previous" and "last" - when only one is really
necessary. It also confuses the two, leading to incorrect output with
APNG_DISPOSE_OP_PREVIOUS mode.
Fixes#9017.
FF_CODEC_CAP_ALLOCATE_PROGRESS makes no sense because the decoder does
not support frame threading.
FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM makes no sense because the decoder
does not handle skip_frame.
The code using ff_exp2 (namely ff_acelp_decode_gain_code) use it only if
G729_BITEXACT is defined. So disable it if not.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allowed to remove forward declarations. Because compilers expect
declarations for all functions they encounter even when it is within
blocks disabled via "if (0 && foo)", one has to use a real #if in
ff_diracdsp_init_x86.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Unused since a1f3b18bf5, yet as nonstatic
functions the compiler can't detect this, so that these functions aren't
stripped and no warning is emitted.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_acelp_decode_8bit_to_1st_delay3, ff_acelp_decode_4bit_to_2nd_delay3
and ff_acelp_decode_5_6_bit_to_2nd_delay3 are all only used once (by
g729dec) whereas ff_acelp_decode_9bit_to_1st_delay6 and
ff_acelp_decode_6bit_to_2nd_delay6 are completely unused; with the
possible exception of ff_acelp_decode_4bit_to_2nd_delay3, these
functions are so small that inlining them is appropriate; and as long as
ff_acelp_decode_4bit_to_2nd_delay3 is only called once, this is also
true for it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Michael Niedermayer
Paul B Mahol
Andreas Rheinhardt
James Almer
Derek Buitenhuis
Anton Khirnov