JVET-S0141 AHG9: A Summary of Proposals Related to HRD [S. Deshpande (Sharp)]

This contribution was discussed in the HLS AHG meeting at 0850 UTC on Thursday 28 May, in the HLS AHG pre-meeting at 1530 on 20 June and in the JVET meeting at 1935–2320 on 23 June (chaired by GJS), 1640 on 24 June (chaired by GJS), 1900 on 25 June (chaired by GJS), 1315 on 27 June (chaired by GJS & JRO), and 2145 on 28 June (chaired by GJS & JRO).

This contribution intends to provide a summary of proposals on core aspects of HRD (including HRD operation, related SEI message signalling and sub-bitstream extraction).

Following proposals listed in JVET-S0137-v2 section 3.1.8 are covered in this summary: JVET-S0064, JVET-S0075 (aspect 2), JVET-S0097, JVET-S0080, JVET-S0086, JVET-S0099, JVET-S0101, JVET-S0102, JVET-S0117, JVET-S0118. Additionally, JVET-S0049 Item 1 is covered.

Additionally, the 14 new proposals listed below in this Section starting from JVET-S0154 are also covered in this summary.

It is suggested that this summary be used for the reviewing of these proposals, such that the discussions may be done in a more structured and efficient manner. The following changes were proposed:

Related to HRD signalling and operation:

1. Conditionally signal bp_sublayer_dpb_output_offsets_present_flag (and bp_dpb_output_tid_offset[ i ]) only when bp_max_sublayers_minus1 is greater than 0 and infer it as 0 otherwise?
   1. Alternatively, add following constraint: when bp_max_sublayers_minus1 is equal to 0, bp_sublayer_dpb_output_offsets_present_flag shall be equal to 0. (JVET-S0064)

See also items 20 and 21 for rationale.

AHG Recommendation (cleanup): Adopt the conditional signalling.

1. When sps_video_paramater_set_id is equal to 0:

AHG Recommendation (bug fix/expression of existing intent): Adopt inferences a, b, c, e, f, and g.i.

• 1. Infer TotalNumOlss to be equal to 1 (JVET-S0075, JVET-S0097)
  2. Infer NumLayersInOls[ 0 ] to be equal to 1 (JVET-S0075, JVET-S0097)
  3. Infer vps_layer_id[ 0 ] to be equal to the single value of nuh_layer_id of all the VCL NAL units. (JVET-S0097)
  4. Require that parameter sets referred to shall have same nuh_layer_id value (JVET-S0075)

It was commented that this aspect is not necessary since the extraction process indirectly requires this.

Also, sharing of PSs is only allowed only if all layers are present in the OLS, which would be violated unless the requirement is true.

Editor action item: The editor is asked to consider adding some explanation to point out that this is the case. Item e below may help to make this clear.

• 1. Infer LayerIdInOls[ 0 ][ 0 ] to be equal to the single value of nuh_layer_id of all the VCL NAL units. (JVET-S0097)
  2. Infer NumSubLayersInLayerInOLS[ 0 ][ 0 ] to be equal to sps_max_sublayers_minus1 + 1. (JVET-S0097)
  3. Modify the inference rule for vps_max_sub_layers_minus1 and range of values for sps_max_sublayers_minus1 by adding quoted text and not inferring vps_max_layers_minus1 to be equal to 6? (JVET-S0097)
     1. “When sps_video_parameter_set_id is greater than 0,” the value of sps_max_sublayers_minus1 shall be in the range of 0 to vps_max_sublayers_minus1, inclusive. “When sps_video_parameter_set_id is equal to 0, the value of sps_max_sublayers_minus1 shall be in the range of 0 to 6, inclusive, and vps_max_sublayers_minus1 is inferred to be equal to sps_max_sublayers_minus1.”

or

• • 1. Modify only the inference for vps_max_sub_layers_minus1 (JVET-S0049 Item 1, JVET-S0097) as: When sps_video_parameter_set_id is equal to 0, the value of vps_max_sublayers_minus1 is inferred to be equal to “sps_max_sublayers_minus1” (instead of 6).

It was commented that option ii has a circularity issue in the semantics of sps_max_sublayers_minus1, so option i is preferred.

1. Modify the semantics of bp_max_sublayers_minus1 to change the range of values from 0 to vps_max_sublayers_minus1 to instead require it to be equal to maxSubLayers (given as input to the ols_hrd_parameters() syntax structure)? (JVET-S0097)

It was commented that this has a relationship to JVET-S0100.

See the notes for JVET-S0100 in section 3.3.

1. Modify the additional bumping process for DPB by doing following? (JVET-S0080)
   1. Move the process for setting the value of PicLatencyCount from within additional bumping process to within the output and removal of pictures from the DPB (i.e., sub clause C.5.2.2) after the invocation of bumping process.

It was commented that no action is needed on this due to the recommended action for PictureOutputFlag for JVET-S0077.

• 1. Remove the additional bumping process or removal of the output of pictures in the additional bumping process.

This aspect was deferred for further study by the HLS AHG.

This was further discussed in the JVET meeting at 1640 on 24 June (chaired by GJS). The contributor said they had concluded that there was a problem with the contribution as proposed, so the request for its consideration was withdrawn.

Discussion in the HLS AHG meeting stopped here at ~0220 on 28 May.

Discussion continued here in the HLS AHG pre-meeting at 1530 on 20 June.

1. Fix an asserted bug in Equation C.10 (also applicable to HEVC)? (JVET-S0101)

AHG Recommendation (bug fix/expression of existing intent): Adopt (also applicable to HEVC).

1. Add a constraint on the sum of InitialCpbRemovalDelay and InitialCpbRemovalOffset as follows? (JVET-S0101)

When bp_concatenation_flag is equal to 0, the sum of InitCpbRemovalDelay[ Htid ][ ScIdx ] and InitCpbRemovalDelayOffset[ Htid ][ ScIdx ] shall be the same as in the previous buffering period.

In the discussion, it was commented that we need to consider the possibility of splicing without the use of bp_concatenation_flag equal to 1. It was commented that this constraint could be a very serious imposition for such a splicing operation, and would be unlikely to be fulfilled in practice.

No action was recommended on this.

1. Include PH and AUD NAL units into the bitstream subject to HRD conformance checking using either of the following alternative options? (JVET-S0118)
   1. Include PH NAL unit and AUD in Type I bitstream
   2. Include PH NAL unit and AUD in Type II bitstream

Currently, Type I includes VCL (i.e., slices) and filler data NAL units only. Everything goes in Type II (possibly needing editorial clarification, but this is clearly what is specified).

Since PH is sometimes in the SH, it will be in Type I when it is not in a separate NAL unit.

When rewriting / BEAMing, we do not ordinarily expect PH content to be rewritten.

