#1356 closed defect (fixed)

Range of refT and refL for MIP in 8.4.5.2.2

Reported by: bheng Owned by:
Priority: minor Milestone:
Component: spec Version: VVC D10 vE
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…

Description

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)"

Change history (6)

comment:1 Changed 14 months ago by 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.

comment:2 Changed 14 months ago by 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.

comment:3 Changed 14 months ago by 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".

comment:4 Changed 14 months ago by 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.

comment:5 Changed 14 months ago by 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.

comment:6 Changed 14 months ago by jlchen

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.