The Joint Collaborative Team on Video Coding (jct-vc) of itu-t wp3/16 and iso/iec jtc 1/sc 29/wg 11 held its second meeting during 21-28 July, 2010 at the itu-t premises in Geneva, ch

JCTVC-B121 [R. Sjöberg (BoG)] Report of High-level syntax BoG

A break-out session was held on July 24 from 11:30 a.m. to 2:00 p.m. in room A to discuss what high-level elements to carry over from AVC to TMuC as a starting point.

A report of this break-out activity was presented and agreed as supported by the group. The planned high-level syntax is based on the AVC high-level syntax but is stripped of elements that are not needed or not appropriate in TMuC.

Questions raised included whether support for interlaced-scan video coding features and color formats other than 4:2:0 was needed in the high-level syntax.

It was emphasized again that no requirement for efficient coding of interlaced-scan video exists in the requirements documents of the parent bodies. Other color formats such as 4:4:4 will need to be developed, but this requires changes to the software at various levels, and is not currently of high priority.

Most of the HL syntax definitions suggested by the BoG would currently only be included in the text document, not implemented in software.

JCTVC-B122 [W. Wan (Broadcom), P. Topiwala (FastVdo), P. Pandit (Harmonic), H. Yu (Huawei), Y. Chiu (Intel), B. Jeon (LG), S. Lei (Mediatek), S. Sekiguchi (Mitsubishi), K. Panusopone (Motorola), K. Chono (NEC), Y. Shishikui (NHK), A. Segall (Sharp), M. Zhou (TI), T. Chujoh (Toshiba), T. Suzuki (Sony)] Proposed approach on test model development (late)

This document was submitted late, on Monday 26 July.

This document proposed an approach for the development of the HEVC Test Model (TM). The stated goal was to accelerate the process of evaluating and developing the HEVC standard in a constructive way. As a first step, it was proposed to define a "reference configuration" of the TMuC software by the conclusion of the Geneva meeting. This "reference configuration" would include only one tool for each, significant functionality. As a second step, it was proposed to evaluate additional tools by comparison with this "reference configuration". The stated goal was to simplify the implementation of remaining tools, as well as other tools, into common software for evaluation. Finally, it was proposed to put more focus on the encoder description during the editing of the TMuC document, with the goal of ensuring a fair evaluation of coding tools.

Issues that were stated:

• 
  Define reference configuration: During the presentation, the authors largely agrees with discussion on Sunday. Request that an output document is provided along with the config files that textually describes the tools in default config. Possibly also a kind of software manual.
  
• 
  Define procedure for TM definition based on evaluation of single tools (note: actually, this is the purpose of TE12)
  
• 
  Develop encoder description (note: Will this be the same document? Who is responsible – same group of people that edits the TMuC?)
  
• 
  Request to have anchor data within one month after the meeting. Potentially, to achieve this, each TE could contribute part of the resources.
  

Much of the content of the contribution seemed to essentially be suggesting plans that had already been agreed or assumed. However, discussing the subjects again explicitly was useful.

It was requested to produce a document describing which tools are used by the reference configuration.

In discussion of the contribution, it was suggested that there should be a document (perhaps the same document) describing how to enable/disable each tool, and where any conflicts might arise in their use in combination.

For adoption into the test model, a proponent must provide adequate evidence of intended benefit based on appropriate metrics, including tool-by-tool analysis and consideration of interaction with other tools – and the effectiveness needs to be verified by a 3rd party. It was agreed that this is our planned (and usual) way of operating.

In terms of evaluation needs, there should not be any presumption of a difference in status between tools in the reference configuration and other tools.

It was requested that an encoder description should be provided for the TMuC tools. It was agreed to create such a document – as a separate document from the decoder description. The creation of this document as JCTVC-B204 was assigned to the TMuC editing AHG.

It was requested for there to be a "reference configuration" of the TMuC software. This had already been planned.

In regard to the evaluation of tools that are already in the TMuC, the inclusion of something in the "reference configuration" setting should not be construed as a selection of technology that needs less analysis and justification than any other feature. This was agreed.

It was suggested to test the effectiveness of transform blocks (TU) that span across multiple prediction unit (PU) blocks. This may be necessary for some asymmetric PU partitioning schemes, but may not be desirable for ordinary 2ⁿx2^m rectangular partitioning (assuming the segmentation signaling is designed appropriately).

It seems that currently only one tool (asymmetric partitioning) cannot be switched off.

JCTVC-B122 requested using only one default configuration setting (instead of high and low complex modes)

• 
  usage of AVC intra coding modes for 4x4 and 8x8
  
• 
  usage of up to 32x32 transform only
  
• 
  usage of 12-tap DCT-based interpolation filter
  
• 
  usage of PIPE
  
• 
  usage of IBDI
  
• 
  switch off combined intra prediction
  
• 
  switch off merge mode
  
• 
  switch off rotational transform
  
• 
  switch off adaptive intra smoothing
  

After discussion, it was agreed to use the reference configurations described elsewhere in this report as documented in JCTVC-B300.