AHG Recommendation (consistency cleanup): Include PH NAL unit in Type I (but keep AUD in Type II as it was).

Related to general and subpicture sub-bitstream extraction processes:

Review of this group of contributions was deferred in the AHG, and the next topic discussed in the AHG was item 12. Discussion of these was held in the main JVET meeting at 1900 on 25 June (chaired by GJS).

1. Perform the asserted bug-fixes for the general sub-bitstream extraction process for determining which AUD NAL units of the input bitstream are kept in the output sub-bitstream as follows? (JVET-S0086)
   1. Add AUD_NUT among the NAL unit types that are kept in the output sub-bitstream regardless of its nuh_layer_id value.
   2. Add removal of an AUD NAL unit for which all VCL NAL units of an AU are removed by the sub-bitstream extraction.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Make the following changes related to the general sub-bitstream extraction process? (JVET-S0102)
   1. Add a constraint that the SEI payload of the BP/PT/DUI/SLI SEI messages for any two OLSs with the same layer set are the same.

Decision (sensibility constraint): Adopt (clarified as per above).

• 1. Modification regarding AUs that become IRAP or GDR AU after extraction by doing one of the two options:
     1. Option 1: Add AUD writing to the extraction process for AUs that become IRAP AUs or GDR AUs.
     2. Option 2: Mandate AUDs to be placed in AUs that contain only IRAP or GDR pictures for the layers of an OLS that contains more than one layer, and add rewriting of aud_irap_or_gdr_au_flag to extraction process.

Item 46) is related. One difference is whether AUD would need to be present in single-layer bitstreams.

The description of option 2 was refined in the group discussion.

It was commented that this requirement is already imposed indirectly by the fact that an extracted bitstream is required to be a conforming bitstream.

Editor action item: The editor is strongly suggested to add a NOTE (or editorial equivalent) to point out that the presence of AUDs for such AUs is indirectly required.

Decision (bug fix): Specify that when an AUD is present and the AU of the output bitstream becomes an IRAP or GDR AU, to set aud_irap_or_gdr_au_flag equal to 1.

Editor action item: The editor is suggested to consider removing “au_” from the name of aud_irap_or_gdr_au_flag, since it seems redundant.

• 1. Place PT SEI messages in individual SEI NAL units when general_same_pic_timing_in_all_ols_flag is equal to 1.

Item 37) is related – see the notes for JVET-S0178-v3 aspect 7.

• 1. Require that the scalable-nested and non-scalable-nested BP SEI messages in a CVS have the same values for the five syntax elements which specify lengths of various u(v) syntax elements.

Decision (consistenty cleanup): Adopt.

1. Modify the subpicture sub-bitstream extraction process regarding handling of scalable-nested SEI messages by performing following? (JVET-S0099)
   1. Removal of scalable-nested SEI messages for non-target subpictures

This is a subset of item 66). See the notes for that item.

• 1. Removal before replacing non-scalable-nested SEI messages

This is a subset of item 72). See the notes for that item.

1. Modify the subpicture sub-bitstream extraction process by performing the following? (JVET-S0117)
   1. Remove rewriting of PPS conformance window syntax elements since pps_conformance_window_flag is asserted to be equal to 0.
   2. Remove subpicture ID mapping in PPS by removing the syntax elements pps_subpic_id[ j ] in all the referenced PPS NAL units, for each j that is not equal to subpicIdx. (Note that the current text already addresses the SPS issue in an earlier version of the contribution.)

If the extracted subpicture is not the first subpicture and the original encoder did not explicitly provide the mapping information, then the mapping needs to be provided in the rewritten SPS.

• 1. Rewrite virtual boundary syntax elements in SPS (when they are present).

Decision (bug fixes): Adopt (all three aspects as described and refined above).

Discussion of these in the main JVET meeting ended at 2030 on 25 June (chaired by GJS).

New submissions (for the June 10th submission deadline)

Discussion in the AHG pre-meeting began here at 1635 on 20 June.

(Convention for text changes proposed: “quoted text” is proposed to be removed and text inside delimiters < > is proposed to be added by proposals)

Related to HRD signalling and operation:

1. Change HRD operation description from being picture-specific to be AU-specific as follows? (JVET-S0157 item 1)
   1. In clauses C.2.3, D.3.2, and D.4.2, rename prevNonDiscardablePic to prevNonDiscardableAu, firstPicInPrevBuffPeriod to firstAuInPrevBuffPeriod, notDiscardablePic to notDiscardableAu, and change their descriptions from being picture-specific to AU-specific.
   2. In clause D.3.2, change the description of the semantics of bp_concatenation_flag and bp_cpb_removal_delay_delta_minus1 from being picture-specific to be AU-specific.
   3. In clause D.3.2, change the description of the condition for the constraint requiring bp_alt_cpb_params_present_flag to be equal to 0 from being picture-specific to be AU-specific.
   4. In clause D.4.2, change the descriptions of BpResetFlag, CpbRemovalDelayMsb[ i ], CpbRemovalDelayVal[ i ] and the constraint requiring pt_cpb_alt_timing_info_present_flag to be equal to 0 from being picture-specific to be AU-specific.
   5. In clause D.4.2, change the description of the semantics of pt_dpb_output_delay, pt_dpb_output_du_delay, and pt_display_elemental_periods_minus1 from being picture-specific to be AU-specific.
   6. In clause D.5.2 (DU information SEI message semantics), change the description of the semantics of dui_dpb_output_du_delay from being picture-specific to be AU-specific.

It was commented that the design intent should already be clear that the HRD is intended to operate on an AU basis. These changes are intended just as editorial expression of this existing design intent.

AHG Recommendation (editorial BF/expression of existing intent): Adopt.

1. In clause D.3.2, modify the constraint related to bp_alt_cpb_params_present_flag as follows: (JVET-S0157 item 2):

When <the associated AU is not an IRAP or GDR AU> “the associated picture is neither a CRA picture nor an IDR picture”, the value of bp_alt_cpb_params_present_flag shall be equal to 0.

The idea of this is to treat GDR picture with ph_recovery_poc_cnt equal to 0 consistently the same as an IRAP picture. This seemed to be just a forgotten, essentially editorial, issue.

AHG Recommendation (editorial BF/expression of existing intent): Adopt as proposed.

1. In clause D.4.2, in the constraint related to requiring pt_cpb_alt_timing_info_present_flag to be equal to 0, add that the RASL pictures in the constraint are RASL pictures that do not have mixed NAL unit types as follows? (JVET-S0157 item 4).

When <all pictures in the associated AU are RASL pictures with pps_mixed_nalu_types_in_pic_flag equal to 0> “the associated picture is a RASL picture”, the value of pt_cpb_alt_timing_info_present_flag shall be equal to 0.

