Organisation internationale de normalisation
Deblocking in SCC (AHG13) (6)
Yüklə 9,04 Mb.
|
Deblocking in SCC (AHG13) (6)See also S0112. 13.0.0.1.1.1.1.1.302JCTVC-S0044 AHG13: Chroma deblocking filter control for SCC [O. Nakagami, T. Suzuki (Sony)] (Consideration of this topic was chaired by A. Norkin on Saturday 10-18 p.m.) This contribution proposes chroma deblocking filter control for SCC. First, disabling deblocking filter was tested under SCC CTC. The existing pps_deblocking_filter_disabled_flag was set to 1. It is reported that the BD-rate difference {G/Y, B/U, R/V} is {+1.1, −0.6, −0.2}/{+1.2, −1.6, −1.5}/{−0.8, −1.5, −1.4} for AI/RA/LB, respectively. Then, disabling chroma deblocking filter was examined. The decoder was changed to skip the chroma process while the luma process was applied as the anchor. It is reported the result is {0.0, −0.6, −0.3}/{0.0, −1.7, −1.6}/{0.0, −1.6, −1.5}. Visual evaluation was also conducted. It is reportedly shown that the deblocking filter affects the character recognition result of the coded picture. Finally, text is proposed to control the chroma deblocking process. Syntax and semantics are presented. The focus is on RGB cases. For deblocking filter control, we have the following:
For example, chroma filtering can be weakened by increasing the chroma QP while decreasing the chroma quant matrix entry values. It can also be weakened by sending a large chroma QP at the slice header level but using a smaller QP at the block level. Basically, the only component-specific control we currently have for the deblocking filter is the component-specific quantization control. Substantially different results were measured depending on the type of content. It was remarked that the overall average across different types of content is not necessary appropriate for this proposal. It was remarked that objective measurements are not the best way to measure the impact of deblocking. It was suggested that with the various controls that we already have, something resembling what is suggested can be approximately accomplished without adding a new control. It was suggested that if we want to add another control, we could control each channel separately rather than grouping the two chroma channels together in the control mechanism. It was remarked that we should try to avoid adding differences relative to the base spec as much as possible. It was suggested to further study the issue since we already have chroma deblocking control in the spec. and we are not sure whether the current approach is optimal. Also since we are discussing changes of other aspects of the deblocking, the motivation for this proposal might also change. Further study was recommended. 13.0.0.1.1.1.1.1.303JCTVC-S0224 Cross-check of ‘AHG13: Chroma deblocking filter control for SCC’ (JCTVC-S0044) by Sony [C. Rosewarne, M. Maeda (Canon)] [late] The contributor was asked to submit a revision to correct the abstract. 13.0.0.1.1.1.1.1.304JCTVC-S0045 AHG13: On deblocking for screen content coding [C. Rosewarne, M. Maeda (Canon)] (Consideration of this topic was chaired by A. Norkin on Saturday 10-18 p.m.) This contribution proposes a modification of the deblocking filter to edges between blocks where intra-block copy is used. In this method, if the block on either side of the edge uses intra-block copy, then the boundary strength is set to 1 (even if the other block uses intra-prediction). Visual testing was performed and did not uncover any reduction in subjective quality. IBC currently uses strong deblocking, because it is treated as an intra mode. Intra uses Bs = 2. The proposal is to always use Bs = 1 for IBC (both sides of the block boundary), and Bs = 2 for other intra edges. The gains for chroma are up to 3.1% on RA and 4.8% on LD. Gains on luma are up to 0.2% on RA and 0.3% on LD. It was remarked that the gains shown are mostly for chroma, and the gain could alternatively be achieved by reducing or disabling deblocking of chroma. It was remarked that it would be desirable to consider harmonization of the proposals with the precious design and try to resuse the existing blocks as much as possible. It was remarked that we should not filter the block boundary if the two adjacent BV are identical. Further discussion was requested to be held after reviewing contributions on harmonization of IBC mode. See also S0112. Further discussion was chaired by A. Norkin Wed. 10-22 p.m. It was remarked that this proposal would need an additional flag in the line buffer (1 bit per 8 samples) and additional check in the deblocking filter. It was decided to study this proposal further in the CE together with the other proposal S0112. 13.0.0.1.1.1.1.1.305JCTVC-S0202 Cross check of On deblocking for screen content coding (JCTVC-S0045) [O. Nakagami (Sony)] [late]
(Consideration of this topic was chaired by G. Sullivan on Saturday 10-18 p.m.) The deblocking filter is applied to palette coded blocks. It was suggested, however, that generally, filtering and smoothing processes are avoided for screen content coding. The contribution proposes (as in JCTVC-R0213) to not deblock CUs coded with palette in the same way that PCM and lossless CUs are not deblocked. This is asserted to reduce complexity, avoid unwanted filtering and achieve BD-rate reductions (up to 0.2%). Additionally, it is suggested that a flag at SPS level could be included to enable/disable deblocking of palette coded CUs. We currently treat palette coded regions as intra, thus applying strong deblocking to them. This is suggested to be undesirable. Some gain is shown for disabling deblocking for palette coded regions. Decision: Disable deblocking within palette coded regions. (Do not introduce a flag.) What about the neighbour region? Should we disable filtering on both sides of the edge? Perhaps not. (The proposal does not disable it, which seems OK.) 13.0.0.1.1.1.1.1.307JCTVC-S0273 Cross-check of ‘AhG13: Palette and deblocking’ (JCTVC-S0096) by Qualcomm [C. Rosewarne, M. Maeda (Canon)] [late]
|