Several decoders disable those anyway and they are not measurably faster
on x86. They might be somewhat faster on other platforms due to missing
emu edge SIMD, but the gain is not large enough (and those decoders
relevant enough) to justify the added complexity.
Allow supporting files for which the image stride is smaller than
the maximum block size + number of subpel mc taps, e.g. a 64x64 VP9
file or a 16x16 VP8 file with -fflags +emu_edge.
This makes sure that linesize * start_y doesn't overflow, so that
emulated_edge_mc can get back the original value if needed.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Move some functions from dsputil. The idea is that videodsp contains
functions that are useful for a large and varied set of video decoders.
Currently, it contains emulated_edge_mc() and prefetch().
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
These arguments are either constants or copies of MpegEncContext
fields just as easily accessed within the function.
Signed-off-by: Mans Rullgard <mans@mansr.com>
These functions do not benefit from being inlined. They are large,
and there are no opportunities for constant propagation.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The main benefit of inlining this function is from constant
propagation for the 'field_based' argument. Instead of inlining
all calls, create two versions of the function for field_based
values of 0 and 1.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This file defines a single, huge function, MPV_motion(), which
although being declared inline is not actually inlined by the
compiler (for good reason). There is thus no sense in defining
this function in a header file, resulting in multiple copies of
it in the final library.
Signed-off-by: Mans Rullgard <mans@mansr.com>
