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

for high resolution videos.
about 20cycles faster per MB for cathederal.

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

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

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

same speed (ask gcc why, i dont know)

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

metadata system.

Patch by Anton Khirnov <wyskas gmail com>.

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

Patch by Anton Khirnov <wyskas gmail com>.

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

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

Patch by Anton Khirnov <wyskas gmail com>.

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

Patch by Anton Khirnov <wyskas gmail com>.

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

10-15 cpu cycles faster.

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

Patch by Anton Khirnov <wyskas gmail com>.

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

same speed as far as i can meassure but it might have fewer branches on some
archs.
Idea from x264 / jason

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

Fixes a crash when audio stream is cycled twice.

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

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

MPV_common_init(), so calling both is redundant and leads to memory
leaks in WMV3/VC-1 decoder. Thus use only the first function in
WMV3/VC-1 decoder initialization.

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

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

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

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

Patch by Yann Coupin, yann.coupin+ffmpeg gmail

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

Patch from Anton Khirnov wyskas gmail

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

Patch from Anton Khirnov wyskas gmail

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

Patch from Anton Khirnov wyskas gmail

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