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 2a54ae9df8cbc1717b3929222ac75f384e2ff240.
avcodec_find_best_pix_fmt_of_2 and avcodec_get_pix_fmt_loss meanwhile
were deprecated in 617e866e25b72fa5d9f9d6bbcbd7e4bd69e63a54 when these
functions were de facto moved to libavutil; this has been mentioned in
APIchanges in f7a1c5e4d2294a8970ede7f6deb2fe0a64e202a5. 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
7e8eba2d8755962d9dca5eade57bf8f591a73c0c, 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 0191f2d29c2a62b8699ac75f09708187e943814c.
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 a1f3b18bf55f106c974eacb1dc831be4d2bd5277, 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>
Added in 0c79b1402a48a99f32435a0f5ad2364c58c6fcf3 to use it
in a function that was never used and was itself removed in
676f1f533e2c2960d81784188592a066b9ff1c3d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Clang infers from the existence of a default case that said case can be
taken. In case of libavcodec/bitstream.c said default case consisted of
an av_assert1 that evaluates to nothing in case of the ordinary assert
level. In this case (that doesn't happen) a variable wouldn't be
initialized, so Clang emitted Wsometimes-uninitialized warnings.
Solve this by making sure that the default path also initializes
the aforementioned variable.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The counter for the number of styles is written on two bytes, ergo
anything > UINT16_MAX is invalid. This also fixes a compiler warning
because of a tautologically true check on 64bit systems.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
tiff.c is the only user of the data from tiff_data.c (the dependency of
the tiff encoder of it is spurious). Therefore this commit moves all the
data from tiff_data.c to tiff_data.h (which is only included by tiff.c)
and makes the objects declared therein static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The NUT and avi demuxers only need ff_codec_movvideo_tags and so this
removes a dependency on the rest of isom.c as well as on mpeg4audio.c
(which isom depends on); it is similar for the Matroska demuxer and
muxers, except that the mpeg4audio.c dependency can't be avoided.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Unneeded since f96a653184e63cea91e08ea75ae60d309e431f40 and
b2bb09bcc330156e9d79d7ddfa59f9c5d05ca149.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
