iDCT IEEE-1180 compliance question

[Cyberia]

In the DGDecode source file "skl_dct_sse.asm", I found this comment:

; -=IDCT=-
;
; A little slower than fdct, because the final stages (butterflies and
; descaling) require some unpairable shifting and packing, all on
; the same CPU unit.
;
; THIS IDCT IS NOT IEEE-COMPLIANT: IT WILL FAIL THE [-300,300]
; INPUT RANGE TEST (because of overflow). But the [-256,255] one
; is OK, and I'm fine with it (for now;)


Is idct=6 (Skal's SSEMMX iDCT) IEEE-1180 compliant or not? I can't tell from the code.

[squid_80]

IIRC, it's not. I think Skal made a slightly modified version that does conform, but I might be thinking of the SSE2 version. Either way it still produces output that is different from the other IDCTs, whether this is worth worrying about I'm not sure.

Maybe the SSE2 code could be used in a future version?

[neuron2]

Didn't jackei just do some work in this area? We could re-use his code.

[Cyberia]

Indeed! I hadn't realized that, but I just checked and Jackei has updated four (4) iDCTs!

IEEE-1180 Reference, MMX, SSE, SSE2 are all updated. There is a troubling line in his new Reference iDCT code:
// revised by Loli.J: bug fix together with rounding mode optimization
// clipping is unnecessary since motion compensation will saturate thereafter

We aren't motion-comping, so does the lack of clipping affect us? I admit I'm not even sure what he's talking about...

None of this affects Skal's iDCT being non-compliant, though. I don't think it's a big deal, but it would be nice to have all the iDCTs be compliant. As far as I can tell, all of the other iDCTs are compliant, including Jackei's new ones.

[Cyberia]

Skal has updated his iDCT also. At least I think he has. There is no date or version in either the new or old iDCT, but the one on his site seems to be more accurate than the one we have.

It has the exact same message about being non-compliant though. :confused:

http://skl.planet-d.net/coding/dct.html

Maybe in 1.4.0 we should update a bunch of iDCTs?

[skal]

Hi,
Originally posted by Cyberia
Skal has updated his iDCT also.

Unlike the example file skl_dct_c.c, the iDCT inside my codec sources (http://skal.planet-d.net/coding/sklmp4-0.23.tgz) is updated to be IEEE-Compliant(there's a #define for that in skl_dct_*.asm). Sorry for the confusion...

bye!
-Skal

[jackei]

clipping is unnecessary since motion compensation will saturate thereafter

Please let me explain in short.

The input and output range of normal iDCT codes are usually designed as 16-bit short integer (-32768 ~ 32767)

The output of a so-called IEEE-1180 compliant must be clipped to 8-bit (0~255), However...

(a) iDCT (16-bit) w/o clipping => MC w/ clipping => 8bit pixel
(b) iDCT (16-bit) w/ clipping => MC w/ clipping => 8bit pixel

There are no difference between the result of (a) and (b).
For the sake of speed, it's unnecessary to clip at the stage of iDCT in this case.