International organisation for standardisation organisation internationale de normalisation

Association of CL-RAS pictures with IRAP access units. AU y does not have any association CL-RAS pictures in this bitstream (copied from JCTVC-O0212/JCT3V-F0072).
The contribution said that the indication of HRD parameters for bitstreams without CL-RAS pictures is the multi-layer equivalent of the indication of HRD parameters for bitstreams without RASL pictures for single-layer bitstreams. The HRD parameters for bitstreams without RASL pictures are indicated in the buffering period SEI message with the cpb_delay_offset, dpb_delay_offset, nal_initial_alt_cpb_removal_delay[ i ], nal_initial_alt_cpb_removal_offset[ i ], vcl_initial_alt_cpb_removal_delay[ i ], and vcl_initial_alt_cpb_removal_offset[ i ] syntax elements.

In this contribution, it is proposed to indicate that HRD parameters for a bitstream without CL-RAS pictures and without RASL pictures associated with the first IRAP picture of each layer using a buffering period SEI message included in a scalable nesting SEI message that applies to a layer set. The syntax elements cpb_delay_offset, dpb_delay_offset, nal_initial_alt_cpb_removal_delay[ i ], nal_initial_alt_cpb_removal_offset[ i ], vcl_initial_alt_cpb_removal_delay[ i ], and vcl_initial_alt_cpb_removal_offset[ i ] are interpreted for a bitstream that excludes both the CL-RAS picture and the RASL pictures (associated with the initial IRAP pictures of each layer). No new syntax is proposed in the contribution.

The detailed proposal is included as change marks in an accompanying specification text document.

It was remarked that in the v1 syntax, we have a NUT that tells the decoder whether there may be RASL pictures or not, and if not, the "alternative" HRD parameters are used by the decoder. We do not have this indication for CL-RAS pictures. (It was previously proposed for CL-RAS pictures to have a distinct NUT value, but this is not the approach that was adopted.)

A prior proposal suggested to have a (possibly externally-supplied) flag associated with the base layer IRAP picture with NoClrasOutputFlag equal to 1 to indicate whether RASL or CL-RAS pictures can be present or not. This approach would presumably work with the proposal.

The proposal avoided needing extra syntax as had been proposed previously in a similar-concept proposal O0212.

It was remarked that the flag could also be sent as an extension bit in the BP SEI message.

It was also remarked that a similar previously-specified flag called UseAltCpbParamsFlag could perhaps benefit from putting such a flag in the SEI message.

It was remarked that one flag may be sufficient for both purposes.

These can be considered, from the v1 perspective, as a form of "external means".

Offline double-checking was conducted and the contribution was further discussed on 01-14 (GJS).

Decision: Adopt (as revised in updated contribution, with the specification of a flag in the BP SEI message).

14.1.97.1.1.1.1.1.326JCTVC-P0069 MV-HEVC/SHVC HLS: Decoded picture buffer signalling [B. Choi, Y. Cho, M.W. Park, J.Y. Lee, H. Wey, C. Kim (Samsung)]

Discussed 01-10 a.m. (GJS).

The decoded picture buffer (DPB) size for each output layer set is signalled according to the maximum number of sub-layers of each output layer set. In VPS extension, max_sub_layers_output_layer_set_minus1[ i ] is proposed to indicate the maximum number of sub-layers for the i-th output layer set. When max_sub_layers_output_layer_set_minus1[ i ] is present, syntax elements related to DPB-size (max_vps_dec_pic_buffering_minus1[ i ][ k ][ j ], max_vps_num_reorder_pics[ i ][ j ], max_vps_latency_increase_plus1[ i ][ j ]) are signalled as many as the values of max_sub_layers_output_layer_set_minus1[ i ]. The maximum number of each output layer set can be inferred from other syntax elements, without explicit signalling.

This first aspect was resolved by the action taken on P0156 proposal 1.

Additionally, it was proposed that the DPB-related syntax elements for sub-layers of each output layer set be moved to the video parameter set VUI instead of being in the current drafted location in the VPS extension. It is asserted that those syntax elements are informative without affecting the normative decoding process. However, it was marked that these syntax elements are used to specify conforming bumping requirements in Annex C, so no action was taken on this aspect.

