JVET-R0343 AHG9: A summary of proposals on parameter sets cleanups [Hendry (LGE)]

This contribution is intended to provide a summary of the proposals on parameter sets cleanups submitted to this JVET meeting by the 3 April 2020 submission deadline.

It was suggested that this summary is used for the reviewing of these proposals, such that the discussions can be in a more structured and efficient manner.

Summary of proposals on SPS cleanups:

This section was discussed in AHG Session 1.1 Monday 6 April at 1440 UTC (chaired by GJS & YKW).

1. New condition for signalling of syntax elements
   1. When sps_ptl_dpb_hrd_params_present_flag is equal to 1, inter_layer_ref_pics_present_flag is not present and inferred to be equal to 0 (JVET-R0156 proposal 2)

Is it possible for such a SPS to be referred to by a layer that has reference layers?

It was commented that JVET-R0205 is related.

This item was moved to 6.1.10.

• 1. Condition the presence of sps_sublayer_dpb_params_flag on the value of sps_ptl_dpb_hrd_params_present_flag, in addition to sps_max_sublayer_minus1 (JVET-R0156 proposal 3) (JVET-R0170) (JVET-R0222 proposal 2) AHG Recommendation: Adopt.
  2. Condition that sps_independent_subpics_flag is present only when there are at least two subpictures. (JVET-R0156 proposal 4)

MC wrap-around was discussed.

It was commented that item 1 of JVET-R0284 and item 1 of JVET-R0071 are identical or similar to this.

This item was moved to 6.2.1.1.

Discussed stopped for AHG Session 1.2 here on Monday 6 April at 1500 UTC (chaired by GJS & YKW), and resumed at the start of AHG Session 1.4 Monday 6 April at 2330 UTC (chaired by GJS & YKW).

• 1. Condition the presence of subpic_info_present_flag by res_change_in_clvs_allowed_flag (JVET-R0266 proposal 3). These cannot be used together currently, although there had been proposals to allow them to be used together. No support was expressed by non-proponents for this.
  2. Add new flag in SPS to indicate that intra-only (i.e., whether inter-coding is allowed). Use this flag to condition the presence of inter-coding related tools. (JVET-R0283 proposal 1) (JVET-R0335). The proponent said this could skip about 40 syntax elements (more than 5 times more than in HEVC), and drew an analogy to monochrome. It was commented that low-resolution still-picture coding might be the strongest argument for this. Another participant suggested that skipping the irrelevant syntax would ease encoder design. After seeing the syntax table, several participants expressed support for this, while others said this adds extra syntax that is not necessary for video and the bit savings seems too small to make a special provision for it. It was asked whether the syntax structure logic should be different if we do this. Data on this (with the encoder minimizing the necessary amount) was requested. An initial estimate was 23 bits per SPS.

It was later confirmed (Wednesday 8 April) that 23 bits in the SPS (and 4 in the PPS and 1 in the PH) could be saved in such a case. The quantity of data is not compelling; the argument is more a matter of the analogy to monochrome. It was commented whether the analogy is really apt, since there was already the chroma array type information in the SPS to use for that.

There is an all-intra constraint flag in the PTL structure, which currently controls only the slice level.

After discussion, there was not a consensus for this change.

See also JVET-R0332 on syntax grouping.

• 1. In a similar train of thought as point above, do the same for PPS (JVET-R0283 proposal 2). This was discussed further on Friday 24 April at 0550 (chaired by GJS), and the proponent considered the proposal unlikely to be acted upon and thus did not indicate to further discuss it.
  2. Add a constraint that sps_ptl_dpb_hrd_params_present_flag shall be equal to 1 when there is at least one OLS which has only one layer or VPS is not present? (JVET-R0275)?

It was said that this relates to some other proposals on SPS cleanup (JVET-R0191, JVET-R0156 aspect 1, JVET-R0108 proposal 3).

If VPS is not present, PTL would be absent if the flag is 0. JVET-R0156 aspect 1 and JVET-R0108 proposal 3 propose that if the sps_video_parameter_set_id is equal to 0, not to signal the flag and infer it to be equal to 1. It was commented that this could affect byte alignment of the PTL information. JVET-R0275 propose to constrain the flag for this. The motivation for not sending it was said to be to prevent the possibility of not having the PTL information at all. AHG Recommendation: To avoid changing byte alignment, the constraint approach was agreed in this case.

When the VPS is present and there is some OLS that has only one layer and the layer ID is the current layer’s ID, this case is proposed to be constrained in JVET-R0191 and JVET-R0275. AHG Recommendation: The constraint was also agreed to apply in this case.

V. Seregin agreed to provide text in an update of JVET-R0275 and to provide the software.

1. Infer the value of sps_ccalf_enabled_flag to be equal to 0 when not present (i.e., when sps_alf_enabled_flag is equal to 1 and ChromaArrayType is equal to 0) (JVET-R0105). This seemed to be what was already the intended behaviour. AHG Recommendation (expression of existing intent): Adopt.
2. Constraint the semantics of subpic_info_present_flag such that when it is equal to 1, at least either pic_width_max_in_luma_samples or the value of pic_height_max_in_luma_samples shall be larger than the CTB size CtbSizeY. (JVET-R0156 part 2 of item 4). After study, this might affect extraction, so no action was taken on this.
3. Change sps_reserved_zero_4bits to sps_reserved_one_4bits to prevent the SPS start code emulation. (JVET-R0266 proposal 1). The case would be with an SPS ID of zero and monochrome and PTL info not present (only in a dependent layer). It was commented that our other reserved bits are zero and this seems somewhat ad hoc. There was no non-proponent interest in this, so no action was taken on it.

Discussion stopped for AHG session 1.4 here on Tuesday 7 April at 0115 UTC, and resumed for AHG Session 1.11 on Wednesday 8 April at 2100 UTC (chaired by GJS & YKW).

1. Consolidate two syntax elements, sps_poc_msb_flag and poc_msb_len_minus1 into a single syntax element poc_msb_len (JVET-R0266 proposal 2)

It was commented that this seems almost editorial. Another participant commented that having a flag could be desired editorially for having a clear way to disable the feature, and that there may have been a similar prior situation.

It was questioned whether the current semantics are really correct, i.e., whether the signalled MSBs are intended to be all of the MSBs of the POC or only some of them. Others confirmed that all “missing” MSBs are inferred to be 0, and that this is intentional. AHG Recommendation (ed.): The editor is asked to review whether this aspect of the semantics of poc_msb_val is sufficiently clear.

It was noted that with the proposal, the value 0 would be overloaded to have a different and special meaning. It would mean more than the name of the syntax element would imply. (The proposed semantics would need some clarification in this regard.) Since this could be confusing, no action was recommended on the proposal.

1. gdr_enabled_flag value constrained by no_gdr_constraint_flag (JVET-R0266 proposal 5, JVET-R0178)

There was discussion of the possibility of having some NUTs that are GDR and some that are not. This is already disallowed.

AHG Recommendation (editorial expression of existing intent): Specify that no_gdr_constraint_flag equal to 1 specifies that gdr_enabled_flag shall be equal to zero. no_gdr_constraint_flag equal to 0 does not impose such a constraint.

1. Grouping syntax elements in SPS based on slice type (i.e. intra or inter) (JVET-R0332)

It was discussed whether we would want to do such a rearrangement regardless of whether we want to gate presence on whether inter pictures are present or not (see JVET-R0283 proposal 1 and JVET-R0335). Some participants said that some minor rearrangements might be OK, but wholesale restructuring would be undesirable. It was commented that software implementation would be desirable to make sure there are no overlooked dependencies. The proponent said they did implement it and could provide software for checking. It was asked for such software to be provided in a revision of the contribution. Support for this was expressed, as a more logical structuring of the syntax – the prior syntax may have been rather randomly ordered. This was further discussed on Friday 24 April at 0510 (chaired by GJS). Software had been provided in a revision of JVET-R0332 and a new contribution JVET-R0408 had been uploaded with a crosscheck. Decision (cleanup): Adopt syntax grouping of JVET-R0332.

Summary of proposals on PPS cleanups:

1. Require the value of pps_conformance_window_flag to be equal to 0 when the picture width and height are the maximum picture width and height, and infer the values of the PPS conformance window syntax elements to be the same as those signalled in the SPS if the picture width and height are the maximum picture width and height and to be equal to 0 otherwise. (JVET-R0068 proposal 6) (JVET-R0262 proposal 1 and 2)

It was commented that there is already a constraint that in this case the window at the PPS level needs to be the same as the one at the SPS level; the question is only whether to require the flag to be 0 and to infer from the SPS level in this case. In the current draft, in this case, the window parameters are required to be sent in every PPS when non-zero and are required to always be the same.

There is also already a requirement that if the picture size in two PPSs is the same, their cropping windows must be the same. (These constraints are intended to ease RPR operation.)

One participant commented that having an inference rule that is conditional on a particular special case seems potentially confusing to implementers. Others said it only makes sense that if the parameters are required to have a particular value, that is the value that should be inferred and there shouldn’t be syntax capable of violating that constraint.

It was noted that this inference from the SPS prevent complete self-contained interpretation of the PPS content, although we already have some such dependencies.

AHG Recommendation: Adopt.

1. Add a new syntax element pps_res_change_allowed_flag in the PPS and use it to condition the presence of the conformance window and scaling window syntax elements (JVET-R0262 proposal 3). This is related to the previous item above. With the action taken on the previous item, this reduces to adding a flag that would skip two flags in the PPS. No action was taken on this, due to the action taken on the previous item.
2. Add a constraint for the cropping window offsets and scaling window offsets that at least one of the offsets is different than its default value when the flag that controls their presence is equal to 1 (JVET-R0115). It was commented that this extra constraint doesn’t really seem necessary, so no action was recommended on this.
3. Change the signalling for wraparound offset. Signal “picture width minus wraparound offset” instead of “wraparound offset” (JVET-R0162 proposal 1). In the 360° ERP case, this corresponds to sending the padding width rather than the pre-padded picture width. For the 360° CTC, this would save about 16 bits per PPS (sending a value of 16 instead of 4448). The current syntax seems obviously inefficient, so this was supported without any expressed misgivings. AHG Recommendation: Adopt.
4. Change the signalling of the PPS ID from ue(v) to u(6), as proposed in JVET-R0266 proposal 4. It was noted that this is the only parameter set ID that uses ue(v) coding for its ID. AHG Recommendation: Adopt.

Summary of proposals on APS cleanups:

1. Handling chroma related syntax elements in APS when ChromaArrayType is equal to 0
   1. To avoid having APS semantics depend on the SPS, move the constraints from the APS semantics to the PH and SH semantics of the relevant APS ID, in, such that the value of scaling_list_chroma_present_flag shall be equal to 0 when the value of ChromaArrayType is equal to 0.

It is also proposed to similarly move the constraint for alf_chroma_filter_signal_flag, alf_cc_cb_filter_signal_flag, alf_cc_cr_filter_signal_flag, and add a similar constraint for lmcs_delta_abs_crs (JVET-R0074).

This is asserted to remove APS-to-SPS dependency in the semantics.

This is related to parts of contribution JVET-R0232.

It was asked whether there is really a problem with constraining APS content based on the SPS content. It was commented that this is probably not desirable, although only an editorial matter.

The contribution proposes a constraint move for the scaling list and ALF (purely editorial), and adding a constraint for LMCS.

LMCS contains only two variables (three bits) relevant to chroma. ALF contains only three flags relevant to chroma.

There was a comment about this approach forcing crs_offset not to be 0.

It was commented that the constraints are not really necessary, as the presence of the chroma data in the APS is not necessarily harmful (although we have been trying to avoid sending irrelevant chroma syntax).

• 1. Add flags (i.e., alf_chroma_present_flag and lmcs_chroma_present_flag) to the APS and constraint them to be equal to 0 when ChromaArrayType is equal to 0 (JVET-R0177 proposal 1)

The LMCS part of this is related to part of contribution JVET-R0232.

• 1. Repurpose the chroma scaling list presence flag in the APS (i.e., aps_chroma_present_flag) and use this flag to condition the presence of chroma presence flags in the APS. (JVET-R0177 proposal 2 and JVET-R0301)

The difference between “b” and “c” is basically only editorial.

This was discussed further on Friday 24 April at 0555 (chaired by GJS).

A similar contribution had been submitted in JVET-R0132, which had not been included in the JVET-R0343 summary due to the timing of its submission.

JVET-R0433 was submitted after offline study. It repurposes a chroma presence flag that had been in the scaling list data and uses it for all three APS types.

Decision (cleanup): Adopt JVET-R0433.

Discussion stopped here for AHG Session 1.12 Thursday 9 April at approximately 0115 UTC.

Discussion began here for JVET Track A Monday 20 April at approximately 1300 UTC (chaired by GJS).

1. Change the constraint on APS NAL units to have the same content within a picture unit to apply within a subpicture (JVET-R0149 proposal 1). This topic had been covered in a prior discussion.
2. Disallow interleaving of APS NAL units of different subpictures (JVET-R0149 proposal 2). This topic had been covered in a prior discussion.
3. Constrain suffix APS NAL units to be located after the last VCL NAL unit of the PU (JVET-R0201). See the notes in section 6.1.2.4.
4. Allow prefix and suffix APS NAL units with particular APS identifier and type to have different content (JVET-R0201). See the notes in section 6.1.2.4.
5. Constrain prefix APS NAL unit to be located before the first VCL NAL unit of the PU(JVET-R0201). See the notes in section 6.1.2.4.
6. Add a mode in PH to allow APS to be signalled within PH, like the mode of signalling PH in SH (JVET-R0273). See the notes in section 6.1.2.4.

Later-added SPS cleanups:

1. Change the value range of sps_max_sublayers_minus1 from 0..vps_max_sublayers_minus1 to 0..(sps_video_parameter_set_id ? vps_max_sublayers_minus1 : 6). (JVET-R0125). See the notes in section .6.3.1.2.
2. Add a constraint on the value of sps_max_sublayers_minus1 such that when sps_video_parameter_set_id is greater than 0 and vps_all_layers_same_num_sublayers_flag is equal to 1, sps_max_sublayers_minus1 shall be equal to vps_max_sublayers_minus1. (JVET-R0125).

After discussion, it appears that this would affect the removal of sublayers from a bitstream and the SPS is rewritten to reflect the actual content of what remains. In this case the SPS sps_max_sublayers_minus1 would become less than vps_max_sublayers_minus1. It was agreed that we don’t want to reflect the ability to do this.

Discussion stopped here for JVET Track A Monday 20 April at approximately 1328 UTC.

SPS cleanups (10)