AHG Recommendation (editorial BF/expression of existing intent): Adopt as proposed.

1. In clause D.5.2, in the semantics of pt_display_elemental_periods_minus1, change fixed_pic_rate_within_cvs_flag[ TemporalId ] (3 instances) to fixed_pic_rate_within_cvs_flag[ Htid ]? (JVET-S0153 item 5)

AHG Recommendation (editorial BF/expression of existing intent): Adopt as proposed.

1. Modify constraints as follows: (JVET-S0175 aspect 3)?

When “fixed_pic_rate_within_cvs_flag[ TemporalId ] is equal to 0 or sps_field_seq_flag is equal to 1, the value of” <any of the following applies> pt_display_elemental_periods_minus1 shall be equal to 0.<:

– sps_field_seq_flag is equal to 1 for the output layers in the OLS.

– <sps_field_seq_flag is equal to 0 for all output layers of the bitstream and there is not frame-field information SEI message present or display_fields_from_frame_flag is equal to 0 if a frame-field SEI message is associated with the AU and fixed_pic_rate_within_cvs_flag[ TemporalId ] is equal to 0.>

It was noted that the frame-field SEI message is in the SEI message specification, and it contains the display_fields_from_frame_flag. It was said that the expressed constraint on pt_display_elemental_periods_minus1 is wrong in both specs.

AHG Recommendation (editorial bug fix/expression of existing intent): Replace the constraint above with “When sps_field_seq_flag is equal to 1, the value of pt_display_elemental_periods_minus1 shall be equal to 0” and to say this (or equivalent) in both specs.

1. Change the condition for fixed picture rate across CVSs, by removing the max_dec_pic_buffering_minus1 (asserted not to be needed) and adding BP SEI message syntax related to concatenation_flag. (JVET-S0175 aspect 1, 2)

AHG Recommendation (bug fix/expression of existing intent): Adopt first aspect. (This also affects HEVC in one place.)

The second aspect would impose an extra burden that is not currently imposed when the general flag is set equal to 0. It was also commented that it may not consider picture decoding time appropriately.

No action was recommended on the second aspect.

Discussion in the HLS AHG pre-meeting stopped here with the remaining items open.

Discussion resumed here in the JVET meeting at 1935 on 23 June (chaired by GJS).

1. Make either of the following changes (JVET-S0175 aspects 4 and 5)?
   1. Add a gating flag for pt_display_elemental_periods_minus1, so that its presence can be controlled and change the derivation of elementalOutputPeriod as follows and change D.9.6 accordingly?

– If a PT SEI message is present for picture n <and pt_display_elemental_periods_present_flag equal to 1>, elementalOutputPeriods is equal to the value of pt_display_elemental_periods_minus1 + 1.

–< Otherwise, if external means are provided to set the value of elementalOutputPeriods, elementalOutputPeriods is set equal to the value provided via external means.

– Otherwise , if frame-field information SEI messages are present for at least one of the output pictures in the AU of picture n, the value of elementalOutputPeriods is set to the lowest value of display_elemental_periods_minus1 + 1 among all present frame-field information SEI messages.>

– Otherwise, elementalOutputPeriods is equal to 1.

• 1. An alternative option to a), with the key difference being that herein the main VVC specification does not depend on the frame-field information SEI message that is specified in the SEI specification.

The current text says that when the PT SEI message is not present, elementalOutputPeriods is always set to 1.

It was commented that presence of PT SEI messages could either be in the bitstream or equivalently by external means but the manner of their presence doesn’t need to be discussed everywhere that the syntax elements are discussed – e.g., since we don’t do that for SPS or PPS – that if they are present they are simply considered present, however they got there. See AVC in the first section of Annex C.

It was asked why the text has a discussion of PT SEI messages not being present at all. AVC considers that some information might not be present “in the bitstream”, but doesn’t seem to consider the idea of them not being present at all.

This was further discussed at 1400 on 27 June (chaired by JRO).

The text changes expressed in item 6 of JVET-S0175-v4 for D.3.2 and D.3.4 were reviewed and refined in group discussion in regard to the concept of whether PT and BP SEI messages may or may not be in the bitstream but shall always be available, either within the bitstream or provided by external means.

It was remarked that some systems use timestamps and buffering concepts that differ substantially from the way the HRD is specified. It was suggested that HRD conformance may not really apply in some contexts, or that bitstreams are sometimes handled in a way that naturally lies well within the HRD constraints. And also that non-conforming bitstreams do occur and often need to be handled by decoders in real-world applications.

Others remarked that the definitions of levels are fundamentally dependent on the capability to handle a specific buffering capacity and frame rate, which are defined through the HRD, and asked how to define levels if not through HRD conformance.

It was noted that the HRD is really a matter of encoder conformance rather than decoder conformance.

It was commented that the HRD is hypothetical (for encoder constraints) rather than a requirement of how decoders need to operate.

A participant remarked that although there may be some differences between the “spec domain” and the way products operate in the real world, the constraints established by the HRD are to provide an assurance of bitstream conformance characteristics.

It was noted that some systems have additional buffering requirements and operate differently from the HRD buffer model.

It was remarked that the external means by which buffering flow information is provided may be quite different from the defined SEI messages.

It was commented that we should not open the door to allowing non-conforming bitstreams to be produced.

Existing wording was noted in the current spec draft, saying that an external means does not need to use the same syntax as the SEI messages specified in the standard.

It was suggested to state, roughly, that “When a bitstream is to be tested for HRD conformance, the PT and BP SEI messages or equivalent information needs to be available, either in the bitstream or by external means (such as timestamps from ISOBMFF).” A suggested wording was:

“HRD conformance testing requires information that can be provided by PT and BP SEI messages. PT and BP SEI messages may not be present within the bitstream, so if HRD-related conformance is to be checked, equivalent information shall be made available and could be provided by external means outside of this Specification (such as system timing information).”

It was remarked that this should apply in concept to everything related to HRD in the spec where applicable (e.g., DUI).

This was further reviewed in the context of the full spec at 2215 on 28 June.

It was suggested that the change should be to replace the paragraph after NOTE 4 of C.1 with the following:

“When HRD conformance testing of a bitstream is performed, all DCI NAL units, when available, all VPSs, SPSs, PPSs, and APSs referred to in the VCL NAL units, and appropriate BP, PT, and DUI SEI messages shall be conveyed to the HRD, in a timely manner, either in the bitstream (by non-VCL NAL units), or by other means not specified in this Specification (such as system configuration and timing information).”

Decision (clarification): Adopt the paragraph rephrasing above.

The only change in this is to add a prefixing phrase at the beginning and a parenthetical comment at the end.

