| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
Fixes several "‘static’ is not at beginning of declaration" warnings.
|
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
Much faster high bit depth deblocking.
|
| |
|
| |
|
|
|
|
|
| |
FF_COMMON_FRAME holds the contents of the AVFrame structure and is also copied
to struct Picture. Replace by an embedded AVFrame structure in struct Picture.
|
| |
|
|
|
|
| |
Eliminate redundant check in filter_mb_fast, consider bit depth in calculating qp_thresh.
|
| |
|
|
|
|
| |
Faster H.264 decoding with ALLOW_INTERLACE off.
|
|
|
|
| |
Significantly faster deblocking in streams with lots of slices.
|
| |
|
| |
|
| |
|
|
|
|
| |
It was broken in 4:4:4, and still did chroma deblocking for no reason in 4:2:0.
|
|
|
|
| |
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
|
|
| |
Needs some ARM/PPC asm modifications.
|
|
|
|
| |
It was broken in 4:4:4, and still did chroma deblocking for no reason in 4:2:0.
|
|
|
|
| |
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
|
|
|
|
|
|
|
|
| |
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
| |
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
| |
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
|
| |
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the H264-specific functions from DSPContext to the new
H264DSPContext. The code is made conditional on CONFIG_H264DSP
which is set by the codecs requiring it.
The qpel and chroma MC functions are not moved as these are used by
non-h264 code.
Originally committed as revision 22565 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
| |
These macros are redundant. All uses are replaced with the generic
DECLARE_ALIGNED macro instead.
Originally committed as revision 22233 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
| |
This eliminates all aliasing violation warnings in h264 code.
No measurable speed difference with gcc-4.4.3 on i7.
Originally committed as revision 21881 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 21866 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 21815 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
Fixes issue1250
Originally committed as revision 21665 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
| |
of the code.
No meassureable speed change.
Originally committed as revision 21566 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
about 0.5% faster MBAFF loop filtering
Originally committed as revision 21552 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
No meassureable speed effect.
Originally committed as revision 21541 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 21540 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
about 0.5% faster loop filtering
Originally committed as revision 21539 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
smaller without any speed loss.
Originally committed as revision 21514 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
|
|
|
|
| |
Originally committed as revision 21506 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
~20 cpu cycles faster loopfilter
Originally committed as revision 21505 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
quite a bit faster
Originally committed as revision 21504 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
~6% faster (slow path) loopfilter (should be ~2% overall)
Originally committed as revision 21503 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
|
|
|
|
| |
Originally committed as revision 21497 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
to split out
Originally committed as revision 21496 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
|
|
|
|
|
|
| |
a few cycles faster
Originally committed as revision 21494 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
|
|
|
|
| |
Originally committed as revision 21479 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
| |
interlacing.
~4 cpu cycles speedup
Originally committed as revision 21474 to svn://svn.ffmpeg.org/ffmpeg/trunk
|