Put it into SnowEncContext instead. Also use the proper type
(it is only used as IDWTELEM aka short).
(The allocation code allocated it in units of uint32_t,
yet it was never used in this way. I made the array so big
that the size (in bytes) does not change.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They have a fixed size and given that nowadays
MotionEstContext is no longer in any decoder's private context,
it is not wasteful to just put it into there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
encode_thread() puts two MPVEncContexts (2*6516B here)
on the stack and zeroes one of them in order to
temporarily store the variables that get changed
during encoding a macroblock (when there is more than
one candidate type for a macroblock). This is wasteful
and therefore this commit adds a small (328B here) structure
to store exactly the fields that actually need to be backed
up. Then one can extend MPVEncContext without fearing
too use up to much stack.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this instead of exporting raw_pix_fmt_tags
via avpriv_get_raw_pix_fmt_tags().
For shared builds this will lead to an increase in the
combined size of the lavc and fourcc2pixfmt binaries
(because the overhead of exporting avpriv_get_raw_pix_fmt_tags()
is dwarfed by the size of the array), but given that
fourcc2pixfmt is a test tool that is not widely distributed
it does not really matter. For static builds the opposite
is true (the rest of lavc/raw.o is no longer pulled into
the test tool and the getter can be removed, too).
This patch has the additional benefit of removing
struct PixelFormatTag from the ABI.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not worth the overhead of exporting it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This is possible without deprecation period, because said field
is documented as only for our libav* libraries and not the general
public.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
Fixes a regression caused by my desire to use loop-scope
for iterators in 72bf3d3c12.
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>