14.1.97.1.1.1.1.1.327JCTVC-P0156 MV-HEVC/SHVC HLS: On DPB Parameters in VPS [S. Deshpande (Sharp)]

Discussed 01-10 a.m. (GJS).

Three items:

• 
  Proposal 1 of this document proposes to signal, in the VPS extension, the DPB parameters for an output layer set for sub-DPBs only up to the maximum temporal sub-layers in the corresponding layer set. It is asserted that this modification avoids signalling meaningless parameters for non-existing temporal sub-layers in a layer set.
  
• 
  Proposal 2a: The derivation of NumSubDpbs[i] is modified to use correct index into the NumLayersInIdList list.
  
• 
  Proposal 2b: Also inference for output_layer_set_idx_minus1[ i ] for default output layer sets is defined.
  
• 
  Proposal 3: The output_layer_flag[i][j] is signalled for j equal to 0 to NumLayersInIdList[ lsIdx ] inclusive. It was remarked that we might be able to just assume that the top layer is always output; however, this was not entirely clear (e.g., for auxiliary picture layers), so the safe thing to do may be to also send the flag for this layer.
  

Decision (cleanup): Adopt (all four aspects).

14.1.97.1.1.1.1.1.328JCTVC-P0192 MV-HEVC/SHVC HLS: On decoded picture buffer management [Y.-K. Wang, A. K. Ramasubramonian, Y. Chen (Qualcomm)]

Discussed 01-10 a.m. (GJS).

At the JCT-VC#15 and JCT-3V#6 meetings in Geneva, the group agreed to specify a separate DPB capacity for each layer without sharing of DPB capacity across layers. This document proposes either to allow for DPB capacity sharing across layers to utilize the process for DPB memory optimization, or to remove the reference marking processes in subclause F.8.1.4 per discardable_flag and in subclause F.8.1.4.1 per VPS layer dependency signalling for specification clean-up.

Alternative #1 in the contribution is a proposal to establish DPB capacity sharing across layers that have the same spatial resolution, bit depths, and colour format. It is asserted that sharing can be specified without very much added text or complication.

Regarding alternative #2 in the contribution, unless some kind of cross-layer sharing/constraint is specified this is essentially editorial clean-up – the current text is not actually broken, but includes a description of two unnecessary processes (one based on discardable_flag and one based on layer-dependency signalling in the VPS).

The contribution also includes some suggested editorial clean-ups.

Decision (Ed.): Editorial aspects delegated to the editors for consideration.

It was noted that P0142 is related, as it advocates a cross-layer constraint on memory usage.

It was remarked that we should probably have a separate DPB for a non-HEVC base layer.

At the previous meeting, it was said that "it seems that the cases where there would be an advantage of sharing the capacity across layers may be sufficiently rare to not be worth worrying about".

However, it seemed desirable for the properties of bitstream characteristics description of the capacity needed for an output layer set to be describing the actual needs of that output layer set. If each capacity is considered entirely separate for each layer, the syntax would have an unnecessarily higher value than what is actually needed to decode that output layer set.

It was suggested for the syntax to describe both properties of the bitstream and for the bumping process to pay attention to both types of properties. Then, for profile/level specification purposes, we can choose which type of constraints to apply, which can be a limit on shared capacity, a limit on per-layer capacity, or both.

Further discussion was held on 01-14 after text was prepared for that approach.

The possibility for the representation format (picture size, bit depth, chroma format) to change within a layer (at the SPS level). Ways to deal with this were discussed:

• 
  Establish sub-DPBs based on the representation format indicated at the VPS level. This approach was preferred.
  
• 
  Re-assign the sub-DPBs when there is a change (which did not seem desirable).
  

It was discussed how a profile/level specification could express constraints. It seemed that this might or might not affect the desired syntax.

It was suggested that the expressed shared capacity limit would need to be less than or equal to the sum of the individual capacity limits.

Decision: Adopt as modified. Further study is encouraged on profile/level constraint selections.

4.