This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Only select the Alpha IDCT if auto or explicitly requested. Also
disable it in lowres mode.
Originally committed as revision 16666 to svn://svn.ffmpeg.org/ffmpeg/trunk
include paths in the source files.
mostly from a patch by Ronald S. Bultje, rbultje ronald.bitfreak net
Originally committed as revision 9034 to svn://svn.ffmpeg.org/ffmpeg/trunk
interlaced mpeg2 encoding
P & B frames
rate distored interlaced mb decission
alternate scantable support
4mv encoding fixes (thats also why the regression tests change)
passing height to most dsp functions
interlaced mpeg4 encoding (no direct mode MBs yet)
various related cleanups
disabled old motion estimaton algorithms (log, full, ...) they will either be fixed or removed
Originally committed as revision 2638 to svn://svn.ffmpeg.org/ffmpeg/trunk
Rullgård <mru@users.sourceforge.net>.
I've left out the idctCol2 part, because W4 has recently been decreed
to be 16383, and also I doubt it will give a noticeable speedup.
Originally committed as revision 1029 to svn://svn.ffmpeg.org/ffmpeg/trunk
takes the most time, and it allows for more efficient unaligned access
and better control over memory latencies.
Originally committed as revision 711 to svn://svn.ffmpeg.org/ffmpeg/trunk
allows better scheduling of the memory accesses, and is portable among
all compilers.
Originally committed as revision 709 to svn://svn.ffmpeg.org/ffmpeg/trunk