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

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

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

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

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

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 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

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

10-15 cpu cycles faster.

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

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 22013 to svn://svn.ffmpeg.org/ffmpeg/trunk

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

ff_combine_frame() is called, which allocates ParseContext->buffer if needed,
so ff_parse_close() must be called to free it.
Patch by jai.

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

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

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

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

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

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

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

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

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

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

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

block decoding at exit, so prevent that memory leak now.

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

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

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

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

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

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

This fixes some issues with the first few timestamps.

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