It is the only encoder supporting quarter samples.
This also allows to remove the qpeldsp dependency from
mpegvideo_enc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For encoders, mpeg_quant is an option of the MPEG-4 encoder
and therefore constant. This implies that one can set
the dct_unquantize_(intra|inter) function pointers during init.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This has the advantage of not having to check for whether
a given MpegEncContext is actually a decoder or an encoder
context at runtime.
To do so, mpv_reconstruct_mb_internal() is moved into a new
template file that is included by both mpegvideo_enc.c
and mpegvideo_dec.c; the decoder-only code (mainly lowres)
are also moved to mpegvideo_dec.c. The is_encoder checks are
changed to #if IS_ENCODER in order to avoid having to include
headers for decoder-only functions in mpegvideo_enc.c.
This approach also has the advantage that it is easy to adapt
mpv_reconstruct_mb_internal() to using different structures
for decoders and encoders (e.g. the check for whether
a macroblock should be processed for the encoder or not
uses MpegEncContext elements that make no sense for decoders
and should not be part of their context).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not require anything that is being set between
the new position where it is called and the old position
where it used to be called; and nothing that it sets
gets overwritten between these two positions.
Doing so allows to remove a check lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not require anything that is being set between
the new position where it is called and the old position
where it used to be called; and nothing that it sets
gets overwritten between these two positions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit moves the encoder-only allocations of the tables
owned solely by the main encoder context to mpegvideo_enc.c.
This avoids checks in mpegvideo.c for whether we are dealing
with an encoder; it also improves modularity (if encoders are
disabled, this code will no longer be included in the binary).
And it also avoids having to reset these pointers at the beginning
of ff_mpv_common_init() (in case the dst context is uninitialized,
ff_mpeg_update_thread_context() simply copies the src context
into dst which therefore may contain pointers not owned by it,
but this does not happen for encoders at all).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
The msmpeg4 decoders/encoders share a common set of prerequisites,
ergo it makes sense to use common subsystems for them. This also
allows to remove the CONFIG_MSMPEG4_DECODER/ENCODER ad-hoc defines
(which violated the CONFIG_ namespace).
Reviewed-by: Martin Storsjö <martin@martin.st>
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>
For 422 frames we should not use hard coded 8 to calculate mb size for
uv plane. Chroma shift should be taken into consideration to be
compatiple with different sampling format.
The error is reported by fate test when av_cpu_max_align() return 64
on the platform supporting AVX512. This is a hidden error and it is
exposed after commit 17a59a634c.
mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
squared error) on current mb, reconstructed mb will be wrote to the
previous mb space, so that the memory can be saved. However if the align
is 64, the frame is shared in somewhere else, so the frame cannot be
reused and a new frame to store reconstrued data is created. Because the
height of mb is wrong when compute sse on 422 frame, starting from the
second line of macro block, changed data is read when frame is reused
(we need to read row 16 rather than row 8 if frame is 422), and unchanged
data is read when frame is not reused (a new frame is created so the
original frame will not be changed).
That is why commit 17a59a634c exposes this
issue, because it add av_cpu_max_align() and this function return 64 on
platform supporting AVX512 which lead to creating a frame in mpeg2enc,
and this lead to the different outputs.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This is more spec-compliant because it does not rely
on dead-code elimination by the compiler. Especially
MSVC has problems with this, as can be seen in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
or
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html
This commit does not eliminate every instance where we rely
on dead code elimination: It only tackles branching to
the initialization of arch-specific dsp code, not e.g. all
uses of CONFIG_ and HAVE_ checks. But maybe it is already
enough to compile FFmpeg with MSVC with whole-programm-optimizations
enabled (if one does not disable too many components).
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>
(M)JPEG does not use motion estimation/motion vectors at all.
These options therefore don't affect the output at all.
So remove them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is a remnant of the old way for user-supplied buffers;
it is always-true since 93016f5d1d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If one encodes MJPEG with a single slice and uses input with
AV_FRAME_DATA_ICC_PROFILE side data, the current allocation code
in ff_mpv_encode_picture() will always increase the size of the
temporary buffer used for allocating packets by the size needed
for to write the ICC chunk even when the current buffer is actually
large enough. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MJPEG is the only mpegvideo-based encoder making use of it.
Fixes linking failures in case mpegvideo_enc.c is compiled
with AMV, LJPEG and MJPEG encoders disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is mostly straightforward. The major complication is that, as a
result of the 16-bit chunk size limitation, ICC profiles may need to be
split up into multiple chunks.
We also need to make sure to allocate enough extra space in the packet
to fit the ICC profile, so modify both mpegvideo_enc.c and ljpegenc.c to
take into account this extra overhead, failing cleanly if necessary.
Also add a FATE transcode test to ensure that the ICC profile gets
written (and read) correctly. Note that this ICC profile is smaller than
64 kB, so this doesn't test the APP2 chunk re-arranging code at all.
Signed-off-by: Niklas Haas <git@haasn.dev>
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>
One can use slices without slice-threading. The results for
mpegvideo-encoders are abysmal: AMV, SpeedHQ, H.263, RV10, RV20,
MSMPEG4v2, MSMPEG4v3 and WMV1 produce broken files.
WMV2 meanwhile expects the MpegEncContext given to ff_wmv2_encode_mb()
to be at the beginning of a Wmv2Context (a structure that this encoder
shares with the WMV2 decoder), yet this is only true for the
main context and not for the slice contexts, leading to segfaults.
SpeedHQ additionally triggers an av_assert2, because it is not
byte-aligned at a position where it ought to be byte-aligned.
Given that no codec not supporting slice threading works this commit
disallows using slices unless the encoder supports slice threading.
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>
Seems to have been always unused since these functions were introduced
in 1f0cd30fd9.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mpegvideo-based encoders supporting bframes implement this
by opening encoders of their own to test how long the chains
of bframes are supposed to be. The needed AVCodec was obtained
via avcodec_find_encoder(). This is complicated, as the current
encoder can be directly obtained. And it also is not guaranteed
that one actually gets the current encoder or not another encoder
for the same codec ID (the latter does not seem to be the case now).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
James Almer
Marton Balint
Anton Khirnov
Andreas Rheinhardt
Wenbin Chen
Niklas Haas
Martin Storsjö