Avoids a (incorrect) "possibly used uninitialized" warning, no measurable
speed difference.
Originally committed as revision 21518 to svn://svn.ffmpeg.org/ffmpeg/trunk
5% faster on Intel Atom with gcc 4.4.1 (performance is unchanged
if using av_always_inline).
Originally committed as revision 21516 to svn://svn.ffmpeg.org/ffmpeg/trunk
This makes it easy to supply extra flags on the make command line
for testing purposes.
Originally committed as revision 21515 to svn://svn.ffmpeg.org/ffmpeg/trunk
This makes it easy to use a replacement allocator instead of the
system default one.
Originally committed as revision 21509 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows freeing the parser memory in the thread_context freeing loop.
Patch by Rafaël Carré gmailify(rafael, carre)
Originally committed as revision 21508 to svn://svn.ffmpeg.org/ffmpeg/trunk
1% faster MBAFF decoding overall, maybe ~0.1% faster for the cathedral sample.
Originally committed as revision 21507 to svn://svn.ffmpeg.org/ffmpeg/trunk
This is a hair slower (0.15% maybe) but i really dont want to have the
identical code duplicated 3 times because gcc adds odd threaded jumps with
register reshuffling and register safe/restore.
Originally committed as revision 21502 to svn://svn.ffmpeg.org/ffmpeg/trunk
In the main per-compiler section, set speed_cflags and size_cflags
with suitable values. Later one or the other is added to CFLAGS.
Originally committed as revision 21499 to svn://svn.ffmpeg.org/ffmpeg/trunk
This prevents the issue with having to switch between slow and
fast code paths in each row.
0.5% faster loopfilter for cathedral
Originally committed as revision 21495 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows many things to be simplified away.
h264 decoder is overall 1% faster with a mbaff sample and
0.1% slower with the cathedral sample, probably because the slow loop
filter code must be loaded into the code cache for each first MB of each
row but isnt used for the following MBs.
Originally committed as revision 21493 to svn://svn.ffmpeg.org/ffmpeg/trunk
finding the 4-byte signature.
Add a check that ignores the signature if we do not have enough previous
data to go back at least 7 bytes.
Originally committed as revision 21487 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
Set CODEC_CAP_SUBFRAMES for adpcm decoders
This makes ffmpeg stop printing millions of
Multiple frames in a packet from stream 0
when decoding adpcm.
Reason: adpcm has no subframes, the flag does not belong there
Originally committed as revision 21481 to svn://svn.ffmpeg.org/ffmpeg/trunk
because CODEC_CAP_SUBFRAMES is primarely misused to hide this warning otherwise
which renders the flag completely useless.
Originally committed as revision 21480 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
Fix misc typos, patch by
Fabian Greffrath base64_decode(PGZhYmlhbkBncmVmZnJhdGguY29tPg==).
This violates the spec.
Originally committed as revision 21478 to svn://svn.ffmpeg.org/ffmpeg/trunk
Laurent Aimar
Måns Rullgård
Justin Ruggles
Reimar Döffinger
Rafaël Carré
Michael Niedermayer
Jai Menon
Ronald S. Bultje
Daniel Kristjansson
Stefano Sabatini
Carl Eugen Hoyos