id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
847	Residual semantic bugs	laurent.birtz@…	bbross	"7.4.9.11: Residual coding semantics:

In the description of coded_sub_block_flag: ""If (xS, yS) is equal to
(0, 0), at least one of the 16 significant_coeff_flag syntax elements is
present for the sub-block at location (xS, yS).

What if only the first TB coefficient is non-zero? In that case its
value would be inferred from last_significant_coeff and no
significant_coeff_flag would be present.

 
7.4.2.2: Sequence parameter set RBSP semantics:

The usage of ScanOrder is inconsistent. Description for
log2_diff_max_min_transform_block_size: ""For the variable log2BlockSize
ranging from Min( 2, Log2MinTrafoSize − 2) to 3, inclusive, the scanning
order array ScanOrder is derived as follows"".

Suppose 4x4 transforms are allowed. Then, Log2MinTrafoSize == 2, the
range for log2BlockSize is [0, 3] and the 4x4 array is mapped at index 0
in ScanOrder.

However, in 7.3.9.11, ScanOrder[2] is used to derive the scan order of
the 16 coefficients: ""xC = ( xS << 2 ) + ScanOrder[ 2 ][ scanIdx ][ n ][
0 ]"". ScanOrder[2] does not correspond to the 4x4 transform.

 
7.4.6: Scaling list data semantics

""scaling_list_pred_mode_flag[ sizeId ][ matrixId ] equal to 0 specifies
that the values of the scaling list are the same as the values of a
reference scaling list.""

The name has the opposite meaning of the usage.

 
7.3.6: Scaling list data syntax:

The interaction between scaling_list_delta_coef and
scaling_list_dc_coef_minus8 is suspicious.

There are 64 scaling_list_delta_coef values present even if
scaling_list_dc_coef_minus8 is present.

First, ScalingFactor is built from scaling_list_delta_coef:
""ScalingFactor[ 3 ][ matrixId ][ x * 4 + k ][ y * 4 + j ] =
ScalingList[ 3 ][ matrixId ][ i ]"".

Then, the first value in ScalingFactor is overridden:
""ScalingFactor[ 3 ][ matrixId ][ 0 ][ 0 ] =
scaling_list_dc_coef_minus8[ 1 ][ matrixId ] + 8"".

It seems to me that the only sensible value for the first
scaling_list_delta_coef is 0 since scaling_list_dc_coef_minus8 covers
the full range of possible values for the first entry in ScalingFactor.
I presume that the first scaling_list_delta_coef is present only to ease
the parsing of the syntax. If that's the case, I suggest to require the
first scaling_list_delta_coef value to be 0. The current logic is
confusing and slows down the parsing operation.
"	defect	closed	minor	HM-9.1	Text	D9 (K1003) v9	fixed		bbross wjhan jct-vc@…