There is a special case I missed, its simpler to just store
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We need to allocate space for 64 coefficients per block;
24dbc4c2e8 wanted to
perform the calculation 64*sizeof(MJpegHuffmanCode)
at compile time, yet in the end did it in a way that
made it allocate 64 times as much memory as needed.
Reported-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The kVTVideoDecoderReferenceMissingErr constant was only added
in the macOS 12 and iOS 15 SDKs. Use a hardcoded value instead
of the named constant, to fix building with older SDKs
after c6214b0d69.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
block_last_index and nCoeffs is an optimization designed
to avoid processing unnecessarily many coefficients; yet
it would be legal to always process all coefficients
(all coefficients beyond nCoeffs are zero anyway and
zeros are always unquantized to zeros). Therefore
one does not need a scalar tail.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't do it depending upon dct_algo, as this is not supposed
to influence the unquantize function selection.
(This check originated in 05c4072b45
where it was used for the dct_quantize function only.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This affected the WMV1/2 encoders (but not when running FATE because
the encoding part uses the fastint dct, so this code isn't used
then anyway).
It did not affect anything else, because a) only WMV1/2 use different
scantables, b) ff_msmpeg4_decode_block() (and therefore the WMV1
decoder) already unquantize inter macroblocks as they are parsed
c) the WMV2 decoder does not use the unquantize functions for inter
macroblocks at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for only keeping the actually used
unquantize functions in MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use spell out what me_cmp_func means.
Avoids inclusions in the H.264 decoder as well as all
mpegvideo decoders.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only set them after mb_x and mb_y are known which happens
only after the call to ff_h261_reorder_mb_index().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reset them in ff_me_init_pic(). It is the appropriate place for it
and allows to remove resetting code from multiple places
(e.g. mpegvideo_enc.c resetted it in two different places
(one for the main slice context, one for all the others)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
