International organisation for standardisation organisation internationale de normalisation

RExt editing status

Starting with P1005-v2, the RExt editorial status was reviewed Tues 1000-1330 (GJS)

• 
  Profile & level
  
  • 
    Question: Should we ever require cabac_bypass_alignment_enabled_flag to be 1? If yes, should we require decoders to decode bitstreams in which it is 0 (e.g. in lower levels)?

    Decision: Main 4:4:4 16 Intra and all other profiles in this meeting's output draft will require the feature to be disabled. The planned new profile to be finalized in July as part of "SHVC" will have an additional profile with higher bit rate capabilities that will require that feature to be enabled and will not require decoders to decode bitstreams in which the feature is disabled.

    
    
  • 
    Question: Table A-3: Scale by 1.25 and 1.5 instead of 1.5 and 2 for bit rate and CPB size adjustments for 4:2:2 and 4:4:4? No action needed – 1.5 and 2 confirmed.
    
  • 
    Question: Change mcts_tier_flag[ i ] and max_mcts_tier_flag as u(1) to mcts_tier_value[ i ] and max_mcts_tier_value as ue(v) for future proofing (although technically OK for currently specified profiles). Decision: Agreed.
    
  • 
    Question: constraint on sps_extension_7bits seems to be wrong.
    Decision (Ed.): Constraint in Annex A is mistaken and should be removed.
    
  • 
    Question: constraint forbidding presence of extension of SPS for Main is unnecessary and should be removed (and may inadvertently cause non-conforming bitstreams to exist). Decision (Ed.): Remove that constraint.
    
  • 
    Question: PPS extension drafted incorrectly regarding using extension flag 0 when it isn't present. Should either have inferred value 0 or should be nested inside if statement that establishes its presence. Decision (Ed.): Agreed (the same editorial alternatives exist for the SPS and PPS extension and it would be editorially preferable to use the same method of describing it in both cases).
    
  • 
    Question: SHVC and MV-HEVC drafts conflict with RExt and do not allow extension bits other than extension bit 7 to be used. Decision (Ed.): Fix that.
    
  • 
    SEI message specification maturity was evaluated, and agreed to be categorized as follows:
    
    • 
      Seem mature – proceed in RExt:
      
      • 
        Colour volume
        
      • 
        No display
        
      • 
        Timecode
        
    • 
      Plan to move from RExt draft to SHVC draft:
      
      • 
        MCTS
        
      • 
        Knee function
        
      • 
        Chroma resampling filter
        
  • 
    Colour VUI – see notes on Q0084.
    
  • 
    No special need for review was identified for the following topics:
    
    • 
      Need to update payloadType list.
      
    • 
      Main 4:4:4 16 Intra should have no other "tool constraints"
      
    • 
      MinCR handling – seems OK.
      
    • 
      Editorially, bracket the constraint flags to clarify and simplify semantics.
      
    • 
      Should we allow additional flag combinations to be used? (No: it is more future-proof to disallow them for now.)
      
    • 
      For hypothetical auxiliary pictures (not in RExt), there is no 8b monochrome profile. This aspect was decided to be changed later, as recorded in sections 7.5.1 and 8.1.
      

In additional further discussion near the end of the meeting (GJS), it was noted that CABAC initialization and CBF had been identified by the editors as areas of potential deficiencies in the text. Decision (Ed.): Generally speaking, discrepancies in these aspects should be resolved by studying the software in case of doubt.

7. HEVC, SHVC and RExt use cases (requirements related) (4)

To be dealt with at parent level – outside the scope of current JCT-VC work. Not reviewed.

1.1.1.1.1.80JCTVC-Q0085 HDR/WCG workflow [B. Mandel (Universal)]

1.1.1.1.1.81JCTVC-Q0190 Evaluation of distortion metrics on HDR video content [E. François, P. Lopez, F. Le Léannec, S. Lasserre (Technicolor)] [late]
1.1.1.1.1.82JCTVC-Q0191 New HDR video coding results [E. François, S. Lasserre, F. Le Léannec (Technicolor)] [late]
1.1.1.1.1.83JCTVC-Q0192 Insights and open questions on HDR/WCG video coding [D. Singer, A. Tourapis] [late]

8. Source video test material (4)

The test sequences described below may be valuable for testing RExt coding performance. Detailed review of these contributions was not requested. Demonstration viewing was conducted for some of these as side activity during the meeting.

1.1.1.1.1.84JCTVC-Q0087 Technicolor clip results [B. Mandel (Universal), C. Fogg, J. Helman (Movielabs)] [late]

1.1.1.1.1.85JCTVC-Q0088 StEM and Telescope HDR/WCG test sequences [J. Helman, C. Fogg (Movielabs)]
1.1.1.1.1.86JCTVC-Q0228 DCI StEM Content Description [J. Helman (Movielabs), W. Husak (Dolby)] [late]
JCTVC-Q0232 HDR/WCG StEM and Telescope clips encoded as Y'DzDx and BT.2020 9 [B. Mandel (Universal), C. Fogg, J. Helman (MovieLabs)] [late]

