The no-output mode (guarded by AV_CODEC_FLAG2_NO_OUTPUT)
does not provide a noteworthy speedup; in fact, it even
turned out to be slower than the code with the no-output
code removed (ordinary encode: 153259721 decicycles,
noout encode: 153259721; encode with this patch applied:
152451581 decicycles; timings are for encode_frame callbacks
when encoding a 1080p sample to MPEG-4).
(Furthermore, this code was broken for most of its existence
(since 9207dc3b0db368bb9cf5eb295cbc1129c2975e31) and no one
noticed, so the no-output mode is probably not used at all.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code had two problems:
1. For reference frames that are not directly output (happens unless
low_delay is set), the mb skip values referred to the next reference
frame to be decoded.
2. For non-reference frames, every macroblock was always considered
skipped.
This makes the output (worse than) useless; that no one ever
complained about this shows that this feature is not really used.
It is therefore removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not a stream property, but a property of an individual picture
(in fact, it is only set by the FLV decoder that does not even support
frame threading).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is always allocated in ff_mpv_frame_start(), so the only
reason to put it into ff_mpeg_update_thread_context()
would be for the case that a frame-threaded decoder
that supports coded fields implements frame-threading.
The only mpegvideo-decoders supporting coded fields
are MPEG-1/2 and VC-1. The latter's bitstream requires
both coded fields to be part of the same access unit/packet,
so that every frame thread will always call ff_mpv_frame_start()
itself. The former only "need" the framesize buffers when
using lowres. If MPEG-1/2 gains frame-threading, one could either
perform framesize allocation in its update_thread_context
or when starting a field.
(Given that the next packet may trigger a reinitialization
due to a frame size change, it was possible for the buffers
that were allocated here to be thrown away unused.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to use a temporary buffer as destination
for the new macroblock before copying it into its proper place.
(Originally, this has been added in commit
b68ab2609c due to concerns about
copying from GPU memory.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Broken in 5ecf5b93dd.
More precisely, 3994623df2 changed
the precursor of ff_mpv_reconstruct_mb() to always decode
to the first row of macroblocks for B pictures when
a draw_horiz_band callback is set and to (they are exported to
the caller via said callback and each row overwrites the previously
decoded row; this was probably intended as a cache-optimization).
This first macroblock row was used as source for the draw_horiz_band
callback.
This of course means that the ordinary output B-frame was not
decoded correctly at all. Therefore the first aforementioned commit
removed this special handling of draw_horiz_band; yet it did not
remove the special handling for B-frames in ff_draw_horiz_band(),
which broke draw_horiz_band for B-frames. This commit fixes this.
(Actually, draw_horiz_band was already broken before
5ecf5b93dd when using slice-threading:
All slice-threads would write to the first row of macroblocks
for B-frames, leading to data races. It seems no one has ever complained
about this, just as no one has ever complained about the breakage
caused by 5ecf5b93dd. Probably no one
uses draw_horiz_band.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Calling it is the first thing ff_clean_h263_qscales() and
ff_clean_mpeg4_qscales() do anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A MECmpContext is quite big (792B here) and given
how ff_update_duplicate_context() works, it is (unfortunately)
copied quite frequently when using slice threading.
Therefore keep only what is needed from MECmpContext
and remove MECmpContext from MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not every function will be set, so zero the context
to initialize everything.
This also allows to remove an initialization in dvenc.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids using MpegEncContext.mecc; it already allows
to avoid touching the latter for snowenc and svq1enc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several of the potential choices of comparison functions
need an initialized MpegEncContext (initialized for encoding,
not only ff_mpv_common_init()) or they crash when called.
Modify ff_set_cmp() to check for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MECmpContext.ildct_cmp is an array of function pointers that
are not set by ff_me_cmp_init(), but that are set by users
to one of the other arrays via ff_set_cmp().
Remove these pointers from MECmpContext and add pointers
for the actually used functions to its users. (The DV encoder
already did so.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MECmpContext has several arrays of function pointers that
are not set by ff_me_cmp_init(), but that are set by users
to one of the other arrays via ff_set_cmp().
One of these other users is mpegvideo_enc; it is the only user
of MECmpContext.frame_skip_cmp and it only uses one of these
function pointers at all.
This commit therefore moves this function pointer to MpegEncContext;
and removes the array from MECmpContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MECmpContext has several arrays of function pointers that
are not set by ff_me_cmp_init(), but that are set by users
to one of the other arrays via ff_set_cmp().
One of these other users is the motion estimation API.
It uses MECmpContext.(me_pre|me|me_sub|mb)_cmp. It is
basically the only user of these arrays.
This commit therefore moves these arrays to MotionEstContext;
this has the additional advantage of making motion_est.c
more independent from MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The majority of the stuff performed in it needs to be done only
once; so factor it out into a function of its own to be called
in the user's init function.
Also avoid using MpegEncContext in it, to separate the two
a bit more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not all compare functions are implemented for all compare function
types. Therefore check for the existence of the used functions.
Fixes issue #10245.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible by using MB_TYPE_CODEC_SPECIFIC for MB_TYPE_ZERO_MV
and due to the MB_TYPE_*_MV flags fitting into an int16_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible now that MB_TYPE_L1 (which does not fit into
an int16_t) is no longer used).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_L[01] is based upon H.264 terminology (it stands for
list); yet the mpegvideo based decoders don't have lists
of reference frames, they have at most one forward and one
backward reference. So use terminology based upon this.
This also has a second advantage: MB_TYPE_L[01] is actually
an OR of two flags (which are set independently for H.264,
but aren't for mpegvideo). Switching to different flags
makes the flags fit into an int16_t, which will be useful
in future commits.
The only downside to this is a very small amount of code
in error_resilience.c and mpegutils.c (the only code shared
between the H.264 decoder and mpegvideo).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The "invalid mtype index" here is always -1, because that is
the value the VLC api uses for not existent leafs in an incomplete tree.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that MB_TYPE_CBP and MB_TYPE_QUANT
fit into an int16_t; only MB_TYPE_H261_FIL needs to
be remapped to MB_TYPE_CODEC_SPECIFIC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this to make MB_TYPE_{CBP,QUANT} fit into an int16_t,
so that can be used in a VLC symbol table.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_ACPRED is currently reused for MB_TYPE_REF0 by H.264,
so that the value fits into an uint16_t. Given that MB_TYPE_ACPRED
is not subject to any such restriction (apart from fitting into
32bits), it can be remapped to a hithereto unused bit.
The then available bit will be declared to be codec-specific
(i.e. unused by generic code), so that H.264 can use it
for MB_TYPE_REF0 and so that it can be reused later for
e.g. MB_TYPE_H261_FIL.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Set them in ff_mpv_idct_init() so that they are already set
in ff_mpv_decode_init(). This is in preparation for avoiding
to set dct_unquantize in every ff_mpv_frame_start().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Video devices categorized by AVFoundation as
'AVCaptureDeviceTypeExternal(Unknown)' (like USB video streams) were not
recognized by libavdevice.
Signed-off-by: Theo Fabi <fabi.theo@gmail.com>
When the SPS associated with a particular SPS ID changes, invalidate all
the PPSs which use that SPS ID. Fixes crashes with illegal bitstreams.
This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
ID reuse validation, as parts of the CBS parsing process for PPSs
depend on the SPS being referred to.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Before After
-------------------------------------------------
make fate-vvc CPU Time (No ASM) 131.52s 134.83s
libavcodec/vvc/* Line Coverage 95.3% 96.9%
inter_template.c Line Coverage 74.3% 88.2%
inter.c Line Coverage 85.3% 99.2%
Signed-off-by: Frank Plowman <post@frankplowman.com>
Fixes: out of array access
Fixes: 68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
