Joint Collaborative Team on Video Coding (jct-vc)
Intra prediction and intra mode coding
Yüklə 0,59 Mb.
|
- Bu səhifədəki naviqasiya:
- 5.16.2LM mode
5.16Intra prediction and intra mode coding5.16.1GeneralJCTVC-I0085 On chroma intra prediction mode coding [Y. Lin, L. Liu (Hisilicon)] JCTVC-I0179 Cross check of Hisilicon’s proposal JCTVC-I0085 [J. Kim (LG)] JCTVC-I0186 On Intra mode coding [E. Francois, S. Pautet (Canon)] This contribution proposes two independent proposals related to intra prediction mode coding. The first proposal consists in making the first MPM (MPM0) only dependent on left neighboring CU. It is reported that the proposal 1 has no impact on the coding efficiency (in PSNR terms). The motivation is to make the logic easier for determining the MPM0. It was asked whether this might cause visual artefacts. The proponent indicated that they had not observed such a problem, and it was noted that DC and planar are often used. It was noted that we previous removed a line buffer for cross-CTB intra prediction mode dependency. It was remarked that the lack of this line buffer might have something to do with the minimal impact of this proposal.
The proposal forces MPM2 to always be the planar mode. The worst case decoding decision tree depth for the remaining mode when not using an MPM is reduced and there is overall less checking to be done for this. It was remarked that fewer checks should be needed in an optimized implementation. Another participant indicated that the complexity of this part of the design is not so significant. It was remarked that forcing planar to always be an MPM would introduce some directional asymmetry in the MPM directionality – biasing the selection of directions. Some non-normative encoding rule change was also applied. If this had not been done, there would have been a small loss in coding efficiency. Generally, the group seemed more interested in maintaining stability in this part of the processing than in the potential improvement from these changes. Some members of the group expressed an interest in the first aspect of the proposal. JCTVC-I0440 Cross-verification of JCTVC-I0186 on intra mode coding [K. Chono (NEC)] [late] The result was confirmed, including software and text. JCTVC-I0227 Prediction modes and mode coding for large size Intra block [X. Zhang, S. Liu, S. Lei (MediaTek)] This contribution proposes two methods for intra mode coding for large size Intra PU (64x64 and above). In method 1, four prediction modes are proposed to be used for intra prediction for large size Intra PU without using probable modes (MPMs). The four modes are represented by fixed length code words. By integrating method 1 in HM6.0, experimental results report average 6% encoding complexity reduction with negligible BD-rate variation for All Intra HE10 and average 7% encoding complexity reduction with negligible BD-rate variation for All Intra Main. In method 2, one prediction mode is used for intra prediction for large size Intra PU. As a result, the entropy coding for large size Intra PU prediction mode is skipped. By integrating method 2 in HM6.0, experimental results report average 9% and 10% encoding complexity reduction with very small average BD-rate variation for All Intra HE10 and All Intra Main. It was commented that there is a desire to treat all block sizes the same way. This proposal would treat certain block sizes differently. Moreover, the stressful case for the decoder is the small block size case, not the large block size case. Regarding the encoder perspective, encoders do not necessarily need to check all modes – a normative change does not seem necessary. No action taken. JCTVC-I0270 Cross-check report for MediaTek's prediction modes and mode coding for large size Intra block [J. Lou, L. Wang] [late] JCTVC-I0302 Intra mode coding for INTRA_NxN [W. -J. Chien, J. Chen, M. Coban, M. Karczewicz (Qualcomm)] There is an inconsistency between HM6.0 and the current specification text [1] on the signaling of the syntax element intra_chroma_pred_mode, which indicates the intra prediction mode of chroma component for the current CU. In HM6.0, an intra chroma prediction mode is signaled after all intra luma prediction modes; however, in the current specification text, one intra chroma prediction mode is signaled after each intra luma prediction mode. In other words, there are four intra chroma prediction modes are signaled if the current CU is INTRA_NxN. In this proposal, the inconsistency is removed by changing the specification text to match HM6.0. Decision: Fix the text to match the software (which is what we believe was actually intended). In the HM6.0 intra luma prediction mode for each PU is coded as the syntax element prev_intra_luma_pred_flag, which is an arithmetically-coded bin, and this is followed by the syntax element mpm_idx or rem_intra_luma_pred_mode, that are bypass-coded bins. Whether signalling mpm_idx or rem_intra_luma_pred_mode depends on the value of prev_intra_luma_pred_flag. For the case of INTRA_NxN in the current design, arithmetically-coded bin and arithmetically-coded bins are signaled interleavely. It is known that the throughput of entropy coder can be improved if more bypass bins are signal consecutively. Therefore, in this proposal, all the arithmetically-coded bins of luma intra modes (prev_intra_luma_pred_flag) are signalled first and then followed by all the bypass-coded bins (mpm_idx/rem_intra_luma_pred_mode) to improve throughput of the entropy coder for the case of NTRA_NxN.It was reported that there is a discrepancy between the text and software. The text would seem to sometimes create 2x2 intra prediction blocks for chroma (with associated prediction overhead). It was remarked that other places have an approach similar to this one (last significant position and MVD). Decision: Adopted. JCTVC-I0430 Cross-check of JCTVC-I0302: Intra mode coding for INTRA_NxN [X. Zhang, S. Liu (MediaTek)] [late] The software and text were checked and verified, and the cross-checker supported the proposed intra prediction mode coding change. 5.16.2LM modeJCTVC-I0085 On chroma intra prediction mode coding [Y. Lin, L. Liu (Hisilicon)] This document proposed a modified chroma intra prediction mode coding when LM mode is enabled. Similar to luma intra prediction mode coding, both a derived mode (DM, in which the prediction direction is derived from the luma prediction direction) and LM modes are treated as MPMs and the other four remaining modes are bypass coded. It was asserted that the proposed method could unify the parsing procedure for luma and chroma mode coding. Simulation results reportedly show a coding efficiency impact of of 0.0%, -0.2% and -0.2% for both AI-HE10 and AI-main with LM enabled. It is recommended to adopt the proposal. The purpose is to make the chroma intra prediction mode coding more like the luma prediction mode coding. There was mixed opinion about the value of this. No action was taken on it. JCTVC-I0179 Cross check of Hisilicon’s proposal JCTVC-I0085 [J. Kim (LG)] JCTVC-I0148 LM Mode Clean-Up [L. Liu (HiSilicon), R. Allen (Altera), X. Zhang (HKUST), P. Kapsenberg (Intel), E. Francois (Canon)] It was reported that there are several mismatches between WD and HM software for linear model (LM) mode. This contribution proposes the suggested corrections for these mismatches. A substantial number of particular issues were noted, with suggested corrections.
This proposal suggests unifying the bit-widths of the multipliers used in the chroma from luma intra prediction (LM mode) in HEVC standard. Instead of using multiple bit-width multipliers, the proposal method only use unified bit-width multipliers according to the InternalBitDepth. The complexity is reduced from the modification. The BD-Rate for this optimization is: AI-HE10: Y: 0.0%, U: 0.0%, V: 0.1%. This type of cleanup seems necessary for a proper design.
Software and text were confirmed. JCTVC-I0320 Crosscheck of Uniform Bit-width Multipliers for LM mode (JCTVC-I0151) [Y. Chiu, W. Zhang, L. Xu, Y. Han (Intel)] [late] JCTVC-I0166 Simplified Parameter Calculation for Chroma LM Mode [J. Hsu, M. Guo, X. Guo, S. Lei (MediaTek)] In HM6.0, when a chroma prediction unit (PU) is coded with intra LM mode, some parameters are calculated with the neighboring pixels of the current chroma PU and the ones of the corresponding luma PU. The derivation of parameters requires a 16-bit multiplication and an online generated look-up table with 63 entries. This contribution proposes two methods to simplify the complexity of this process. Firstly, the depth of the multiplication is reduced from 16 to the internal bit depth. Secondly, the entries of the look-up table are reduced from 63 to 32, and the bits for each entry are reduced from 16 bits to 10 bits. It is reported that there is almost no BD bit rate and running time changes. The first part of this is the same as the proposal I0151. An additional aspect was also proposed – to further reduce the complexity by reducing the number of entries and the bit depth of the entries in a decoder-generated LUT (used to approximate a division operation – table called lmDiv). Decision: Adopted this further aspect. JCTVC-I0322 Crosscheck of Simplified Parameter Calculation for Chroma LM Mode (JCTVC-I0166) [Y. Chiu, W. Zhang, L. Xu, Y. Han (Intel)] [late] JCTVC-I0175 Improved LM mode with template shift [X. Zhang (HKUST), O.C. Au, F. Zou, J. Dai, C. Pang] This contribution proposes to change the chroma intra prediction mode LM mode. By changing the shape of the template in the LM mode, the outer border of the neighbouring pixels is suggested to also be considered. We propose four schemes of changing the shape of the template. All of the four schemes do not increase the computational complexity but provide a BD-rate up to -0.02%, -0.27% and -0.26% for Y, Cb and Cr components respectively under intra main configuration with LM on and intra HE 10bit configuration without Class F. No computational complexity is added. This is basically a coding efficiency improvement proposal. The "scheme 4" is the suggested approach, which only offsets the top row sample positions, not the left column sample positions. No action taken.
This contribution proposes to change the process of restricting the bit-depth of alpha value to 7 bits in the LM mode. With the proposed operations, it is asserted that the "if-else" conditional judgement can be skipped. It was asserted that this would simplify both the HM software and WD. A small gain is reported for chroma components under intra main configuration (with LM on) and intra HE 10bit configuration. Decision: Adopted this further aspect. JCTVC-I0476 Cross-check of Simplified Alpha Bit-depth Restriction in Chroma LM Mode (JCTVC-I0178) [Y. Chiu, W. Zhang, L. Xu, Y. Han (Intel)] [late] Software and text were checked. Cross-checker supported the proposal. JCTVC-I0412 Cross-check of simplified alpha bit-depth restriction in chroma LM mode (JCTVC-I0178) [J. Xu (Microsoft)] [late] JCTVC-I0187 Border subsampling for LM mode [C. Gisquet, E. Francois, S. Pautet (Canon)] This contribution aims at simplifying the luma-based chroma (LM) prediction. In JCTVC-G129, in order to reduce the number of operations, it was proposed to downsampled by a factor of 2 the input luma and chroma signal for the OLS computation of the LM mode. However, applying this downsampling to 4x4 CUs (worst decoding case) was bringing coding efficiency loss. In the current proposal, in order to create more diversity, LM mode applies either to the even or odd samples (parity is signalled to the decoder). The technique reportedly brings 0.7% (U) and 0.8% (V) BDR gains in AI Main, 0.4% (U) and 0.6% (V) in AI HE10, 1% (U) and 0.9% (V) in RA Main, 0.8% (U) and 0.9% (V) in RAHE10, while enabling to save 22% of the multiplications in the worst decoding case. The proposal suggests to have two LM modes rather than 1. One of these modes uses even-parity samples for prediction and the other uses odd-parity samples. As tested, the encoder checks both modes and picks the best performing one. The proposal removes the horizontal prediction mode. No action taken. JCTVC-I0309 Cross-check of Cannon's proposal on Border subsampling (JCTVC-I0187) [X. Zheng (HiSilicon)] [miss] The cross-checker checked the software and text. JCTVC-I0188 Use of chroma phase in LM mode [E. Francois, C. Gisquet, S. Pautet (Canon)] This proposal provides additional inputs related the chroma phase issue in the luma-based chroma prediction mode (LM mode), previously addressed in contribution JCTVC-H0177. The issue consists in a possible misalignment of interpolated luma samples with the chroma samples. It is proposed to signal the chroma phase parameters and to adapt the luma interpolation process based on this chroma phase information. This proposal reports further experiments based on the HM6.0. One set of filters is recommended to handle the different considered cases. The evaluation has been made on different versions of 4:2:0 sequences, generated from 4:4:4 sequences, whose chroma components have been downsampled with specific chroma phases. Using these recommended filters, it is reported that average gains around 4% on chroma components can be observed. The set of 4:4:4 sequences have been converted into several sets of 4:2:0 sequences with different chroma phases. One average BDR gain is measured for each set of 4:2:0 sequences. The phase information is proposed to be sent at sequent or PPS level when the coding format is 4:2:0 or 4:2:2. The proponent indicated that this is probably not needed in a "Main" profile, but might be worthy of study for some extended-capability profile – e.g. some "studio" or "professional" profile. Further study in such a context was recommended. Yüklə 0,59 Mb. Dostları ilə paylaş:
|