Organisation internationale de normalisation
Yüklə 9,04 Mb.
|
HL syntax (0)No contributions were noted in this area.
13.0.0.1.1.1.1.1.327JCTVC-S0031 Additional Definitions of FPA SEI Message for Inclusion of Centralized Colour-Depth Packing (CCDP) Formats [J.-F. Yang, K.-Y. Liao, H.-M. Wang, Y.-H. Hu (NCKU)] (Consideration of this topic was chaired by G. Sullivan on Sunday 10-19 a.m.) The most popular frame compatible formats for transmitting stereoscopic views are side-by-side (SbS) and top-and-bottom (TaB). Currently, the defined frame packing arrangement (FPA) SEI message supports these two formats and some others ones. However, there are no related standard packing formats for 3D video represented by colour and depth information. This contribution proposes an FPA SEI message to cover a series of centralized colour-depth packing (CCDP) formats for representation of 3D video with colour and depth information. It is reported that 3D video encoded with the CCDP formats could be directly viewed on 2DTV displays without any pre-processing. The CCDP formats are also asserted to have better performance in both colour-depth coding and multiview rendering results compared to the frame-compatible colour-and-depth SbS packing method based on HM 13.0. The proposed additional FPA SEI Message includes the CCDP formats for delivery of 3D video services in the existing HEVC and AVC video coding standards. The contribution proposes an x = { 3/4, 5/6, 7/8, 11/12, 15/16 } downscaling of the texture data and 1 − x downscaling of the depth data, with the depth data split, flipped and attached as top and bottom sidebars above and below the texture data. There was a prior proposal JCT3V-F0087 as a late contribution in November 2013. No action was taken on it at that time. It was asked what is the relationship between this proposal and the texture and depth view packing SEI message, which is reported in an AVC draft amendment (but not an AVC draft amendment). (Y. Chen, T. Senoh). It was asked why this is proposed to JCT-VC rather than JCT-3V, and was suggested for it to be reviewed in JCT-3V rather than in JCT-VC. 13.0.0.1.1.1.1.1.328JCTVC-S0095 HLS: Dependent RAP indication SEI message [R. Sjöberg, M. Pettersson, J. Samuelsson (Ericsson)] (Consideration of this topic was chaired by G. Sullivan on Sunday 10-19 a.m.) This is a follow-up contribution of JCTVC-R0059, for which further study was encouraged at the July meeting in Sapporo. The contribution proposes a new dependent RAP indication SEI message for the HEVC base specification and its extensions. The SEI message is used to indicate the presence of a dependent random access point (DRAP) picture in the bitstream. The following constraints are proposed when a DRAP picture is present:
When performing random access at a DRAP picture, the associated IRAP picture must first be decoded and the value of pic_output_flag should be inferred to be equal to 0 for all pictures that precede the DRAP picture in output order. No parameters are signalled in the SEI message. It is asserted that DRAP pictures improve the compression efficiency for random access coded video, especially for video services that often have very static content including screen sharing and surveillance video. The presentation was requested to be uploaded. Some use cases and associated measured benefits were presented. As proposed, the SEI message would contain no syntax elements. The prior proposal had included three syntax elements. The usefulness of one of those syntax elements had been questioned in the previous meeting's discussion. It was asked whether there are multilayer issues that should be considered. As proposed, the layer ID is required to be zero. It was remarked that higher-level signalling would be needed in the presented DASH scenario, to the extent that additional in-band signalling might not also be necessary. Other participants suggested that since the concepts are closely tied to the random access properties of the HEVC design, it may be beneficial to have a specification of those properties within the HEVC specification and that the in-band indication may be useful for other environments as well. There was further discussion chaired by GJS & JRO on Thursday 10-23 a.m. Additional use cases were presented, avoiding the use of IRAP pictures in two scenarios:
It was remarked that S0196 is related. Another participant said that this approach seems simpler for decoders than needing to handle the redundant picture functionality. Here the decoder is not required to do anything out of the ordinary to decode the video. Decision: Adopt. 13.0.0.1.1.1.1.1.329JCTVC-S0148 Indication of the end of coded data for pictures and partial-picture regions [Y. Wu, L. Zhu, S. Sadhwani, G. J. Sullivan (Microsoft)] (Consideration of this topic was chaired by J. Boyce on Sunday 10-19 a.m.) This contribution proposes the specification of an SEI message to indicate the slice segment address of the next slice header (when present) for decoding latency minimization. It is asserted that it would be beneficial, especially in ultra-low latency use cases, to have an earlier indication of when the coded picture is complete, and particularly to have such an indication within the same access unit as that coded picture itself. Some decoders may be designed to wait for reception of the complete decoded picture before performing the parsing and decoding processes for the picture's VCL NAL units. Requiring such decoders to wait until the next access unit begins is asserted to sometimes add significant delay. Moreover, for some decoding architectures that are based on region segmentation, it is asserted that it would be similarly beneficial for a decoder to have an indication of how much of the decoded picture has been sent in the preceding VCL NAL units (without waiting for the next slice header). To provide such an indication, an SEI message is proposed for HEVC to identify the slice segment address of the next slice header (when present). The SEI message is primarily proposed as a suffix SEI message. The same problem is reported to be present in the AVC context, for which the contribution proposes using a previously-reserved NAL unit type (type code 22) for the same basic purpose, since suffix SEI messages are not (at least not yet) defined in AVC. More generally, it would be possible to add the general concept of suffix SEI messages to AVC, for which this message could be the first to be specified. It was asserted that some decoders may want to buffer up received slices and wait until the entire picture (or region) is available to begin decoding. In the current specification, parsing would be required for the decoder to know that the entire picture has arrived. The SEI message is also proposed for AVC, but only the HEVC proposal will be considered within the scope of JCT-VC. Both prefix and suffix SEI message options are proposed. The contents always apply to the next coded slice. During discussion, it was suggested to add a syntax element (flag) to indicate whether or not a dependent slice segment follows. It was questioned what the implications would be for scalability, or other multi-layer context. The proposal could apply to a single layer. It would allow detection of the end of picture, but not the end of the access unit. While we have an access unit delimeter, that is carried in the next access unit, not the current access unit. Some systems environments have an indication for end of picture, such as the marker bit in RTP. There was support for the proposal. Interest was expressed in fully considering the multi-layer context. There is an expectation to adopt at the next meeting (Feb, Geneva) to allow more time for study. 13.0.0.1.1.1.1.1.330JCTVC-S0196 HLS: On Redundant Pictures SEI message for HEVC [M.Sychev, S.Ikonin (Huawei)] [late] (Consideration of this topic was chaired by G. Sullivan on Sunday 10-19 a.m.) (The second version upload was corrupted. The first and third were not. The third version was the intended second version.) This contribution follows up on the previous proposals P0062, Q0090 and R00159 proposing a redundant pictures indication for HEVC. The contributor asserted that the proposal would provide the ability for significantly reduce traffic overhead (up to few times) while joining a new participant to a multi-point video conference while maintaining visual quality. Other use cases, such as packet loss recovery, were also presented. The contributor said that it was well-established that packet loss protection of video streams loss using existing HEVC and MMT tools is often not sufficient for current networks, and that current networks sometimes have packet loss probabilities up to 20%, as reflected in in IP network model standards ANSI TIA-921 and in Rec. ITU-T G.1050 in 2011. The contributor said that existing error protection tools are able to cover only up to 3% of packet loss. The contributor said that the proposal would provide a source-level packet loss protection scheme that would be effective for filling an asserted gap between current HEVC abilities and real network requirements. The proposal would send a redundant picture in an out-of-order manner – in a different access unit – not in the same order as found in AVC redundant pictures. Remarks from prior meetings included the following: Meeting P: "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." Meeting Q: "Further study was encouraged on this topic, but no immediate action was planned. This would be for consideration beyond the scope of the current phase of work." Meeting R: "Some interest was expressed in further study of the idea, although it is not clear there is a desire to move toward adoption at this time. Further study would be needed to determine whether there is adequate need for this." Two SEI messages were proposed. The first one would be sent with a redundant picture that indicates that it is a redundant picture, and indicating properties of the primary picture (POC and POC reset information). Such pictures would have PicOutputFlag equal to 0 and would not be referred to by any subsequent pictures (for temporal MV prediction or inter prediction referencing). The second could be sent with a primary picture, and indicate properties of the redundant pictures. The first one could be used with or without the second, and vice versa. The pictures used as references by the redundant picture (if any) would need to be retained in the RPS of the intervening pictures. A participant remarked on need for system-level support for the usage and delivery of such pictures. A participant remarked that it did not seem clear that this is the appropriate approach for the multipoint acquisition use case. The differing timestamp of the redundant picture was mentioned as an aspect that seemed a bit complicated. Some systems might have alternative handling approaches. It was remarked that the DRAP proposal S0095 is related. No action was initially planned, pending further discussion to determine the level of interest. This was further discussed chaired by JRO & GJS on Thursday 10-23 a.m. Some form of redundant pictures was previously standardized, but has not proven popular in actual use. As proposed, a bitstream would contain these extra pictures, out of order, and these would be indicated for decoding. This implies some loss of coding efficiency relative to not containing this data. If the decoder decodes these pictures when it does not need them, this would also add decoding complexity (relative to not having this data). The benefit would need to outweigh these considerations, and it was not clear to participants that this would often be the case. As previously remarked, other approaches may be more feasible and simpler (e.g., just DRAP pictures or server-side caching of original pictures – perhaps with some system-level support). No interest was expressed by non-proponents. 13.0.0.1.1.1.1.1.331JCTVC-S0197 VUI codepoint for SMPTE ST 2085 (YDzDx) [C. Fogg, J. Helman (MovieLabs)] (Consideration of this topic was chaired by G. Sullivan on Sunday 10-19 a.m.) Changes to accommodate a code point to indicate YDzDx (SMPTE CD 2085) are proposed for VUI (Annex E) matrix_coeffs (Table E-5) elements in the HEVC and AVC specifications. The Society of Motion Pictures and Television Engineers development of ST 2085 is reportedly expected to be completed by February 2015. A liaison statement to MPEG (m34700) from SMPTE includes the latest draft of CD 2085. It was commented that the video standards do not accommodate the modified code value range described in Annex A of the CD 2085 draft. Some prior information about this was discussed at the San Jose meeting, but at that time the draft of ST 2085 was at an earlier stage (although essentially the same in technical content). In the discussion, there was a generally favorable reaction. It was suggested that since this is something being standardized by SMPTE, we should presume that we would want to support it. Decision: Adopt (into SCC draft). The proposal for support in AVC should be considered by the parent bodies.
|