For Item 5, we have pt_display_elemental_periods_minus1 in the PT SEI message (with OLS scope), constrained to match the display_elemental_periods_minus1 in the frame-field SEI message (which is layer-specific).

A problem was identified in the definition of DisplayElementalPeriods in the proposal. This was drafted as an input to the SEI spec, not an output of it. The main spec can just refer to pt_display_elemental_periods_minus1 + 1. The SEI message spec does not need that variable.

It was commented that there may be a problem with 4-bit length of the display_elemental_periods_minus1 syntax element in the frame-field information SEI message, if it is intended to be used for temporal sublayering timing.

The HRD is OLS specific. It was commented that we need only one elementalOutputPeriods per OLS.

It was commented that perhaps the frame-field information SEI message should not be used in the example use case.

The PT SEI message is for HRD purposes.

The FFI SEI message is for display purposes.

Skipping the syntax element in the PT SEI message was discussed as a possibility.

This was further discussed at 1620 on 27 June (chaired by GJS).

It was commented that we could just disallow use of the FFI SEI message in the multi-layer/multi-sublayer context. However, it was commented that the combination could be useful, and the constraint resolves the semantics consistency issue.

Decision (bug fix/sensibility constraint): Establish the modified constraint and use u(8) instead of u(4) for (ffi_)display_elemental_periods_minus1 and pt_display_elemental_periods_minus1, but not otherwise modify the syntax of the PT SEI message.

1. Enable decoder operation without HRD timing SEI messages when fixed picture rate is signalled? (JVET-S0175 aspect 6). This is related to JVET-S0109 in section 3.1.2.

This relates to the question of HRD operation without any BP and PT SEI messages present (or at least present in the bitstream) if there is a fixed elemental period. See notes elsewhere on the basic issue of that concept.

This was further discussed at 1630 on 27 June (chaired by GJS).

The proposal would provide fixed picture rate information but skip information in the HRD parameters syntax, such as bit rate, CPB size, tick divisor, and low-delay HRD flag.

It was asked where, if the skipped information is not in the HRD parameters syntax, this information would be obtained.

It was commented that, editorially, it seems odd to say that HRD parameters are being sent but most of the HRD parameters are not being sent. It was suggested to do some editorial work to rename the syntax elements and syntax structures to avoid this potential confusion.

It was also suggested to constrain the use so that the syntax would only use the abbreviated form if there is some CLVS that has fixed_pic_rate_flag equal to 1.

Offline work was requested for this editorial refinement.

It is proposed that when (full) HRD parameters are not present in the bitstream but fixed_pic_rate_within_cvs_flag[ i ] is (present and) equal to 1, the pt_display_elemental_periods_minus1 would be required to be equal to 0.

It was proposed to also add a constraint that pictures with ph_pic_output_flag equal to 0 would be disallowed under the envisioned usage, but it was agreed that this was unnecessary and undesirable (e.g., sending a non-output IRAP picture at the beginning of a bitstream or having low frame-rate operation in a level with sufficient CPB decoding time capability for a higher decoding frame rate). So it was agreed that this constraint should not be imposed.

It was commented that JVET-S0109 does not need to be considered additionally if action is taken to adopt this aspect.

The editorial expression of the above was reviewed at 2140 on 28 June (chaired by GJS).

If vps_timing_hrd_params_present_flag is 0, general_nal_hrd_params_present_flag and general_vcl_hrd_params_present_flag are not assigned a value.

When those are not present, the fixed_pic_rate_within_cvs_flag[ i ] is also not present.

Decision (cleanup): Adopt option 2 for aspect 6 in -v6. (A small editorial change to remove “general_” from a syntax element name is expected in -v7.)

1. Conditionally signal bp_sublayer_initial_cpb_removal_delay_present_flag, only when bp_max_sublayers_minus1 is greater than 0 and infer it to 0 otherwise? (JVET-S0181 proposal 1, JVET JVET-S0157 item 3)

It was commented that a similar conditioning was proposed in JVET-S0064 and was recommended for adoption. See also item 21 for rationale.

Decision (cleanup): Adopt the conditional signalling.

1. Move the signalling of bp_max_sublayers_minus1 to be before the signalling of bp_cpb_removal_delay_deltas_present_flag and conditionally signal bp_cpb_removal_delay_deltas_present_flag and bp_num_cpb_removal_delay_deltas_minus1 and bp_cpb_removal_delay_delta_val[ i ] syntax elements, only when bp_max_sublayers_minus1 is greater than 0 and infer bp_cpb_removal_delay_deltas_present_flag equal to 0 otherwise? (JVET-S0181 proposal 2)?

It was commented that generally we should not be signalling things about temporal sublayers if there are no temporal sublayers.

Decision (cleanup): Adopt the conditional signalling.

1. Move the syntax element pt_cpb_removal_delay_minus1[ bp_max_sublayers_minus1 ]  to locate it near the other CPB removal delay syntax elements, in particular other pt_cpb_removal_delay_minus1[ i ] syntax elements (and pt_cpb_removal_delay_delta_idx[ i ] syntax elements) for i in the range of TemporalId to bp_max_sub_layers_minus1 − 1, inclusive? (JVET-S0185 proposal 1)

Decision (cleanup): Put pt_cpb_removal_delay_minus1[ bp_max_sublayers_minus1 ] first, followed by similar information for sub-layers, followed by pt_dpb_output_delay, followed by the rest of the syntax in the current order.

1. Move the signalling of syntax element bp_alt_cpb_params_present_flag to locate it near the syntax element bp_use_alt_cpb_params_flag where it is used? (JVET-S0185 proposal 2)

Decision (cleanup): Adopt this aspect.

1. Modify the output and removal of picture from DPB as follows? (JVET-S0198)

C.5.2.2 Output and removal of pictures from the DPB

…

– Otherwise (the current AU is not a CVSS AU or the current AU is a CVSS AU that is not AU 0 but the current picture is not the first picture of the current AU), all picture storage buffers containing a picture which are marked as "not needed for output" and "unused for reference" are emptied (without output). For each picture storage buffer that is emptied, the DPB fullness is decremented by one. “When one or more of the following conditions are true, t”<T>he "bumping" process specified in clause C.5.2.4 is invoked repeatedly “while further decrementing the DPB fullness by one for each additional picture storage buffer that is emptied,” until <the number of pictures in the DPB is less than max_dec_pic_buffering_minus1[ Htid ] + 1>. “none of the following conditions are true:

• The number of pictures in the DPB that are marked as "needed for output" is greater than max_num_reorder_pics[ Htid ].
• max_latency_increase_plus1[ Htid ] is not equal to 0 and there is at least one picture in the DPB that is marked as "needed for output" for which the associated variable PicLatencyCount is greater than or equal to MaxLatencyPictures[ Htid ].
• The number of pictures in the DPB is greater than or equal to max_dec_pic_buffering_minus1[ Htid ] + 1.”

…

The intent of this is only editorial. The intent is clear.

It is certainly not intended for the fullness to be decremented twice when one picture is removed.

The other parts of this are just trying to remove conditions that are asserted to be redundant.

Decision (bug fix/expression of existing intent): Adopt.

1. In clause 8.1.1, add the derivation of the variables DuHrdPreferredFlag and DecodingUnitHrdFlag, similarly as in HEVC. (JVET-S0248 aspect 2 late)

Decision (bug fix/expression of existing intent): Adopt.

1. In clauses C.2.2 and C.2.3, change the local variable decodingUnitParamsFlag to be a global variable DecodingUnitParamsFlag, to address the issue that decodingUnitParamsFlag was used in clause C.2.2 without being defied/initialized. (JVET-S0248 aspect 3 late)

Editorial action item: Apply the usual variable name convention.

1. In clause C.3.2, change the condition on when to remove decoded pictures neither needed for referecne nor needed for output such that it is applied to all pictures except for the first picture of AU 0. (JVET-S0248 aspect 4 late)

Decision (bug fix/expression of existing intent): Adopt.

1. In clause C.5.2.2, change "Otherwise (the current AU is not a CVSS AU or the current AU is a CVSS AU that is not AU 0 but the current picture is not the first picture of the current AU)" to either of the following, as the condition in the parentheses is assertedly incorrect.
   1. "Otherwise (the current AU is not a CVSS AU, <the current AU is CVSS AU 0,> or the current AU is a CVSS AU that is not AU 0 but the current picture is not the first picture of the current AU)" (JVET-S0223)
   2. "Otherwise" (JVET-S0248 aspect 5 late)

Decision (editorial bug fix): Adopt approach b.

1. In clause C.5.2.3, remove "AU n containing " from the first sentence, i.e., "The processes specified in this clause happen instantaneously when the last DU of AU n containing the current picture is removed from the CPB." (JVET-S0223, JVET-S0248 aspect 6 late)

Decision (bug fix/expression of existing intent): Adopt.

1. In clause D.3.2, add the following constraint to disallow the combination of alternative timing for the CRA/DRAP case and the decoding unit HRD mode: When bp_alt_cpb_params_present_flag is equal to 1, the value of bp_du_hrd_params_present_flag shall be equal to 0. (JVET-S0248 aspect 7 late)

Decision (bug fix/expression of existing intent): Adopt.

Discussion in JVET stopped here at 2320 on 23 June.

Discussion in JVET resumed here at 1650 on 24 June.

Related to sub-bitstream extraction

General SEI semantics and constraints:

1. Fix an asserted missing integration of an agreement (from JVET-Q0394) that specifies that non-scalable-nested HRD-related SEI messages apply to the OLSs that include the same set of layers as the entire bitstream (instead of only to the 0th OLS)? (JVET-S0178 aspect 1)
   1. Consequently, add a constraint such that when there is no OLS that includes the set of layers that is the same as the entire bitstream, there shall be no non-scalable-nested SEI message with payloadType equal to 0 (BP), 1 (PT), 130 (DUI), or 203 (SLI)? (JVET-S0178 aspect 1.a)
   2. And remove the constraint requiring the value of nuh_layer_id for an SEI NAL unit containing non-scalable-nested HRD-related SEI messages to be equal to vps_layer_id[ 0 ], such that the value of nuh_layer_id for such SEI NAL units is unconstrained, same as for the nuh_layer_id for DCI, VPS, AUD, and EOS NAL units? (JVET-S0178 aspect 1.b)

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspects 1, 1.a, 1.b).

1. Remove the payloadType value 203 (SLI, subpicture level information) from the VclAssociatedSeiList? (JVET-S0178-v3 aspect 2)

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspect 2).

1. Add the clarification (that was recently added to the HEVC specification as an corrigendum item) on the value ranges of tone_map_id, frame_packing_arrangement_id, knee_function_id, and colour_remap_id, including potential collisions of the interpretation for values of these syntax elements? (JVET-S0178-v3 aspect 3)

This is purely editorial.

Editor action item: The editor is asked to attend to this issue (JVET-S0178-v3 aspect 3).

1. Add a constraint such that when general_same_pic_timing_in_all_ols_flag is equal to 1, there shall be no SEI NAL units that contain a scalable-nested SEI message with payloadType equal to 1 (PT) ? (JVET-S0178-v3 aspect 4)

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspect 4).

1. Modify an existing constraint, to add the SLI SEI message, such that when an SEI NAL unit contains a non-scalable-nested SEI message with payloadType equal to 0 (BP), 1 (PT), 130 (DUI), or 203 (SLI), the SEI NAL unit shall not contain any other SEI message with payloadType not equal to 0, 1, 130, or 203? (JVET-S0178-v3 aspect 5)

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspect 5).

1. Modify an existing constraint, to add the SLI SEI message, that when an SEI NAL unit contains a scalable-nested SEI message with payloadType equal to 0 (BP), 1 (PT), 130 (DUI), or 203 (SLI), the SEI NAL unit shall not contain any other SEI message with payloadType not equal to 0, 1, 130, 203, or 133 (scalable nesting) ? (JVET-S0178-v3 aspect 6)

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspect 6).

1. Add a constraint such that when an SEI NAL unit contains an SEI message with payloadType equal to 3 (filler payload), the SEI NAL unit shall not contain any other SEI message with payloadType not equal to 3? (JVET-S0178-v3 aspect 7)

Item 9).c) above is a similar issue for PT SEI messages in individual SEI NAL units when general_same_pic_timing_in_all_ols_flag is equal to 1.

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspect 7) and JVET-S0102 aspect 3.

1. Add a constraint such that when an SLI SEI message and a BP SEI message that apply to a particular OLS are present within an AU, the SLI SEI messages shall precede the BP SEI message in decoding order? (JVET-S0178-v3 aspect 8)

Decision (editorial bug fix/expression of existing intent): Adopt (JVET-S0178-v3 aspect 8).

Discussion in the main JVET meeting stopped here at 1720 on 24 June.

Discussion in the main JVET meeting resumed here at 2030 on 25 June (chaired by GJS).

Scalable nesting SEI message:

1. Modify semantics of sn_num_subpics_minus1 (based on following options)? (Adding blue text in angle brackets and removing red text in quotes)
   1. Clarify the association of scalable-nested SEI messages for subpictures to either layers or OLS as follows? (JVET-S0173 item 2)

