International organisation for standardisation organisation internationale de normalisation

14.13TE12 TMuC encoder-only aspects

14.13.1.1.1.1.1.1.1JCTVC-C044 TE12: Results for experiments on max CU size, RDOQ and AIS [F. Bossen, T. K. Tan (NTT DoCoMo)]

This section discusses the RDOQ part of this contribution – other parts of the same document were addressed in other categories.

Rate-distortion optimized quantization (RDOQ) is a well-known technique for improving the rate-distortion performance associated with the encoding of transform coefficients. In the following experiments this optimization is disabled to quantify its contribution to coding efficiency and to encoding time. Only low-complexity configurations were tested. The reduction of encoding time observed when disabling RDOQ ranges from 8 to 17%. While this difference is significant, the drop in BD-rate performance can be signigicant, up to 3.2% on average for the random-access configuration.

It should be noted that the experiments were run on version 0.7 of the software and thus do not include updates to the low-complexity entropy coder (LCEC_PHASE2 macro).

Considering the reported results, the contributor suggested to keep RDOQ enabled by default for future work.

14.13.1.1.1.1.1.1.2JCTVC-C238 TE12.8: Results on RDOQ in high efficiency settings [J. Zan, J. Meng, M. T. Islam, D. He (RIM)]

This contribution reported results of cross-checking activities performed by RIM on RDOQ (described in JCTVC-B312) for all three high-efficiency settings.

Test results had been compared to those generated by Ericsson. For "intra" and "low delay" modes, RIM test results reportedly matched Ericsson’s; for the "random access" mode, there is minor (less than 0.1%) differences on four sequences: 1) the PeopleOnStreet sequence on the V component; 2) the Kimono sequence on the U component; 3) the ParkScene sequence on the U and V component; and 4)the RaceHorsesC sequence on the V component. Overall, the difference in results between the RIM and Ericsson tests was reported to be very minor and all the data on the summary tab of the results spreadsheet matched each other.

The test results were reported to have shown that RDOQ is an effective technique to enhance the coding performance (Rate and PSNR) of the video coding algorithm. Specifically, for intra only setting, the gain by using RDOQ on Y-component was reported to be on average 4.7% (in BD-rate); for random access setting, the gain on Y-component was reported to be on average 4.4%; and for low-delay setting, the gain on Y-component was reported to be on average 2.5%. It was observed that RDOQ offers the largest coding performance gain on Class B sequences.

Considering the reported results, the contributor suggested to keep RDOQ enabled by default for future work.

14.13.1.1.1.1.1.1.3JCTVC-C159 TE12: Cross verification of RDOQ [K. Andersson (Ericsson)]

Both low complexity and high efficiency test cases were tested by Ericsson.

Similar results were reported by Ericsson as in the other RDOQ contributions.

Considering the reported results, the contributor suggested to keep RDOQ enabled by default for future work.

15Project planning and Test Model establishment

15.1Project timeline

15.1.1.1.1.1.1.1.1JCTVC-C022 WG11 USNB contribution: Suggested practices for the HEVC project in the JCT-VC [A. G. Tescher (for USNB to WG11)]

The USNB to WG11 requested to establish the following practices for the HEVC project in the JCT-VC:

• 
  The group-adopted "Test Model" (which is expected to be produced in version 1 form at the October 2010 meeting) should contain only the minimum set of well-tested tools that together form a coherent design that has been confirmed to show good capability.
  
• 
  This "minimum set" may include such variations as would be appropriate for forming multiple profiles of the design (but should not otherwise contain significant duplication of functionality).
  
• 
  In the event that insufficient analysis is available to establish a consensus on the appropriate minimum set of well-tested tools by the October 2010 meeting, it was suggested that obtaining this consensus should be a higher priority than the goal of adopting a version 1 of the Test Model in October 2010.
  
• 
  An encoder text description, a decoder text specification, and software matching the encoder and decoder algorithms should be provided for the tools in the Test Model within one meeting cycle of the adoption of a tool into the Test Model. (It may be appropriate for the encoder text description to be in a separate document from the decoder specification.)
  
• 
  Appropriate software coding guidelines should be established and followed to ensure high quality software development of the Test Model.
  

These aspects were tentatively agreed on Sunday a.m.

15.1.1.1.1.1.1.1.2JCTVC-C023 WG11 USNB contribution: HEVC standardization timeline [A. G. Tescher (for USNB to WG11)]

Considering the timeline plan for the HEVC standardization approval process and the substantial need for maturation of the design and text drafting efforts for this new standard, the USNB to WG11 proposed that the timeline plan should be adjusted to:

• 
  CD ballot to be issued from the April/May 2012 meeting
  
• 
  DIS (formerly FCD) ballot to be issued from the October 2012 or January 2013 meeting
  
• 
  FDIS to be issued from the July 2013 meeting.
  

15.1.1.1.1.1.1.1.3JCTVC-C299 UK National Body comments on HEVC Timescales [UKNB to WG11] (late registration, missing prior, available first day)

