JVET-M0891 BoG report on CE7 related quantization and coefficient coding contributions [Y. Ye]

This report was discussed in Track A Thursday 17 January 1700-1800 (chaired by GJS).

There were 13 technical contributions in the CE7 related category. These contributions are classified into the following three categories:

• Rice parameter related
• Complexity reduction and simplification
• Coding efficiency

The first BoG session was held 1900–2345 on January 14 2019 in Saba.

The second BoG session was held 1300–1400 on January 17 2019 in Saba.

Section 1 of this document summarizes the BoG’s recommendations. Section 2 of this document contains detailed notes on BoG discussion.

Recommended adoptions:

• JVET-M0470, CE7-related: Golomb-Rice/exponential Golomb coding for abs_remainder and dec_abs_level syntax elements
  • In VTM 3.0, worst case is 33 bits for abs_gt3_level_flag, and 35 bits for dec_abs_level for escape codes of coefficient levels, in comparison with is 32 bits for both syntax elements in HEVC.
  • Two aspects in this proposal: the first aspect uses a constant transition prefix code length of 6, and eliminates a LUT; the second aspect uses HEVC RExt extended precision scheme to limit worst case code length to 32 bits
  • Performance: 0.00%/0.01%/0.02% for AI/RA/LB
  • Proposed aspects seemed to be straightforward and aligned with HEVC. It also would solve a software issue that currently exists in VTM 3 that could cause decoder crash.

Decision (BF): Adopt JVET-M0470.

• JVET-M0251 (Non-CE7: Last position coding for large block-size transforms) and JVET-M0257 (CE7-related: coefficient scanning and last position coding for TUs of greater than 32 width or height)
  • Three contributions in this BoG tried to address the coefficient coding issues due to high frequency zeroing: JVET-M0250, JVET-M0251 (which is a superset of JVET-M0250), and JVET-M0257
  • Propose to scan only the portions of the transform blocks that have not been zeroed out
  • JVET-M0257 and JVET-M0251 are identical from spec text point of view, but simulation results are slightly different due to some difference in encoder implementation
  • M0257: 0.00% AI, -0.01% RA, -0.01% LB
  • M0251: 0.01% AI, 0.01% RA, full set of LB results not yet available at time of discussion
  • Recommend to adopt JVET-M0251/ JVET-M0257. Use JVET-M0257’s encoder implementation (better performance and cleaner code)

Decision (BF): Adopt JVET-M0251/JVET-M0257 (software from JVET-M0257).

• JVET-M0305 CE7-related: Joint coding of chrominance residuals
  • The proposal adds a chroma residual coding mode where the Cr residual is not signalled, and is derived from the Cb residual by reversing the signs of the Cr residual.
  • The proposed method is applied to intra and inter coded blocks.
  • At the encoder side, the Cb and -Cr residuals are averaged together. In the proposed mode, that average residual is coded. RD decision is made to select between the conventional chroma coding method and this proposed method (in which case the average residual thus computed is coded). The mode flag is sent when the cbfs for both Cb and Cr are 1.

• • This proposal achieves similar gains for all sequence classes and all coding configurations.
  • This method is simpler than an LM chroma mode that predicts Cr from Cb that was previously proposed, and achieves similar coding performance as that previous LM chroma mode. This complexity reduction of this proposed method compared to the previous LM chroma mode could be especially beneficial for the decoder.
  • It seems that such coding gain was usually not available from coefficient coding methods.
  • Low QP results (provided in a v3 of the contribution) were discussed at the second BoG session. The chroma gains are reported to be somewhat lower than those of CTC, but the gains in luma are similar to (AI case) or higher than (RA and LB cases) those of CTC.
  • In Track A, a participant commented wondered whether there could be subjective artefacts.
  • A participant asked how many blocks used this, and it was said that around half of the time that both channels had a residual, it would use this mode.
  • The proponent said it seems to also work for HDR.

Further study in a CE was planned for this.

BoG recommendations for CE testing:

• CE on coefficient coding (cleanup):
  • JVET-M0198, CE7-related: Unified Rice parameter derivation for coefficient level coding (some more computes but hardware friendly, removing one variation)
  • No test of this one (some loss): JVET-M0469, CE7-related: Unified Rice parameter derivation for coefficient coding
  • JVET-M0558: CE7-related: Template-based Rice parameter derivation (some more storage of reconstructed values and computes but hardware friendly, removing one variation)
  • No test of this one (don’t worry about number of contexts at this point): JVET-M0107: CE7-related: Reduced local neighbourhood usage for transform coefficients coding
  • No test of this one (don’t worry about number of contexts at this point): JVET-M0489: CE7-related: Reduced context models for transform coefficients coding
  • JVET-M0491: CE7-related: Reduced maximum number of context-coded bins for transform coefficient coding
• CE on screen content coding (coding efficiency)
  • JVET-M0278: Non-CE7: Residual rearrangement for transform skipped blocks
  • JVET-M0279: Non-CE7: Sign coding for transform skip

Regarding JVET-M0198, JVET-M0469 and JVET-M0558, during the BoG discussion, the pros and cons of the proposed approach vs the current design in VVC draft 3 were discussed. The approaches of JVET-M0198 and JVET-M0558 seemed to be more hardware friendly, whereas the current coefficient coding method in VVC draft 3 seemed to be more software implementation friendly.

This was discussed in Track A when determining which CEs to conduct.

JVET-M0891 BoG report on CE7 related quantization and coefficient coding contributions [Y. Ye]

See section 6.7.