The mmx code is floating-point only, and this function does not know
from which decoder it is called.  Without this change, the integer
decoder only "works" because the size of the context struct is smaller
in this case, and the mmx init function writes the function pointer
outside the allocated context.

Fixes issue 2054.

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

rectalogic at rectalogic dot com
Fixes issue #1754

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

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

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

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

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

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

Patch by Josh Allmann, joshua dot allmann at gmail

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

Patch by Josh Allmann, joshua dot allmann at gmail

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

Avoid a compile-time dependency of the pad filter on libavcodec.

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

prototype and also always call them with exactly those arguments.
The previous way seems to have worked on all supported platforms, however
it was not strictly valid C and would crash e.g. with a compiler that
uses stdcall by default.
Also avoids warnings if -Wstrict-prototypes is used.

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

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

they now also depends on cabac.o for ff_h264_norm_shift

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

warning: the address of 'number' will always evaluate as 'true'
patch by Eli Friedman   eli _dot_ friedman _at_ gmail _dot_ com

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

The ADTS output files are not explicitly signaled because the format
does not support explicit signalling.

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

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

This allocates per-thread copies of some MpegEncContext.ac_val which
is used concurrently from the encoding threads.

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

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

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

If both /dev/random and /dev/urandom failed to return data, an
uninitialised value might be returned.  Since most systems have a
non-blocking /dev/urandom or have /dev/random with similar properties,
the chance of blocking is minimal, and the alternative of returning
non-random data is worse.

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

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

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

Whose idea was it to have a CPU that didn't SIGILL on an invalid instruction?

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

Patch by Rafaël Carré (rafael <dot> carre <at> gmail).

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

This fixes a stack overflow.

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

Necessary because of this GCC bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44474
To do this, convert some, but not all (!) of the variables in VP56RangeCoder
into local variables.
If we convert c->high into a local variable, gcc gets the stupids and refuses
to use a conditional move for the unpredictable main branch.

TODO: dispense with this bullshit and write an asm version.

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

other filters.

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

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

This incantation causes gcc 4.3 to generate cmov on x86, a vastly better option
than a completely unpredictable branch.
Hopefully this carries over to newer versions and other CPUs with conditionals.
~5 cycles saved per call on a Core i7.

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

Negate "bits" to eliminate a negate in cache refilling.

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

Patch by XBMC

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

Patch by Mike Scheutzow, scheutzow alcatel-lucent com

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

Patch by Mike Scheutzow, scheutzow alcatel-lucent com

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

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

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

Patch by Daniel Kristjansson, danielk cuymedia net

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

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

Should allow for future SIMD optimizations.

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

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

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