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

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

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

patch by Zhou Zongyi @ zhouzy () os punkt pku dot edu speck cn

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

 It happens when the number of channels defined by DCAContext:acmod is lower
than DCAContext:prim_channels. In this case, dca_subsubframe() will call
qmf_32_subbands() using s->channel_order_tab[] entries equal to -1.

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

result depending on uninitialized data.

FATE result may change for this test.

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

This way, we avoid overwriting stream_index in the user's AVPacket
with a nonsense value.

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

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