Experiences with new Walken & IEEE1180 compliant Skal-idct?

[NaN]

Hi!

Does anybody have some experiences with the Walken & IEEE1180 compliant version of Skal's idct/fdct? It was recently commited to xvid-cvs.

I ported it to a test version of my DGDecode+ build and got excellent results:

Xvid simple: SSIM: 99.50% Time: 1:23
new Skal: SSIM: 99,63% Time: 1:20

The sample contained 3000 frames.

Any experiences? I pm'ed Skal but he didn't answer yet.

Cheers, NaN

[squid_80]

I've found it gives identical results to xvid's other SSE2 IDCT (Dmitry's) but is a little bit slower.

(xvid devs: why was Dmitry's SSE2 IDCT never used? It gives exactly the same results as the 3DNow implementation.)

[NaN]

What do you mean with 'identical results'? Same SSIM or binary identical?

Thanks! NaN

[squid_80]

Binary identical.

[NaN]

Thanks for the info!

I'll look at it if time permits and post the experiences.

Cheers, NaN

[CruNcher]

useing SSE2 in XviD with at least AMD Athlon 64 Venice Cpu will slow it down by 3 sec that's my expierence since i moved to AMD :-)

[skal]

hi Squid_80!

I've found it gives identical results to xvid's other SSE2 IDCT (Dmitry's) but is a little bit slower.


Depends on the bitrate. I've optimized the idct-sse2 for sparse matrices...


(xvid devs: why was Dmitry's SSE2 IDCT never used? It gives exactly the same results as the 3DNow implementation.)

hmm? really? Then it's an error. Will cross-check...

The problem is: the idct should be "Walken-compliant", regarding rounding errors.
Historically, Walken (hi Walken if you're reading!:) ) wrote a version with some given
rounding constants that are now wildely used. You can squeeze a (very) little
more precision by changing these constants, but you risk experiencing a drift
in decoding, even using an IEEE compliant idct. I've got some test bitstreams
for that. This should be avoided, and we should stick to "Walken-compliance"
whenever possible.
The problem with Dmitry's idct is that it's not Walken-compliant, and now, the
3DNow might be too, from your report. You can try 'xvid_bench 7' for testing
IEEE-compliance.

@cruncher: welcome to a non-deterministic world :) Note: on my laptop (Centrino),
the SSE2 unit is a fake, and the SSE2 code are slower than the MMX. So, 3 secs
isn't that bad ! hehe

bye!
-Skal

[squid_80]

Depends on the bitrate. I've optimized the idct-sse2 for sparse matrices...
Whoops. I have looked at the code (I used it in the x64 version of dgdecode) but that didn't occur to me.


hmm? really? Then it's an error. Will cross-check...

The problem is: the idct should be "Walken-compliant", regarding rounding errors.
Historically, Walken (hi Walken if you're reading!:) ) wrote a version with some given
rounding constants that are now wildely used. You can squeeze a (very) little
more precision by changing these constants, but you risk experiencing a drift
in decoding, even using an IEEE compliant idct. I've got some test bitstreams
for that. This should be avoided, and we should stick to "Walken-compliance"
whenever possible.
The problem with Dmitry's idct is that it's not Walken-compliant, and now, the
3DNow might be too, from your report. You can try 'xvid_bench 7' for testing
IEEE-compliance.
Yep, I know that. It's not an error in the 3dnow idct, I was just using it as an example - all the non-simple idcts (idct_mmx, idct_xmm, idct_3dne, idct_sse2_dmitry) give exactly identical output (as they should). If there's a case where Dmitry's fails I've yet to see it.

While I've got your attention can I ask something about this code from qpel.h...
x_int = xRef/4;
if (xRef < 0 && xRef % 4)
x_int--;

Why not just replace it with "x_int = xRef >> 2;" ? (Beta 1 of VS2005 had a nasty bug when it came to div/mod by a constant power of 2. Unfortunately that's what MS used for the x64 compiler in the platform SDK.)

[squid_80]

Why not just replace it with "x_int = xRef >> 2;" ? (Beta 1 of VS2005 had a nasty bug when it came to div/mod by a constant power of 2. Unfortunately that's what MS used for the x64 compiler in the platform SDK.)I see this has been changed in CVS. Just a little nit-pick: there's a typo in the checking function.if (sizeof(uint32_t)<4) {
printf( "ERROR: sizeof(uint8_t)<4!\n" );
nb_err++;
If sizeof(uint8_t)<4 indicates an error, we're in big trouble :p

[skal]

thanks squid_80!

(arf, now everybody knows i'm copy-pasting ;) )

-Skal