Clarification on 9.3.3.2 Rice parameter derivation process

[marie-pierre.gallasso]

I think that the specification needs to add clarification on input parameters of 9.3.3.2 Rice parameter derivation process for abs_remainder[] and dec_abs_level[] paragraph.

Inputs to this process are some parameters and especially the scan location (xC, yC), the binary logarithm of the transform block width log2TbWidth, and the binary logarithm of the transform block height log2TbHeight.

The specification should clarify if the binary logarithm of the transform block width and the binary logarithm of the transform block height correspond to:

a) the value of the input parameters of residual_coding( x0, y0, log2TbWidth, log2TbHeight, cIdx )

or

b) the value of log2TbWidh and log2TbHeight after their possible modification inside residual_coding():

log2TbWidth = log2ZoTbWidth
log2TbHeight = log2ZoTbHeight

The VTM uses case a) to derive rice parameter for abs_remainder and dec_abs_level.

---

In case a), log2TbWidth and log2TbHeight may be equal to 6 (for a 64x64 transfo).
In case b), log2TbWidth and log2TbHeight may be equal to 5 (even for a 64x64 transfo).

scan location does not exceed (31, 31).

In locSumAbs derivation, the following condition (for a 64x64 transfo):

    if( xC < ( 1 << log2TbWidth ) - 1 )
    {
    }

does not take the same value when xC = 31.
case a): if (31 < 63) => true
case b): if (31 < 31) => false

Identical for yC.

For Main10, Main10_444, it has no impact but for range extension profiles as Main12_444 when sps_rrc_rice_extension_flag or sps_persistent_rice_adaptation_enabled_flag are enabled, the derivation process in case a) and b) may differ.

[dmytro.rusanovskyy]

Thank you for reporting on this. There is indeed a possibility for different interpretations of the specification text of the binarization in clauses 9.3.3.1, 9.3.3.2 and respective calls from syntax table 7.3.11.11.
Binarization of abs_remainder[ ] and dec_abs_level[ ] (clauses 9.3.3.2) is invoked with log2TbWidth and log2TbHeight as input, which are defined as a local variable across sections of 9.3.3 for the binary logarithm of the transform block width and height. VTM software follows this specification (for both VVCv1 and VVCv2) and uses transform block dimensions (m_width and m_height) to derive rice parameter.
At the same time, syntax table 7.3.11.11, receiving variables log2TbWidth and log2TbHeight as a binary logarithm of transform block dimensions, redefines its value, which can be interpreted as these redefined values should be used for invoking clause 9.3.3.2 (there is no explicit text, though).
To clarify the text, we would like to support the following solution:

1. Avoid redefinition of the input parameters log2TbWidth/log2TBHeight within syntax table (clause 7.3.11.11). Use a separate variable Log2ZoTbWidth within this table.
2. Define in syntax table (clause 7.3.11.11) a global variables Log2TbWidth/Log2TBHeight initialized with the input parameters. This global variable can be referred in the Table 127 of the clause 9.3.3.1.

abs_remainder[ ] 9.3.3.11 cIdx, current sub-block index i, x0, y0, xC, yC, Log2TbWidth, Log2TbHeight
dec_abs_level[ ] 9.3.3.12 cIdx, x0, y0, xC, yC, Log2TbWidth, Log2TbHeight

If agreed this text can be incorporated in the next version of the draft specification and the wording could be refined by editors.

[yk]

Thanks to you both! Fixed in JVET-X2005.