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
(there's still 2 more, but there's burried into several levels of macros, so it's hard to narrow them down)
Originally committed as revision 9265 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Graham Booker % perian A cod3r P com% with some minor fixes by me.
historic of the patch: http://trac.perian.org/ticket/113
Original thread:
Date: May 11, 2007 9:45 PM
Subject: [FFmpeg-devel] [PATCH] Altivec version of-altivec h264_h-v_loop_filter_luma
Originally committed as revision 9264 to svn://svn.ffmpeg.org/ffmpeg/trunk
instead of compiler-dependent __attribute__((aligned(16)))
Origiginal thread:
Date: May 17, 2007 12:30 AM
Subject: [PATCH] Use DECLARE_ALIGNED_16 in libavcodec/ppc/
Originally committed as revision 9047 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
