- 15 Jan, 2011 1 commit
-
-
Jason Garrett-Glaser authored
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
-
- 14 Jan, 2011 2 commits
-
-
Jason Garrett-Glaser authored
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
-
Jason Garrett-Glaser authored
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
-
- 06 Jul, 2010 1 commit
-
-
Eli Friedman authored
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
-
- 05 Jul, 2010 1 commit
-
-
Michael Niedermayer authored
Originally committed as revision 24056 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 30 Jun, 2010 1 commit
-
-
Måns Rullgård authored
Originally committed as revision 23904 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 28 May, 2010 2 commits
-
-
Howard Chu authored
Originally committed as revision 23364 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Howard Chu authored
Fixes many "non-existing PPS referenced" error messages Originally committed as revision 23363 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 26 May, 2010 1 commit
-
-
Howard Chu authored
Patch by Howard Chu, hyc highlandsun com Originally committed as revision 23340 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 20 Apr, 2010 1 commit
-
-
Diego Biurrun authored
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
-
- 13 Apr, 2010 1 commit
-
-
Diego Biurrun authored
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
-
- 30 Mar, 2010 2 commits
-
-
Michael Niedermayer authored
Originally committed as revision 22733 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Benoit Fouet authored
Originally committed as revision 22729 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 16 Mar, 2010 1 commit
-
-
Måns Rullgård authored
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
-
- 15 Mar, 2010 1 commit
-
-
Måns Rullgård authored
This fixes libavcodec/h264.h:1100: warning: integer overflow in expression Originally committed as revision 22558 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 06 Mar, 2010 1 commit
-
-
Måns Rullgård authored
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
-
- 04 Mar, 2010 2 commits
-
-
Michael Niedermayer authored
1 cpu cycle faster Originally committed as revision 22193 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22192 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 03 Mar, 2010 8 commits
-
-
Michael Niedermayer authored
5 cpu cycles faster. Originally committed as revision 22183 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
to the end of the structure. 4 cpu cycles faster in 3k cpu cycles Originally committed as revision 22181 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22179 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22177 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22171 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22169 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22162 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
30 cpu cycles faster Originally committed as revision 22161 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 27 Feb, 2010 2 commits
-
-
Michael Niedermayer authored
Originally committed as revision 22086 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22085 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 26 Feb, 2010 7 commits
-
-
Michael Niedermayer authored
8 cpu cycles faster. Originally committed as revision 22079 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
maybe 0.5 cpu cycles faster Originally committed as revision 22078 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
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
-
Michael Niedermayer authored
Originally committed as revision 22071 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
This seems unneeded as nothing seems to ever set it to non zero values. Originally committed as revision 22070 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22069 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22067 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 25 Feb, 2010 5 commits
-
-
Michael Niedermayer authored
ones based on mb_stride in h264. about 20 cpu cycles faster overall per MB Originally committed as revision 22065 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
seems 20cpu cycles faster Originally committed as revision 22055 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
Originally committed as revision 22054 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
3-7 cpu cycles faster Originally committed as revision 22053 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Michael Niedermayer authored
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
-