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>
mm_support() instead.
Reduce complexity and simplify pending move to libavutil.
Originally committed as revision 25074 to svn://svn.ffmpeg.org/ffmpeg/trunk
This moves the H264-specific functions from DSPContext to the new
H264DSPContext. The code is made conditional on CONFIG_H264DSP
which is set by the codecs requiring it.
The qpel and chroma MC functions are not moved as these are used by
non-h264 code.
Originally committed as revision 22565 to svn://svn.ffmpeg.org/ffmpeg/trunk
These macros are redundant. All uses are replaced with the generic
DECLARE_ALIGNED macro instead.
Originally committed as revision 22233 to svn://svn.ffmpeg.org/ffmpeg/trunk
allowing to re-enable ff_h264_idct_add_altivec's usage.
Patch by David Conrad %lessen42 A gmail P com%
Originally committed as revision 16465 to svn://svn.ffmpeg.org/ffmpeg/trunk
h264_idct_add16intra, h264_idct_add8 need to be implemented.
Add C version of ff_h264_idct8_dc_add in AltiVec so that ff_h264_idct8_add_altivec
can be used.
Originally committed as revision 16311 to svn://svn.ffmpeg.org/ffmpeg/trunk
The original problem was that FSF and Apple gcc used a different syntax
for vector declarations, i.e. {} vs. (). Nowadays Apple gcc versions support
the standard {} syntax and versions that support {} are available on all
relevant Mac OS X versions. Thus the greater compatibility is no longer
worth cluttering the code with macros.
Originally committed as revision 14366 to svn://svn.ffmpeg.org/ffmpeg/trunk
This includes indentation changes, comment reformatting, consistent brace
placement and some prettyprinting.
Originally committed as revision 14316 to svn://svn.ffmpeg.org/ffmpeg/trunk
ppc/h264_altivec.c: In function ‘put_h264_qpel16_mc00_altivec’:
ppc/h264_altivec.c:394: warning: implicit declaration of function ‘put_pixels16_altivec’
ppc/h264_altivec.c: In function ‘avg_h264_qpel16_mc00_altivec’:
ppc/h264_altivec.c:395: warning: implicit declaration of function ‘avg_pixels16_altivec’
ppc/h264_altivec.c: In function ‘dsputil_h264_init_ppc’:
ppc/h264_altivec.c:872: warning: implicit declaration of function ‘has_altivec’
Originally committed as revision 11330 to svn://svn.ffmpeg.org/ffmpeg/trunk
part 1 of h264 luma interpolation 8x8 for altivec contributed by
Mauricio Alvarez % lokifo A gmail P com %
Original thread:
Date: Jun 26, 2007 8:15 PM
Subject: Re: [FFmpeg-devel] [PATCH] h264 luma interpolation 8x8 for altivec
Originally committed as revision 10090 to svn://svn.ffmpeg.org/ffmpeg/trunk
In h264_deblock_q1, the result of the deblock needs to be kept to
be used in future deblocks, so return this value now.
Also change the sign of tc0 vector: It is really a signed value, so
treat it as such until after the >=0 check;
then, at that point, after being masked, it can be treated as unsigned.
Patch by Graham Booker % gbooker A tamu P edu%
Originally committed as revision 9349 to svn://svn.ffmpeg.org/ffmpeg/trunk
all 255s, and then doing the subtraction, nor of the vector with itself: saves
one instruction and a register.
Patch by Graham Booker % gbooker A tamu P edu%
Originally committed as revision 9340 to svn://svn.ffmpeg.org/ffmpeg/trunk
( http://www.pennfans.net/files/videos/Penn&Teller.on.The.View.mp4 )
with current Altivec implementation of loopfilter, while others are fine.
Let's disable it until we iron this bug out.
Originally committed as revision 9317 to svn://svn.ffmpeg.org/ffmpeg/trunk
