[Mp4-tech] MPEG4 Simple Profile question. Is DC/AC saturation in the range [-2048, 2047] redundant provided that bits_per_pixel is 8?

[Shevach Riabtsev]

Gary
Thanks for your reply. I completely agree with you but one subtle point.
In Simple Profile DC residuals are limited to the range [-511,511]
according to the Note in B.1.4 and Table B-15:
The variable length code for dct_dc_size_luminance of 10, 11 and 12 are
not valid for any object types where the pixel depth is 8 bits. They
shall not be present in a bitstream conforming to these object types.
Therefore DC values obtained from DC prediction will not exceed
[-1024..1024] range. So, I see that the DC clipping is redundant in a
Simple Profile decoder. 
Regards
________________________________
From: Gary Sullivan [mailto:garysull windows.microsoft.com] 
Sent: Thursday, April 17, 2024 2:47 AM
To: Shevach Riabtsev; mp4-tech lists.mpegif.org
Subject: RE: [Mp4-tech] MPEG4 Simple Profile question. Is DC/AC
saturation in the range [-2048, 2047] redundant provided that
bits_per_pixel is 8?
Shevach Riabtsev et al,
I think the clipping is necessary.  The first thing to remember is that
the standard specifies the decoding process and the constraints on
bitstream conformance.  It does not specify how encoding is done.  So if
you are trying to base your rationale on what you assume that an encoder
must be doing, you need to give up and stop looking at things from that
perspective.
Section A.1 was replaced a year or two ago - part of the purpose of that
replacement was to clarify what the standard was trying to say.  It
would be best to make sure that you're looking at the latest version of
that section if you want to refer to something in it.  And make sure
that you're aware of the difference between normative and non-normative
aspects of the standard.  My guess is that you're trying to refer to the
forward DCT operation, which is not normative, since that is something
that happens (if it happens) only in an encoder - and encoding methods
are not normatively specified by the standard.  Encoders are not
actually required to use a forward DCT.
I think you are correct that dc_scaler is always at least 8 for Simple
profile.
There is an equation at the beginning of 7.4.3.2 that specifies how
QFx[0][0] is computed using PQFx[0][0], dc_scaler, and Fa[0][0] or
Fc[0][0].  So to determine the range of values, prior to the clipping
specified at the beginning of 7.4.3.4, you should examine the ranges of
values that those four variables can have, and then assume an "evil"
worst case combination of them for the equation in 7.4.3.2.  Again,
don't assume that the encoder is doing anything friendly.  Assume that
the encoder has been designed to try to force a violation of the
clipping range without regard to whether you would consider what it is
doing to be sensible.
Best Regards,
Gary Sullivan
________________________________
	From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Shevach Riabtsev
	Sent: Wednesday, April 16, 2024 6:55 AM
	To: mp4-tech lists.mpegif.org
	Subject: [Mp4-tech] MPEG4 Simple Profile question. Is DC/AC
saturation in the range [-2048, 2047] redundant provided that
bits_per_pixel is 8?
	Dear experts 
	I have a question on MPEG4 Simple Profile related to DC/AC
quantized coefficient saturation. 
	According to 7.4.3.4 
	The quantized coefficients resulting from the DC and AC
Prediction are saturated to lie in the range [-2048, 2047].
	In MPEG4 Simple Profile bits_per_pixel value is 8, I don't see a
case when a quantized DC or AC coefficient can exceed [-2048,2047]
range. 
	For example,  DC obtains the maximal value equal 8*255 = 2040
provided that all pixels in a 8x8 block are 255, see A.1. The minimal DC
quantization scaler is 8 (see Table 7-1). Thus the maximal quantized DC
magnitude is 2040/8=255. Hence DC residual lies in the interval
[-255..255].  The same reasoning can be applied to AC case. 
	Thus I conjecture that AC/DC coefficients satuaration is
redundant in Simple Profile. Am I right?
	Regards, Shevach 
	Broadcom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20080417/6acb552a/attachment.html