Opened 10 years ago

Last modified 10 years ago

#1230 closed defect

Deblocking of horizontal edges 422 — at Initial Version

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

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


| | |
| 8x8 | 8x8 |
| TU | TU |
| | |


| | |
| 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 (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)
  • David Flynn(Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • Karl Sharman(Subscriber, Participant)
  • karl.sharman@…(Always)
  • Karsten Suehring(Participant, Always)