No speed improvement, but necessary for some future stuff.
Also opens up the possibility of asm chroma dc idct/dequant.
Originally committed as revision 26349 to svn://svn.ffmpeg.org/ffmpeg/trunk
Useful so that we don't have to run the hierarchical DC iDCT if there aren't
any coefficients. Opens up some future opportunities for optimization as well.
Originally committed as revision 26337 to svn://svn.ffmpeg.org/ffmpeg/trunk
About 2.5x the speed.
NOTE: the way that the asm code handles large qmuls is a bit suboptimal.
If x264-style dequant was used (separate shift and qmul values), it might
be possible to get some extra speed.
Originally committed as revision 26336 to svn://svn.ffmpeg.org/ffmpeg/trunk
libavcodec/h264.h:1260: warning: ‘decode_mb_skip’ defined but not used
patch by Eli Friedman, eli.friedman gmail com
Originally committed as revision 24069 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
The function is only used within that file, so it makes sense to place
it there. This fixes many warnings of the type:
h264.h:1170: warning: ‘fill_filter_caches’ defined but not used
Originally committed as revision 22876 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
this seems 1 cpu cycle slower even though we practically just remove code.
Speed loss seems caused by the merge of if(left_type), iam commiting this
anyway as i cant imagine this to be anything but compiler messup.
Originally committed as revision 22073 to svn://svn.ffmpeg.org/ffmpeg/trunk
about 5 cpu cycles slower in the local code but should be overall faster
due to reduced cache use. (my sample though has too few intra4x4 blocks
for this to be meassureable easily either way)
Originally committed as revision 22052 to svn://svn.ffmpeg.org/ffmpeg/trunk
The code read/write code itself was 1 cycle faster, overall its
likely more due to cache effects
Originally committed as revision 22048 to svn://svn.ffmpeg.org/ffmpeg/trunk
This eliminates all aliasing violation warnings in h264 code.
No measurable speed difference with gcc-4.4.3 on i7.
Originally committed as revision 21881 to svn://svn.ffmpeg.org/ffmpeg/trunk
Ronald S. Bultje
Jason Garrett-Glaser
Eli Friedman
Michael Niedermayer
Måns Rullgård
Howard Chu
Diego Biurrun
Benoit Fouet