1.8x faster than altivec radix-2 on a G4
8% faster vorbis decoding
Patch (mostly) by Loren Merritt
Originally committed as revision 23956 to svn://svn.ffmpeg.org/ffmpeg/trunk
This checks which assembler syntax is supported and defines macros
for register names accordingly.
Originally committed as revision 23952 to svn://svn.ffmpeg.org/ffmpeg/trunk
Also put compute_antialias_integer() under !CONFIG_FLOAT and change
forward declarations to declare only the relevant one of these.
Fixes warnings about unused functions and pointer type mismatches.
Originally committed as revision 23950 to svn://svn.ffmpeg.org/ffmpeg/trunk
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
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
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
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
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
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
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
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
