It is no longer necessary: Most encoders don't use any MMX code
at all any more and the ones that do issue emms on their own.
Instead add an ff_asser1_fpu() to check that it stays that way.
To add some more information, only the halfpel (and fullpel),
qpel and motion estimation APIs use MMX in addition to the
SBC and Snow specific dsp code. halfpel is used by the
mpegvideo encoders, SVQ1 and Snow encoders. The same
encoders in addition to the AC-3 ones and dvvideo use me_cmp.
qpel is only used by the MPEG4 encoder which is part of
mpegvideo. None of these codecs need the generic emms_c (even on
errors):
a) The AC-3 encoders only use a width 16 me_cmp function which
can no longer use MMX since d91b1559e0.
b) dvvideo and SBC emit emms on their own and have no error paths
after the start of the part that can use MMX.
c) SVQ1 calls emms_c() on its own, even on all error paths
that need it.
d) Snow calls emms_c() on its ordinary (success) return path;
it has only one error path in the part of the code that uses MMX,
but even it is fine as ratecontrol_1pass() always calls emms_c()
itself.
e) For mpegvideo, the MMX code is almost confined to the part
of the code reachable from the worker threads (if slice threading
is in use). The exception to this is in skip_check() which always
calls emms_c() itself. Because encode_picture() always calls
emms_c() itself after executing the worker threads and before any
error condition, the floating point state is clean upon exit from
encode_picture().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
And rename it to ff_encode_add_stats_side_data() and move its
declaration to encode.h. Also constify the error pointee.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check that all audio codecs except decoders with the
AV_CODEC_CAP_CHANNEL_CONF flag have a positive sample rate set.
Fixes: AVERROR_BUG return
Fixes: 413997604/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-5188382613635072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead, use forward declarations; and in order not to affect
any user include these headers for them, but not internally.
This has the advantage of removing implicit inclusions of these
headers from almost all files providing codecs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Mention encoder name in the message to emphasize that the value in
question is not supported by this specific encoder, not necessarily by
libavcodec in general.
Print a list of values supported by the encoder.
The goal is to distinguish between APIs provided by the generic layer to
individual codecs and APIs internal to the generic layer.
Start by moving ff_{decode,encode}_receive_frame() and
ff_{decode,encode}_preinit() into this new header, as those functions
are called from generic code and should not be visible to individual
codecs.
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
Current code prefers deprecated AVFrame.pkt_duration over its
replacement AVFrame.duration whenever the former is set and not equal to
the latter. However, duration will only be actually used when the
caller sets the AV_CODEC_FLAG_FRAME_DURATION flag, which was added
_after_ AVFrame.duration.
This implies that any caller aware of AV_CODEC_FLAG_FRAME_DURATION is
also aware of AVFrame.duration. pkt_duration should then never be used.
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we use 64 bit
values for them.
Also deprecate the old 32 bit frame_number attribute.
Signed-off-by: Marton Balint <cus@passwd.hu>
This is intended to be a more convenient replacement for
reordered_opaque.
Add support for it in the two encoders that offer
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE: libx264 and libx265. Other
encoders will be supported in future commits.
Some encoders (ffv1, flac, adx) are marked with AV_CODEC_CAP_DELAY onky
in order to be flushed at the end, otherwise they behave as no-delay
encoders.
Add a capability to mark these encoders. Use it for setting pts
generically.
Now that it is ensured that the old and new channel count/layout
values coincide if the old ones are set, the consistency of the
AVChannelLayout (which is checked before we reach this point)
implies the consistency of the old values, making these checks
here dead code. So remove them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Andreas Rheinhardt
Piotr Pawlowski
Niklas Haas
James Almer
Marton Balint
Michael Niedermayer
Anton Khirnov
Zhao Zhili