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

Don't prefetch reference frames that were used less than 1/32th of the time so
far in the frame.
This helps speed up to ~2% on videos that, in many frames, make near-zero
(but not entirely zero) use of golden and/or alt-refs.
This is a very common property of videos encoded by libvpx.

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

erroneous message for last frame.

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

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

~0.3% faster overall.

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

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

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

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

Prefetch all refs (including altref), but only if they've been used so far this
frame.
~2.5% faster overall.

TODO: Do something even smarter, like using how often each ref has been used
so far, so that a couple blocks of a rarely-used ref don't force us to prefetch
it.

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

rest of FFmpeg.

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

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