JVET-R0249 AHG9: Proposed structural text changes to HLS in the VVC specification [M. Pettersson, R. Sjöberg, M. Damghanian, Z. Zhang, J. Enhorn (Ericsson)]
This contribution was discussed on 22 April at 1740 (chaired by GJS & YKW).
The first two items are purely editorial, and were already well agreed and had been incorporated into side activity during. The third aspect is almost, but not quite, editorial. The purpose of the contribution is purely to improve readability.
This contribution proposes the following changes to the VVC specification (which do not really change the structure of the standard, but are proposed for consistency and readability):
- Replace ‘slice_’ prefix for slice header syntax elements by ‘sh_’, except for slice_address and slice_type which are proposed to be renamed to sh_slice_address and sh_slice_type, respectively. (editorial)
- Rename syntax elements in VPS, SPS, PPS, PH, SH to ensure that the names of all syntax elements in these places start with ‘vps_’, ‘sps_’, ‘pps_’, ‘ph_’ and ‘sh_’, respectively. (editorial)
- Change disable flags to enable flags throughout the VVC specification, i.e. change the following syntax elements to enable flags (normative, but only because the bits for these flags in the bitstream are inverted):
- pps_deblocking_filter_disabled_flag
- ph_deblocking_filter_disabled_flag
- slice_deblocking_filter_disabled_flag
- ph_disable_bdof_flag
- ph_disable_dmvr_flag
- ph_disable_prof_flag
- scaling_matrix_for_lfnst_disabled_flag (related to other contributions)
- slice_ts_residual_coding_disabled_flag (related to JVET-R0483, JVET-R0485, and JVET-R0486)
Proposed changes 1 and 2 are claimed to make it possible to see the scope and placement of syntax elements from their names alone. Proposed change 3 is claimed to align all enable/disable flags so that a ‘1’ always means enable and ‘0’ always means disable, thereby improving readability.
Specification text on top of JVET-Q2001-vE for replacing the disable flags with enable flags is provided with the contribution.
It was commented that in most cases (e.g. for the deblocking flags and for the mode flags that are only present when a feature is enabled at a higher level) the flag names are to imply enabling by default and that there are various related contributions under consideration that might be complicated by these changes). It was thus agreed to take no action on this aspect.
Editorial action item: The editor is asked to consider renaming ph_disabled_xxx_flag to ph_xxx_disabled_flag.