Inconsistent input block size (cb / tb) used which may result in incorrect decoding result in 8.7.5.3

[ksthey]

When 8.7.5.1 is invoked in 8.4.5.1 (General decoding process for intra blocks), input width & height (nCurrSw & nCurrSh) are set according to transform block size.

When 8.7.5.1 is invoked in 8.5.1 (General decoding process for coding units coded in inter prediction mode) & 8.6.1 (General decoding process for coding units coded in IBC prediction mode), input width & height (nCurrSw & nCurrSh) are set according to coding block size.

However, in 8.7.5.1, when 8.7.5.3 is invoked, the input width & height are mentioned as transform block width & height, as below:
– Otherwise (cIdx is greater than 0), the picture reconstruction with luma dependent chroma residual scaling process for chroma samples as specified in subclause 8.7.5.3 is invoked with the chroma location ( xCurr, yCurr ), the transform block width nCurrSw and height nCurrSh, the coded block flag of the current chroma transform block tuCbfChroma, the predicted chroma sample array predSamples, and the residual chroma sample array resSamples as inputs, and the output is the reconstructed chroma sample array recSamples.

Use of transform block or coding block size may result in an overall different decoding result for chroma component, because in 8.7.5.3, one of the condition to skip residual scaling process is "nCurrSw * nCurrSh is less than or equal to 4".

VTM seems like using transform block size for both intra & inter block to determine the aforementioned condition:

  //===== reconstruction =====
  flag = flag && (tu.blocks[compID].width*tu.blocks[compID].height > 4);
  if (flag && (TU::getCbf(tu, compID) || tu.jointCbCr) && isChroma(compID) && slice.getPicHeader()->getLmcsChromaResidualScaleFlag())
  {
    piResi.scaleSignal(tu.getChromaAdj(), 0, tu.cu->cs->slice->clpRng(compID));
  }

  //===== reconstruction =====
  const Slice           &slice = *cs.slice;
  if (slice.getLmcsEnabledFlag() && isChroma(compID) && (TU::getCbf(currTU, compID) || currTU.jointCbCr)
   && slice.getPicHeader()->getLmcsChromaResidualScaleFlag() && currTU.blocks[compID].width * currTU.blocks[compID].height > 4)
  {
    resiBuf.scaleSignal(currTU.getChromaAdj(), 0, currTU.cu->cs->slice->clpRng(compID));
  }

[jlchen]

It seems to me that we have bug in 8.5.1 (General decoding process for coding units coded in inter prediction mode) & 8.6.1 (General decoding process for coding units coded in IBC prediction mode). In the two subclauses, before invoking 8.7.5.1, the CU should be split into TUs based on MaxTUsize.

Can the related experts comments on this? And provide potential solution if the reported problem do exist.

[bbross]

Good catch thanks! This will be fixed in JVET-S2001-vH as suggested in the attached doc.