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.bou...@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 [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
