This is in preparation for moving the fields only used
by H.263-based decoders from MPVContext to H263DecContext.
For now only the decode_mb function pointer has been moved
(to be able to switch said callback to use an H263DecContext*).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code in h263dec.c is not supposed to know that the MPEG-4
decoder uses an Mpeg4DecContext as private context at all
(said context is only exposed in a header so that hardware
accelerations can access it and for the parser to use).
Passing an MPVContext* directly also allows to remove
the indirection via AVCodecContext.priv_data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just ensure that dct_unquantize_inter is set iff it is used
and check for the function pointer instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the MPEG-4 decoder and the encoders.
Notice that this field is a per-frame property and therefore
does not need to by synced in mpeg4_update_thread_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When switching to the XviD IDCT, the IDCT permutation can change.
Given that we already permute the quant matrices when parsing
them, they need to be permuted, too. Up until now this has not been
done; instead the header has been parsed again in the expectation
that the currently active quant matrix is contained in this header.
This expectation is wrong; it is for example wrong when the VOL
header is only available via extradata (such a file can be easily
created from xvid_vlc_trac7411.h263 (in the FATE suite) via the
remove_extra BSF). It could also be wrong if the XviD user data
is only available in a subsequent packet.
This commit therefore switches to permuting the relevant matrices
directly. It also stops parsing the header a second time
when switching to the XviD IDCT.
(I wonder whether ff_mpv_idct_init() should take alternate_scan
into account when initializing permutated_intra_h_scantable
as the decoder does. Does the MPEG-4 encoder use a wrong scantable
in this case?)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For all encoders and all decoders except MPEG-4 the unquantize
functions to use don't change at all and therefore needn't be
kept in the context. So discard them after setting them;
for MPEG-4, the functions get assigned on a per-frame basis.
Decoders not using any unquantize functions (H.261, MPEG-1/2)
as well as decoders that only call ff_mpv_reconstruct_mb()
through error resilience (RV30/40, the VC-1 family) don't have
the remaining pointers set at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the packet is reference-counted
and because we never combine the data from several packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible by moving the code using it to open a GetBitContext
from h263dec.c to mpeg4videodec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is an MPEG-4-only value; it is always five for the MPEG-4
encoder, so just hardcode this value and move the MpegEncContext
field to Mpeg4DecContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is accessed via AV_RN64A in ff_simple_idct_put_int32_10bit().
Should fix the UBSan failures in the mpeg4-simple-studio-profile
test here:
https://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by gmc/gmc1 which is only used by the MPEG-4
decoder, so move it to Mpeg4DecContext and rename it
to Mpeg4VideoDSP. Also compile it iff the MPEG-4 decoder is compiled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
