International organisation for standardisation organisation internationale de normalisation

5.7Deblocking filter

5.7.1.1.1.1.1.1.1JCTVC-H0190 Non-CE10: Difference-QP-based Deblocking [K. Sato (Sony)]

In common test conditions, the QP value remains the same within a picture, but in real applications it will vary. Performance of HEVC with varying QP should well be studied before it becomes an international standard.

One of the tools that should be studied under the varying QP scenario is the deblocking filter. In the 7th meeting, there were two proposals related to this topic. One was JCTVC-G384, which proposed using the maximum QP of the two neighbouring blocks for deblocking. Another was JCTVC-G640, which proposed using the average QP. The latter one is the same as AVC and was adopted into HM-5.0.

However, it is asserted that blocking artefacts are visible if the QP of one block is small and the one for the other block is large. Either of the previous proposals can reportedly reduce such blocking artefacts.

This document proposes one additional operation for the deblocking filter that is asserted to take the difference of QPs of neighbouring blocks into account.

This document proposes the following additional logic into the strong/weak filter criterion:

if (Bs > 0) && (AVE[QP_P, QP_Q] >= 34) && (Diff[QP_P, QP_Q] >=8)

StrongerFilterApplied;

Still-frame examples of the asserted subjective benefit were shown.

In PSNR terms, a small loss was reported (0.1-0.2%).

It was commented that the idea seems attractive and worthy of study, as we should avoid neglecting the consideration of non-constant-QP operation. However, the particular method of approaching the issue did not necessarily seem like the most clean and correct approach. Further study of deblocking for non-constant QP was requested to be performed in an AHG.

5.7.1.1.1.1.1.1.2JCTVC-H0644 Non-CE10: Cross-verification report for difference-QP-based deblocking (JCTVC-H0190) [H. Aoki, K. Chono (NEC)] [late 02-04]

The cross-checker did not check visual quality.

5.7.1.1.1.1.1.1.3JCTVC-H0275 Non-CE10: Introduction of strong filter clipping in deblocking filter [M. Ikeda, T. Suzuki (Sony)]

This contribution addresses strong filter operation in deblocking filter. The strong filter currently does not have a clipping process, but the weak filter does.

In some cases, especially in Class F, the pixel value is changed by a large amount when the strong filter is applied.

In this proposal, a clipping process using 2*tc is proposed to be introduced to strong filter operation. It was asserted that this proposed technique can prevent pixels from being filtered too much.

It was reported that the average compression impact results, excluding class-F, are as follows: AI HE: 0.0%, RA HE: 0.0%, RA HE10: 0.0%, LB HE: 0.0%, AI LC: 0.0%, RA LC: 0.0% and LB LC: 0.0% and that the average ones including class-F are as follows: AI HE: 0.0%, RA HE: -0.1%, RA HE10: 0.0%, LB HE: -0.1%, LP HE: -0.1%, AI LC: -0.1%, RA LC: -0.1%, LB LC: -0.2% and LP LC: -0.1%.

The overall impact on Class F PSNR is beneficial in all cases: 0.4-0.7% benefit on average in every configuration.

Considering the use of clipping in the weak filter case, this may be characterized as a bug fix.

Decision: Adopted.

5.7.1.1.1.1.1.1.4JCTVC-H0587 Non-CE10: Cross check of the introduction of strong filter clipping in deblocking filter of Sony (JCTVC-H0275) [M. Narroschke, A. Kotra, S. Esenlik (Panasonic)] [late]

5.7.1.1.1.1.1.1.5JCTVC-H0281 Non-CE10: Removing QP line buffer [Y.-W. Chen, J.-L. Lin, Y.-W. Huang, S. Lei (MediaTek)]

In HM-5.0, deblocking filter (DF) employs an average of QPs on both sides of an edge to look up the β and t_c parameters. When LCUs are processed by the DF in a raster scan order, each LCU needs the QP values from its upper LCU. Therefore, a line buffer of 3.9K bits is required to store QPs of upper LCUs for 4Kx2K video in hardware. Since the QP line buffer is only used by the DF, in this contribution, a simplified DF is proposed to remove the QP line buffer as follows. When processing the horizontal edges between a current LCU and its upper LCU, only the QP of the current LCU is used. Simulation results reportedly show that the proposed method introduces no meaningful change in BD bit rates and run times when QP adaptation is enabled on top of the JCTVC-G1200 common test conditions. The proponents also claim that the visual quality is the same as HM-5.0.

