Said block will only be referenced by blocks from the same macroblock,
which will read the new AC values instead of the reset values
from this function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The underlying element type has always a size of 32B,
so that the pointer is always at least 16B aligned.
Clang uses this to upgrade the (inlined) memset to
aligned stores. GCC doesn't (it does it only when
the alignment hint is provided via __builtin_assume_aligned).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are already mostly unused; not using them here is in
preparation for removing them altogether. Use block_index[4..5]
instead for addressing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All callers check the corresponding entry of MpegEncContext.mbintra_table
and if set (indicating that the intra tables might have been written to
when decodeing a intra MB, so that they are "dirty"), call
ff_clean_intra_table_entries(), which resets them to default values
and resets the mbintra_table entry. Move resetting to the callers
(via an inline function that also performs the checks). This currently
has the advantage that the additional load of the mbintra_table ptr
can be avoided. It will also allow to simplify
ff_clean_intra_table_entries() (by using block_index[4] and [5]).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Allocate them before the slice contexts, so that they are automatically
copied to the slice contexts. This avoids having to set them in a loop.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will allow to perform initializations between ff_mpv_common_init()
and ff_mpv_init_duplicate_contexts() that will be automatically
copied to the slice contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The motion estimation code only uses block_index[0..3],
so only initialize that (just like estimate_motion_thread()
in mpegvideo_enc.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not really needed, as none of the buffers allocated
in ff_mpv_common_init() are used lateron; in fact, ff_mpv_common_init()
is called with MpegEncContext.width and height equal to zero
(as well as encoding equal to zero, so that the error resilience
parts are initialized...), so that all the buffers are too small
anyway.
The call to ff_mpv_common_init() has been added in commit
f6774f905f in order to allocate
{current,last,new}_picture.f (an AVFrame). Yet this is unnecessary
since 7814dd77aa.
The only task that ff_mpv_common_init() does that may be used
is initializing the HpelDSPContext embedded in the MpegEncContext.
In fact, it was not initialized before
f6774f905f and not initializing
it passes FATE, yet I can't prove that it is indeed unnecessary.
Therefore it is still initialized and used instead of
SVQ1EncContext.hdsp.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 65015003f5c4b83a8202abfa7420ccf37cde6ce3;
after said commit, freeing scratchbuf on error in svq1_encode_frame()
could lead to segfaults lateron, because the buffer will not
be allocated again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the MPEG-1/2 decoders unquantize the blocks
on their own, block_last_index is only used to signal
to ff_mpv_reconstruct_mb() whether a block is skipped
or not; but this is only checked for inter macroblocks,
so it is unnecessary to set block_last_index for intra
macroblocks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Overriding the number of coefficients is only necessary if
ac_pred is in used, not for h263_aic alone (for which only
the DC coefficient is predicted) as it is done here.
And since d50635cd24
the H.263 unquantize-intra functions override the number of
coefficients in case of ac_pred, so we don't have to do this here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.
This caused configure to hang for some configurations and by
extension some FATE clients. You might want to check if you run
affected configurations automated in FATE clients or similar setups.
Fixes: 45a30e0361
Signed-off-by: Martin Storsjö <martin@martin.st>
This should prevent the possibility of audio data accumulating.
The commit also cleans up and simplifies the code a bit so all frame producers
(filter_frame(), flush_frame()) functions follow similar logic as
ff_inlink_consume_frame() for the return code.
Signed-off-by: Marton Balint <cus@passwd.hu>
Easier to read, less convoluted, and ~30% faster. Most importantly, this
avoids repeating the redundant recalculation of the true peak on every
single sample, by moving the FIND_PEAK() loop out of the main loop. (Note
that FIND_PEAK() does not depend on the current sample index at all, so
there is no reason for it to ever be recomputed here)
Processes two channels in parallel, using 128-bit XMM registers.
In theory, we could go up to YMM registers to process 4 channels, but this is
not a gain except for relatively high channel counts (e.g. 7.1), and also
complicates the sample load/store operations considerably.
I decided to only add an AVX variant, since the C code is not substantially
slower enough to justify a separate function just for ancient CPUs.
