These fields are only ever set by the encoder for the current picture
and for no other picture. So only one set of these values needs to
exist, so move them to MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These tables are only used by encoders and only for the current picture;
ergo they need not be put into the picture at all, but rather into
the encoder's context. They also don't need to be refcounted,
because there is only one owner.
In contrast to this, the earlier code refcounts them which
incurs unnecessary overhead. These references are not unreferenced
in ff_mpeg_unref_picture() (they are kept in order to have something
like a buffer pool), so that several buffers are kept at the same
time, although only one is needed, thereby wasting memory.
The code also propagates references to other pictures not part of
the pictures array (namely the copy of the current/next/last picture
in the MpegEncContext which get references of their own). These
references are not unreferenced in ff_mpeg_unref_picture() (the
buffers are probably kept in order to have something like a pool),
yet if the current picture is a B-frame, it gets unreferenced
at the end of ff_mpv_encode_picture() and its slot in the picture
array will therefore be reused the next time; but the copy of the
current picture also still has its references and therefore
these buffers will be made duplicated in order to make them writable
in the next call to ff_mpv_encode_picture(). This is of course
unnecessary.
Finally, ff_find_unused_picture() is supposed to just return
any unused picture and the code is supposed to work with it;
yet for the vsynth*-mpeg4-adap tests the result depends upon
the content of these buffers; given that this patchset
changes the content of these buffers (the initial content is now
the state of these buffers after encoding the last frame;
before this patch the buffers used came from the last picture
that occupied the same slot in the picture array) their ref-files
needed to be changed. This points to a bug somewhere (if one removes
the initialization, one gets uninitialized reads in
adaptive_quantization in ratecontrol.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also constify the corresponding code in mpegvideo.c that handles
lowres.
(Unfortunately, not everything that is const could be constified:
ref_picture could be made const uint8_t* const* if C allowed the
safe automatic conversion from uint8_t**; and pix_op, qpix_op
could be made to point to const function pointers, but C's handling
of const in pointers to arrays is broken.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible for most of the callers, because e.g. only
the MPEG-4 decoder can have bits_per_raw_sample > 8.
Also most mpegvideo-based codecs are 420 only.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit removes the ineffective FF_MPV_DEPRECATED_ options,
namely mpeg_quant (this is only an option for MPEG-4), a53cc
(this is only an option for MPEG-2), force_duplicated_matrix
(applies only to MJPEG) and b_strategy, b_sensitivity and brd_scale
(these options only make sense for encoders supporting B-frames,
which currently means the MPEG-1/2 and MPEG-4 encoders).
Given that these options never changed the outcome of encoding,
they are removed at once.
Notice that the options for the encoders for which it made sense
are not affected by this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is currently a "Picture", an mpegvideo-specific type
that has a lot of baggage, all of which is unnecessary
for new_picture, because only its embedded AVFrame
is ever used. So just use an ordinary AVFrame.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MpegEncContext is used by many different codecs and
every one of these uses just a subset of its fields.
If one tries to separate this and e.g. add a real MpegContext
and extension structures (say MpegDecContext and MpegEncContext),
one runs into two difficulties:
a) Some code is shared between decoder and encoder of
the same format and they therefore use the same contexts,
either MpegEncContext itself or identical extensions thereof.
The latter is the case for H.261 as well as WMV2.
b) In case of slice threading, the generic code can only allocate
and initialize the structure it knows about; right now this is
an MpegEncContext. If the codec has an even more extensive structure,
it is only available for the main thread's MpegEncContext.
Fixing this would involve making ff_mpv_common_init() aware
of the size the size of slice context to allocate and would be
part of separating the main thread's context from the slice contexts
in general.
This commit only intends to tackle the first issue by adding
a pointer to MpegEncContext that codecs can set to a common
context so that the aforementioned codecs can use this context
(together with the MpegEncContext) in their common code.
This will allow to move fields only used by the main thread
to more specialized contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An offset has the advantage of not needing to be updated
when the buffer is reallocated. Furthermore, the way the pointer
is currently updated is undefined behaviour in case the pointer
is not already set (i.e. when not encoding MPEG-1/2), because
it calculates the nonsense NULL - s->pb.buf.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that dealing with the Simple Studio Profile
has been moved to mpeg4videodec.c. It also allows to avoid
allocations, because one can simply put the required buffers
on the context (if one made these buffers part of MpegEncContext,
the memory would be wasted for every codec other than MPEG-4).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The a53_cc option is only useful and meaningful for MPEG-2,
yet it was accidentally added for all mpegvideo-based encoders.
This means that it is possible for a53_cc to be set for other
encoders as well.
This commit changes this and reroutes a53_cc to the dummy field
in MpegEncContext for all codecs for which it is not supported.
This allows to avoid a check for the current codec in mpeg12enc.c.
Also add a compile-time check for whether the MPEG-2 encoder is
available while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that MJpegContext is allocated jointly
with MpegEncContext as part of the AVCodecContext's private data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is supported only by a few decoders (h263, h263p, mpeg(1|2|)video
and mpeg4) and is entirely redundant with parsers. Furthermore, using
it leads to missing frames, as flushing the decoder at the end does not
work properly.
Co-authored-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The child_class_next API relied on different AVCodecs to use
different AVClasses; yet this API has been replaced by
child_class_iterate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Deprecated in commits 7fc329e2dd
and 31f6a4b4b8.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.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>
Modifying static storage must not happen because of multithreading
(except initialization of course), so add const to the pointed-to type
for pointers that point to static storage.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These two are always called directly after each other (with the
exception of the calls in mpeg_decode_init() where some irrelevant
modifications of the avctx (which could just as well be done before
ff_mpv_decode_defaults(), because it doesn't have a pointer to the
AVCodecContext at all and therefore can't see these modifications at
all) are performed in between), so merge ff_mpv_decode_defaults() in
ff_mpv_decode_init().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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
Anton Khirnov
Andreas Rheinhardt
Jean-Baptiste Kempf
Ramiro Polla
Mathieu Duponchelle