It was noted that the "line buffer" is at the QP granularity, which is probably a factor of 8 or 16 lower than the pixel level.

QP variation conditions of CE10 were used in experiment. No degradation of visual quality was reported.

It was remarked that this seems to conflict with the spirit of H0190, and could hypothetically cause line-buffer-related artefacts at LCU row boundaries.

Relatively modest modifications of QP were tested.

The minimum spatial granularity of QP variation in the profiles (which are yet to be defined) has not yet been determined. It could hypothetically be as small as 4x4, although it seems unlikely that we would want to allow that.

Further study (along with H0190) in an AHG was encouraged.

5.7.1.1.1.1.1.1.6JCTVC-H0639 Cross-check report on Removing QP line buffer (JCTVC-H0281) [I.-K Kim (Samsung)] [late]
5.7.1.1.1.1.1.1.7JCTVC-H0424 Non-CE10 Subtest 4: On Deblocking Parameter Signalling [G. Van der Auwera, Y.-K. Wang, X. Wang, M. Karczewicz (Qualcomm)]

This contribution proposes to add a condition in the slice header that checks the deblocking_filter_in_aps_enabled_flag to determine whether deblocking parameters are signalled in the APS, and in only that case it is proposed to include the inherit_dbl_params_from_APS_flag in the slice header. The benefit is that the signalling overhead of the inherit_dbl_params_from_APS_flag is avoided in case deblocking parameters are only signalled in the slice header.

Closely related to H0398, and actually more a matter of high-level syntax than deblocking filtering.

Decision: This aspect is adopted (merged with adoption as recorded in notes for H0398).

In addition, this contribution addresses a minor mismatch between the working draft text and the HM5.1 source code. However, this had already been fixed in a more recent draft.

Also, a potential non-normative improvement of the deblocking filter source code was suggested. This (non-normative) aspect was delegated to the software coordinator for consideration.

5.7.1.1.1.1.1.1.8JCTVC-H0577 Cross-verification of Qualcomm proposal JCTVC-H0424 on deblocking filtering [A. Norkin (Ericsson)] [late]
5.7.1.1.1.1.1.1.9JCTVC-H0448 AHG6: Deblocking of IPCM Blocks Containing Reconstructed Samples [G. Van der Auwera, X. Wang, M. Karczewicz (Qualcomm)]

This contribution addresses the deblocking of IPCM blocks containing reconstructed samples. The HM5 deblocking filter always assigns the quantization parameter (QP) value 0 to IPCM blocks, independent of the value of the pcm_loop_filter_disable_flag (SPS), which results in inadequate QP values for deblocking parameter lookup. The proposal is to assign the reconstructed QP value (QPY) to the IPCM blocks in case deblocking is enabled on IPCM samples (pcm_loop_filter_disable_flag equals 0). In case deblocking is disabled on IPCM samples (pcm_loop_filter_disable_flag equals 1), deblocking filtering of non-IPCM samples is proposed to be determined by the reconstructed QP value of the non-IPCM block that is neighbouring the IPCM block, while the IPCM block is assigned QP value 0.

Based on the discussion, a suggested CE or AHG starting basis (AHG6, established as recorded below) we outlined as follows:

• 
  Never deblock inside of IPCM regions
  
• 
  Send a QP for the IPCM region (terminate CABAC, then send number of successive blocks n, then send n QP values using FLC with the minimum number of bits needed for the QP range or as delta QP with se(v) or as ue(v), then send byte alignment bits, then send samples).
  
• 
  Outside of the IPCM region, apply deblocking as usual.
  

5.7.1.1.1.1.1.1.10JCTVC-H0578 AHG6: Inspection report on deblocking of IPCM Blocks containing reconstructed samples (JCTVC-H0448) [K. Chono, H. Aoki (NEC)] [late]
5.7.1.1.1.1.1.1.11JCTVC-H0722 Clarification request on varying QP in deblocking [M. Horowitz (eBrisk)] [late 02-05]

It was reported that the software does not use unavailable QP values to derive beta and t_c values for deblocking, but text seems to.

Decision (SW): The software (as well as the text) should use the neighbour region's QP whenever deblocking the boundary edge with a neighbouring region, regardless of whether it is in a different slice or tile (unless otherwise controlled – e.g. by disabling the filter at that boundary).

5.7.1.1.1.1.1.1.12JCTVC-H0733 Response to clarification request on varying QP in deblocking in JCTVC-H0722 [C.-W. Hsu, C.-Y. Tsai, Y.-W. Huang, S. Lei (MediaTek)] [late 02-06]