sn_num_subpics_minus1 plus 1 specifies the number of subpictures to which the scalable-nested SEI messages apply. <When sn_ols_flag is equal to 0,> the value of sn_num_subpics_minus1 shall be less than or equal to the value of sps_num_subpics_minus1 in the SPS referred to by the pictures <of the indicated layer. Otherwise, when sn_ols_flag is equal to 1, the value of sn_num_subpics_minus1 shall be less than or equal to the value of sps_num_subpics_minus1 in the SPS referred to by the pictures of the highest layer in the OLS with sps_num_subpics_minus1 greater than 0.>

• 1. Specify the semantics of sn_num_subpics_minus1 and sn_subpic_idx[ i ] in a way such that the syntax elements are about the subpictures of the layers with multiple subpictures per picture? (JVET-S0177 aspect 7)

<Among the layers in the OLSs (when sn_ols_flag is equal to 1) to which the scalable-nested SEI messages apply, or among the layers (when sn_ols_flag is equal to 0) to which the scalable-nested SEI messages apply, those for which the referenced SPSs have sps_num_subpics_minus1 greater than 0 are referred to as the multiSubpicLayers.>

sn_num_subpics_minus1 plus 1 specifies the number of subpictures <in each picture in the multiSubpicLayers> “to which the scalable-nested SEI messages apply”. The value of sn_num_subpics_minus1 shall be less than or equal to the value of sps_num_subpics_minus1 in the SPS<s> referred to by the pictures in the <multiSubpicLayers> “CLVS”.

This was further discussed at 1315 on 27 June after offline work to harmonize the text expressions in “a” and “b”. The modified text was drafted as follows:

“The layers that are referrred to as the multiSubpicLayers are defined as follows:

– If sn_ols_flag is equal to 1, the layers that are referrred to as the multiSubpicLayers are the layers in the OLSs to which the scalable-nested SEI messages apply for which the referenced SPSs have sps_num_subpics_minus1 greater than 0.

– Otherwise (sn_ols_flag is equal to 0), the layers that are referrred to as the multiSubpicLayers are the layers to which the scalable-nested SEI messages apply for which the referenced SPSs have sps_num_subpics_minus1 greater than 0.

It is a requirement of bitstream conformance that the value of sps_num_subpics_minus1 shall be the same in all SPSs referenced by pictures in the multiSubpicLayers.

sn_num_subpics_minus1 plus 1 specifies the number of subpictures in each picture in the multiSubpicLayers. The value of sn_num_subpics_minus1 shall be less than or equal to the value of sps_num_subpics_minus1 in the SPSs referred to by the pictures in the multiSubpicLayers.”

Decision (clarification): Adopt as per above (or editorial equivalent).

1. Change sn_subpic_id[ i ] to sn_subpic_idx[ i ] and remove sn_subpic_id_len_minus1 or change the semantics of sn_subpic_id_len_minus1 as follows?
   1. Per JVET-S0177 aspect 1

sn_subpic_id<x>[ i ] “indicates” <specifies the subpicture index of> the i-th subpicture “ID associated with the scalable-nested SEI messages” <in each picture in the multiSubpicLayers. The value of sn_subpic_idx[ i ] shall be less than or equal to the value of sps_num_subpics_minus1 in the SPSs referred to by the pictures in the multiSubpicLayers.> “The length of the sn_subpic_id[ i ] syntax element is sn_subpic_id_len_minus1 + 1 bits.” <The scalable-nested SEI messages also apply to the single subpicure in each picture in the layers that are not in the multiSubpicLayers but are among the layers in the OLSs (when sn_ols_flag is equal to 1) to which the scalable-nested SEI messages apply or among the layers (when sn_ols_flag is equal to 0) to which the scalable-nested SEI messages apply.>

“sn_subpic_id_len_minus1 plus 1 specifies the number of bits used to represent the syntax element sn_subpic_id[ i ]. The value of sn_subpic_id_len_minus1 shall be in the range of 0 to 15, inclusive.

It is a requirement of bitstream conformance that the value of sn_subpic_id_len_minus1 shall be the same for all scalable nesting SEI messages that are present in a CLVS.”

• 1. Or change semantics of sn_subpic_id_len_minus1 by changing CLVS to CVS (JVET-S0173 item 2):

sn_subpic_id_len_minus1 plus 1 specifies the number of bits used to represent the syntax element sn_subpic_id[ i ]. The value of sn_subpic_id_len_minus1 shall be in the range of 0 to 15, inclusive.

It is a requirement of bitstream conformance that the value of sn_subpic_id_len_minus1 shall be the same for all scalable nesting SEI messages that are present in a C“L”VS.

It was commented that the “id” is a position-independent identifier and that using that can prevent some need for rewriting.

Decision (editorial bug fix): Adopt approach “b”.

1. Disallow containing of filler payload SEI messages in a scalable nesting SEI message? (JVET-S0177 aspect 2)

It was commented that if we do not do this, the extraction process would need to be made more complicated in order to deal with nested filler data.

Decision (bug fix of extraction process): Adopt.

1. Constrain that, when a scalable nesting SEI message contains one or more subpicture level information (SLI) SEI messages, the value of sn_ols_flag shall be equal to 1, and the value of sn_subpic_flag shall be equal to 0? (JVET-S0177 aspect 3)

This is said to be because the SLI SEI message is HRD related, so it needs to have similar constraints as for BP/PT/DUI SEI messages in regard to the sn_ols_flag.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Modify an existing constraint, to include the SLI message, such that when a scalable nesting SEI message contains a BP, PT, DUI, or SLI SEI message, the scalable nesting SEI message shall not contain any other SEI message with payloadType not equal to 0 (BP), 1 (PT), 130 (DUI), or 203 (SLI)? (JVET-S0177 aspect 4)

This is similar in spirit to item 42.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Modify an existing constraint, to include recently added SEI messages, such that when a scalable nesting SEI message contains an SEI message that has payloadType not equal to 132 (decoded picture hash), the SEI NAL unit containing the scalable nesting SEI message shall have nal_unit_type equal to PREFIX_SEI_NUT? (JVET-S0177 aspect 5)

Typically we have planned for SEI messages to be prefixes except decoded picture hashes, filler payload and scalable nesting.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Add a constraint such that when a scalable nesting SEI message contains an SEI message that has payloadType equal to 132 (decoded picture hash), the SEI NAL unit containing the scalable nesting SEI message shall have nal_unit_type equal to SUFFIX_SEI_NUT? (JVET-S0177 aspect 6)

This is similar in spirit to item 44.

Decision (editorial bug fix/expression of existing intent): Adopt.

General sub-bitstream extraction:

1. Handling of AUD in sub-bitstream extraction process (JVET-S0102 item 5, JVET-S0225)
   1. Restrict aud_irap_or_gdr_au_flag to a one-way constraint in single-layer bitstreams as follows? (JVET-S0102 item 5).

