Of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11

3Project development, status, and guidance (6)

3.1Corrigenda items (0)

See the section discussing the AHG 2 and AHG7 reports.

3.2Profile/level definitions (1)

JCTVC-X0034 On profiles and per-feature flags [S. Wenger (Vidyo)]

It is was proposed to include a set of flags in the VPS or equivalent, which can be used to signal the non-use of individual coding tools in a given signalled profile. The mechanism is intended to allow the encoder to “dial down” on the feature set used in the bitstream, relative to the signalled profile. If the use of a tool becomes inadvisable due to technical or economical concerns, it is suggested that encoders stop using the tool and, “if the pain were too high”, upgradable decoders could stop implementing it as well – without becoming considered non-compliantconforming. As a result, a likelihood is claimed that the a tool could falls into disuse;, in which case the implementation/testing burden for new or updated encoders and decoder should go down, and the economic base for exploiting a disabled tool should go away –, making the exploitation of its implementation economically difficult if not impossible.

See notes on joint meeting of Monday in section 7.2.

3.3Conformance test set development (0)

See the AHG report JCTVC-X0004 and outputs JCTVC-X1016XX for … SCC.

3.4Text development for HDR/WCG coding practices report (1)

JCTVC-X0079 Suggestion for new draft version of Conversion and Coding Practices for HDR/WCG Video [J. Samuelsson, A. Tourapis, J. Ström, C. Fogg] [late]

Initially discussed Fri. 27 May 0900–1100 (JRO).

This document contains a new suggested draft of the “recommended practice” technical report on HDR video. It is based on JCTVC-W1017 with modifications discussed during the teleconference meetings of AHG13 on April 11 and May 9 and some further modifications. It provides guidance on processing of high dynamic range (HDR) video. The purpose of this document is to provide a publicly referenceable recommended practice for the operation of AVC or HEVC systems adapted for compressing HDR video. This document includes a description of processing steps for converting linear light, RGB, 4:4:4 video signals into ST 2084, Non Constant Luminance (NCL) YCbCr, 4:2:0 video signals compressed by the AVC or HEVC encoding. This document also includes a description of post-decoding processing steps for converting ST 2084, NCL YCbCr, 4:2:0 to linear light, RGB, 4:4:4 after decoding. Some high- level recommendations for compression with HEVC and AVC are also included in this document.

The term “HDR10” has been defined by other bodies. This should be used with reference to those (already in list of references) without redefining it. Note that, even though currently mainly referring an “HDR10” style encoder, the report may finally point to the usage of additional elements, e.g., SEI messages.

It was suggested that the dThe document should not say “we” but make it neutral

Document will come with software, and configuration files that reflects how the latest anchors were generated. Then, the processing done for the anchors should be described as primary examples, and at appropriate points express other ways of potentially doing it. The old CfE configuration and the current anchor configuration should be called “models” for which software configuration settings are provided, and this could later be extended by other models, if value is demonstrated.

The main body of the text should describe the processing steps, with some additional notes how it is done in the model(s), or how it might be done differently. More precise description of the model(s) should then be given in annex(es).

It was discussed whether to start experimentation on using different types of filters. Several experts expressed a desire for doing this. However, the current output draft TR document should only specifically describe the filters used for "anchor 3.2" (i.e., [1 6 1]/8 with [-−1 9 9 -1−1]/16), and should not give the impression that only these specific filters are useful.

Discussion about the purpose of the document:

• 
  The AHG report suggests that in general the document should be less of a “specification” and more of a “description”.
  
• 
  However, it should only contain a description of building blocks for which a benefit has been demonstrated and agreed by JCT-VC.
  
• 
  The document should enable the reader to understand how the current anchors are generated and what the motivation of certain processing steps is.
  
• 
  The configuration(s) of the “model(s)” that are used to generate anchors should be described in annex(es).
  
• 
  The current 7.2 and 10.2 of X0079 should be further studied, not included in the “conversion and coding practices” output.
  

The part about encoding should describe:

• 
  The profile and transfer colour metadata types that are used
  
• 
  The methods that were agreed to be useful for fixed QP, brightness adaptive quantization when adaptive QP is available, chroma QPqp offset, but primarily in terms of motivation rather than exactly specifying how it is done in the anchors. Side activity was requested (coord. by Jacob Strom and Andrew Segall) was requested to draft a some text for further discussion.
  

Further discussion was held Tuesday 1500 (GJS)

Decision: Regarding precision, it was agreed to have a sentence or two, but at least not much more, to mention that rounding can sometimes be done prior to the downsampling, e.g., to 10 bit, although retaining more precision through that process would avoid introducing distortion in that step.

Decision: The method used in the anchor will be described precisely (although briefly), but characterized only as an example to illustrate the concept.

The document should not say “we”, which seems informal and could lead the reader to wonder exactly who that is (since no specific authors will be identified in the published report).