Of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11

6.5HL syntax in SHVC (6 - NYF)

6.5.1Generic HLS issues (1)

JCTVC-O0251 SHVC HLS: On adaptive resolution change based on single_layer_for_non_irap_flag [V. Seregin, Y. Chen, Y.-K. Wang, A. K. Ramasubramonian (Qualcomm)]

Reviewed Tues. 29th (GJS).

See also notes for related contribution O0199.

In SHVC, resolution change can be enabled by setting single_layer_for_non_irap_flag in the VPS equal to 1. This proposal discusses some issues related setting single_layer_for_non_irap_flag equal to 1, including some DPB related issues and other issues. It was proposed that, when a resolution switching occurs, all reference pictures in the DPB be as marked as "unused for reference" and other decoded pictures with PicOutputFlag equal to 0 be removed from the DPB. For other issues discussed, some bitstream constraints are proposed.

The first proposed action was in section 2 of the contribution.

It was noted that this interacts with the agreement to use a layer-specific DPB.

It was remarked that the RPS behaviour indicated could be achieved by, e.g., a VPS VUI indicator flag, or could be indicated on a picture basis, e.g., by an SEI message. The SEI message could indicate that no lower layer pictures will be used anymore, or only the last one in decoding order will be use, or only the one in the RPS with the highest POC value, etc. Further study was encouraged, e.g., to draft such an SEI message.

It was remarked that the output order relationship between BL and EL for ARC should be studied and perhaps constrained.

Regarding section 3 in the contribution, it was remarked that the persistence might be difficult to specify, e.g., in relation to temporal sub-layering, in a way that would not be undesirably constraining, so no action was planned.

Regarding section 4 in the contribution, it was remarked that the alternative output layer flag would take care of this issue, so no action was planned.

The reaction regarding section 5 in the contribution was similar to that for section 3.

Regarding section 6, if there is a problem, it is not solved by the suggested text, and after discussion it seemed that no action was needed.

Regarding section 7, the extracted bitstream would still be decodable and potentially useful, so no action was determined to be needed.