[FFmpeg-soc] Differing

[Michael Niedermayer]

On Wed, Jul 22, 2009 at 05:45:58PM -0300, Ramiro Polla wrote:
> On Wed, Jul 22, 2009 at 4:48 AM, Michael Niedermayer<michaelni at gmx.at> 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.

fast bilinear was written at a time when CPUs where not that fast and
HW scalers where not that common
thus the original reason behind it is realtime decoding in good quality
(SDLs sw scaling is and was absolutely trash)


> 
> What do you think is the best to do:
> 1- make them bitexact (will slow them down a bit, some more than others)

no slowdown! except that making them more similar or better is welcome


> 2- choose one of the 3 algorithms and use it under bitexact (falling
> back to slower code if needed)

hmm


> 3- document that fast_bilinear has no intention of being bitexact (and
> in fact ignores that flag)

4 - fail if bitexact & FAST_BILINEAR

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20090724/91226350/attachment.pgp>