[XviD-devel] [BUG]

skal skal at planet-d.net
Thu Oct 30 22:35:06 CET 2003



	Hi Walken ! (long time no see:)

On Wed, 2003-10-29 at 23:35, Michel LESPINASSE wrote:
> Hi Skal :)
> 
> On Wed, Oct 29, 2003 at 09:09:30PM +0100, skal wrote:
> > 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
>     2b) quantify fdct output to be integers, saturate to -2048;+2047 range
> > > 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
> > 
> > 	In fact the test is not that one. Instead, you
> > 	must compare, at step 3), the result of the reference
> > 	idct (double-precision) against your Idct. And not
> > 	compare with the original matrix (which is an interesting
> > 	test, but not the IEEE one).
> 
> Step 2b is important there. Because of this quantize-and-sature step,
> the full precision idct result is not identical to the original matrix -
> and if saturation occured, the difference could be large too.
> 
> In a real mpeg encoder, step 2b is even worse: you quantify not just
> to the nearest integer, but to the closest multiple of a given
> quantization factor, which might potentially be large.
> 
	very true. And respecting the specs regarding dequant
	saturation is a real pain (cf. comment in
	dequant_mpeg_intra_mmx() func, e.g.)

> So even though we have a guarantee that the original fdct input is
> within -255;+255 range, we still don't have any guarantee that the
> full precision idct output will be in that range too. That's why the
> IEEE people specify a test range of +- 300; the mpeg people on the
> other hand, do not consider this sufficient and require an additional
> test with a range of -384;+383 and one million iterations. There is
> also an mpeg1 test stream, known as compcore/ccm1, which has been
> purposefully created with checker like patterns that tend to create
> internal overflow in IDCT routines, and large quantization factors. 

	seems an interesting stream. Do you have it somewhere?


> PS skal: hmmm, maybe I should ask if you have an ultrasparc VIS
> routine handy ? :)

	you mean, the one with all the *ptr++ and *ptr--? 
	I thought you had stopped gluttony :)_

	cheers,

Skal




More information about the XviD-devel mailing list