Re: [FFmpeg-devel] [PATCH 2/3] simple_idct12: align C and x86

2015-10-14 Thread Michael Niedermayer
On Wed, Oct 14, 2015 at 08:46:22AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2015-10-14 0:04 GMT+02:00 Michael Niedermayer :
> > the ome and syserr values worsen by this
> 
> I have mixed feelings about this, too.
> 
> On the one hand, omse in any case says anyway none of those idcts are
> accurate enough to some sense (inter error propagation? / per the mpeg

yes, i doubt they would work for inter frames, at least not with
GOPs a hundread frames long

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/3] simple_idct12: align C and x86

2015-10-13 Thread Michael Niedermayer
On Tue, Oct 13, 2015 at 09:21:40PM +0200, Christophe Gisquet wrote:
> Results for omse on the 3 idct dct-test.
> 
> C:   0.16915859   0.11848359   0.12913125
> x86: 0.16883281   0.11849063   0.19041875
> 
> Using 14 and 17 as shifts subtantially improve those, but actually
> cause overflows and incorrect decoding of 12bpp content.
> ---
>  libavcodec/simple_idct_template.c | 17 -
>  libavcodec/x86/idctdsp_init.c |  8 +++-
>  libavcodec/x86/simple_idct10.asm  |  7 +++
>  3 files changed, 10 insertions(+), 22 deletions(-)

dct-test -i changes
IDCT SIMPLE-C12: max_err=1 omse=0.11856094 ome=0.00286875 syserr=0.0259 
maxout=288 blockSumErr=64
to
IDCT SIMPLE-C12: max_err=1 omse=0.11825703 ome=0.01024297 syserr=0.05225000 
maxout=288 blockSumErr=64

dct-test -i 2
 5825711334133413341334  582571
   2571  5813341334133413342571  58
 5825713805   -11563805   -1156  582571
   2571  58   -11563805   -115638052571  58
 5825713805   -11563805   -1156  582571
   2571  58   -11563805   -115638052571  58
 5825711334133413341334  582571
   2571  5813341334133413342571  58
IDCT SIMPLE-C12: max_err=1 omse=0.12911875 ome=0.06609375 syserr=0.19025000 
maxout=256 blockSumErr=64
to
   25605073256025602560256025605073
   50732560256025602560256050732560
   256050735031  705031  7025605073
   50732560  705031  70503150732560
   256050735031  705031  7025605073
   50732560  705031  70503150732560
   25605073256025602560256025605073
   50732560256025602560256050732560
IDCT SIMPLE-C12: max_err=1 omse=0.19041875 ome=0.15929375 syserr=0.25365000 
maxout=256 blockSumErr=64

the ome and syserr values worsen by this

iam not objecting to this if thats what people want, just want to
make sure its not missed

also IIUC this is just to make C and x86 match, so it could just be
skiped with no ill effects except that tnen x86 and C would not be
bitexact matches ?


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/3] simple_idct12: align C and x86

2015-10-13 Thread Ganesh Ajjanagadde
On Tue, Oct 13, 2015 at 6:04 PM, Michael Niedermayer
 wrote:
> On Tue, Oct 13, 2015 at 09:21:40PM +0200, Christophe Gisquet wrote:
>> Results for omse on the 3 idct dct-test.
>>
>> C:   0.16915859   0.11848359   0.12913125
>> x86: 0.16883281   0.11849063   0.19041875
>>
>> Using 14 and 17 as shifts subtantially improve those, but actually
>> cause overflows and incorrect decoding of 12bpp content.
>> ---
>>  libavcodec/simple_idct_template.c | 17 -
>>  libavcodec/x86/idctdsp_init.c |  8 +++-
>>  libavcodec/x86/simple_idct10.asm  |  7 +++
>>  3 files changed, 10 insertions(+), 22 deletions(-)
>
> dct-test -i changes
> IDCT SIMPLE-C12: max_err=1 omse=0.11856094 ome=0.00286875 syserr=0.0259 
> maxout=288 blockSumErr=64
> to
> IDCT SIMPLE-C12: max_err=1 omse=0.11825703 ome=0.01024297 syserr=0.05225000 
> maxout=288 blockSumErr=64
>
> dct-test -i 2
>  5825711334133413341334  582571
>2571  5813341334133413342571  58
>  5825713805   -11563805   -1156  582571
>2571  58   -11563805   -115638052571  58
>  5825713805   -11563805   -1156  582571
>2571  58   -11563805   -115638052571  58
>  5825711334133413341334  582571
>2571  5813341334133413342571  58
> IDCT SIMPLE-C12: max_err=1 omse=0.12911875 ome=0.06609375 syserr=0.19025000 
> maxout=256 blockSumErr=64
> to
>25605073256025602560256025605073
>50732560256025602560256050732560
>256050735031  705031  7025605073
>50732560  705031  70503150732560
>256050735031  705031  7025605073
>50732560  705031  70503150732560
>25605073256025602560256025605073
>50732560256025602560256050732560
> IDCT SIMPLE-C12: max_err=1 omse=0.19041875 ome=0.15929375 syserr=0.25365000 
> maxout=256 blockSumErr=64
>
> the ome and syserr values worsen by this
>
> iam not objecting to this if thats what people want, just want to
> make sure its not missed

I do not object if there is a good reason for why keeping the error
bars the same is not feasible. As a percentage of the original errors,
these changes do not look negligible.

This should be documented as (preferably) commit message + comment, or
at the least in the commit message.

>
> also IIUC this is just to make C and x86 match, so it could just be
> skiped with no ill effects except that tnen x86 and C would not be
> bitexact matches ?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel