For the Chroma longer tap deblocking, longer tap filter is currently switched off at the horizontal CTU boundaries to reduce line buffer.

In the VTM-5.0 code, in function xEdgeFilterChroma, the position for the horizontal CTU boundary seems to be computed incorrectly, which is as follows: pos.y % cuP.slice->getSPS()->getCTUSize() == 0 which does not take into account the Chroma re-scaling based on the Chroma format.

A possible fix could be as follows: (pos.y % (cuP.slice->getSPS()->getCTUSize() >> ::getComponentScaleX(COMPONENT_Cb, nChromaFormat)) == 0)

In Secion 8.8.1, there seems to be a typo in Step 4 ("sample adaptive offset" should be replaced by "adaptive loop filter" as shown below)

4. When sps_alf_enabled_flag is equal to 1, the following applies:

– The adaptive loop filter process as specified in clause 8.8.5.1 is invoked with the reconstructed picture sample array SL and, when ChromaArrayType is not equal to 0, the arrays SCb and SCr as inputs, and the modified reconstructed picture sample array S′L and, when ChromaArrayType is not equal to 0, the arrays S′Cb and S′Cr after sample adaptive offset adaptive loop filter as outputs.

In section 8.8.2.6.3, Equation 1364 and corresponding sematics use slice_cr_beta_offset_div2. This should be replaced with slice_cr_tc_offset_div2 as shown below:

The value of the variable tC′ is determined as specified in Table 43 based on the chroma quantization parameter Q derived as follows: sliceTcOffsetDiv2 = ( cIdx = = 1 ? slice_cb_tc_offset_div2 : slice_cr_betatc_offset_div2 ) Q = Clip3( 0, 65, QpC + 2 * ( bS − 1 ) + ( sliceTcOffsetDiv2 << 1 ) ) (1364) where slice_cb_tc_offset_div2 and slice_cr_betatc_offset_div2 are the values of the syntax elements slice_cb_tc_offset_div2 and slice_cr_betatc_offset_div2, respectivelyl, for the slice that contains sample q0,0.