[FFmpeg-devel] [PATCH] ARM: NEON optimised simple_idct

[Michael Niedermayer]

On Mon, Aug 25, 2008 at 10:10:03PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > tOn Mon, Aug 25, 2008 at 09:04:27PM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Mon, Aug 25, 2008 at 07:47:16PM +0100, M?ns Rullg?rd wrote:
> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> > [...]
> >> >> >2. depending on the pattern of non zero / all zero rows one of 8
> >> >> > optimized column transforms is used.  This may be a bad idea though
> >> >> > for a CPU with a small code cache ...
> >> >> >
> >> >> > also maybe it would make sense to look at i386/idct_sse2_xvid.c
> >> >> > which uses SSE2 (128bit registers), this one uses only 16bit operations
> >> >> > for the column transform so it may be faster when the tricks of the simple
> >> >> > idct arent applicable
> >> >> 
> >> >> Do you expect any sane person to be able to read that?  
> >> >
> >> > well, a little insanity may be needed
> >> >
> >> >> That's also
> >> >> not bitexact, right?
> >> >
> >> > it is supposed to be bitexact, and i cannot remember a case where any
> >> > input lead to different output. Also the MMX one is used in the
> >> > regression tests and they match between MMX and non x86 cpus ...
> >> 
> >> All the different IDCT variants (int, simple, simplemmx, libmpeg2mmx,
> >> xvidmmx, faani) give different output on my machine with current
> >> FFmpeg.  Which one is correct?
> >
> > all
> >
> > and if you really have a case where simple and simplemmx return different
> > output for the same and correctly permutated input then iam very interrested
> > in that.
> 
> I see differences with most files.  Can you suggest an easy way to
> extract the coefficients for the offending block?

hmm, hack one idct so it runs the second one on a correctly permutated
copy of the block and print any where the result differs

or dump all blocks and hack dct-test so it can test such use provided
coeffs.

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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-devel/attachments/20080826/b2b88268/attachment.pgp>