This encoder has AVCodec.pix_fmts set, so ff_encode_preinit() already
checks for this.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value zero for AVPacket.duration means that the duration is unknown,
which in practice means "play this subtitle until overridden by the next
subtitle". Yet for Matroska a BlockGroup with duration zero means
that the subtitle really has a duration zero. "Display until overridden"
is achieved by not setting a duration on the container level at all and
this is achieved by using a SimpleBlock or a BlockGroup without
duration. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: left shift of negative value -224
Fixes: 32144/clusterfuzz-testcase-minimized-ffmpeg_dem_MVI_fuzzer-4971479323246592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Apparently for various image sequences libavformat/utils.c can
calculate rather fancy r_frame_rate values, such as `186/1921`,
and since ffmpeg.c utilizes r_frame_rate for the filter chain
time base, this can quite deteriorate the output frame timing - even
though the user has requested the image sequence to be interpreted
at a specific, constant frame rate.
Most of the codecs just need everything zeroed. Those that don't
are either handled inline during decode, or pull state from
extradata.
Move state reset/init functionality into adpcm_flush(), and
invoke it from adpcm_decode_init().
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The block size is hardcoded, so the buffer size is always known.
Statically allocate the buffer on the stack.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
MPEG-1/2/4 are the only mpegvideo based encoders that support bframes;
yet even the encoders not supporting bframes have options that only make
sense for an encoder that supports bframes; setting any of these options
for such an encoder has no impact on the encoded outcome (but setting
b_strategy to two slows down encoding considerably). So deprecate these
options.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-2 encoder is the only mpegvideo-based encoder that supports
embedding a53 side data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mpeg_quant may only be set for MPEG-4 and MPEG-2, yet for the latter
it is no option as the code acts as if it were always set.
So deprecate the option for all codecs for which it makes no sense.
Furthermore, given that the code already errors out if the option is set
for a codec that doesn't support it we can restrict the range of
the option for all these codecs without breaking something. This means
that the checks for whether mpeg_quant is set for these codecs can be
removed as soon as AVCodecContext.mpeg_quant is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This has the advantage that one does not waste some allocations
if one errors out because of these checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently said list contains only the pixel formats that are always
supported irrespective of the range and the value of
strict_std_compliance. This makes the MJPEG encoder an outlier as all
other codecs put all potentially supported pixel formats into said list
and error out if the chosen pixel format is unsupported. This commit
brings it therefore in line with the other encoders.
The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
informed decision would be possible if colour range were available
at this point, but it isn't.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The documentation for AV_PIX_FMT_YUVJ420P reads:
"planar YUV 4:2:0, 12bpp, full scale (JPEG), deprecated in favor of
AV_PIX_FMT_YUV420P and setting color_range"
Yet the LJPEG encoder only accepts full scale yuv420p when strictness is
set to unofficial or lower; with default strictness it emits a nonsense
error message that says that limit range YUV is unofficial. This has
been changed to allow full range yuv420p, yuv422p and yuv444p irrespective
of the level of strictness.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All encoders using ff_mpv_encode_init() already have pix_fmts set
so that the pixel format is already checked in ff_encode_preinit().
The one exception to this is MJPEG whose check remains.
(Btw: The AVCodec.pix_fmts check for AMV is stricter than the check
in ff_mpv_encode_init().)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using optimal Huffman tables is not supported for AMV and always
disabled by ff_mpv_encode_init(); therefore one can build
the AMV encoder without mjpegenc_huffman if one adds the necessary
compile-time checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now the relevant checks all checked for the existence of the
MJPEG encoder only.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ProRes encoder allocates huge worst-case buffers just to be safe;
and for huge resolutions (8k in this case) these can be so big that the
number of bits does no longer fit into a (signed 32-bit) int; this means
that one must no longer use the parts of the PutBits API that deal with
bit counters. Yet proresenc_kostya did it, namely for a check about
whether we are already beyond the end. Yet this check is unnecessary
nowadays, because the PutBits API comes with automatic checks (with
a log message and a av_assert2() in put_bits() and an av_assert0() in
flush_put_bits()), so this is unnecessary. So simply remove the check.
Fixes ticket #9173.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Calling av_frame_make_writable() from decoders is tricky, especially
when frame threading is used. It is much simpler and safer to just make
a private copy of the frame.
This is not expected to have a major performance impact, since
APNG_DISPOSE_OP_BACKGROUND is not used often and
av_frame_make_writable() would typically make a copy anyway.
Found-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 32968/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSP2_fuzzer-5315296027082752
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The (deprecated) field AVCodecContext.mpeg_quant has no range
restriction; MpegEncContext.mpeg_quant is restricted to 0..1.
If the former is set, the latter is overwritten with it without
checking the range. This can trigger an av_assert2() with the MPEG-4
encoder when writing said field.
Fix this by just setting MpegEncContext.mpeg_quant to 1 if
AVCodecContext.mpeg_quant is set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The pix_fmts of the LJPEG encoder already contain all supported pixel
formats (including the ones only supported when strictness is unofficial
or less); yet the check in ff_encode_preinit() ignored this list in case
strictness is unofficial or less. But the encoder presumed that it is
always applied and blacklists some of the entries in pix_fmts when
strictness is > unofficial. The result is that if one uses an entry not
on that list and sets strictness to unofficial, said entry passes both
checks and this can lead to segfaults lateron (e.g. when using gray).
Fix this by removing the exception for LJPEG in ff_encode_preinit().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
