loop filter. This removes one obstacle of getting ff_h264_filter_mb_fast()
bitexact. code is maybe 0.1% faster
Originally committed as revision 21280 to svn://svn.ffmpeg.org/ffmpeg/trunk
Run loop filter per row instead of per MB, this also should make it
much easier to switch to per frame filtering and also doing so in a
seperate thread in the future if some volunteer wants to try.
Overall decoding speedup of 1.7% (single thread on pentium dual / cathedral sample)
This change also allows some optimizations to be tried that would not have
been possible before.
Originally committed as revision 21270 to svn://svn.ffmpeg.org/ffmpeg/trunk
No benchmark because its just replacing variables with litteral constants
(so no risk for slowdown outside gcc silliness) and i need sleep.
Originally committed as revision 21237 to svn://svn.ffmpeg.org/ffmpeg/trunk
This could have caused the linking failure of pred_pskip_motion() missing if
a compiler included never used static functions.
Originally committed as revision 21221 to svn://svn.ffmpeg.org/ffmpeg/trunk
Seems to speed the code up a little...
The placement of many generic functions between h264.c and h264.h is still open
Currently they are a little randomly placed between them.
Originally committed as revision 21178 to svn://svn.ffmpeg.org/ffmpeg/trunk
called once per MB in worst case and doesnt seem to benefit from static inline.
Actually the code might be a hair faster now (0.1% according to my benchmark but
this could be random noise)
Originally committed as revision 21173 to svn://svn.ffmpeg.org/ffmpeg/trunk
no speedloss meassured, also its really not touching anything that is speed relevant.
Originally committed as revision 21169 to svn://svn.ffmpeg.org/ffmpeg/trunk
No speedloss meassured (its slightly faster here but that may be random fluctuations)
Originally committed as revision 21165 to svn://svn.ffmpeg.org/ffmpeg/trunk
functions called more than per mb are moved into the header, scan8 is also
as it must be known at compiletime.
The code after this patch duplicates h264data.h, this has been done to minimize
the changes in this step and allow more fine grained benchmarking.
Speedwise this is 1% faster on my pentium dual core with diegos cursed cathedral
sample.
Originally committed as revision 21157 to svn://svn.ffmpeg.org/ffmpeg/trunk
This ensures that the parser will no longer leak memory for all SPS/PPS it encounters.
Originally committed as revision 18406 to svn://svn.ffmpeg.org/ffmpeg/trunk
as a uint64_t in get_dct8x8_allowed().
Patch by David S. Miller <davem at davemloft dot net>
Originally committed as revision 17655 to svn://svn.ffmpeg.org/ffmpeg/trunk
ff_h264_decode_sei, ff_h264_decode_seq_parameter_set,
ff_h264_decode_picture_parameter_set, ff_h264_decode_nal,
ff_h264_decode_rbsp_trailing
Patch by Ivan Schreter, schreter gmx net
Originally committed as revision 17487 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
Now correct values are propagated to interlaced_frame, top_field_first
and repeat_pict in AVFrame structure.
patch by ffdshow tryouts
Originally committed as revision 15773 to svn://svn.ffmpeg.org/ffmpeg/trunk
