[XviD-devel] [BUG]

[skal]

	Hi all,

On Wed, 2003-10-29 at 18:20, Michael Militzer wrote:

> > skal (skal at planet-d.net) wrote:
> > > 	Sure.
> > > 
> > > 	(read the comments: idct is not IEEE compliant, on
> > > 	purpose, since it doesn't abide to the silly [-300,300]
> > > 	input range test).
> > 
> > The old ones were  known to be unprecise too, so we'll  give these one a
> > try, and let SSE2 users see if they're fine enough to be used.
> 
> 1) All idct code ever used in XviD was IEEE 1180 compliant (keep that in
> mind when calling it 'unprecise').
> 

	indeed, i think a reminder/clarification about 'unprecise'
	wouldn't hurt:

IEEE-1180 specifies an acceptable range of errors when you follow
the following process:
1) take a random 8x8 matrix with coefficients in range [-R,R[
2) perform double-precision "exact" fdct on this matrix
3) Apply the Idct you want to test to the result of 2)
4) Compare result of 3) with the original random matrix of 1)
5) repeat 10000 times

	The sum/peak of (squared/) errors obtained in the end
	should be less than some given, normative values.

	Now, there are several ranges [-R,R[ a compliant
	idct should pass the test. Amongst which R=300.
	This one is useless for 8b video, since no idct
	output can be outside [-256,256[ range.

	(and this is this one i don't support, using up
	all 16bits of precision to support [-256,256[
	range with no extra instructions. For comparison,
	it's like requiring a car to be able to run
	at 150mph for going on roads with speed limit
	of 90mph. Well, a car exploding at 91mph would
	suffice (cf. Speed III with Sandra Bullock?:))

	that's it.

	bye!
Skal


Note: IEEE does not specify precision for the fdct (encoding). 
Only decoding (idct)

> 2) Please do not even think of using Skal's idct code or we'll get into
> very serious trouble again because of idct mismatches between the XviD P4
> version and the regular version

Note2: I also have SSE, MMX and plain-C versions if you want to
get further corrupted with un-precision ;)