On Wed, Jul 22, 2009 at 4:48 AM, Michael Niedermayer<[email protected]> wrote: > On Wed, Jul 22, 2009 at 01:58:16AM -0300, Ramiro Polla wrote: >> >From what I understood and from some tests I've done, this creates >> some rather ugly last lines at the far right of the image. The output >> also differs for C, mmx, and mmx2, and it's not under BITEXACT. >> >> To remove this adjustment and have the same output for all >> configurations, wouldn't it only be necessary to: >> - adjust mmx and mmx2 filters to only work up to the last input pixels >> it can before reading past the end. >> - run the C code on the last pixels if necessary. > > that would need a benchmark, after all the fast_bilinear case is intended > to be fast ...
fast_bilinear has different output with different optimizations not only because they treat the width differently to not read past the end, but because the algorithms they use are different: C luma, x86 luma and chroma: src[xx] * (128 - xalpha) + src[xx+1] * (xalpha) C chroma: src[xx] * (127 - xalpha) + src[xx+1] * (xalpha) MMX2 luma and chroma: src[xx] * (127 - xalpha) + src[xx+1] * (xalpha + 1) I would prefer if they all gave the same output, but as you mention fast_bilinear is intended to be fast (I would suppose just for testing purposes). It is also not under BITEXACT. What do you think is the best to do: 1- make them bitexact (will slow them down a bit, some more than others) 2- choose one of the 3 algorithms and use it under bitexact (falling back to slower code if needed) 3- document that fast_bilinear has no intention of being bitexact (and in fact ignores that flag) Ramiro Polla _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
