1.3x and 3% on G4.
Though I think only part of this speedup is due to my optimizations per se;
some of it is that I got a better roll on the GCC random code generator.
Trivial reorderings of this function have a disproportionate effect on speed.
Originally committed as revision 19726 to svn://svn.ffmpeg.org/ffmpeg/trunk
The first member of struct ScanTable is a simple pointer, extra alignment
of which serves no purpose. The alignment specifier was added along with
some Altivec optimisations also adding a 16-byte-aligned array at the end
of struct ScanTable. Presumably the redundant, outer alignment was added
by mistake. The inner one is clearly sufficient.
Originally committed as revision 19724 to svn://svn.ffmpeg.org/ffmpeg/trunk
These arrays are passed to functions for which we promise 16-byte
alignment, so make sure we fulfil that promise.
Originally committed as revision 19716 to svn://svn.ffmpeg.org/ffmpeg/trunk
Bluray subtitle decoder instead of as small as possible.
This avoids completely unnecessary issues with e.g. libswscale.
(See r19673)
Patch by Stephen Backway, stev391 A exemail D com D au
Originally committed as revision 19714 to svn://svn.ffmpeg.org/ffmpeg/trunk
Storing a single element from a vector where all elements have the same
value does not require an aligned destination. Which element is stored
depends on the alignment of the destination address, but since they all
have the same value, the result is the same regardless of the alignment.
Originally committed as revision 19696 to svn://svn.ffmpeg.org/ffmpeg/trunk
Instead of filling a local array with the desired value and loading it,
load a single element and vec_splat() it to fill the vector.
Originally committed as revision 19691 to svn://svn.ffmpeg.org/ffmpeg/trunk
decoders instead of as small as possible.
This avoids completely unnecessary issues with e.g. libswscale.
Originally committed as revision 19673 to svn://svn.ffmpeg.org/ffmpeg/trunk
There is a theoretical possibility to pass a very long string to ff_parse,
which could crash if allocated from the stack. This allows the allocation
to be checked properly.
Originally committed as revision 19670 to svn://svn.ffmpeg.org/ffmpeg/trunk
pred_order can never exceed 32, so always allocating that amount is safe
and not very wasteful.
Originally committed as revision 19669 to svn://svn.ffmpeg.org/ffmpeg/trunk
When a frame is allocated using libschroedinger routines, the frame data size
does not match the actual frame size if the width is not a multiple of 16. So
we cannot do a straightforward memcpy of the frame returned by libschroedinger
into the FFmpeg picture as the stride differs from the width.
Fix this bug by allocating for the libschroedinger frame with the dimensions
in AVCodecContext within libavcodec and passing the frame to libschroedinger.
patch by Anuradha Suraparaju, anuradha rd.bbc.co uk
Originally committed as revision 19653 to svn://svn.ffmpeg.org/ffmpeg/trunk
This function will be used in the upcoming AMR-NB floating point decoder for
high-pass filtering.
Patch by Colin McQuillan ( m.niloc googlemail com )
Originally committed as revision 19649 to svn://svn.ffmpeg.org/ffmpeg/trunk
Makes no difference for the sample AVI files since they all have no packet pts values.
Originally committed as revision 19646 to svn://svn.ffmpeg.org/ffmpeg/trunk
Loren Merritt
Diego Biurrun
Måns Rullgård
Christian Schmidt
Lars Täuber
Sascha Sommer
Stephen Backway
Reimar Döffinger
Vitor Sessak
Alex Converse
Anuradha Suraparaju
Colin McQuillan