id summary reporter owner description type status priority milestone component version resolution keywords cc 844 Deblocking filter typos laurent.birtz@… bbross "8.7.2.3: Derivation process of boundary filtering strength ""where xL is equal to ((( xC + xDi ) >> 3) << 3) + ((( xC + xDi ) >> 3) & 1) * 7"" Is this a removal oversight from Draft 9? The same condition was removed from 8.5.3.1.2: Derivation process for spatial merging candidates. 8.7.2.4.3: Decision process for luma block edges ""The variable dqp is set equal to 2*dpq0."" Should be dpq instead of dqp. 8.7.2.4.5: Filtering process for chroma block edges ""Q = Clip3( 0, 53, QPC + 2 * ( bS − 1 ) + ( tc_offset_div2 << 1 ) )"" Should be qPi instead of QPC. 8.7.2.4.7: Filtering process for a luma sample ""each of the filtered sample values, pi' with i = 0..nDp−1, is substituted by the corresponding input sample value pi"" Correct, but setting nDp = 0 is simpler. 8.7.2.4.1: Vertical edge filtering process: Quoting the unanswered question from Harish Mahendrakar which seems pertinent (I'd like to know the answer as well): HEVC draft mentions a grid of 8x8 for chroma deblocking with filtering done for 4 pixels at a time. What is the need for an 8x8 grid in chroma? Since chroma deblocking uses only 2 pixels each on both sides of the edge being filtered and only one pixel on each side is modified a grid of 8x8 is not needed. In luma filtering without 8x8 grid, all vertical edges (or all horizontal edges) cannot be filtered in parallel because, edge at a given 4 pixel boundary will need output from previous filter. But in chroma this problem does not arise because only one pixel on each side is modified. So 4x4 grid for chroma will not have any problems in multi-core implementation and also will ensure all intra edges (at luma 8x8 grid) will be filtered in both luma and chroma. Or was 8x8 grid for chroma specified to keep the computational complexity down? " defect closed minor HM-9.1 Text D9 (K1003) v9 fixed bbross wjhan jct-vc@…