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

Reduce scalefactors in non-zero bands that underflow by twice as much as those
in bands that just fail to hit psy targets.

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

definition of ff_yuv2packedX_altivec

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

audio encoders.
This is purely for clarity/documentation purposes.

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

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

used to initialized another array element of the same array.

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

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

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

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

are defined.

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

If there is little unread data in the ByteIOContext buffer, this may lead
to reducing the size of the ByteIOContext buffer to little more the probe
data size. This can lead to suboptimal aviobuf behaviour, e.g. making some
demuxers fail to do short seeks backwards (if the input isn't seekable).

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

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

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

This is slightly faster and opens the door for further optimization.

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

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

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

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

This is a lot more reliable to get cmov rather than trying to trick gcc into
generating it, useful since it's 2% faster overall.

Patch by Eli Friedman <eli.friedman at gmail>

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

Much faster read_mv_component, slightly faster overall

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

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

on the huffman tree, instead of traversing the tree in a while loop.

Based on the similar optimization in libvpx's detokenize.c

10% faster at normal bitrates, and 30% faster for high-bitrate intra-only

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

No difference at the moment, but allows a future branchy variant
of vp56_rac_get_prob to be significantly faster

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

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

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

Also add Ronald to maintainers.

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

Mostly seems to help in the MC code, which gets a hundred cycles faster.

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

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

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

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

sequential geometries instead of running all algorithms sequentially for each
geometry.

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

Don't clamp best mv unless it's actually used.

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

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

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

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

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

Apparently the official conformance test vectors don't test this feature,
even though libvpx uses it.

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

Add MMX idct_dc_add4uv function for this case.
~40% faster chroma idct.

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

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

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

Take shortcuts based on statistically common situations.
Add 4-at-a-time idct_dc function (mmx and sse2) since rows of 4 DC-only DCT
blocks are common.
TODO: tie this more directly into the MB mode, since the DC-level transform is
only used for non-splitmv blocks?

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