The 4-tap filters should only access one row/column before the
reference block.

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit e0e46cae37)

GCC 4.3 and later are more particular about signedness matching
in vector operations.  The operations under if(rangered) were
missing assignments and thus had no effect.

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 381efba0ec)

(cherry picked from commit 78e2380a6d)

Merging these functions allows merging some loops, which makes the
results (particularly after SIMD optimizations) much faster.
(cherry picked from commit f8bed30d8b)

(cherry picked from commit 484a337cd7)

Advantage is that it allows us to combine several loops into a single
one, and these can eventually be merged into the IDCT itself. Also, it
allows us to remove vc1_put_block(), and makes CODEC_FLAG_GRAY faster.
(cherry picked from commit bbfd2e7ab4)

lsf_r is an array of int16_t, not float.

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 1efa772e20)

It was doubled in size for the LTP implementation. This brings it back
down to its original size.

The 4-tap filters should only access one row/column before the
reference block.

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

GCC 4.3 and later are more particular about signedness matching
in vector operations.  The operations under if(rangered) were
missing assignments and thus had no effect.

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

Merging these functions allows merging some loops, which makes the
results (particularly after SIMD optimizations) much faster.

Advantage is that it allows us to combine several loops into a single
one, and these can eventually be merged into the IDCT itself. Also, it
allows us to remove vc1_put_block(), and makes CODEC_FLAG_GRAY faster.

Advanced profile never uses "range reduction", so vc1_put_block() quite
literally just calls put_pixels_clamped() from vc1_decode_i_blocks_adv().
By inlining the function, we can prevent calling IDCT8x8 if
CODEC_FLAG_GRAY is set, and we don't have to scale the coeffs in the
[0,256] range, but can instead use put_signed_pixels_clamped().
(cherry picked from commit 70aa916e46)

Remove ff_vector128, it is identical to ff_pb_80.
(cherry picked from commit bf6fa73245)

Patch discussed and taken from https://roundup.ffmpeg.org/issue2584
(cherry picked from commit 2bbec1eda4)

With negative stride, the start of the edge_emu buffer should be pointing to
the last line, not the end of the buffer.
With positive stride, pointing to the end of the buffer was completely wrong.
(cherry picked from commit a89f4ca005)

(cherry picked from commit 9707f84fa7)

Also remove qscale_table code; this didn't make sense anyways as VP3 doesn't
use an MPEG-like quantizer scale.
(cherry picked from commit 902685b8ab)

lsf_r is an array of int16_t, not float.

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

Advanced profile never uses "range reduction", so vc1_put_block() quite
literally just calls put_pixels_clamped() from vc1_decode_i_blocks_adv().
By inlining the function, we can prevent calling IDCT8x8 if
CODEC_FLAG_GRAY is set, and we don't have to scale the coeffs in the
[0,256] range, but can instead use put_signed_pixels_clamped().

Remove ff_vector128, it is identical to ff_pb_80.

Patch discussed and taken from https://roundup.ffmpeg.org/issue2584

With negative stride, the start of the edge_emu buffer should be pointing to
the last line, not the end of the buffer.
With positive stride, pointing to the end of the buffer was completely wrong.

Also remove qscale_table code; this didn't make sense anyways as VP3 doesn't
use an MPEG-like quantizer scale.

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 351423ae1f)

(cherry picked from commit ed040f35f2)

This one didn't actually need to be initialized.
(cherry picked from commit 891b1f15a7)

(cherry picked from commit bcf4568f18)

(cherry picked from commit 7634771e70)

(cherry picked from commit 12802ec060)

(cherry picked from commit 0b16cdc3fa)

(cherry picked from commit 1da6ea3954)

3*n4 was already calculated in n3.
(cherry picked from commit 979395bbbb)

The rematrixing strategy reuse flags are not reset between frames, so they
need to be initialized for all blocks, not just block 0.

Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 5b54d4b376)

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

This one didn't actually need to be initialized.

3*n4 was already calculated in n3.

The rematrixing strategy reuse flags are not reset between frames, so they
need to be initialized for all blocks, not just block 0.

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>

While 4 works for some samples, 3 is the correct value since 8x8
DCT is used by (m)jpeg.

Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 1f004fc512)