Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#1230 closed defect (fixed)

Deblocking of horizontal edges 422

Reported by: cchi-jctvc Owned by:
Priority: major Milestone: HM+RExt-7.0
Component: HM RExt Version: RExt-5.0 (HM-12.1)
Keywords: deblock 422 Cc: davidf, karlsharman, jct-vc@…

Description (last modified by davidf)

Dear experts,

there is a possible mismatch in the RExt D5 (01005v4) and HM-12.1+RExt-5.1 for deblocking with 422 subsampling. In the following luma CB/TB partitioning for a 16x16 CB two horizontal edges are considered for filtering:

      luma 16x16                
-----------------------    <- considered for filtering (1)
|          |          |      
|  8x8     |   8x8    |     
|  TU      |   TU     |     
|          |          |     
-----------------------    <- considered for filtering (2)
|          |          |
|  8x8     |   8x8    |
|  TU      |   TU     |
|          |          |
-----------------------

For the corresponding chroma part for both 420 and 422 only (1) is considered and (2) is not considered:

TComLoopFilter.cpp:223

if ( chFmt!=CHROMA_400
 && (bAlwaysDoChroma
  || (uiPelsInPart>DEBLOCK_SMALLEST_BLOCK)
  || (iEdge % ( (DEBLOCK_SMALLEST_BLOCK<<'''1''')/uiPelsInPart ) ) == 0)
) {
   xEdgeFilterChroma   ( pcCU, uiAbsZorderIdx, uiDepth, edgeDir, iEdge );
}

Here there is from my understanding a difference in the text and software exist as the text (8.7.2.5.2) edge (2) also is filtered in 422 but not in 420. It might be a misinterpretation from the text.

The question basically boils down to: do chroma TB and PB boundaries that are in 420 not on a 8x8 grid, and in 422 are promoted to the 8x8 grid, need to be filtered? Note that in the current software chroma CB boundaries that are promoted in such a way are filtered, so for the corresponding case with 4 8x8 CBs would result in both (1) and (2) being filtered for 422.

Best,
Chi

Change History (7)

comment:1 Changed 11 years ago by DefaultCC Plugin

  • Cc davidf karlsharman jct-vc@… added

comment:2 Changed 11 years ago by cchi-jctvc

Any thoughts on this?

comment:3 Changed 11 years ago by davidf

  • Description modified (diff)

comment:4 Changed 11 years ago by crosewarne

I think the text is OK but the software has a bug.

The expression (DEBLOCK_SMALLEST_BLOCK << 1) is OK for 4:2:0 but not OK for 4:2:2.

The following code should resolve the issue in 4:2:2 (and remove the need for special handling of 4:4:4 via bAlwaysDoChroma):

  TComPicYuv* pcPicYuvRec = pcCU->getPic()->getPicYuvRec();
  const UInt shiftFactor = (edgeDir == EDGE_VER ? 
    pcPicYuvRec->getComponentScaleX(COMPONENT_Cb) : 
    pcPicYuvRec->getComponentScaleY(COMPONENT_Cb));

  ...
    if ( chFmt!=CHROMA_400 && 
         ((uiPelsInPart>DEBLOCK_SMALLEST_BLOCK) || 
          (iEdge % ( (DEBLOCK_SMALLEST_BLOCK<<shiftFactor)/uiPelsInPart ) ) == 0 ) )
     {
       xEdgeFilterChroma   ( pcCU, uiAbsZorderIdx, uiDepth, edgeDir, iEdge );
     }

comment:5 Changed 11 years ago by karlsharman

Fixed in r3869.

comment:6 Changed 11 years ago by davidf

  • Milestone changed from RExt D5 to HM+RExt-6.1
  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from RExt D5 (O1005) v3 to RExt-5.0 (HM-12.1)

comment:7 Changed 10 years ago by ksuehring

  • Milestone changed from HM+RExt-6.1 to HM+RExt-7.0
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • cchi-jctvc(Reporter, Participant)
  • Chris Rosewarne(Participant)
  • David Flynn(Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • Karl Sharman(Subscriber, Participant)
  • karl.sharman@…(Always)
  • Karsten Suehring(Participant, Always)