the second and third sources were incremented only by half of the needed size
---
The loop was iterated only once in the previous tests and the higher filter
orders that expose this bug happen only on APE files with extrahigh or insane
compression level. I've tested favourite 3.99 insane compression file to
verify that conjecture and that this fix works for it. And it makes
fate-lossless-monkeysaudio-394b1-extrahigh pass on AltiVec PPC too.
---
libavcodec/ppc/int_altivec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ppc/int_altivec.c b/libavcodec/ppc/int_altivec.c
index 67d119c..8357ca7 100644
--- a/libavcodec/ppc/int_altivec.c
+++ b/libavcodec/ppc/int_altivec.c
@@ -129,8 +129,8 @@ static int32_t scalarproduct_and_madd_int16_altivec(int16_t
*v1, const int16_t *
pv1[0] = vec_mladd(t0, muls, i0);
pv1[1] = vec_mladd(t1, muls, i1);
pv1 += 2;
- v2 += 8;
- v3 += 8;
+ v2 += 16;
+ v3 += 16;
} while(--order);
res = vec_splat(vec_sums(res, zero_s32v), 3);
vec_ste(res, 0, &ires);
--
1.7.9.5
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
