Since RV40 and VC-1 use almost the same algorithm so optimizations for
those two decoders are easy to do and included.

The code represents a considerable maintenance burden and it is not
clear that it gives a noticeable benefit to outweigh this after 10
years of improvements in compiler technology since its creation.

The current API where the plain size is exposed is not of much
use - in most cases it is allocated dynamically anyway.

If allocated e.g. on the stack via an uint8_t array, there's no
guarantee that the struct's members are aligned properly (unless
the array is overallocated and the opaque pointer within it
manually aligned to some unspecified alignment).
Signed-off-by: Martin Storsjö <martin@martin.st>

Introduce a basic layout, the subpages are currently left empty.

Split libavutil in multiple groups as example of the structure

Signed-off-by: Mans Rullgard <mans@mansr.com>

Consistently apply this rule: the guard name is obtained from the
filename by stripping the leading "lib", converting '/' and '.'  to
'_' and uppercasing the resulting name. Guard names in the root
directory have to be prefixed by "FFMPEG_".

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

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

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

and fix GPL/LGPL version mismatches.

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

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

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

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

depending on CONFIG_SMALL this can either be compiled to a fully unrolled kernel / rfc reference style md5 routine
or a single loop similar to what mplayer uses

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