Opened 5 years ago

Closed 5 years ago

#567 closed defect (fixed)

Issues with numSbX and numSbY in Section 8.5.5.2

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

Description

1.) SBTMVP values overwritten by Affine
For SBTMVP, the numSbX and numSbY values get set in Step 1, but they get overwritten in Step 2 (the affine candidate derivation), regardless of whether the final selected vector was Sub-PU or Affine.

It seems like there should be something like a numSbColX / numSbColY and a separate numSbAffineX / numSbAffineY, and the final values should be determined based on whether the selected candidate was SbCol or not.

2.) Unassigned Sub-Block Size
If SBTMVP is enabled, but not available, numSbX and numSbY don’t get set to anything in Section 8.5.5.3. And, if affine is also disabled (sps_affine_enabled_flag = 0), numSbX and numSbY don’t get set to anything in Section 8.5.5.2 either. Therefore, the resulting (0,0) candidate, derived in Step 8, doesn’t have a numSbX or numSbY assigned.

Normally the sub-block size of a (0,0) candidate wouldn’t make much difference (4x4 vs 8x8), but RPR results are different depending on whether they are applied on an 8x8 or 4x4 basis, so some valid value has to be assigned here.

Note, currently VTM treats this (0,0) candidate in this situation like affine (4x4 sub-blocks) even though affine is disabled. This may not be the desired behavior.

Change history (4)

comment:1 Changed 5 years ago by bbross

  • Version changed from VVC D6 vE to VVC D7 vC

comment:2 Changed 5 years ago by bbross

  • Version changed from VVC D7 vC to VVC D7 vD

comment:3 Changed 5 years ago by bbross

  • Version changed from VVC D7 vD to VVC D7 vE

comment:4 Changed 5 years ago by jlchen

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

Item 1 is to be fixed as suggested.
Item 2 is to be fixed to match with software.

Note: See TracTickets for help on using tickets.