Joint Collaborative Team on Video Coding (jct-vc)

3Project development, status, and guidance

3.1Conformance test set development

JCTVC-J0291 Instructive (and sometimes evil) conformance bitstreams [C. Fogg (Harmonic), A. Wells (Ambarella)]

The authors indicate that they believe that conformance bitstreams that do not push the legal limit permitted by the Profile & Level can lull the implementer into under-designing the performance capabilities of their decoders. It is asserted that once decoders are discovered to crash or drop frames under some conforming stream conditions, a new, de facto interoperability point is established within industry that must be tracked by encoder vendors for the lifetime of the specification. For HEVC, the contributor recommended that JCT-VC create test definitions and example streams that maximize the performance with the aim of creating one true interoperability point for each profile. It was asserted that if the performance is judged to be too high for implementers to meet, then JCT-VC should lower the profile and level limits to match baseline implementation expectations. It was asserted that otherwise, there are as many potential profiles & levels as there are decoder designs that must be supported by encoders.

Exercising the reference picture list possibilities was one aspect suggested to be an important feature to test.

3.2Draft text specification improvements [the right place for this?]

4Core experiments

4.1CE1: Intra transform mode dependency simplifications

4.1.1Summary

JCTVC-J0021 CE1: Summary report of Core Experiment on intra transform mode dependency simplifications [K. Ugur, A. Saxena (CE coordinators)]

Three non-CE contributions were also noted to be relevant. These are listed in section 5.17.

In this core experiment, two simplifications were tested. Simplification 1 uses 2D DST for all intra prediction modes of 4x4 luma TUs rather than using mixed transform types (4 difference cases). Simplification 2 uses DST for all intra prediction modes of 4x4 luma TUs except that the DC mode is coded with DCT. Both simplifications show coding efficiency loss ranging between 0.0–0.1% on average excluding class F. In class F there was some more loss – between 0.2‒0.8% on average.

Visual testing was planned to be done for simplification 1 only.

It is intended to do visual testing

The results of visual testing were as follows:

• 
  Testing was performed with 14 participants, mainly CE1 participants
  
• 
  Tests indicate that there is no visual difference
  

(A BoG report about the tests will be was provided.).

Decision: Adopt simplification 1

Due to this adoption, there was no need to discuss the remaining documents under CE1

4.1.2Contributions

JCTVC-J0030 CE1: Cross-verification of Intra transform mode dependency simplifications (JCTVC-J0021) [R. Cohen (MERL)]
JCTVC-J0034 CE1: Cross-check of Intra transform mode dependency simplifications [A. Saxena, E. Alshina, F. Fernandes (Samsung)]
JCTVC-J0035 CE1: Nokia’s results on intra transform mode dependency simplifications [K. Ugur, O. Bici (Nokia)]

This contribution presents the CE1 results by Nokia on intra transform mode dependency simplifications. In this core experiment, two simplifications were tested. Simplification 1 uses 2D DST for all intra prediction modes of 4x4 luma TU’s. Simplification 2 uses 2D DST for all intra prediction modes of 4x4 luma TU’s except the DC mode is coded with 2D DCT. Both simplifications show coding efficiency loss ranging between 0.0%–0.1%.

BR increase is 0.5% in class F (0.8% for low QP) for simplification 1, 0.3% for simplification 2.

JCTVC-J0276 CE1: Crosscheck of Nokia’s results on intra transform mode dependency simplifications (JCTVC-J0035) for low QPs [R. Joshi (Qualcomm)]
JCTVC-J0129 CE1: Cross-check of mode-dependent transform simplifications [C. Yeo, Y. H. Tan (I2R)]

An additional variant is tested where DST is used for all 4x4 TUs for both luma and chroma and for both inter and intra. This was not tested visually, and was not advocated for adoption. It was remarked that the 4x4 transform is a subset of the larger transforms anyway.

JCTVC-J0388 Cross-check of simplification 3 of JCTVC-J0129 [K. Ugur (Nokia)] [late]
JCTVC-J0243 CE1: Cross-check of intra transform mode dependency simplifications [J. Xu (Microsoft)]

5Non-CE Technical Contributions

5.1HEVC Standard Development

5.1.1Technical suggestions

JCTVC-J0292 Suggested figures for HEVC specification [C. Fogg (Harmonic)]

This proposal suggests the addition of a few diagrams not currently in the draft HEVC specification 1) Overall decoder stages to establish the logical flow order, in particular the sequential loop filters (DF, SAO, ALF); 2) an illustration showing the possible generic (non-profile/level specific) block shapes for CU, TU, PU ; 3) the possible transform types and sizes. While pseudo-code and specification language written in a literal manner that could be assembled into meaning by a compiler has its uses (contractdisputes, artificial intelligence, natural language to Verilog/VHDL translators..), collective studies show that human understanding improves with visual aides that engage a larger area of the cortex analyzing spatial relationships than the networks integrating just the processing islands of non-symbolic language and logic.

It was agreed that having more figures may be desirable, if feasible – provided the figures are correct. The consideration of this input was delegated to the editor.

JCTVC-J0293 Lumpy Intra frames in HEVC [C. Fogg (Harmonic)]

The author conducted a series of tests designed to approximate a typical VoD and IPTV operating points of 480p MPEG-2 (FFMPEG), 720pAVC (x264), and 1080pHEVC (HM 7.0) all coded at 3 Mbit/sec 2-pass average bitrate with CBR-like buffering constraints. The study concluded that, as expected, I-frames exhibited increased relative size to average coded frame size in HEVC compared to AVC and MPEG-2. In essence, the highest temporal GoP layer (non-referenced b-frames) has shrunk much more than the lower temporal layers (referenced B frames, "P" frames, and I frames). The question this presents is: does this merit new tools to address this problem, or should industry accept the benefit of lower overall bitrates provided by HEVC and change trick mode practice?