8 cpu cycles faster.

Originally committed as revision 22079 to svn://svn.ffmpeg.org/ffmpeg/trunk

maybe 0.5 cpu cycles faster

Originally committed as revision 22078 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Francesco Cosoleto gmail($name)

Originally committed as revision 22077 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22075 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

Originally committed as revision 22072 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22071 to svn://svn.ffmpeg.org/ffmpeg/trunk

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

Originally committed as revision 22069 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22068 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22067 to svn://svn.ffmpeg.org/ffmpeg/trunk

Not benchmarked as this is petty much just code removial.

Originally committed as revision 22066 to svn://svn.ffmpeg.org/ffmpeg/trunk

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

Most of the make builtin rules, which we do not need, are suffix rules,
and we use only new-style pattern rules.  Disabling suffix rules saves
some time when building on slow systems.

Originally committed as revision 22064 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 30730 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale

Originally committed as revision 30729 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale

Also link avfiltergraph.o and graphparser.o against libavfilter, as it
uses them.

Originally committed as revision 22063 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22062 to svn://svn.ffmpeg.org/ffmpeg/trunk

if the checksums match

Originally committed as revision 22061 to svn://svn.ffmpeg.org/ffmpeg/trunk

svq3 decoder does not work yet though but i didnt want to keep compilation
broken longer

Originally committed as revision 22060 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Anton Khirnov wyskas gmail com

Originally committed as revision 22059 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Anton Khirnov wyskas gmail com

Originally committed as revision 22058 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Anton Khirnov wyskas gmail com

Originally committed as revision 22057 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22056 to svn://svn.ffmpeg.org/ffmpeg/trunk

seems 20cpu cycles faster

Originally committed as revision 22055 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22054 to svn://svn.ffmpeg.org/ffmpeg/trunk

3-7 cpu cycles faster

Originally committed as revision 22053 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

Originally committed as revision 22051 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch from Anton Khirnov wyskas gmail com

Originally committed as revision 22050 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch from Anton Khirnov wyskas gmail com

Originally committed as revision 22049 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

Originally committed as revision 22047 to svn://svn.ffmpeg.org/ffmpeg/trunk

This is consistent with the metadata displaying in show_format() and
with the documentation.

Originally committed as revision 22046 to svn://svn.ffmpeg.org/ffmpeg/trunk

opt_input_file(). More consistent and more clear, as "filename" can be
easily confused with the global "input_filename".

Originally committed as revision 22045 to svn://svn.ffmpeg.org/ffmpeg/trunk

Due to a shortcoming in the AAC specification, if an all zero buffer is
fed to section data decoding it will never terminate. That means without
a buffer exhaustion check decode_band_types() will consume all input
buffer padding. Worse if a get_bits() implementation that returns zeros
when padding is exhausted is used, the function will never terminate.

The fixes that by added a buffer exhaustion check in the sectioning
decoding loop.

Originally committed as revision 22044 to svn://svn.ffmpeg.org/ffmpeg/trunk

@patchby Tomas Härdin |tomas dot hardin at codemill dot se|

Originally committed as revision 22043 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22041 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22040 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22039 to svn://svn.ffmpeg.org/ffmpeg/trunk