Profiling on a Raspberry Pi revealed the best performance to correspond
with VLC_BITS = 5. Results for overall audio decode and the get_vlc2 function
in particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     348.8  20.1     339.6  15.1    88.8%       +2.7%  (insignificant)
6:2 function  38.1   8.1      26.4   4.1     100.0%      +44.5%
8:2 total     339.1  15.4     324.5  15.5    99.4%       +4.5%
8:2 function  33.8   7.0      27.3   5.6     99.7%       +23.6%
6:6 total     604.6  20.8     572.8  20.6    100.0%      +5.6%
6:6 function  95.8   8.4      68.9   8.2     100.0%      +39.1%
8:8 total     766.4  17.6     741.5  21.2    100.0%      +3.4%
8:8 function  106.0  11.4     86.1   9.9     100.0%      +23.1%

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

Profiling results for overall audio decode and the rematrix_channels function
in particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     370.8  17.0     348.8  20.1    99.9%       +6.3%
6:2 function  46.4   8.4      45.8   6.6     18.0%       +1.2%  (insignificant)
8:2 total     343.2  19.0     339.1  15.4    54.7%       +1.2%  (insignificant)
8:2 function  38.9   3.9      40.2   6.9     52.4%       -3.2%  (insignificant)
6:6 total     658.4  15.7     604.6  20.8    100.0%      +8.9%
6:6 function  109.0  8.7      59.5   5.4     100.0%      +83.3%
8:8 total     896.2  24.5     766.4  17.6    100.0%      +16.9%
8:8 function  223.4  12.8     93.8   5.0     100.0%      +138.3%

The assembly version has also been tested with a fuzz tester to ensure that
any combinations of inputs not exercised by my available test streams still
generate mathematically identical results to the C version.

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

Verified with profiling that this doesn't have a measurable effect upon
overall performance.

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

Profiling results for overall audio decode and the mlp_filter_channel(_arm)
function in particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     380.4  22.0     370.8  17.0    87.4%       +2.6%  (insignificant)
6:2 function  60.7   7.2      36.6   8.1     100.0%      +65.8%
8:2 total     357.0  17.5     343.2  19.0    97.8%       +4.0%  (insignificant)
8:2 function  60.3   8.8      37.3   3.8     100.0%      +61.8%
6:6 total     717.2  23.2     658.4  15.7    100.0%      +8.9%
6:6 function  140.4  12.9     81.5   9.2     100.0%      +72.4%
8:8 total     981.9  16.2     896.2  24.5    100.0%      +9.6%
8:8 function  193.4  15.0     103.3  11.5    100.0%      +87.2%

Experiments with adding preload instructions to this function yielded no
useful benefit, so these have not been included.

The assembly version has also been tested with a fuzz tester to ensure that
any combinations of inputs not exercised by my available test streams still
generate mathematically identical results to the C version.

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

There is no point in having a separate file just for the instantiation
that provides the public functions.

There is no point in having this separate; it is not used as a template.

The functions are not used templatized.

The indirection makes no sense without multiple instantiation.

The indirection makes no sense without multiple instantiation.

This allows detemplatizing the bits that are not instantiated twice.

Multiple inclusion makes no sense as it is only used in the 8-bit case.

This fixes FATE with mmxext CPUFLAGS set.

They're guaranteed by the x265 API to be contiguous in memory.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Matroska, MP4, and other containers require it.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This allows for more elegant dependency and object declarations.

libavcodec/lagarith.c:671:16: warning: '#' flag used with ‘%u’ gnu_printf format [-Wformat]

There is no point in populating NuvContext with another DSPContext.

Also split static and dynamic initialization bits to avoid running the
static initialization parts over and over.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This gets rid of aliasing completely unrelated structs to Picture.

Fixes the remaining compilation warnings in the vdpau code.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

The code passed H264Picture* and Picture*, and assumed the
hwaccel_picture_private field was in the same place in both
structs. Somehow this happened to work in Libav, but broke in
FFmpeg (and probably subtly breaks in Libav too).

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This is in line with how the top-level libavcodec Makefile is structured.

This avoids recalculating the value over and over again.

This allows for a more natural macro usage.