aud_irap_or_gdr_au_flag equal to 1 specifies that the AU containing the AU delimiter is an IRAP or GDR AU. aud_irap_or_gdr_au_flag equal to 0 specifies that the AU containing the AU delimiter is not an IRAP or GDR AU <when NumLayersInOls[ TargetOlsIdx ] is greater than 1>.

• 1. And/or modify sub-bitstream extraction process using either one of the following two options: (JVET-S0225)
     1. Option 1: Add AUD or rewrite aud_irap_or_gdr_au_flag of the existing AUD when the associated extracted AU is an IRAP AU or GDR AU as follows:

<When an AU is an IRAP AU or GDR AU and no associated AUD, add an AUD NAL unit of type AUD_NUT before the first VCL NAL unit of the AU with aud_irap_or_gdr_au_flag equal to 1. Otherwise for any existing AUD, set aud_irap_or_gdr_au_flag equal to 1 for  an IRAP AU or GDR AU.>

• • 1. Option 2: Add AUD or rewrite aud_irap_or_gdr_au_flag of the existing AUD when the associated AU is an IRAP AU or GDR AU and the target OLS has multi-layers; and either remove the existing AUD or rewrite aud_irap_or_gdr_au_flag of the existing AUD when the associated AU is an IRAP AU or GDR AU and the target OLS contains only single layer as follows:

– <When the targte OLS contains more than one layer,

• For each AU that is an IRAP AU or GDR AU with no associated AUD, add a NAL unit of type AUD_NUT before the first VCL NAL unit of the AU with aud_irap_or_gdr_au_flag equal to 1.
• Otherwise for any existing AUD, set aud_irap_or_gdr_au_flag equal to 1 for an IRAP AU or GDR AU.

– Otherwise (the target OLS contains only one layer), remove the associated AUD from outBitstream for each AU, or for any existing AUD, set aud_irap_or_gdr_au_flag equal to 1 for an IRAP AU or GDR AU.>

Item 9).b) is related. See the notes for that item. No further action was determined to be needed for either aspect of this item.

1. In the general sub-bitstream extraction process, specify the conditions under which an output sub-bitstream is required to be a conforming bitstream such that the value of tIdTarget is specified to be in the range of 0 to vps_ptl_max_tid[ vps_ols_ptl_idx[ targetOlsIdx ] ], inclusive (instead of 0 to 6 inclusive)? (JVET-S0158 aspect 1)

This seemed purely editorial and obvious upon study.

Editor action item: The editor is suggested to include this change.

1. Specify the general sub-bitstream extraction process such that it would remove, from the output bitstream outBitstream, SEI NAL units that contain a scalable nesting SEI message with sn_ols_flag equal to 0 while the applicable layers as indicted in the scalable nesting SEI message does not include any layer in the target OLS? (JVET-S0158 aspect 2)

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Make the following changes to the 4^th step in the general sub-bitstream extraction process? (JVET-S0158 aspect 3)
   1. Remove the redundant condition "nuh_layer_id is equal to LayerIdInOls[ targetOlsIdx ][ j ] for a value of j in the range of 0 to NumLayersInOls[ targetOlsIdx ] − 1 inclusive". (This is asserted to be editorial.)?

Editor action item: The editor is suggested to remove the redundant expression.

• 1. When removing from the output bitstream the VCL NAL units, instead of removing the associated SEI NAL units containing SEI messages other than the BP, PT, DUI and SLI SEI messages, remove all SEI NAL units that contain SEI messages that become not applicable to any picture or subpicture remaining in the final output bitstream? (Since this is not easy to do, another option is not to remove SEI NAL units in this step.)

It was commented that the TemporalId should be sufficient to identify the relevant pictures, so SEI NAL units associated with an AU with a particular TemporalId should only apply to VCL NAL units with TemporalId greater than or equal to that value of TemporalId.

This was further discussed at 1330 on 27 June (chaired by GJS).

Offline study was conducted to determine whether we have clear specification of extraction of SEI messages/NAL units associated with an AU. Aside from not mentioning SLI, the text was said to be adequate in this regard, since the extraction process removes all NAL units with TemporalId greater than the target TemporalId.

Decision (editorial bug fix): Classify SLI SEI messages along with BP, PT, and DUI in this step of the extraction process.

1. Make the following changes to the last step in the general sub-bitstream extraction process? (JVET-S0158 aspect 4)
   1. Change the condition as follows?

When the list LayerIdInOls[ targetOlsIdx ] does not include all values of nuh_layer_id in all <VCL> NAL units in the bitstream <inBitstream>.

• 1. When at least one layer is removed by the extraction process, also remove all SEI NAL units that contain a non-scalable-nested SLI SEI message (same as for BP, PT, and DUI SEI messsages)?
  2. Insert SEI NAL units to directly contain those SEI messages that were scalable-nested HRD-related SEI messages that apply to the output bitstream, and remove their original container SEI NAL units from the output bitstream. When the target OLS includes only one layer, apply the same for scalable-nested non-HRD-related SEI messages?

Decision (editorial bug fix/expression of existing intent): Adopt (all three subitems).

Subpicture level information (SLI) SEI message:

1. Clarify the scope of Subpicture Level Information (SLI) SEI to be CVS instead of CLVS? (JVET-S0173 item 1)

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Include all layers of the OLS in MinCr related constraint for subpictures by making the following changes? (JVET-S0173 item 3):

• The sum of the NumBytesInNalUnit variables for AU 0 corresponding to the j-th subpicture shall be less than or equal to FormatCapabilityFactor * ( Max(“SubpicSizeY[ j ]”<AuSizeMaxInSamplesY[ 0 ]>, fR * MaxLumaSr <) >* OlsRefLevelFraction[ i ][ j ] ÷ 256 “)” + MaxLumaSr * ( AuCpbRemovalTime[ 0 ] − AuNominalRemovalTime[ 0 ] ) * OlsRefLevelFraction[ i ][ j ] ) ÷ ( 256 * MinCr ), where MaxLumaSr and FormatCapabilityFactor are the values specified in Table A.2 and Table A.3, respectively, that apply to AU 0, at level sli_ref_level_idc[ i ], and MinCr and AuSizeMaxInSamplesY[ 0 ] are derived as indicated in A.4.2.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Modify the inference rule for sli_ref_level_fraction_minus1[ i ][ j ]? (JVET-S0173 item 5):

