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 the left neighbouring 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 previously 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 second proposal consists in setting the third MPM (MPM2) to planar mode. These modifications are reported to simplify the intra mode coding process, by reducing the number of checks when MPM0 (2 to 3 less checks), MPM2 (6 to 8 less checks) or the remaining mode (worst case, 4 less checks) is signalled.
With the proposal 2, an average BD-BR gain of 0.1% for AI-Main and AI-HE10 cases and no difference for inter cases was reported.
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 the planar mode 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 PUs (64x64 and above, as applicable). 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 codewords. By integrating method 1 in HM6.0, experimental results reportly showed average 6%
encoding complexity reduction with negligible BD-BR variation for All Intra HE10 and average 7%
encoding complexity reduction with negligible BD-BR 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 reportly showed average 9% and 10% encoding complexity reduction with very small average BD-BR 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 was taken on this.
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)]
It was reported that there is an inconsistency between HM6.0 and the current specification text draft 6 on the signalling 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 signalled after all intra luma prediction modes; however, in the current specification text, one intra chroma prediction mode is signalled after each intra luma prediction mode. In other words, there are four intra chroma prediction modes that are signalled if the current CU is INTRA_NxN. In this proposal, the inconsistency is removed by changing the specification text to match HM6.0.
Decision (Ed.): 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, the prev_intra_luma_pred_flag arithmetically-coded bin and other arithmetically-coded bins are signalled in an interleaved fashion. It is reported that the throughput of the entropy coder can be improved if more bypass bins are signalled 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 the throughput of the entropy coder for the case of INTRA_NxN. It was also 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 in the design have an approach similar to this one (in particular, the 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 adoption of the proposed intra prediction mode coding change.
5.16.2 LM mode
JCTVC-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 0.0%, −0.2% and −0.2% for both AI-HE10 and AI-main with LM enabled.
The purpose of this proposal 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 draft specification and the HM software for the linear model (LM) mode. This contribution proposes suggested corrections for these mismatches.
A substantial number of particular issues were noted, with suggested corrections.
Decision: Adopted.
JCTVC-I0194 Cross check of JCTVC-I0148 on LM clean-up [J. Kim (LG)]
JCTVC-I0151 LM mode with Uniform Bit-width Multipliers [Lingzhi Liu, Yongbing Lin (HiSilicon), Guichun Li (SCU)]
This proposal suggests unifying the bit-widths of the multipliers used in the chroma-from-luma intra prediction mode (LM mode) in HEVC. Instead of using multiple bit-width multipliers, the proposal uses unified bit-width multipliers according to the InternalBitDepth. The complexity is reportedly reduced from the modification. The BD-BR impact 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.
Decision (BF): Adopted.
JCTVC-I0221 Crosscheck of LM mode with Uniform Bit-width Multipliers (JCTVC-I0151) [M. Budagavi (TI)] [late]
Both the 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 neighbouring 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 number of entries of the look-up table is reduced from 63 to 32, and the bit depth for each entry is reduced from 16 bits to 10 bits. It is reported that there are 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 LM chroma intra prediction 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.
Four schemes of changing the shape of the template were described. All of these four schemes do not increase the computational complexity but provide a BD-BR impacts 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 configurations without Class F. No computational complexity is reportedly 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 was taken on this.
JCTVC-I0402 Cross-check result for I0175 [Y. Piao, J. H. Park (Samsung)] [late]
JCTVC-I0178 Simplified alpha bit-depth restriction in chroma LM mode [X. Zhang (HKUST), O.C. Au, F. Zou, J. Dai, C. Pang]
This contribution proposes to change the process of restricting the bit-depth of alpha values to 7 bits in the LM chroma intra prediction 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, of course) and intra HE 10bit configuration.
Decision: Adopted.
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. The 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 (and the 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 suggested to have two LM modes rather than one. 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 was taken on this.
JCTVC-I0309 Cross-check of Cannon proposal on Border subsampling (JCTVC-I0187) [X. Zheng (HiSilicon)]
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 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 the sequence 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.