International organisation for standardisation organisation internationale de normalisation
Yüklə 8,2 Mb.
|
Other (5)14.1.97.1.1.1.1.1.293JCTVC-P0062 MV-HEVC/SHVC HLS: Redundant pictures for SHVC/MV-HEVC/HEVC [M. Sychev, V. Stepin, V. Anisimovskiy, S. Ikonin (Huawei)] Discussed 01-09 p.m. (GJS). This contribution proposes a scheme for coding redundant pictures in SHVC/MV-HEVC (and possibly HEVC v1). The proposal describes syntax and semantics for such redundant pictures (in the enhancement layers) by enabling more than one frame in the same layer to have the same POC, and proposes HRD behaviour when processing a frame with a duplicated POC. This contribution has two proposed schemes for usage of redundant pictures for loss resilience and one for performing inter-layer prediction for redundant pictures. It was proposed for the redundant pictures to be coded in a different order than the primary coded pictures. It was asked whether a decoder would be expected to wait several picture periods for a redundant picture to arrive and then decode that picture for use as a reference picture for the prediction of other dependent pictures that have arrived in the meantime. It was noted that the proposal is entirely new as a concept for HEVC, and has arrived at a late stage of the development of the current phase of extensions development. It was asked whether, assuming we like the proposed functionality, it could be added in a later extension rather than being done within the current phase of work. This seemed possible in principle, so it was suggested that it may be appropriate to prioritize this lower than current in-progress work. Several variants of the concept were described in the proposal, and some modifications were discussed in its discussion. It was noted that the lack of redundant pictures in non-Baseline AVC profiles has not previously been broadly identified as a serious problem. No significant interest was expressed by non-proponents for short-term action on this. Further study was encouraged, although it seemed unlikely that such a concept could be incorporated within our current phase of active extension developments. 14.1.97.1.1.1.1.1.294JCTVC-P0118 RExt HLS: Picture referencing across CRA pictures [R. Sjöberg, J. Samuelsson, Y. Wang (Ericsson)] Discussed 01-10 a.m. (GJS). This contribution claims that the restriction “When a picture is a leading picture, it shall precede, in decoding order, all trailing pictures that are associated with the same IRAP picture” can hurt compression efficiency, especially for field coding picture structures. The contribution proposes to use NAL unit type 11 to indicate a new type of picture: the CRA trailing reference (CTR) picture, which may be associated with CRA and BLA pictures. The contribution further proposed that the restriction above is changed to “When a picture is a leading picture, it shall precede, in decoding order, all trailing pictures with nal_unit_type not equal to CTR_NUT that are associated with the same IRAP picture” and that a new restriction is added: “Any CTR picture associated with a CRA or BLA picture shall precede any leading picture associated with the CRA or BLA picture in decoding order”. The contribution reports a −1.56% average bit-rate difference on the four publicly available test sequences used within the MPEG AHG on study of interlaced coding in HEVC. Version 2 of this contribution contains source code patches for HM-12.1+RExt-5.0rc1 that are claimed by proponents to enable testing the compression efficiency effect of the restriction. It was suggested to check whether the HM encoding technique that was integrated into HM 12.1 is actually producing non-conforming bitstreams in regard to having a trailing picture of a CRA picture reference a leading picture (or vice versa). (It was later remarked on 01-14 that there did not seem to be a problem in that regard.) The contribution proposed a new NUT for a trailing picture that can be used as a reference for trailing pictures, termed a CTR picture. CTR pictures would lie between IRAP and leading pictures in decoding order. It was remarked that perhaps there should be a constraint such a CRA/BLA can have only one such CTR picture. It was remarked that one approach for v1 bitstreams would be to, instead of using a CRA picture, to use an all-intra picture with a recovery point SEI message (and code the complementary field as a "trailing picture" of that pseudo-IRAP picture). It was remarked that, rather than using a different NUT, we could change the constraint specification such that one picture that follows a CRA or BLA in decoding order can be a trailing picture that is followed (in decoding order) by leading picture that use it as a reference picture. It was remarked that the primary decision is whether there should be such a special functionality in range extensions profiles (esp. 4:2:2) that is not supported in version 1 – particularly for interlace, which is a topic being studied for other future extension work. It was remarked that in 4:2:2 use, GOP structures are typically smaller and bit rates are typically higher – such that the benefit may be smaller. No action was taken on this. However, if we had thought of this sooner, we probably would have done something different in version 1. This was further discussed on 01-16. A 1.5% average gain for interlaced test sequences with field coding was reported for the modification. It was suggested to add a flag in the RExt SPS extension to allow the behaviour to change (such that one picture that follows a CRA or BLA in decoding order can be a trailing picture that is followed (in decoding order) by leading picture that uses it as a reference picture), and infer the value 0 when not present. It was noted that using a recovery point SEI message is an alternative approach that does not require a change. Further study was encouraged for consideration at the next meeting. 14.1.97.1.1.1.1.1.295JCTVC-P0137 REXT/MV-HEVC/SHVC/3D-HEVC HLS: On indication of decoding process and profile-level-tier combinations [M. M. Hannuksela (Nokia)] Discussed 01-09 p.m. (GJS). The contribution proposes the following three aspects. Aspect 3 is proposed only if aspect 1 is adopted.
It is asserted that aspects 1 and 2 provide the following functionality:
Regarding item 3, it was remarked that the coupling of the scalability dimension with coding tools in the current 3D HEVC design seems questionable (e.g., instead there indicators of coding features, subject to profile constraints). It was suggested that item 3 should be acted upon even if the rest is not. Potential decision: Use DepthFlag rather than AuxId for depth. If not decided by JCT-3V, this question is deferred to the next meeting. In our current design, auxiliary pictures may not have a profile that establishes constraints on their content. It was agreed that this is a problem. It is asserted that it would be essential to be able to provide the functionality of indicating which decoding process (v1, REXT, MV-HEVC, SHVC, 3D-HEVC) is used for each layer for the following functionality:
The contribution seems to raise some important issues for consideration. 14.1.97.1.1.1.1.1.296JCTVC-P0187 HEVCv1/MV-HEVC/SHVC HLS: On inference of NoOutputOfPriorPicsFlag [Y.-K. Wang, Y. Chen (Qualcomm)] Discussed 01-10 a.m. (GJS). This contribution discusses the inference of NoOutputOfPriorPicsFlag and proposes to take into account the colour format and bit depth for the inference, in addition to spatial resolution. It was noted that this would be a relaxation of a conformance constraint for version 1. Decision (BF & corrigendum): Adopt.
|