Opened 12 years ago

Closed 12 years ago

#847 closed defect (fixed)

Residual semantic bugs

Reported by: laurent.birtz@… Owned by: bbross
Priority: minor Milestone: HM-9.1
Component: Text Version: D9 (K1003) v9
Keywords: Cc: bbross, wjhan, jct-vc@…

Description

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.

Change History (5)

comment:1 Changed 12 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 12 years ago by laurent.birtz@…

As per Karsten suggestion, I'm copy-pasting a comment sent by email:

"The scaling list data syntax seems fine.

Consider a 32x32 block size. The first value in scaling_list_delta_coef
is used to set the ScalingFactor for the lowest 4x4 group of
coefficients (except the DC). The ScalingFactor corresponding to the DC
coefficient is set to (scaling_list_dc_coef_minus8 + 8). If the first
scaling_list_delta_coef is restricted to be 0 as per your suggestion,
that would force the ScalingFactor for the lowest 4x4 group of
coefficients (except DC) to be 0."

You are absolutely right. Sorry!

comment:3 Changed 12 years ago by bbross

Re: 7.4.9.11: Residual coding semantics
"What if only the first TB coefficient is non-zero?"
In that case lastSubBlock = 0, lastScanPos = 0 and coded_sub_block_flag[ xS ][ yS ] is inferred to be equal to 1 which, as you cited correctly, means that "at least one of the 16 significant_coeff_flag syntax elements is present for the sub-block at location (xS, yS)".
The problem is that the loop over the coefficients to parse the significant_coeff_flag:

for( n = ( i = = lastSubBlock ) ? lastScanPos − 1 : 15; n >= 0; n− − ) {

gets never executed because since i = lastSubBlock and lastScanPos = 0, n get initialized with lastScasnPos-1 = -1 which violated the condition n>=0.
A fix for that semantics issue would be to change
"– 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 ) ."
to
"– If ( xS, yS ) is equal to ( 0, 0 ) and ( LastSignificantCoeffX, LastSignificantCoeffY ) is not 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 ) ."

Re: 7.4.2.2: Sequence parameter set RBSP semantics:
The current definition of scan order is consistent because it is defined for log2BlockSizes. For the 4x4 sub-blocks, the log2BlockSize is always equal to 2 and thus ScanOrder is indexed correctly with 2. The indexing with log2TrafoSize − 2 serves to get the scan order of the sub-blocks, that is why the coefficient location xC, yC is 4x4 ScanOrder plus the sub-block location xS,yS.

comment:4 Changed 12 years ago by laurent.birtz@…

You are correct about the scan order. Apologies.

comment:5 Changed 12 years ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • Benjamin Bross(Owner, Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • laurent.birtz@…(Reporter, Participant)
  • Woo-Jin Han(Subscriber)