When not present, the value of sli_ref_level_fraction_minus1[ i ][ j ] is inferred to be equal to <Max( 256,> Ceil( 256 * SubpicSizeY[ j ] ÷ PicSizeInSamplesY * MaxLumaPs( general_level_idc ) ÷ MaxLumaPs( sli_ref_level_idc[ i ] ) <)>− 1.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Resolve editorial notes related to subpictures as follows? (JVET-S0173 item 6):
   1. Refer to minCR and fR derivation in A.4.2.
   2. Replace PicSizeInSamplesY with PicSizeMaxInSamplesY and clarify that the picture size of the highest layer with subpictures in the OLS is taken.

Decision (editorial bug fix/expression of existing intent): Adopt (and also start the minCR and fR variable names with capital letters since they are referred to in multiple clauses).

1. Replace sps_num_subpics_minus1 with sli_num_subpics_minus1 in semantics of sli_num_ref_levels_minus1? (JVET-S0173 item 7)

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Modify alignment constraint of intendent subpictures by adding sps_subpic_treated_as_pic_flag[ i ] syntax element to the clause as follows? (JVET-S0173 item 4):

– All the SPSs referred to by the layers in targetLayerSet shall have the same value of sps_num_subpics_minus1 and <sps_log2_ctu_size_minus5 and> shall have the same values of sps_subpic_ctu_top_left_x[ j ], sps_subpic_ctu_top_left_y[ j ], sps_subpic_width_minus1[ j ], sps_subpic_height_minus1[ j ], and sps_subpic_treated_as_pic_flag[ j ], respectively, for each value of j in the range of 0 to sps_num_subpics_minus1, inclusive.

It was noted that these syntax elements are signalled in units of CTUs, so it doesn’t achieve the subpicture layout alignment constraint if they have different CTU sizes.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Add sli_max_sublayers_minus1, sli_sublayer_info_present_flag, and a loop for sublayers for the signalled fractions and reference level indicators, to support levels for sublayers? (JVET-S0176 item 1)

It was noted that scalable nesting has support for sublayers.

It was asked whether sublayers are supported in HEVC temporal MCTS SEI messages, and the syntax of that SEI messages does not directly support that, but that functionality is supported by scalable nesting.

Decision (cleanup/consistency): Adopt.

1. Allow SLI SEI messages to be available either in the bitstream or provided through an external means not specified in this Specification? (JVET-S0176 item 2)

This is another consistency correction to treat SLI SEI messages similarly as BP/PT/DUI SEI messages.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Change the persistency scope for SLI SEI from one CVS to one or more CVSs, to be consistent with VPSs and SPSs wherein level information are or may be signalled? (JVET-S0176 item 3)

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Change the definition of subpicture sequence to cover the case when there is one or more layers with single subpicture per picture? (JVET-S0176 item 4)

This is to properly cover the case where there are multiple subpictures in an enhancement layer with other reference layers that are not split into multiple subpictures.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Require that, when an SLI SEI message is present for a CVS, the value of sps_num_subpics_minus1 shall be the same for all the SPSs referenced by the pictures in the layers with multiple subpictures per picture. (JVET-S0176 item 5)?

This is similar in spirit to the previous item.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Specify the semantics of sli_num_subpics_minus1 in a way such that the syntax element is about the subpictures of the layers with multiple subpictures per picture? (JVET-S0176 item 6)

This is similar in spirit to the previous item.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Make variable derivations subpicture sequence specific as follows: Add an array index, which identifies a subpicture sequence, to both the variables SubpicLevelIdc and SubpicLevelIdx, as well as to the arrays SubpicCpbSizeVcl, SubpicCpbSizeNal, SubpicBitRateVcl, and SubpicBitRateNal in the last set of constraints in the semantics of the SLI SEI message? (JVET-S0176 item 7)

This is said to be just something that was previously overlooked.

Decision (editorial bug fix/expression of existing intent): Adopt.

Subpicture sub-bitstream extraction:

1. Modify the specification of subpicture sequences, which when extracted, are required to be a conforming bitstream? (JVET-S0154 aspect 1)?

Across all layers, for the extraction of subpictures, it should select the subpictures in the same position for the layers that are split into multiple subpictures, and it should select the entire pictures for the layers that are not split into subpictures.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Remove VCL NAL units and their associated filler data NAL units and associated filler payload SEI messages, etc., regardless of whether there is an external means for replacing of the parameter sets? (JVET-S0154 aspect 2)

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Remove SEI NAL units containing scalable-nested SEI messages that do not apply to the output bitstream from the output bitstream? (JVET-S0154 aspect 3, also proposed in item 10.a)

A similar action was taken for the general extraction process in item 48; this is for the subpicture extraction process.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Specify the subpicture index for identifying the subpicture sequence as the subpicture index of the to-be-extracted subpictures in the layers with multiple subpictures per picture, not the layers with only one subpicture per picture? (JVET-S0154 aspect 4)

This is similar to items 60–62 in spirit.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Rewrite both general_level_idc and sublayer_level_idc[ k ] for k in the range of 0 to tIdTarget − 1, inclusive, in the referenced VPSs, when present, and in the referenced SPSs, when NumLayersInOls[ targetOLsIdx ] is equal to 1? (JVET-S0154 aspect 5)

This was further discussed at 1340 on 27 June (chaired by GJS).

This is related to the agreement to add sublayer level information into the SLI SEI message.

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Rewrite cpb_size_value_minus1[ k ][ j ] and bit_rate_value_minus1[ k ][ j ] for all values of k in the range of 0 to tIdTarget, inclusive, in the referenced VPSs, when present, and in the referenced SPSs, when NumLayersInOls[ targetOLsIdx ] is equal to 1? (JVET-S0154 aspect 6)

This was further discussed at 1350 on 27 June (chaired by GJS).

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Specify the calculation and rewriting of the scaling window offset parameters as part of the subpicture sub-bitstream extraction process?
   1. As per JVET-S0154 aspect 7?
   2. As per JVET-S0189?

The two proposed approaches have the same intention, intended to be the same except editorial differences.

Decision (editorial bug fix/expression of existing intent): Adopt option “a”.

1. Rewrite cbr_flag[ tIdTarget ][ j ] in the referenced VPSs, when present, and in the referenced SPSs, when NumLayersInOls[ targetOLsIdx ] is equal to 1? (JVET-S0154 aspect 8)

This was further discussed at 1355 on 27 June (chaired by GJS).

Decision (editorial bug fix/expression of existing intent): Adopt.

1. Insert SEI NAL units to directly contain those SEI messages that were scalable-nested HRD-related SEI messages that apply to the output bitstream, and remove their original container SEI NAL units from the output bitstream. When the target OLS includes only one layer, apply the same for scalable-nested non-HRD-related SEI messages? (JVET-S0154 aspect 9)

A similar action was taken for the general extraction process in item 50; this is for the subpicture extraction process.

Item 10.b is a subset of this proposal.

Decision (editorial bug fix/expression of existing intent): Adopt.

Discussion of the above items in the main JVET meeting stopped at 1620 on 25 June.