International organisation for standardisation organisation internationale de normalisation
Yüklə 8,2 Mb.
|
HLS for hybrid scalability (3)Discussed 01-09 p.m. (GJS). 14.1.97.1.1.1.1.1.304JCTVC-P0140 MV-HEVC/SHVC HLS: On non-HEVC base layer [M. M. Hannuksela (Nokia)] The contribution discusses two aligned designs for enabling non-HEVC-coded base layer:
As the changes are asserted to be substantial and may require verification by both expert review and software implementation, the contribution was submitted for discussion rather than as a proposal. The contribution follows up on JCTVC-O0166/JCT3V-F0060. It was asked why we would need RPS information. It was remarked that this is to provide a synchronized output for the base layer pictures as if they were HEVC pictures, and that it may not be needed if a substantial amount of the operation is controlled by external means. It was asked whether the decoded pictures provided by external means really need to be arriving in the same decoding order as if they were HEVC pictures within the same bitstream. It was remarked that if decoded pictures are provided by external means, a conformance test bitstream would need to include copies of these decoded pictures (or a way to generate/obtain them). It was remarked that perhaps we don't need to have anything from the base layer except the availability of the decoded pictures and awareness of their representation format (e.g., width, height, bit depth and colour format, and perhaps field parity information). No immediate action was requested. 14.1.97.1.1.1.1.1.305JCTVC-P0184 Support of AVC base layer in SHVC [Y.-K. Wang, J. Chen, Y. Chen, Hendry (Qualcomm)] This document propose a way for the support of AVC base layer in SHVC that is asserted to be the simplest in terms of the changes needed to the SHVC specification. The two key aspects of the proposed design are: 1) no encapsulation, meaning decoded base layer pictures are provided by external means; and 2) output of base layer pictures, including the synchronization with output of enhancement layer pictures, is controlled by external means. Proposed spec text changes for the design are provided in the attachment of this document, with changes marked in relative to the latest SHVC spec text in JCTVC-O1008v3. See also notes above on P0140. Also related to P0203. 14.1.97.1.1.1.1.1.306JCTVC-P0203 Hybrid codec scalability profile in SHVC [J. Samuelsson, J. Enhorn, R. Sjöberg (Ericsson)] See also section 3.5.2. This contribution proposes to include the hybrid codec scalability profile as described in JCTVC-O1012 into the SHVC draft with the following modifications:
The contribution asserts that only one encapsulation format is needed and that it is important that the AVC NAL units are unmodified (i.e. no additional header is put in front of the AVC NAL unit header). See also notes above on P0140. The contributor indicates that if the AVC is wrapped within HEVC headers, that wrapping would need to be removed in order to feed the base layer to the legacy decoder, and it was asserted that this could especially be a problem if the bitstream is encrypted. Further study in an AHG along with P0184 was encouraged (and consider the alternative encapsulation approach in O1012 – the other approach provides temporal ID and layer ID, enabling bitstream extraction by a middle box without paying attention to the contents within the NALUs – if the encapsulation was the other way around, prefix NALUs may be needed for the base layer and some way to convey VPS and parsing the embedded HEVC NUHs would be needed for the enhancement layer). 14.1.97.1.1.1.1.1.307JCTVC-P0183 AHG9: On AVC independent non-base layer indicator [Y. He, Y. Ye (InterDigital)] This contribution proposes to expand the current avc_base_layer_flag to allow independent non-base layers to be coded in AVC. The proposal is to put a flag in the VPS extension to indicate, for each non-base layer, whether the layer is AVC or HEVC. It was remarked that although the concept seems to make sense and provide a potentially useful capability if we assume that such a within-the-bitstream muxing is otherwise supported within HEVC syntax. However, it seems premature to conclude that this will be the case. This should be further considered when that higher-level question is answered. The concept was reportedly developed based on just examining potential syntax expression capability rather than a specific use case – further understanding of such use cases would be needed.
|