[FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

[Matthieu Bouron]

On Tue, Dec 15, 2015 at 06:22:43PM +0100, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron <matthieu.bouron at stupeflix.com>
> > 
> > ---
> > 
> > Hi,
> > 
> > This commit is likely to break fate on arm since the current C code path
> > seems to use less precision.
> > 
> > How should I proceed to fix it ?
> 
> hmm
> can the precission of the C code path and any asm impl of it under
> bitexact (if they exist), be changed to higher precission without
> speedloss?
> if so that would be an option

We are currently facing 4 cases (with this patch applied)

  * [1] ARM +ACCURATE_RND: uses neon, 13bit coefficients and 32bit
  precision overall
  * [2] ARM -ACCURATE_RND: uses neon, 6bit coefficients and 16bit
  precision overall
  * [3] X86 +ACCURATE_RND: uses a C code path with lookup tables
  * [4] X86 -ACCURATE_RND: uses MMX+MMXEXT with apparently 13bit
  coefficients (libswscale/yuv2rgb.c around line 800).

Notes:
  * The 4 outputs are different with [3] being ugly (ghosting/non-sharp
  edges).

  * [1] and [4] (13bit coefficient accuracy) should be the same but have
  slight differences.

Questions:

  * What is the meaning of the ACCURATE_RND flag ?
  * Does [3] use some kind of interpolation instead of duplicating
  chroma lines ? Its output seems inferior to the other code paths.
  * Is [3] the output that should be taken as reference ?
  * Should we use BITEXACT instead of ACCURATE_RND to determine the
  precision used ?

The different outputs of testsrc2,format=yuv420,format=rgba can
be found here:
http://0x5c.me/yuv2rgb

Matthieu
[...]