Range of refT and refL for MIP in 8.4.5.2.2

[bheng]

In Section 8.4.5.2.2, in the following sentence:

"For the generation of the reference samples refT[ x ] with x = 0..refW − 1 and refL[ y ] with y = 0..refH − 1, the following applies"

I think refW and refH should probably be replaced with nTbW and nTbH, respectively, since that would match up with the actual range over which refT and refL are derived in Equations (255) and (256).

"The reference samples refT[ x ] with x = 0..nTbW − 1 and refL[ y ] with y = 0..nTbH − 1 are assigned as follows:

refT[ x ] = refUnfilt[ x ][ −1 ] (255)
refL[ y ] = refUnfilt[ −1 ][ y ] (256)"

[jlchen]

It seems that that "refT[ x ] with x = 0..nTbW − 1 and refL[ y ] with y = 0..nTbH − 1 " are used in the MIP process. It is a bit weird to me why refW and refH is defined as follows in the spec.

refW = nTbW + 1 (253)
refH = nTbH + 1 (254)

Should we just modify them as

refW = nTbW (253)
refH = nTbH (254)

This should not have impact on 84.5.2.9 output since we don't have CIP in VVC.

[bheng]

I was guessing there must be some corner case there where the top samples are unavailable but the top-right sample is available (raster scan slices for example). I'm guessing that's why the reference is extended by 1 extra pixel before 8.4.5.2.9, but I'm not 100% sure.

[jlchen]

I will just take your change, for the safety at this moment.

I think VVC should not have the case that "the top samples are unavailable but the top-right sample is available".

[bbross]

I would be careful of changing anything last minute now there before not at least Frank or maybe Jonathan can confirm. I remember that there was quite some discussion around this part of the text.

[fbossen]

I think this was discussed in JVET-Q0371 when the +1 was added. From the notes: "The contribution points out a mismatch in a non-CTC case (TU and CTU of same size, 32 or 64)". However the conclusion at the time may not apply to the final spec since if the top-right samples are within the same slice as the current CB but the top samples aren't, that means that the top-right samples are in a different tile and hence unavailable. So there should be no case where padding of the reference array occurs using a top-right sample.

[jlchen]

Ok, let's take Brian's initial bug fix, and close this ticket for now.