International organisation for standardisation organisation internationale de normalisation

5.10.2Coding of LCU/TU/PU

Note that some contributions in this area relate to high-level syntax – see also section 5.13.

5.10.2.1.1.1.1.1.1JCTVC-H0154 Side information signalling improvement for TU [B. Lee, M. Kim (KAIST)] [late]

No need to be presented.

5.10.2.1.1.1.1.1.2JCTVC-H0664 Cross check of KAIST proposal JCTVC-H0154 [J. Kim, C. Kim (LGE)] [late]

5.10.2.1.1.1.1.1.3JCTVC-H0202 PU structure for intra NxN [H. Nakamura, S. Fukushima (JVC Kenwood)]

The PU structure for intra NxN is reportedly not clear in the HM5.0 implementation. Moreover, the WD5 description reportedly does not match the HM5.0 software implementation.

This contribution recommended that the prediction unit syntax described in the text should correspond to the HM software implementation, with the smallest possible changes.

It was suggested to change both the draft text and the HM software somewhat. The prediction information for both luma and chroma prediction blocks in the same location was proposed to be coded in the same prediction unit. More specifically, each of the intra prediction modes for each luma and chroma prediction block having partition index PartIdx equal to 0 would be coded in the same prediction unit in the case of PART_NxN as well as PART_2Nx2N.

The HM5 software reportedly defines the intra chroma PU independent of luma, but this is deviating from the WD text. Additionally, it was proposed to modify the coding order

Furthermore, a structure for cases of 4:4:4, 4:2:2 and 4:0:0 chroma sampling were proposed.

Conclusion: It is necessary to align the text and software (and the software has been more well established thus far), but there is no argument for making the proposed modification of coding order, 4:4:4, etc. Colour formats not currently fully addressed in the design.

5.10.2.1.1.1.1.1.4JCTVC-H0638 Cross-check report on PU structure for intra NxN (JCTVC-H0202) [I.-K. Kim (Samsung)] [late]

5.10.2.1.1.1.1.1.5JCTVC-H0269 AHG15: Independent control of Max CU and LCU size for small LCU [J. B. Choi, J. H. Kim, K. H. Lee, J. H. Park, C. Kim (Samsung)]

The LCU sizes have a significant impact on the HEVC codec data flow and architecture. The LCU size of 64x64 has been selected as a good trade-off between coding gain and complexity. Smaller LCU sizes such as 16x16 have been used in several previous standards. A modification of the min and max CU size was proposed in the high level syntax to compensate for coding loss caused by using a smaller LCU size. The results reportedly show -0.3/-0.3/-0.4 for AI HE, -0.6/-0.5/-0.4 for RA HE, and -0.9/-0.6/0.0 for LD HE impacts, compared to 32x32 LCU, and -1.0/-1.1/-1.3 for AI HE, -2.1/-1.5/-1.5 for RA HE, and -2.7/-1.4/2.5 for LD HE, compared to using a 16x16 LCU.

It was suggested to modify the max/min CU sizes independent of the BPU size – e.g. LCU could be smaller than BPU.

Gain was reported when compared to HM encoding with 32x32 LCU = BPU, and keeping BPU = 64x64 (not compared to LCU = BPU = 64, which are the common test conditions).

However, it was asked why one would use a smaller LCU than the BPU, and commented that this may have implications on slice definition. There was no support for this from other experts.

5.10.2.1.1.1.1.1.6JCTVC-H0623 AHG15: Crosscheck of JCTVC-H0269 on independent control of Max CU and LCU size for small LCU [Y. Jeon, B. Jeon (LG)] [late]