The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700
to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb
(in the decode_slice loop) goes from 1759 to 1733 cycles on the clip
tested (cathedral), i.e. almost 30 cycles per mb faster.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Martin Storsjö <martin@martin.st>

Results of IDCT can by far outreach the range of ff_cropTbl[], leading
to overreads and potentially crashes.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Use of these has been broken ever since the h264 idct was changed
to always use transposed inputs.  Furthermore, they were only
ever used if some *other* non-default idct was requested.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This naming scheme is used elsewhere, so it's sensible to be consistent.

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.

Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

seems git missed them and we temporary lost our improvments in them.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).

Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.

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>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Needed for high bit depth h264 decoding.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).

Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Needed for high bit depth h264 decoding.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Mans Rullgard <mans@mansr.com>

(cherry picked from commit 66c6b5e2)

No speed improvement, but necessary for some future stuff.
Also opens up the possibility of asm chroma dc idct/dequant.

Originally committed as revision 26349 to svn://svn.ffmpeg.org/ffmpeg/trunk

About 2.5x the speed.

NOTE: the way that the asm code handles large qmuls is a bit suboptimal.
If x264-style dequant was used (separate shift and qmul values), it might
be possible to get some extra speed.

Originally committed as revision 26336 to svn://svn.ffmpeg.org/ffmpeg/trunk

It was an ugly hack to begin with and didn't give any performance.

NOTE: this patch opens up some future simplifications to be made (such as
removing some of the scantables from H264Context) but doesn't take advantage
of them yet.

Originally committed as revision 26329 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 23728 to svn://svn.ffmpeg.org/ffmpeg/trunk

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

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

Originally committed as revision 16811 to svn://svn.ffmpeg.org/ffmpeg/trunk

h264_idct8_add_c: 780 -> 735 cycles on conroe

Originally committed as revision 16307 to svn://svn.ffmpeg.org/ffmpeg/trunk

thus avoiding the calling overhead.
New functions are not yet used.

Originally committed as revision 16206 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 9484 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7256 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6992 to svn://svn.ffmpeg.org/ffmpeg/trunk

and fix GPL/LGPL version mismatches.

Originally committed as revision 6577 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 4971 to svn://svn.ffmpeg.org/ffmpeg/trunk