International organisation for standardisation

6.6Block structures and partitioning

6.6.1.1.1.1.1.1.1JCTVC-F070 Sub-8x8 PU coding with fixed reference index [M. Zhou, M. Budagavi (TI)]

DDR bandwidth has become increasingly a bottleneck for chip designs targeted for HD/UHD video applications. However, in the current HM3.0 design, PUs down to 4x4 block size can have their own reference index, which essentially increases the decoder memory bandwidth requirements when compared to AVC. A simple algorithm is tested to qualify the benefit of having the reference index granularity down to 4x4 blocks. In the tested algorithm all the 8x4, 4x8 and 4x4 PUs are fixed to having reference index equal to zero, and reference index is not encoded into bitstream for sub-8x8 blocks. The simulation results reveal that the loss by constraining the reference index for sub-8x8 blocks to zero is fairly limited. On average BD-rate increase of 0.3% in RA-HE, 0.5% in RA-LC, 0.2% in LB-HE and 0.4% in LB-LC, respectively, is observed for common test conditions with four reference frames. It is recommended to conduct further study on this topic for reduction of memory bandwidth requirements of motion compensation.

4x4 does not exist anymore.

Losses are mainly observed for the smaller picture sizes (class C and D, the latter is 0.8%).

Further study was suggested.

6.6.1.1.1.1.1.1.2JCTVC-F116 Cross-verification results of TI’s Sub-8x8 PU coding with fixed reference index (JCTVC-F070) by LG [Hendry, S. Park, B. Jeon (LGE)]

6.6.1.1.1.1.1.1.3JCTVC-F107 Redundancy removal of residual information for CAVLC in merge 2Nx2N [J. Park, B. Jeon (LGE)]

In the current HM, skip mode and merge mode for 2Nx2N PU size (2Nx2N_MRG) share the same motion representation method. The difference between the two modes is whether the residual information is sent or not. Hence, no_residual_data_flag in CABAC coding is inferred to be equal to 0 when CU is coded with 2Nx2N_MRG mode (in S/W, not in W/D). However there is no such consideration for CAVLC coding. In a similar spirit as with the CABAC case, this contribution proposed a change in cbp_and_split_transform syntax. Applying this change reportedly brings 0.1% BD-rate reduction for both random access and low delay configurations.

It was reported that the no_residual_data_flag inference is in the software but not in the WD - this must be checked and corrected if it is the case.

The other item (CAVLC) could be an issue, but it was suggested that there may be other solutions. It was suggested to check offline with X. Wang and report back on this, and then was later confirmed OK.

Decision: Adopted (both aspects).

6.6.1.1.1.1.1.1.4JCTVC-F371 Cross-check report for LGE's proposal JCTVC-F107 [H. Sasai, T. Nishi (Panasonic)]

6.6.1.1.1.1.1.1.5JCTVC-F192 A study on addition of 64x64 transform to HM 3.0 [Y. Sugito, A. Ichigaya, S. Sakaida (NHK), K. Sugimoto, A. Minezawa, S. Sekiguchi (Mitsubishi)]

This contribution proposes addition of 64x64 transform to HM 3.0. 64x64 transform improves the coding efficiency of higher resolution images – providing an average reported gain around 0.5% for sequences of Class A and B (peak is 2.6%). The results of encoding and decoding time are up to 3% increase compared with HM 3.0.

Question: Is the gain more due to 64x64 luma or 32x32 chroma?

Should it be studied to just to use 32x32 chroma transform?

In general, with most sequences, the gain is small, such that a revision of the previous decision (small gain vs. high implementation cost in hardware) is not adequate.

One expert remarked that a similar tendency of increased gain by 64x64 transform was observed with other SHV sequences (not in the current test set).

6.6.1.1.1.1.1.1.6JCTVC-F690 Cross check by Canon on Merge Candidate Selection in 2NxN, Nx2N, and NxN Mode from Qualcomm (JCTVC-F302) [G. Laroche (Canon)] [late reg. 07-08, upload 07-11]
6.6.1.1.1.1.1.1.7JCTVC-F418 Joint coding of CU splitting flag and inter modes based on HM 3.1 [W. Zhang (ZTE)] [late upload 07-08]

In HM 3.1, there is up to eight cases could be summarized for CU splitting flag and inter modes. A joint coding method which is different to CU-depth dependent and counter-based adaption (JCTVC-D370, JCTVC-E143) was proposed. As test results reported, it has saved about 0.6% BD-rate for CAVLC configurations.

In this proposal, the representing method of CU splitting flag and inter modes had been unified both in CAVLC and CABAC. And about 0.1% BD-rate deviation was observed for coding efficiency of CABAC comparing to HM 3.1. It’s also proposed that IPCM could be enabled in intra slice while CU size greater than 16x16 and in inter slice while CU size greater than 8x8 (min CU) with a loss of 0.1% BD-rate in AI-LC configuration only.

Refers also JCTVC-D275, JCTVC-E072 and JCTVC-E258

The proposal introduces new tables for the joint mode (16 instead of 4 tables).

Where does the gain come from? Cross-checkers are not able to explain.

For HE, very often slight loss is observed – there is no good reason to use the same method

There is some dependency on the previous slice (parsing dependency) – this is not desirable and could explain some of the gain

No action.

6.6.1.1.1.1.1.1.8JCTVC-F117 Cross-verification results of ZTE’s inter mode coding (JCTVC-F418) by LG [Hendry, J. Lim, B. Jeon (LGE)] [late upload 07-11]

6.6.1.1.1.1.1.1.9JCTVC-F279 Cross-check Report for ZTE’s Proposal JCTVC-F418 [Z. Zhou, S. Liu (MediaTek)] [late upload 07-13]
6.6.1.1.1.1.1.1.10JCTVC-F578 RQT with rectangular transform unit support [K. Panusopone, X. Fang, V. Kung, L. Wang (Motorola Mobility)]

This contribution describes a simplification for residual tree with rectangular transform unit. The proposed method aims to minimize change in reference software and syntax while maintaining coding performance.

New type: Nx2N and 2NxN TU; joint split flag for first level, normal RQT starting from second.

Some gain reported, but not using common test conditions.

Contribution noted.

6.6.1.1.1.1.1.1.11JCTVC-F596 The effect of LCU size on coding efficiency in the context of MTU size matching [M. Horowitz, S. Xu (eBrisk Video), E. S. Ryu, Y. Ye (InterDigital Communications)]

This contribution contains information showing the effect of LCU size on coding efficiency in the context of encoding with a maximum transmission unit (MTU) size constraint. Results were presented comparing a simulation configured to use 1500-byte slices and a separate simulation using 1500-byte slices and tiles, each against an HM 3.0 anchor that was configured to use one slice per picture. Separate simulations were run for each of three LCU sizes: 16x16, 32x32, and 64x64. Results show that the coding efficiency loss of 1500-byte per slice relative to the single slice anchor grows with decreasing LCU size. In addition, simulations featuring 1500-byte slices and tiles show higher coding efficiency in nearly all cases than those where only 1500-byte slices were used. It is also noted that gains using tiles and 1500-byte slices relative to using 1500-byte slices only increase with decreasing LCU size.

Analyzes the tradeoff between MTU size and LCU size. Combination slice+tile is usually causing less coding loss than slices alone (loss does not grow with LCU size any more). Fine granularity slices (as available in HM3.3) were not considered, which also would solve the problem.