On Friday, May 24, 2013, Kostya Shishkov <[email protected]> wrote: > 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
Confirming this fixes fate-lossless-monkeysaudio-394b1-extrahigh on AltiVec-enabled PPC builds. -- Sean McG. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