The UKNB welcomed the progress that had been made so far in the development of the new High Efficiency Video Coding (HEVC) standard. They said that the creation of the "Test Model under Consideration" has been a useful first step in making the transition from a competitive to a collaborative method of working, and that the momentum that has built up around this approach should be maintained.

They indicated that there is a need to deliver this important new standard to the market in a timely manner, and requested for MPEG to maintain the timescales that were defined in the Call for Proposals, as follows:

• 
  Test model selection by 2010/10
  
• 
  Final standard approval by 2012/07
  

The UKNB further requested MPEG to provide details of the planned intermediate stages of this process, bearing in mind the revised procedural rules to be followed by ISO/IEC JTC 1 and the need to align key steps with the ITU approval process.

Further discussion was then postponed to Wednesday (see below)

15.1.1.1.1.1.1.1.4m18579 Comments on HEVC Test Model [CNNB to WG11, late registration, missing prior, available later]

The Chinese NB to WG11 submitted this late document, which was not registered as a JCT-VC document. Since it was brief, it is quoted below for the record:

"According to the tentative timeline described in Joint Call for Proposals on Video Compression Technology (W11113), the Test Model of HEVC is expected to be created at the October 2010 meeting.

CNNB believes that a stable version of Test Model with good quality is essential to the further development of the HEVC standard. Each tool in the Test Model shall be well-tested and be confirmed with good performance. The group should give quality and stability as highest priority in the development of the Test Model.

Considering the frequent updates and inadequate testing to the TMuC software during the interim period, CNNB suggests the group adopts only such well-tested tools in the TMuC to create the first version of TM and expects the group could get consensus at this meeting."

These remarks were taken into consideration in the subsequent discussion, which is reported below.

15.1.1.1.1.1.1.1.5Schedule plan discussion (held Wednesday)

The current WG 11 plan / UK suggestion was summarized as follows:

• 
  (WD 11/01) CD July 11 FCD/DIS Jan 12 FDIS July 12.
  

The WG 11 US NB suggestion was summarized as follows:

• 
  (WD 11/01) CD May 12 FCD/DIS Oct 12 or Jan 13 FDIS July 13.
  

It was remarked that we could establish a WD now (as the TM is a complete solution), rather than waiting until 2011/01. Later at the meeting, we did agree to issue a WD as an output of this meeting.

Participants remarked that a CD should be

• 
  Stable in text
  
• 
  Fully verified by software
  
• 
  Meeting the goals in terms of coding efficiency (roughly)
  

Opinions expressed were recorded as follows:

• 
  It would take 4-5 meeting cycles to come from current TM to CD.
  
• 
  H.262 / MPEG-2 took 5 cycles; MPEG-4pt2 took more cycles than that.
  
• 
  AVC took 16 meeting cycles from initial H.26L reference to final standard (12 to CD).
  
• 
  "We should keep the meeting schedule to put sufficient pressure on ourselves", vs. "We could release the pressure and always go faster if things come together more quickly than anticipated."
  
• 
  The market is changing rapidly (and new applications are coming), and the timeline should be kept but could be changed later if necessary.
  
• 
  Milestones were met so far (CfP/TM), why should we shift the upcoming milestones compared to what was said in the CfP?
  
• 
  There is a danger that proprietary codecs may appear and take over if we wait for too long
  
• 
  Stable software is needed to serve as the basis of the work, and stability of text depends on that (need for verification of the text by the software). And being able to run the software is one thing, having an opportunity to actually understand it and properly specify it is another.
  
• 
  As code is not well documented yet, and a considerable amount of new tools are still needed to achieve the goal of coding efficiency, it will be difficult to reach adequate maturity in the 3 meeting cycle periods between now and a July 2011 CD milestone.
  
• 
  Dual track idea – make a low complexity variation first? This might counteract the desire to have most tools in common for LC and HE. We must also make sure that the solution keeps the complexity reasonable – for both HE and LC. Even for an LC variant, there is an HE intent.
  
• 
  The current specification (as from TMuC) is still far from being mature.
  
• 
  We still need better understanding about the interaction of the different parts of the TM.
  
• 
  The compromise then suggested was: CD Jan 12, DIS July 12, FDIS Jan 13.
  
• 
  The coding efficiency goal is important and should not be missed. The market will take it up when HEVC achieves 50% compared to AVC.
  
• 
  The compromise suggested would be agreeable if Jan 13 is really staying the end point (i.e. unless a substantial instability or failure of reaching the goals is detected in the standard later).
  
• 
  This compromise was agreed and recorded in a resolution reported to the WG11 parent body: "The JCT-VC thanks the NBs of UK and US on their valuable comments related to standardization timelines of HEVC. The situation has been considered, particularly including the feasibility of proceeding from the current test model and WD to a mature CD text that fulfils the requirements of the project within the available number of meeting cycles. It is believed that with a timeline of CD 12/02, DIS 12/07 and FDIS 13/01, the probability of producing a high-quality standard would be maximized. With such a timeline being established, only exceptional circumstances should require further delay. Considering comments about the process for test model development that has been followed by the JCT-VC, which were raised by these NB comments and by the NB of China, a document N11642 [a document produced for WG11 corresponding to the content of JCTVC-C401] has been issued which provides an explanation of this process."