International organisation for standardisation
Adaptive loop filter (“other”)
Yüklə 9,08 Mb.
|
6.5.3Adaptive loop filter (“other”)6.5.3.1.1.1.1.1.1JCTVC-F047 Modifications of in-loop filter based on non-local means filter [M. Matsumura, Y. Bandoh, S. Takamura, H. Jozawa (NTT)] This contribution reports the performance of a technique that utilizes an adaptive denoising filter as the in-loop filter of HM codec. In the proposed method, a denoising filter called non-local means (NLM) filter is added in the in-loop filter process of the encoder/decoder in addition to deblocking, ALF, and SAO filters of HM3.0. The proposal was implemented in HM3.0 software (for High Efficiency) to evaluate its performance. Compared to the anchor of HM3.0, the average BD-rate gains were reported as “intra (Y: −1.0%, U: −0.9% and V: −1.2%)”, “random access (Y: −1.0%, U: −2.2% and V: −2.1%)” and “lowdelay B(Y: −1.2%, U: −2.8% and V: −3.3%)”, and “lowdelay P (Y: −1.3%, U: −3.2% and V: −3.9%)”, respectively. And the average decoding time increased 7–11%. The maximum gain was about “lowdelay P (Y: −1.5%, U: −9.2% and V: −8.8%)” for the sequence “BasketballDrill”. Consistently more gain in chroma than luma. It was noted that this does not seem to provide gain for Nebuta, which seems odd because that is a noisy sequence. It was noted that this adds more line buffering. The proponent indicated that the subjective quality At the last meeting, it was suggested to test applying this as a pre-processing filter rather than making it part of the decoder. Considering a post-processing filter may also be an alternative. Further study was encouraged, although we are reluctant to add more filters and more line buffers to the design. 6.5.3.1.1.1.1.1.2JCTVC-F323 Cross-check for NTT's proposal on in-loop filter based on non-local means filter (JCTVC-F047) [T. Yoshino, K. Kawamura, S. Naito (KDDI] 6.5.3.1.1.1.1.1.3JCTVC-F054 Adaptive Loop Filter with Zero Pixel Line Buffers for LCU-based Decoding. [C.-Y. Chen, C.-Y. Tsai, C.-M. Fu, Y.-W. Huang, S. Lei (MediaTek)] When the adaptive loop filter (ALF) in HM-3.0 is enabled, seven additional luma line buffers and seven additional chroma line buffers are asserted to be required for LCU-based decoding. In this contribution, ALF with padding at virtual boundaries was proposed to remove all the line buffers. When the deblocking filter (DF) in HM-3.0 was used, the luma and chroma virtual boundaries were LCU row boundaries upward shifted by four and two pixels, respectively. The general concept was to process a to-be-filtered pixel on one side of a virtual boundary without using any pixel from the other side. Repetitive padding was used to replace pixels from the other side. In comparison with HM-3.0, no line buffer was needed, and BD-rates were reportedly 0.1%, 0.1%, and 0.2% for HE-AI, HE-RA, and HE-LD, respectively, where a positive number means loss while a negative number means gain. A boundary handling technique is applied to try to avoid visible line boundaries. It was reported that no visual artifacts seem to be created with the scheme. It was also proposed to replace the 9x7 diamond filter by the 9x9 diamond filter for luma and to always use the 7x7 diamond filter instead of the 5x5 square filter for chroma. Corresponding BD-rate were 0.1%, −0.1%, and −0.4% reportedly for HE-AI, HE-RA, and HE-LD, respectively. In addition, a boundary smoothing technique was proposed to remove possible visual artifacts near virtual boundaries, and corresponding BD-rates were 0.1%, 0.0%, and −0.2% reportedly for HE-AI, HE-RA, and HE-LD, respectively. All the experiments reportedly achieved no change in run time. JCTVC-F272 is a somewhat competing proposal. This seems to be a simpler approach than JCTVC-F272. See additional notes in discussion of JCTVC-F272. 6.5.3.1.1.1.1.1.4JCTVC-F367 Cross-Verification of MediaTek’s proposal on adaptive loop filter (JCTVC-F054) by Qualcomm [I. S. Chong, M. Karczewicz (Qualcomm)
Similar to JCTVC-F054, but applied to SAO. To be considered in CE along with JCTVC-F272 and JCTVC-F254. 6.5.3.1.1.1.1.1.8JCTVC-F366 Cross-Verification of MediaTek’s proposal on sample adaptive offset (JCTVC-F055) by Qualcomm [I. S. Chong, M. Karczewicz (Qualcomm)] 6.5.3.1.1.1.1.1.9JCTVC-F056 Sample Adaptive Offset with LCU-based Syntax [C.-M. Fu, C.-Y. Chen, C.-Y. Tsai, Y.-W. Huang, S. Lei (MediaTek), I. S. Chong, M. Karczewicz (Qualcomm)] In HM-3.0, sample adaptive offset (SAO) parameters are coded for each region in a picture. In order to support localization of SAO parameters with higher flexibility, this contribution proposed a new syntax that allowed SAO parameters to be adaptively changed at any largest coding unit (LCU). Simulation results reportedly showed that the proposed syntax caused 0%, 0.1%, 0.1%, 0%, 0%, and 0.1% bit rate increases for HE-AI, HE-RA, HE-LD, LC-AI, LC-RA, and LC-LD, respectively, with almost the same encoding and decoding times when the algorithm of deriving localized SAO parameters was unchanged. The scheme is preliminary at this stage, as no coding gain is shown and the proposal seems to increase decoding complexity. Further study may result in some improvement. 6.5.3.1.1.1.1.1.10JCTVC-F439 Cross-check of MediaTek’s and Qualcomm’s proposal on Sample Adaptive Offset (JCTVC-F056) by Samsung [E. Alshina (Samsung)] [late upload 07-07] 6.5.3.1.1.1.1.1.11JCTVC-F057 Sample Adaptive Offset for Chroma [C.-M. Fu, C.-Y. Chen, Y.-W. Huang, S. Lei (MediaTek), S. Park, B. Jeon (LGE), A. Alshin, E. Alshina (Samsung)] Sample adaptive offset (SAO) for luma was adopted in HM-3.0. In this contribution, the same techniques of band offset (BO) and edge offset (EO) used for luma were applied for chroma. The three components were independent, and each component had its own partitions and offsets. It was reported that SAO reduced Cb bitrates by 2.0%, 3.3%, 4.6%, 1.8%, 2.7%, and 6.3%, and Cr bitrates by 2.9%, 3.9%, 5.9%, 2.4%, 2.8%, and 7.6% for HE-AI, HE-RA, HE-LD, LC-AI, LC-RA, and LC-LD, respectively, while encoding and decoding times were almost unchanged. A small loss (averaging approximately 0.1% was reported in the luma). The gain for luma SAO was approximately 2-3%. Decision: Adopted (pending no objection relating to text and software quality – no objection was raised). It was remarked that SAO in general needs significant code clean-up, and those interested in that feature volunteered to help. 6.5.3.1.1.1.1.1.12JCTVC-F364 Cross-Verification of MediaTek’s proposal on sample adaptive offset of chroma (JCTVC-F057) by Qualcomm [I. S. Chong, M. Karczewicz (Qualcomm)] [initial version rejected as placeholder; corrected version late upload 07-06] 6.5.3.1.1.1.1.1.13JCTVC-F058 Sample Adaptive Offset with PPS-level Syntax [C.-M. Fu, C.-Y. Tsai, C.-Y. Chen, Y.-W. Huang, S. Lei (MediaTek)] In HM-3.0, the sample adaptive offset (SAO) parameters are adapted at picture level. However, when a picture contains multiple slices, the entire SAO information is always sent in the first slice header, which is undesirable for parallel processing of multiple slices. In JCTVC-E045, a solution to a similar problem for adaptive loop filter (ALF) was adopted into HM-3.2. Therefore, by analogy with JCTVC-E045, this contribution proposed to add an option of moving SAO parameters to the picture parameter set (PPS). The option could be enabled for multiple slices per picture or disabled for single slice per picture by using a flag in PPS, and the flag could be shared by SAO and ALF. Compared with the SAO syntax coded in the first slice header, the proposed PPS-level SAO syntax reportedly showed no difference in BD-rate and run time under JCTVC-E700 common test conditions with 1500-byte slices per picture. Decision: Use adaptation parameter set for SAO parameters (see JCTVC-F747). 6.5.3.1.1.1.1.1.14JCTVC-F700 Cross-check of MediaTek's Sample Adaptive Offset (JCTVC-F058) [T. Yamazaki, T. Ikai, Y. Yasugi, T. Yamamoto (Sharp)] [late reg. 07-11, upload 07-14] 6.5.3.1.1.1.1.1.15JCTVC-F093 Sample Adaptive Offset with Padding at LCU, Slice, and Image Boundaries [C.-M. Fu, C.-Y. Tsai, C.-Y. Chen, Y.-W. Huang, S. Lei (MediaTek)] In the adaptive loop filter (ALF) process of HM-3.2, padding is used at slice and image boundaries. In the sample adaptive offset (SAO) process of HM-3.2, skipping is used at largest coding unit (LCU), slice, and image boundaries. This contribution proposed to replace the skipping technique used in SAO by the padding technique as a unification between ALF and SAO. Simulation results reportedly showed no change of BD-rates and run times. Moreover, it was reported some visual artifacts of the skipping technique could be removed. Visual artifacts were observed in the Kimono sequence, which are asserted to be removed by this technique. It was remarked that ALF should be applied to the left and right boundaries of the LCU rather than padding them or skipping them. This seemed like a good suggestion. See notes below in discussion of JCTVC-F232. 6.5.3.1.1.1.1.1.16JCTVC-F365 Cross-Verification of MediaTek’s proposal on sample adaptive offset (JCTVC-F093) by Qualcomm [I. S. Chong, M. Karczewicz (Qualcomm)] [initial version rejected as placeholder; corrected version late upload 07-06] 6.5.3.1.1.1.1.1.17JCTVC-F232 SAO LCU boundary processing [M. Budagavi (TI)] Sample adaptive offset (SAO) processing in HM-3.0 is done in an LCU-independent way. As a result, during edge offset type of SAO processing, the top and bottom row and/or left and right column of LCU are not SAO processed. This is reported to result in grid line type of noticeable visual artifact in Kimono HM-3.0 encoding. This contribution presents techniques for SAO processing at LCU boundary to eliminate the grid line type of visual artifact. The techniques presented do not use additional line buffer. Two of the techniques presented do SAO processing in LCU-independent fashion. All the techniques are reported to have BD-Rate of 0.0% for common conditions. Three variations to resolve this were described in the contribution. Related proposal JCTVC-F093. The main difference between this proposal and JCTVC-F093 seems to be in regard to the vertical processing at the top and bottom edges. Remark: Somewhat less bad in HM 3.2. Remark: Kimono is the only sequence this is happening in (within the common conditions). Remark: Consider the interaction between the deblocking filter and SAO (e.g., switch their order). Response: That has (objective) coding efficiency loss. Remark: The line buffers are (currently) in there anyway, so perhaps just apply the SAO the same way everywhere for now (including at LCU boundaries), and work out how to deal with this in a more unified way in the future. Decision: Agreed to apply SAO the same way at LCU boundaries (that are not slice boundaries) as at interior of LCU. Also establish a CE for further study. 6.5.3.1.1.1.1.1.18JCTVC-F442 Cross-check for SAO LCU boundary processing (JCTVC-F232) by Samsung [E. Alshina (Samsung)] 6.5.3.1.1.1.1.1.19JCTVC-F396 Improvement of Sample Adaptive Offset with modified bit accuracy and restricted offsets [T. Yamazaki, T. Ikai, Y. Yasugi, T. Yamamoto (Sharp)] In this contribution, a bit accuracy modification and offset range restriction in Sample Adaptive Offset (SAO) were proposed.
With the proposed offset range, the memory usage can reportedly be reduced up to 40% compared to HM-3.0 when internal bit depth is 10 bits. It is reported that the bit accuracy modification and offset range restriction have negligible effect on the coding efficiency in the normal QP range (22-37) while it achieves up to 0.2% gain in lower QP range (12-27). Decision: Adopted. 6.5.3.1.1.1.1.1.20JCTVC-F693 Crosscheck for Sharp's SAO in JCTVC-F396 [C.-Y. Tsai, Y.-W. Huang (MediaTek)] [late reg. 07-09, upload 07-14 after opening] Yüklə 9,08 Mb. Dostları ilə paylaş:
|