4. Core experiment in SHVC (10)

   1. SCE1: Colour gamut and bit depth scalability (10)

      1. SCE1 summary and general discussion (1)

1.1.1.1.1.87JCTVC-Q0021 SCE1: Summary Report of Colour Gamut and Bit Depth Scalability [P. Andrivon, A. Duenas, E. Alshina, Y. Ye, K. Ugur, X. Li]

Discussed 2nd day p.m. (GJS).

This document summarizes the activities and test results performed in SCE1 on Colour Gamut and Bit Depth Scalability. The evaluated tools and the test conditions are defined in document JCTVC-P1101.

Basically, there were two groups of proposals.

• 
  1.1, 1.2, 1.3, 1.4 = various gain/offset models
  
• 
  2.1, 2.2 = 3D LUT mapping 8x2x2 – 8 uniform segments for luma, and 2 uniform segments for each colour channel, (a, b, c, d)  Y' = a_Y * Y + b_Y * U + c_Y * V + d_Y, U' = a_U * Y + b_U * U + c_U * V + d_U, V' = a_V * Y + b_V * U + c_V * V + d_V.
  

1.1 and 1.3 have thousands of table entries, which is generally agreed to be excessive.

1.4 requires a lot of computations and does not have great performance.

1.2 does not have a significant performance benefit relative to the anchor.

2.1 and 2.2 have 384 bytes of table data each, and not too much computational load, and operate in the lower-resolution domain. For each, a table would be sent in PPS and optionally updated in SH. It was asserted that the table content would be unlikely to be totally stable within a CVS of significant length. There was discussion of whether slice-level update is necessary or not – likely not seemed to be the tentative conclusion.

It was suggested that the 2.x proposals each contain a combination of techniques, and that some of the elements of these (esp. entropy coding part) may not be necessary/justified.

The difference between 2.1 and 2.2 is the use of spatial phase positioning alignment for chroma in 2.1, based on the assumption of the default positioning of the chroma samples. The gain for this is in the 0.31–1.0% range. The overall gain is 6–10% (as a percentage of the total bit rate).

The overall conclusion was that a 2.x approach or something close to it would not be overly burdensome to include and has adequate gain to justify its complexity, and should thus be adopted.

But it is for a particular application space, so should it be in a "generic" scalable profile for all profiles with a certain bit depth capability, or should it have its own profile?

Between 2.1 and 2.2, the gain difference is about 0.6%, with some extra complexity associated with the alignment adjustment due to look-ahead aspect of the position adjustment processing. There were mixed opinions about that.

A non-CE proposal Q0129 was trying to find a new trade-off.

Five sequences; two colour grades each, different resolutions, two bit depths for BT.709.

Gain was roughly 8% relative to WP for the highest-performing methods, 3% for the lowest-performing (1.2).

Further review was held in the evening of Wed. 2 April (GJS). Regarding the selection between the 2.1 and 2.2 variants, there was discussion of whether method 2.2 was simpler, and it was estimated that method 2.1 has about 0.6% gain over method 2.2.

Decision: Adopt method 2.1, with se(v) coding.

2. SCE1 primary contributions (2)

1.1.1.1.1.88JCTVC-Q0048 SCE1: Colour gamut scalability with asymmetric 3D LUT [X. Li, J. Chen, M. Karczewicz (Qualcomm), Y. He, Y. Ye, J. Dong (InterDigital), P. Bordes, P. Andrivon, E. Francois, F. Hiron (Technicolor)]
1.1.1.1.1.89JCTVC-Q0072 SCE1: Colour gamut scalability using gain-offset models [A. Aminlou, K. Ugur, M. M. Hannuksela (Nokia)]

3. SCE1 cross checks (7)

1.1.1.1.1.90JCTVC-Q0059 SCE1: Cross-check of JCTVC-Q0048 [A. Aminlou, K. Ugur (Nokia)]
1.1.1.1.1.91JCTVC-Q0097 SCE1: Crosscheck report on colour gamut scalability using gain-offset models (JCTVC-0072) [X. Li (Qualcomm)] [late]
1.1.1.1.1.92JCTVC-Q0123 SCE1: Crosscheck for Colour gamut scalability using gain-offset models (JCTVC-0072) Test 2 [K. Minoo (Arris)] [late]
1.1.1.1.1.93JCTVC-Q0143 Crosscheck report of SCE1 test on colour gamut scalability using 8x8x8 regions and matrix mapping (JCTVC-Q0072) [K. Misra (Sharp)] [late]
1.1.1.1.1.94JCTVC-Q0144 Crosscheck report of SCE1 test on asymmetric 3D-LUT with phase alignment filter disabled (JCTVC-Q0048) [K. Misra (Sharp)] [late]
1.1.1.1.1.95JCTVC-Q0196 SCE1: Crosscheck result of Test 1.3 [K. Sato (Sony)] [late]
1.1.1.1.1.96JCTVC-Q0222 SCE1: Cross-check of 3D-LUT parameter coding of JCTVC-Q0048 [K. Ugur, A. Aminlou (Nokia)] [late]

5.