Opened 4 months ago

Last modified 4 weeks ago

#1632 new defect

Incorrect indexing used for choosing matrix intra sample prediction

Reported by: peterderivaz Owned by:
Priority: minor Milestone: H.266/VVC v4
Component: spec Version: H.266/VVC v3
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…

Description

Clause 8.4.5.2.1 reads:

Inputs to this process are:
– a sample location ( xTbCmp, yTbCmp ) specifying the top-left sample of the current transform block relative to the 
top-left sample of the current picture,
...
if MipChromaDirectFlag[ xTbCmp ][ yTbCmp ] is equal to 1 and cIdx is not equal to 0, 

This looks up values in MipChromaDirectFlag based on counts of chroma samples.

However, when MipChromaDirectFlag is derived, the indexing is done based on counts of luma samples:

 Derivation process for chroma intra prediction mode
Input to this process are:
– a luma location ( xCb, yCb ) specifying the top-left sample of the current chroma coding block
  relative to the top-left luma sample of the current picture,
...
In this process, the chroma intra prediction mode IntraPredModeC[ xCb ][ yCb ] and the MIP chroma direct mode flag 
MipChromaDirectFlag[ xCb ][ yCb ] are derived.

I think this can be fixed by changing 8.4.5.2.1 to use "MipChromaDirectFlag[ xTbCmp * SubWidthC ][ yTbCmp * SubHeightC ]" instead of "MipChromaDirectFlag[ xTbCmp ][ yTbCmp ]".

Change history (1)

comment:1 Changed 4 weeks ago by bbross

  • Milestone set to H.266/VVC v4
  • Version set to H.266/VVC v3

Good catch, thanks! This was indeed an oversight and should take the chroma subsampling into account as suggested. Will be fixed in v4.

Note: See TracTickets for help on using tickets.