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

[Michael Niedermayer]

On Thu, Dec 17, 2015 at 04:54:31PM +0100, Matthieu Bouron wrote:
> 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

which LUT do you mean here ?


>   * [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 ?

it should enable accurate rounding


>   * Does [3] use some kind of interpolation instead of duplicating
>   chroma lines ? Its output seems inferior to the other code paths.

are you sure that is true for real images?
its easy to end up with wrong conclusions with synthetic inputs
unless you want to use the scaler only for such inputs.

either way line duplication is likely not optimal for real images
iam not made of constant color blocks that are aligned to some cammeras
2x2 samples


>   * Is [3] the output that should be taken as reference ?

id say, the reference is reality, making the output as close as a
image of the new resolution would be if it had been taken that way


>   * Should we use BITEXACT instead of ACCURATE_RND to determine the
>   precision used ?

BITEXACT is to avoid platform differences and allow regression tests

if all else is equal it would be best if C and asm matches, and if
C is bad then it should be improved


> 
> The different outputs of testsrc2,format=yuv420,format=rgba can
> be found here:
> http://0x5c.me/yuv2rgb
> 
> Matthieu
> [...]
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151217/f433c9df/attachment.sig>