High-level syntax and semantics cleanup (26) Video parameter set (14)
14.1.97.1.1.1.1.1.308JCTVC-P0045 MV-HEVC/SHVC HLS: On layer set definition [T. Ikai, T. Tsukuba, T. Yamamoto (Sharp)]
Discussed 01-10 p.m. (GJS).
This contribution presents a restriction and a flag on layer sets which are asserted to be beneficial to avert troubles caused by lack of clarity. The restriction (proposal 1) is that a layer shall be included in at least one layer set, where profile/level information is defined, to avoid the non-defined bitstream which is unknown for how to decode or how much decoding capability is needed. The flag (proposal 2), named complete_layer_set_flag, is to indicate whether the defined layer set can be extracted into sub-bitstream.
The contribution is asserted to remove an asserted lack of clarity on whether layers should be included in layer sets or layer set can be safely extracted into conforming sub-bitstream.
It was noted that this is related to P0137.
For auxiliary pictures, we don't currently have a concept of what they conform to. We do not send profile/level information in SPSs with nuh_layer_id > 0.
We currently send profile/level for output layer sets.
We current allow auxiliary pictures or non-auxiliary EL pictures to be present that are not in any output layer set.
It was suggested to consider the case where an aux picture layer is in an output layer set and the decoding requirements do not require that layer to be decoded.
A second question in the contribution is whether a layer set can be specified that does not include the base layer. This was discussed in regard to such a layer set that may or may not depend on the base layer.
It was remarked that P0182 is also related.
Regarding the proposal to have a "complete layer set" flag, it was remarked that the flag may not be necessary since dependency information is provided and it can be easily checked whether any layer in the dependency tree is missing.
It was remarked that the bitstream extraction process is already specified in version 1, including for non-base layers, and it requires the base layer to be present.
It was remarked that there should be a way for a version 1 decoder to identify whether the bitstream conforms to version 1 decoding capability, which basically means profile/tier/level values for nuh_layer_id equal to 0 should be seen by a version 1 decoder.
This topic requires further study along with other contributions relating to decoding capabilities specification.
14.1.97.1.1.1.1.1.309JCTVC-P0046 MV-HEVC/SHVC HLS: Additional layer set [T. Ikai, T. Tsukuba, T. Yamamoto (Sharp)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.310JCTVC-P0048 MV-HEVC/SHVC HLS: Syntax clean-up of profile, tier and level information [T. Tsukuba, T. Yamamoto, T. Ikai (Sharp)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.311JCTVC-P0052 MV-HEVC/SHVC HLS: VPS extension clean-up [Y. Cho, B. Choi, M. W. Park, J. Y. Lee, H.-C. Wey, C. Kim (Samsung)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.312JCTVC-P0070 MV-HEVC/SHVC HLS: On video parameter set extension [B. Choi, Y. Cho, M.W. Park, J.Y. Lee, H. Wey, C. Kim (Samsung)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.313JCTVC-P0076 MV-HEVC/SHVC HLS: On VPS extension and VPS VUI [H. Lee, J. W. Kang, J. Lee, J. S. Choi (ETRI)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.314JCTVC-P0110 MV-HEVC/SHVC HLS: On default output layer sets [K. Ugur, M. M. Hannuksela (Nokia)]
Initially reviewed in BoG P0290. See BoG report P0290 and related notes.
Discussed in Joint 3V+VC session 01-12 (GJS & JRO).
It is asserted that the default output layer set mechanism in the current SHVC/MV-HEVC design is not suitable for various use cases, such as ROI and view scalability. In addition, for common configurations of SHVC and MV-HEVC, it is asserted that the default output layer set mechanism does not bring any coding efficiency benefit. For these reasons, it is proposed to remove the default output layer set functionality from the SHVC/MV-HEVC design.
Alternatives:
-
Remove default_one_output_layer_idc indication, or
-
Define a three-state value for default_output_layer_idc (e.g., 0 = default is all layers of a particular layer set, 1 = default is top non-auxiliary layer of a particular layer set, 2 = no default is indicated, 3 = reserved)
Decision: Three-state approach (text in P0295, decoder shall allow 3 to be present and shall treat 3 the same as the value 2).
14.1.97.1.1.1.1.1.315JCTVC-P0295 MV-HEVC/SHVC HLS: On default target output layer set [Y.-K. Wang (Qualcomm)] [late]
This contribution further discussed along with P0110 Sun 3 p.m. (see notes above under P0110, which reflect that an approach of P0295 was adopted).
14.1.97.1.1.1.1.1.316JCTVC-P0125 MV-HEVC/SHVC HLS: On VPS extension offset and VPS VUI offset [A.K. Ramasubramonian, Hendry, Y.-K. Wang (Qualcomm)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.317JCTVC-P0132 MV-HEVC/SHVC HLS: On alt_output_layer_flag [A. K. Ramasubramonian, Y.-K. Wang, Hendry, Y. Chen (Qualcomm)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.318JCTVC-P0136 MV-HEVC/SHVC HLS: Improvements of Video and Picture Parameter Sets [Truong Cong Thang (UoA), Jung Won Kang, Jinho Lee, Hahyun Lee, Jin Soo Choi (ETRI)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.319JCTVC-P0157 MV-HEVC/SHVC HLS: On Indications for Inter-layer Prediction [S. Deshpande (Sharp)]
Discussed 01-10 p.m. (GJS).
This document proposes to assign a special (currently disallowed) value to max_tid_il_ref_pics_plus1[ i ][ j ] as an indication that sub-layer non-reference pictures belonging to highest temporal sub-layer in a layer are not used for inter-layer prediction. (It was noted that this would provide a higher-level indication otherwise only available at a lower level using discardable_flag.) All the indications that can be currently signalled using max_tid_il_ref_pics_plus1[ i ][ j ] are maintained. The new indication is proposed to be added to those existing indications by assigning a special value. Specification text changes related to the proposed indication were provided. It was asserted that the proposed indication enables indicating a low complexity decoding property for multi-loop decoding.
In the initial discussions, the idea seemed reasonable if it does not introduce any problems. One participant had some concerns and requested time for offline discussion for clarification. This was later reported on 01-14 to have been resolved satisfactorily.
In additional discussion on 01-14, it was remarked that using a special value of the syntax element might not be the cleanest approach to signal this if we want to signal it, and that the impact on some expressions in the text seemed somewhat intrusive. It was remarked that it would be easy to simplify the editorial impact on the text without technical alteration. Some participants indicated that using a flag might be a cleaner approach.
There was also some questioning of the envisioned use case, which was asserted to be a pre-encoded base layer that was encoded without using temporal IDs.
Considering the questioning of the use case and the ability to later enable a signalling of the same thing in some future-defined SEI message or VUI extension, no action was taken on this. Further study was encouraged.
During discussion on 01-10, it was mentioned that our CTC for HM does not use non-zero temporal IDs, but for the RA case, it could be using them (without changing its referencing structure). It was suggested to change the CTC config files to use non-zero temporal IDs. It was also suggested to provide example config files that follow a more well-nested temporal structuring (at some minor loss in coding efficiency), since such usage has its own benefits and it may be helpful to compare the coding efficiency difference. It was remarked that config files in L0322 may provide such configurations (for an older HM). A. K. Ramasubramonian volunteered to assist in preparing such config files. Decision (SW): Make this change to the RA config file and provide the addition nesting config file in the RS package (assuming it causes no unforseen difficulties).
14.1.97.1.1.1.1.1.320JCTVC-P0078 MV-HEVC/SHVC HLS: On output_layer_flag [H. Lee, J. W. Kang, J. Lee, J. S. Choi (ETRI)]
See BoG report P0290 and related notes.
14.1.97.1.1.1.1.1.321JCTVC-P0262 Support for out-of-band signalling in VPS to enable future layer additions [A. Luthra, S. Narasimhan (Arris)]
Discussed 01-16 (GJS).
The current VPS structure in HEVC would require a change to the VPS (in the underlying video stream) to signal layer specific parameters when a new scalable layer is added to pre-compressed SHVC content.
Even though removal of layers is supported currently (with an SEI message), addition of new layers without a change to the VPS in the underlying video elementary stream is currently not possible. One of the examples of the use case is where lower layer corresponds to 60 fps and higher layer corresponds to 120 fps. Some earlier contributions (JCTVC-N0048, JCTVC-K0206 and ISO/IEC WG 11/N 12956) discussed adding new layers at re-distribution points without a change to the parameters (VPS, SPS, PPS) in the lower layers and advocated for this capability to be included in SHVC specification.
In order to enable this, the contribution proposed to add a flag (VPS external means flag) to the VPS syntax to indicate that parameters (such as profile, level, layer sets) for additional layers are transmitted via external means rather than in the VPS. MPEG-2 transport streams provide the capability to signal these parameters through a ‘descriptor’ associated with the new layer-specific video stream carried in a separate PID. The proposal uses one of the ‘reserved’ bits in the VPS for this flag. Based on the setting of VPS external means flag the layer specific parameters are either signalled in-band in the VPS or are sent through external means. With this addition, it is asserted that the VPS does not have to be altered at re-multiplexing or re-distribution points when a new layer is added.
Suggestion from a participant: Write the standard to say that, when external means is available to convey the VPS or to identify the selected VPS, additional VPSs may be present in the bitstream that apply only to a subset of the NAL units in the bitstream.
It was also suggested to similarly specify SPS behaviour (e.g., in regard to HRD parameters).
Further study was encouraged to determine whether the suggestion would suffice.
14.1.97.1.1.1.1.1.322JCTVC-P0300 MV-HEVC/SHVC HLS: On alt_output_layer_flag [M. M. Hannuksela (Nokia)] [late]
See BoG report P0290 and related notes.
Dostları ilə paylaş: |