Of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11
HL syntax in SHVC and 3D extensions (35)
Yüklə 0,95 Mb.
|
- Bu səhifədəki naviqasiya:
- 6.4.2POC alignment and derivation (5)
- 6.4.3HLS for hybrid scalability (3)
- 6.4.4High-level syntax and semantics cleanups (25)
- 6.4.4.2Sequence and picture parameter sets (2)
- 6.4.4.4Miscellaneous HLS topics (6)
6.4HL syntax in SHVC and 3D extensions (35)6.4.1Generic HLS issues (2)JCTVC-P0043 Version 1/MV-HEVC/SHVC HLS: Access unit boundary detection [M. M. Hannuksela (Nokia)] Discussed 01-10 am (GJS). The contribution discusses problems related to access unit boundary detection and contains the following three proposals (one with two alternatives):
Planned to be chaired by GJS. It is asserted that the access unit (AU) boundary detection has the following problems currently:
It is specified that the first VCL NAL unit of a coded picture after the last VCL NAL unit of the previous coded picture starts a new access unit. The intent in SHVC/MV-HEVC is to allow several coded pictures, each having different values of nuh_layer_id, in the same access unit.
It is allowed to have access units where the base layer picture is not present for example to enable a base layer @ 30 Hz and a spatial or quality enhancement layer @ 60 Hz. If there is no NAL unit that starts a new access unit (e.g. an access unit delimiter) present and also if there is no base layer picture present in the access unit (AU), it is asserted that HEVC v1 decoders may consider the following coded enhancement layer pictures as a part of the previous access unit, while SHVC/MV-HEVC decoders are intended to consider them as part of a new access unit. Consequently, it is asserted that the HRD parameters for AU-based CPB operation may become ambiguous and may be interpreted differently by HEVC v1 decoders and SHVC/MV-HEVC decoders. A similar issue occurs in hybrid codec scalability, when the AVC base layer pictures are either not present in the HEVC bitstream or are encapsulated in NAL units that are not interpreted to start a new access unit.
However, in the discussion, it was remarked that non-nested HRD parameters and AU boundary detection for version 1 decoders must consider EL-only AUs to not be separate AUs. It was remarked that the version 1 text may not be fully clear in that regard, and that this should be clarified.
Discussed 01-10 am (GJS). It is asserted that in JCT-3V common test conditions (without multiple slices per picture), the overhead of enhancement-layer (EL) slice headers is on average about 3.4% when compared to the EL bit rate only for both MV-HEVC and 3D-HEVC and about 1.0 and 1.2% (for MV-HEVC and 3D-HEVC, respectively) when compared to the total bit rate. The motivation of the contribution is to reduce the EL slice header overhead by a header parameter set (HPS) design, which enables the inheritance of slice header syntax elements from the HPS. HPS was proposed earlier in JCTVC-J0109 for HEVC version 1. The HPS design in this contribution is asserted to be similar to that of JCTVC-J0109 with the addition that repetitive slice header patterns e.g. for an entire IRAP picture period can be included in the HPS and addressed either by slice_pic_order_cnt_lsb values or an indicated index hps_entry_idx in the slice header. In version 2 of the contribution, illustrative figures were added on the use cases how the proposed HPS can be used. The HPS, of course, would only be used by the ELs. The HPSs could be shared across multiple pictures as well as across multiple slices per picture. The encoder would be able to choose whether to use an HPS or send an ordinary SH. The proposed HPS scheme would send not just one set of SH data but a list of them, and the applicable index into the list would be derived either by sending an index in the SH or by using POC LSBs. No cross-verification was provided. It seemed too late in the design process for the current projects for considering a change of this magnitude.
Discussed 01-10 pm (GJS). This contribution presents an updated design for the signalling and derivation of picture order count in SHVC and MV-HEVC. It is proposed that POC reset be indicated by a two-bit indication, to fully utilize the fact that there would never be POC LSB reset only. Additionally, a POC LSB is signalled in order to provide better error resilience to the POC derivation process and for support of missing-collocated-picture scenarios. Finally, the MSB value of the picture order count is also signalled for CRA pictures. The main changes compared to the solution in JCTVC-O0213v4 are as follows:
The text changes are included in the attachment of the contribution, relative to JCT3V-F1004v6. In v2 of JCTVC-P0041/JCT3V-G0031, the document template/header was corrected, without change marks. The spec text changes and other parts remain unchanged as in v1. In v3 of JCTVC-P0041/JCT3V-G0031, an example is added in section 3, with change marks. The spec text changes and other parts remain unchanged as in v2. In v4 of JCTVC-P0041/JCT3V-G0031, the following changes were made, and the text changes are included in the attachment, with changes marks in relative to the attachment in v3 of JCTVC-P0041/JCT3V-G0031 (and the old change marks are also kept, with different user names):
For identification of a picture in feedback messages, it is suggested that, when operating in the context of an SHVC or MV-HEVC profile, in addition to the POC value, the POC-resetting period ID of the latest decoded picture is also signalled in a feedback message. The encoder can then uniquely identify the previously encoded picture. Upon reception of a feedback message with a POC value and a POC-resetting period ID, when latest encoded picture is in a different POC-resetting period, it would track back to the signalled POC-resetting period and add back the POC delta value decremented for each new POC-resetting period. No spec text change for this aspect is provided. In v5 of JCTVC-P0041/JCT3V-G0031, some discussions on the approach proposed in v6 of JCTVC-O0275/JCT3V-F0092 are included in section 4. In v6 of JCTVC-P0041/JCT3V-G0031, some editorial simplifications to the spec text changes were included.
It was commented that it may be desirable to add a NOTE to describe the concept of what poc_reset_idc = = 3 is for. It was remarked that we should require each non-IRAP picture that has discardable_flag equal to 1 to have NUT value indicating that it is a sub-layer non-reference picture. This was agreed.
Discussed 01-10 pm (GJS). The contribution includes the following two parts, where part 1 is proposed if part 2 is not adopted.
The contribution is a follow-up of contribution JCTVC-O0275v7/JCT3V-F0092v7. It was remarked that allowing a POC anchor picture to be from a direct or indirect reference layer may implicitly require cross-layer slice_pic_order_cnt_lsb alignment, which could be a problem in the case where there are two IDR pictures that are consecutive in the base layer and one of them is lost. It was remarked that having LSB alignment with the proposed modification would be beneficial for saving bits in slice headers by not needing to indicate MSB cycles as often. It was suggested to consider having a VPS-level flag that indicates whether the alignment applies or not and have the operation depend on that flag. It was suggest that if we do this, it should allowed for the encoder to also send the POC MSB cycle in EL non-IRAP pictures. Decision: Adopt Proposal 1 (in spirit – with the suggested modifications – revisit for text). JCTVC-P0067 MV-HEVC/SHEVC HLS: Comments on POC alignment [M. Li, P. Wu, G. Shang, Y. Xie (ZTE)] Discussed 01-10 am (GJS). Proposed is a design for signalling and deriving picture order count (POC) in SHVC and MV-HEVC for POC alignment. It is proposed that enhancement layer (EL) slice headers, when nuh_layer_id is greater than 0 and a POC alignment flag is set to 1, the value of the most significant bit (MSB) for POC calculation be explicitly signalled, and the value of least significant bit (LSB) be conveyed by slice_pic_order_cnt_lsb. The proposed design only introduces additional bits to slice headers of enhancement layer (EL) pictures without changes to the base layer, and makes the POC values for both BL and EL pictures unique and static. The encoder sets the MSB and LSB values in EL slice headers so that the decoded POC value of the EL picture is equal to the POC value of the existing or hypothetically existing base layer (BL) picture in the same access unit (AU), which also facilitates the POC alignment for hybrid scalability cases. Furthermore, as full POC is signalled, this design can also be applied to the pictures, which do not need POC alignment, to improve error resilience performance for cases of possible picture loss. The POC values of earlier pictures are not changed in this approach. It was commented that this would make POC resets cause RPSs to contain very large POC deltas and mess up POC-based scaling for temporal MV prediction (so the encoder might not want to use temporal MV prediction in such a case). Output would need to be based on alignment with base-layer POC values. Text for the output determination was not provided. It was remarked that this is similar to output for the scheme in P0056. It was noted that the encoder could not use a POC value for a current picture if that POC value was already being used for a picture that the encoder wanted to be in its RPS. No action taken on this. JCTVC-P0260 MV-HEVC/SHVC HLS: Additional information on the POC design in JCTVC-P0041/JCT3V-G0031 [A. K. Ramasubramonian, Hendry, Y.-K. Wang (Qualcomm)] [late] [miss] Discussed 01-10 am (GJS). This contribution provides some additional information on the POC design in JCTVC-P0041/JCT3V-G0031, some of which with comparison to the layer tree based POC design in JCTVC-P0056/JCT3V-G0042. Provided information includes 1) an analysis of error resilience compared to the POC design in JCTVC-P0056/JCT3V-G0042, 2) a point regarding using of POC and layer-tree POC in post-processing entities, 3) an analysis of how it works with multi-standard multi-layer coding designs, and 4) a showcase of whether it works with important use cases. The second aspect of topic 1 was suggested not to be serious, since there is syntax to avoid it. Topic 2 was questioned as to whether it was really valid. A showcase and testing plans for the scheme in JCTVC-P0041/JCT3V-G0031 was described. It was reported that most of the described cases had been verified and that the testing may be revealing bugs in the prior SHM software. Important use cases to be tested/demonstrated:
Common encoding configurations
Coding structures
Additional suggestions:
For each of the following 21 combinations, the test would show that the decoding result for the decoded pictures, in output order, matches at the encoder and decoder sides.
The proposal JCTVC-P0041/JCT3V-G0031 is being implemented, including the following aspects:
A few bugs in the SHM software are reportedly fixed with appropriately commented guard macros. The source code and the showcase script are provided in the attachment of this document. It can reportedly thus be shown that the POC design in JCTVC-P0041/JCT3V-G0031 works with all the important use cases described above.
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. JCTVC-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. The 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.
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.
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.
6.4.4.1Video parameter set (13)JCTVC-P0045 MV-HEVC/SHVC HLS: On layer set definition [T. Ikai, T. Tsukuba, T. Yamamoto (Sharp)] Discussed 01-10 pm (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 unclearness 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 aux 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 decodability, which basically means profile/tier/level values for nuh_layer_id equal to 0 should be seen by a version 1 decoder. Revisit. JCTVC-P0046 MV-HEVC/SHVC HLS: Additional layer set [T. Ikai, T. Tsukuba, T. Yamamoto (Sharp)] JCTVC-P0048 MV-HEVC/SHVC HLS: Syntax clean-up of profile, tier and level information [T. Tsukuba, T. Yamamoto, T. Ikai (Sharp)] JCTVC-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)] JCTVC-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)] JCTVC-P0076 MV-HEVC/SHVC HLS: On VPS extension and VPS VUI [H. Lee, J. W. Kang, J. Lee, J. S. Choi (ETRI)] JCTVC-P0110 MV-HEVC/SHVC HLS: On default output layer sets [K. Ugur, M. M. Hannuksela (Nokia)] JCTVC-P0125 MV-HEVC/SHVC HLS: On VPS extension offset and VPS VUI offset [A.K. Ramasubramonian, Hendry, Y.-K. Wang (Qualcomm)] JCTVC-P0132 MV-HEVC/SHVC HLS: On alt_output_layer_flag [A. K. Ramasubramonian, Y.-K. Wang, Hendry, Y. Chen (Qualcomm)] JCTVC-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)] JCTVC-P0157 MV-HEVC/SHVC HLS: On Indications for Inter-layer Prediction [S. Deshpande (Sharp)] Discussed 01-10 pm (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 leven 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 added to those existing indications by assigning a special value. Specification text changes related to the proposed indication are provided. It is asserted that the proposed indication enables indicating a low complexity decoding property for multi-loop decoding. During discussion, 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). The idea seemed reasonable if it does not introduce any problems. One participant had some concerns that could potentially be resolved by offline discussion for clarification.
6.4.4.3Hypothetical reference decoder (HRD) (4)Planned to be chaired by GJS. JCTVC-P0138 MV-HEVC/SHVC HLS: HRD parameters for bitstreams excluding CL-RAS pictures [M. M. Hannuksela (Nokia)] Discussed 01-09 pm (GJS). This contribution concerns CPB, and is the only contribution on that subject. Cross-layer random access skip (CL-RAS) pictures need not be decoded and hence it is asserted that HRD parameters without CL-RAS pictures would be beneficial. It is proposed to indicate that HRD parameters for a bitstream without CL-RAS pictures and without RASL pictures associated with the first IRAP picture of each layer using a buffering period SEI message included in a scalable nesting SEI message that applies to a layer set. No new syntax is proposed in the contribution. Cross-layer random access skip (CL-RAS) pictures are pictures that cannot be correctly decoded when the decoding process starts from an IRAP access unit that does not contain IRAP pictures in all layers. CL-RAS pictures are not indicated in the bitstream but they are concluded during the decoding process: a CL-RAS picture is a picture with nuh_layer_id equal to layerId such that LayerInitializedFlag[ layerId ] is equal to 0. The figure below shows an example how CL-RAS pictures are concluded when the decoding starts from AU x (in which case the CL-RAS pictures are the green pictures marked with "associated with AU x") or from AU z (in which case the CL-RAS pictures are the green pictures marked with "associated with "AU z"). When the decoding process starts from AU x or AU z, the respective CL-RAS pictures (the green pictures marked with "associated with AU x" or "AU z", respectively) can be removed from the bitstream, while the bitstream remains conforming. 
Association of CL-RAS pictures with IRAP access units. AU y does not have any association CL-RAS pictures in this bitstream (copied from JCTVC-O0212/JCT3V-F0072). The contribution said that the indication of HRD parameters for bitstreams without CL-RAS pictures is the multi-layer equivalent of the indication of HRD parameters for bitstreams without RASL pictures for single-layer bitstreams. The HRD parameters for bitstreams without RASL pictures are indicated in the buffering period SEI message with the cpb_delay_offset, dpb_delay_offset, nal_initial_alt_cpb_removal_delay[ i ], nal_initial_alt_cpb_removal_offset[ i ], vcl_initial_alt_cpb_removal_delay[ i ], and vcl_initial_alt_cpb_removal_offset[ i ] syntax elements. In this contribution, it is proposed to indicate that HRD parameters for a bitstream without CL-RAS pictures and without RASL pictures associated with the first IRAP picture of each layer using a buffering period SEI message included in a scalable nesting SEI message that applies to a layer set. The syntax elements cpb_delay_offset, dpb_delay_offset, nal_initial_alt_cpb_removal_delay[ i ], nal_initial_alt_cpb_removal_offset[ i ], vcl_initial_alt_cpb_removal_delay[ i ], and vcl_initial_alt_cpb_removal_offset[ i ] are interpreted for a bitstream that excludes both the CL-RAS picture and the RASL pictures (associated with the initial IRAP pictures of each layer). No new syntax is proposed in the contribution. The detailed proposal is included as change marks in an accompanying specification text document. It was remarked that in the v1 syntax, we have a NUT that tells the decoder whether there may be RASL pictures or not, and if not, the "alternative" HRD parameters are used by the decoder. We do not have this indication for CL-RAS pictures. (It was previously proposed for CL-RAS pictures to have a distinct NUT value, but this is not the approach that was adopted.) A prior proposal suggested to have a (possibly externally-supplied) flag associated with the base layer IRAP picture with NoClrasOutputFlag equal to 1 to indicate whether RASL or CL-RAS pictures can be present or not. This approach would presumably work with the proposal. The proposal avoided needing extra syntax as had been proposed previously in a similar-concept proposal O0212. It was remarked that the flag could also be sent as an extension bit in the BP SEI message. It was also remarked that a similar previously-specified flag called UseAltCpbParamsFlag could perhaps benefit from putting such a flag in the SEI message. It was remarked that one flag may be sufficient for both purposes. These can be considered, from the v1 perspective, as a form of "external means".
Discussed 01-10 am (GJS). The decoded picture buffer (DPB) size for each output layer set is signalled according to the maximum number of sub-layers of each output layer set. In VPS extension, max_sub_layers_output_layer_set_minus1[ i ] is proposed to indicate the maximum number of sub-layers for the i-th output layer set. When max_sub_layers_output_layer_set_minus1[ i ] is present, syntax elements related to DPB-size (max_vps_dec_pic_buffering_minus1[ i ][ k ][ j ], max_vps_num_reorder_pics[ i ][ j ], max_vps_latency_increase_plus1[ i ][ j ]) are signaled as many as the values of max_sub_layers_output_layer_set_minus1[ i ]. The maximum number of each output layer set can be inferred from other syntax elements, without explicit signaling. This first aspect was resolved by the action taken on P0156 proposal 1. Additionally, it was proposed that the DPB-related syntax elements for sub-layers of each output layer set be moved to the video parameter set VUI instead of being in the current drafted location in the VPS extension. It is asserted that those syntax elements are informative without affecting the normative decoding process. However, it was marked that these syntax elements are used to specify conforming bumping requirements in Annex C, so no action was taken on this aspect.
Discussed 01-10 am (GJS). Three items:
Decision (cleanup): Adopt (all four aspects). JCTVC-P0192 MV-HEVC/SHVC HLS: On decoded picture buffer management [Y.-K. Wang, A. K. Ramasubramonian, Y. Chen (Qualcomm)] Discussed 01-10 am (GJS). At JCT-VC#15 and JCT-3V#6 meetings in Geneva, the group agreed to specify a separate DPB capacity for each layer without sharing of DPB capacity across layers. This document proposes either to allow for DPB capacity sharing across layers to utilize the process for DPB memory optimization, or to remove the reference marking processes in subclause F.8.1.4 per discardable_flag and in subclause F.8.1.4.1 per VPS layer dependency signalling for specification clean-up. Alternative #1 in the contribution is a proposal to establish DPB capacity sharing across layers that have the same spatial resolution, bit depths, and colour format. It is asserted that sharing can be specified without very much added text or complication. Regarding alternative #2 in the contribution, unless some kind of cross-layer sharing/constraint is specified this is essentially editorial clean-up – the current text is not actually broken, but includes a description of two unnecessary processes (one based on discardable_flag and one based on layer-dependency signalling in the VPS). The contribution also includes some suggested editorial clean-ups. Decision (Ed.): Editorial aspects delegated to the editors for consideration. It was noted that P0142 is related, as it advocates a cross-layer constraint on memory usage. It was remarked that we should probably have a separate DPB for a non-HEVC base layer. At the previous meeting, it was said that "it seems that the cases where there would be an advantage of sharing the capacity across layers may be sufficiently rare to not be worth worrying about". However, it seemed desirable for the properties of bitstream characteristics description of the capacity needed for an output layer set to be describing the actual needs of that output layer set. If each capacity is considered entirely separate for each layer, the syntax would have an unnecessarily higher value than what is actually needed to decode that output layer set. It was suggested for the syntax to describe both properties of the bitstream and for the bumping process to pay attention to both types of properties. Then, for profile/level specification purposes, we can choose which type of constraints to apply, which can be a limit on shared capacity, a limit on per-layer capacity, or both. Revisit to review text for that approach. 6.4.4.4Miscellaneous HLS topics (6)JCTVC-P0047 MV-HEVC/SHVC HLS: On sub-bitstream extraction [T. Tsukuba, T. Yamamoto, T. Ikai (Sharp)] JCTVC-P0068 MV-HEVC/SHVC HLS: On parameter improvements [B. Choi, Y. Cho, M.W. Park, J.Y. Lee, H. Wey, C. Kim (Samsung)] JCTVC-P0079 MV-HEVC/SHVC HLS: comments on MV-HEVC WD 6 and SHVC WD 4 [H. Lee, J. W. Kang, J. Lee, J. S. Choi (ETRI)] JCTVC-P0130 MV-HEVC/SHVC HLS: Miscellaneous HLS topics [A. K. Ramasubramonian, Hendry, Y.-K. Wang, Y. Chen, V. Seregin (Qualcomm)] JCTVC-P0141 MV-HEVC/SHVC HLS: On temporal enhancement layers [M. M. Hannuksela (Nokia)] [late] Discussed 01-10 pm (GJS). This contribution asserts that "diagonal" inter-layer prediction would be useful when an SHVC-coded temporal enhancement layer is provided for an AVC base layer or when an enhancement layer provides a temporal enhancement, possibly along with spatial or quality enhancement, relative to the base layer, where the picture rate ratio is non-dyadic, e.g. 24 Hz base layer and 50 Hz enhancement layer. When no conventional inter-layer prediction from the same access unit is used, it is proposed to enable the use of other pictures from a direct reference layer as a reference for prediction as follows:
It was remarked that redundant pictures might also be another use case for diagonal referencing. The proposal could avoid cases where an encoder would otherwise generate a picture as a picture with all-skipped CTUs only to shift the temporal location of a BL picture to enable its referencing. It would also enable multiple-reference-picture use with BL reference pictures. It was noted that there is a case where an unnecessary flag sent in the proposed syntax. Another problem in the syntax was identified in regard to conditioning of a syntax element presence. The contribution also envisions using non-zero MVs to reference BL pictures, which is not currently allowed for SHVC use. It was suggested that non-zero motion should be prohibited when the cross-layer reference involves upsampling. It was also noted that our HRD partitioning cannot partition based on temporal sub-layers. It was suggested that we should reconsider the scalability type identifiers of Table F-1 if we enable the use of layers for temporal scalability. It was also remarked that a "pure SNR" scalability type could be constructed by prohibiting diagonal referencing as a sequence-level property, and the associated syntax could be skipped in that case. However, it was questioned whether such a constrained usage case would really be necessary (i.e., it may be desirable to just allow an SNR enhancement layer to reference multiple reference layer pictures in different AUs). For spatial scalability, it is already specified that only picture can be referenced with upsampling (to avoid unnecessary upsampling processes), and this constraint seems desirable.
Discussed 01-10 pm (GJS). This contribution proposes parameter set syntax signalling modifications and constraints intended to simplify the sub-bitstream extraction and bitstream rewriting process. It includes the ability to extract a non-base layer that would be converted to a v1-compatible base layer. This process would involve some modification of the data as well as extraction of it. It was proposed that each independent non-base layer must be included in a layer set that includes only that layer. It was also proposed to establish some constraints such that the PSs must be structured in a manner that can be converted easily to a layer with layer ID equal to 0. It was remarked that the "Option 1" approach in section 4 seemed simpler and more straightforward than the "Option 2". It was noted that in MVC there is an informative description of how to rewrite a non-base view tree as a base view tree. The impact of scalable nesting SEI messages was discussed. It was remarked that this probably could not work for auxiliary pictures that do not conform to the Main profile and accompany a base layer that does conform to the Main profile, because a Main profile decoder would likely reject a bitstream that has an SPS with a layer ID equal to 0 that has an unrecognized profile_idc. It was remarked that having some exception for this case might fix that. It was agreed that the functionality is desirable, but it was suggested not for it to be a required property of all independent non-base layers – e.g., in regard to having extra SPSs and PPSs with zero-valued layer IDs. Instead it was suggested to be able to signal when the properties would apply that would enable the simple rewrite. It was suggested that all that would be needed is an indication that a particular independent non-base layer has SPSs and PPSs that obey the constraints, and to add some informative text to describe the rewriting process. The contribution did not consider the ability to specify a rewriting process that would extract / rewrite entire layer trees – only individual independent layers, but it did provide some syntax for layer tree property descriptions as a proposed VUI syntax called "layer set info". It was suggested to check the processes related to sub-bitstream extraction to consider extraction of a bitstream subset that doesn't include the base layer. Revisit to consider syntax for such an indicator. Yüklə 0,95 Mb. Dostları ilə paylaş:
|