id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 1230,Deblocking of horizontal edges 422,cchi-jctvc,,"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 ",defect,new,major,RExt D5,HM RExt,RExt D5 (O1005) v3,,deblock 422,davidf karlsharman jct-vc@…