International organisation for standardisation

5.5CE5: CAVLC entropy coding improvement

5.5.1Summary

5.5.1.1.1.1.1.1.1JCTVC-F025 CE5: Summary report of Core Experiment on CAVLC entropy coding improvements [X. Wang, P. Wu (CE coordinators)] [upload 07-13]

5.5.2Contributions

5.5.2.1.1.1.1.1.1JCTVC-F345 Cross-check report on CE5: Modifications for inter mode and split flags coding in CAVLC (JCTVC-E258) [K. Chono, H. Aoki (NEC)]
5.5.2.1.1.1.1.1.2JCTVC-F390 CE5: Simplification of transform coefficient coding in CAVLC [Y. Yasugi, T. Yamamoto (Sharp)]

In JCTVC-F390, a run mode bypass mechanism is proposed. According to the scheme, when the level of the last non-zero coefficient is greater than one and the current block is an intra-coded luma block, run mode is bypassed with level mode started directly. It’s asserted that such a run mode bypass scheme can lower encoding and decoding complexity. It’s reported that there is no change in coding performance with proposed scheme.

Comments: It would be good to see more detailed analysis on complexity reduction.

A proposal was presented with regard to that. Disagreement was raised w.r.t. that run mode is not necessarily more complex than level mode, and invoking the level mode instead may even increase the complexity.

No action was taken on this.
5.5.2.1.1.1.1.1.3JCTVC-F404 CE5: Cross-check of Yonsei Univ. and Samsung's proposal (JCTVC-F408) [Y. Yasugi (Sharp)] [late upload 07-06]
5.5.2.1.1.1.1.1.4JCTVC-F408 CE5: Run and level mode coding improvement in CAVLC [S. Kim, J. Lee, S. Lee (Yonsei Univ.), J. Chen, J. Park (Samsung)]

In JCTVC-F408, several things are proposed.

• 
  For intra block coding, one more parameter table is added specifically for block size 16x16 or larger. The parameter table is used in determining codeword mapping in run-level coding. Currently in HM3.0 one table is shared for block size 8x8 and larger.
  
• 
  Modifications to VLC table adaptive selection in level coding. In HM3.0 one set of threshold values is defined in VLC table selection. Based on the proposal these threshold values are made dependent on factors such as block type (intra luma, P luma, B luma, or chroma) as well as RQT depth.
  
• 
  Modifications to VLC tables
  

With all the changes above, it is reported that the BD-rate savings are 0.7% for Intra, 0.3% for random access and 0.2% for low delay.

Comments:

• 
  Relative to JCTVC-E446, (2) and (3) seems to be new changes also (1) would need to be modified if (2) and (3) are used.
  
• 
  In the software, (1) and (2) are controlled under one macro. It would be good to know the performance improvement from (1) alone.
  

Gain for (1) alone is 0.4/0.2/0.1 for AI/RA/LD

(1) needs 2 additional tables (approx. 400 byte in total), adopting this standalone would not be justified. JCTVC-F612 is also similar to (1) but does not add tables.

Further study in CE5 (if continued, there are more non-CE contributions for CAVLC improvements).

Action: present JCTVC-F408 in the non-CE section - done.

See notes in non-CE section.

5.5.2.1.1.1.1.1.5JCTVC-F409 CE5: Crosscheck for Sharp's proposal (JCTVC-F390) [J. Lee, S. Kim, S. Lee (Yonsei Univ.), J. Chen, J. Park (Samsung)] [late upload 07-12]

5.5.2.1.1.1.1.1.6JCTVC-F524 CE5: Results on modified inter mode coding and joint coding of split flags for CAVLC [Anand Kotra, Virginie Drugeon, Thomas Wedi (Panasonic)]

Two techniques are proposed in JCTVC-F524.

For inter mode coding, the VLC index mapping table is currently defined CU depth dependent in HM3.0. This proposal proposes that for each CU depth level, multiple (3 or 5) VLC mapping tables are used depending on the partitioning and prediction information of the CUs above and left.

A joint coding scheme of CU split flags for I-frame. More specifically based on the proposal split flags of four neighboring CUs at the same depth level are grouped and coded together. For each CU depth, three VLC tables are used based on neighboring block flags. In addition, different set of VLC tables are trained based on slice QP value smaller than 30 or not.

Coding gain from two proposed techniques is reported to be about 0.1% for different configurations.

Comments:

Cross-checker suggested code improvement, e.g. avoid duplication of code.

Less gain than in original proposal, not worthwhile to consider. Version 4 shows more gain for the range of high QPs (not the common test conditions).

No action was taken on this.