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>
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>
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>
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 (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>
Several encoders used code like the following to check for the amount of
bytes left in a PutBitContext:
pb->buf_end - pb->buf - (put_bits_count(pb) >> 3)
Besides the fact that using the pointers directly might pose
a maintainence burden in the future this also leads to suboptimal code:
The above code reads all three pointers (buf, buf_ptr and buf_end), but
touching buf is unnecessary and switching to put_bytes_left()
automatically fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is a prerequisite for making any encoder that uses
ff_mpv_encode_init() init-threadsafe; it already makes the AMV,
the MJPEG and the MPEG-1/2 encoders init-threadsafe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The usage of a static variable presents a potential for data races and
means that this function can't be used in init functions of codecs with
FF_CODEC_CAP_INIT_THREADSAFE (unless of course one presumes that
everything is alright in which case the error is not triggered; but then
the whole function is pointless...). This makes the Snow decoder
init-threadsafe as it already claims.
Notice that this function has been removed in 2014 by Libav in commit
9103185bd1, because only some codepaths
are checked this way and because it only affects legacy compilers. The
latter is of course even more true today.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes issue reported by: Xu Guangxin <guangxin.xu@intel.com>
Original report:
Steps to reproduce:
1. ./configure --enable-debug=3 --disable-libx264 && make install
2. ffmpeg -i input.mp4 -profile:v baseline output.mp4 -y
you will see a crash like this:
[mpeg4 @ 0x5555575854c0] [Eval @ 0x7fffffffbf80] Undefined constant or missing '(' in 'baseline'
[mpeg4 @ 0x5555575854c0] Unable to parse option value "baseline"
[mpeg4 @ 0x5555575854c0] Error setting option profile to value baseline.
Thread 1 "ffmpeg" received signal SIGSEGV, Segmentation fault.
root cause:
If the codec has FF_CODEC_CAP_INIT_CLEANUP flag, and avcodec_open2 got an error before avctx->codec->init,
the ff_mpv_encode_end will face a null s->avctx.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
flush_put_bits() already fills the bitstream with zeroes, so it is
unnecessary to align the bitstream before.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
then ff_mpv_encode_end() will be unnecessary in ff_mpv_encode_init()
if it's failed.
The FF_CODEC_CAP_INIT_CLEANUP flag is need for single thread, For multithread,
it'll be cleanup still by AV_CODEC_CAP_FRAME_THREADS flag if have.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
as well as includes of libavutil/timer.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This option allows more control over the use of intra macroblocks in
predictive frames.
By using '-intra_penalty max', intra macroblocks are never used in
predictive frames.
It is useful for glitch artists to generate input material. This option
allows them to split and merge two video files while maintaining fluid
motion from the second video without having intra macroblocks restoring
chunks of the first video.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Andreas Rheinhardt
Andreas Rheinhardt
James Almer
Anton Khirnov
Gyan Doshi
Jean-Baptiste Kempf
Michael Niedermayer
Steinar H. Gunderson
Limin Wang
Ramiro Polla
Steven Liu
Rostislav Pehlivanov
Muhammad Faiz
Carl Eugen Hoyos
Stefano Sabatini
Vittorio Giovara