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>
There are two types of MPVPictures: Three (cur_pic, last_pic, next_pic)
that are directly part of MpegEncContext and an array of MPVPictures
that are separately allocated and are mostly accessed via pointers
(cur|last|next)_pic_ptr; they are also used to store AVFrames in the
encoder (necessary due to B-frames). As the name implies, each of the
former is directly associated with one of the _ptr pointers:
They actually share the same underlying buffers, but the ones
that are part of the context can have their data pointers offset
and their linesize doubled for field pictures.
Up until now, each of these had their own references; in particular,
there was an underlying av_frame_ref() to sync cur_pic and cur_pic_ptr
etc. This is wasteful.
This commit changes this relationship: cur_pic, last_pic and next_pic
now become MPVWorkPictures; this structure does not have an AVFrame
at all any more, but only the cached values of data and linesize.
It also contains a pointer to the corresponding MPVPicture, establishing
a more natural relationsship between the two.
This already means that creating the context-pictures from the pointers
can no longer fail.
What has not been changed is the fact that the MPVPicture* pointers
are not ownership pointers and that the MPVPictures are part of an
array of MPVPictures that is owned by a single AVCodecContext.
Doing so will be done in a latter commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Specifically, add const to the pointed-to-type of pointers
that point to something static or that belong to last_pic
or next_pic (because modifying these might lead to data races).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
current_picture->cur_pic, last_picture->last_pic, similarly
for new_picture and next_picture.
Also rename the corresponding *_ptr fields.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Therefore use a proper prefix for this API, e.g.
ff_init_vlc_sparse -> ff_vlc_init_sparse
ff_free_vlc -> ff_vlc_free
INIT_VLC_LE -> VLC_INIT_LE
INIT_VLC_USE_NEW_STATIC -> VLC_INIT_USE_STATIC
(The ancient INIT_VLC_USE_STATIC has been removed
in 595324e143, so that
the NEW has been dropped.)
Finally, reorder the flags and change their values
accordingly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
For the intra_[hv]_scantables, only ScanTable.permutated
is used, so one only needs to keep that.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
This automatically makes the FLV, H.263, H.263+, Intel H.263,
MPEG-4, RealVideo 1.0 and RealVideo 2.0 decoders init-threadsafe.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case it means moving ff_h263_pred_dc() resp. ff_h263_pred_acdc()
to ituh263enc.c resp. ituh263dec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, ff_h263_rl_inter was initialized by both ituh263dec and
ituh263enc; this is an obstacle in making the codecs that use this code
init-threadsafe.
This obstacle is eliminated by only initializing this RLTable from
a single place that is guarded by a dedicated AVOnce.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RLTable ff_rl_intra_aic is only used by ituh263dec and ituh263enc;
the former only uses the RLTable's VLC, the latter only index_run,
max_level and max_run. Yet ituh263dec also initializes the latter.
This commit stops doing so.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
msmpeg4dec and ituh263dec both create VLCs with identical parameters out
of ff_mvtab. Given that ff_msmpeg4_decode_init() always (indirectly) calls
ff_h263_decode_init_vlc(), the VLC initialized by the latter can be
directly used by msmpeg4dec. Doing so saves a bit more than 2KB from the
.bss segment as well as the code to initialize a VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ff_rl_intra_aic RLTable is only used by ituh263dec and ituh263enc;
the former is the only user of its RL VLC tables. It uses only the very
first one of these VLC tables, but up until now all 32 are initialized,
wasting 68696B from the .bss segment (or that amount of memory if this
decoder has actually been used). This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RealVideo 1.0 decoder uses VLCs to parse DC coefficients. But the
values returned from get_vlc2() are not directly used; instead
-(val - 128) (which is in the range -127..128) is. This transformation
is unnecessary as it can effectively be done when initializing the VLC
by modifying the symbols table used. There is just one minor
complication: The chroma table is incomplete and in order to distinguish
an error from get_vlc2() (due to an invalid code) the ordinary return
range is modified to 0..255. This is possible because the only caller of
this function is (on success) only interested in the return value modulo
256.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If they mismatch an infinite loop can occur
Fixes: Timeout (infinite loop)
Fixes: 17043/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5695051748868096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This matches ff_h263_decode_motion() both functions error codes are interpreted by the same common code
Fixes: 690/clusterfuzz-testcase-4744944981901312
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes invalid shift
Fixes: 670/clusterfuzz-testcase-4852021066727424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 659/clusterfuzz-testcase-5866673603084288
Huge DMV could be created by an encoder ignoring the spec
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: u263_b-frames_1.avi
Fixes part of Ticket1536
return -1 is used here as it is used in similar code in this function, I intend
to replace it by proper error codes in the whole function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>