[Mp4-tech] Why in AVC standard the inverse Hadamar transform for DC chroma and DC luma precedes the inverse quantization process

[Gary Sullivan]

Shevach Riabtsev et al,
If I recall correctly, the other order would have increased the dynamic range (i.e. processing wordlength) needed for those stages of the processing.  That trick helped keep everything easily implementable with 16 bit wordlengths for 8 bit decoded sample bit depth.  Some sources that may describe this aspect could be Q15-F-11, VCEG-N20, VCEG-N43, VCEG-N44, VCEG-O09, JVT-B038, JVT-B039, JVT-C024 and the paper by Malvar, Hallapuro, Karczewicz, and Kerofsky in the IEEE Trans CSVT issue of July 2003 (pp. 598-603).
(But I just glanced at the CSVT paper and didn't spot it there.)
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces lists.mpegif.org [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Shevach Riabtsev
Sent: Tuesday, May 13, 2024 6:47 AM
To: mp4-tech lists.mpegif.org
Subject: [Mp4-tech] Why in AVC standard the inverse Hadamar transform for DC chroma and DC luma precedes the inverse quantization process
Dear experts
Unless I am mistaken in AVC standard the inverse Hadamar transform for DC chroma and DC luma precedes the inverse quantization process. This is in contrast to the decoding of non-DC blocks.
Indeed for non-DC block, the residuals shall be inverse quantized and then inverse transformed, while for DC block the residuals shall be inverse Hadamar-transformed and then inverse quantized (the obtained results are then combined with AC inverse quantized coefficients to form 4x4 blocks and finally each 4x4 block is again inverse transformed).
Why AVC designers didn't accept the following chain of decoding operationsfor DC blocks: first of all inverse quantize and then inverse trensforms? What reasoning behind?
Regards,  Shevach
Broadcom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20080513/2dde4984/attachment.html