International organisation for standardisation organisation internationale de normalisation
No-CE technical contributions (12)
Yüklə 7,38 Mb.
|
No-CE technical contributions (12)
14.1.1.1.1.1.1.1.242JCT3V-F0103 Definite and sparse depth access for DoNBDV and VSP [T. Ikai (Sharp)] This proposal presents a depth access restriction to avoid arbitrary depth access. The depth access is carried out for depth refinement DV(DoNBDV) or view synthesis prediction. Although the depth access is sparsely accessed in each block thanks to only corner point access but the top-left position of the depth access is not restricted. Therefore it is proposed to restrict the vertical position of the depth access to be zero (Proposal 1). The depth access is considered as a kind of parameter access since that is used for motion parameter derivation and needs to be completed before motion compensation process and the other parameter access is 4x4 block basis at the minimum. Therefore it is proposed to set corner position of vertical position to a multiple of 4 (Proposal 2) or 8 (Proposal 3) to reduce depth access further. The experiment results show 0.0 %, 0.1 % and 0.0 % coding gain in synthesis in Proposal1, Proposal2 and Proposal3 respectively. Proposal 2 gives losses in coding dependent views of GTFly. Not clear what the real benefit of proposal 1 is, as the random memory access still applies with horizontal disparity. Some concerns whether the omission of the depth samples in proposals 2 and 3 would give wrong depth data, and the benefit may also be implementation specific. Further evidence needed about the benefit of the proposed method. 14.1.1.1.1.1.1.1.243JCT3V-F0220 Crosscheck of Definite and sparse depth access for DoNBDV and VSP by Sharp (JCT3V-F0103) [X. Zhang, K. Zhang (MediaTek)] [late] 14.1.1.1.1.1.1.1.244JCT3V-F0122 HTM support of depth coding in MV-HEVC [Y. Chen, L. Zhang, X. Zhao, M. Karczewicz (Qualcomm)] [late] This proposal provides the concrete design of coding depth views in MV-HEVC. The proposal includes both the software for HTM and working draft text changes in MV-HEVC. Instead of conveying the information of indicating the depth view characteristics or signaling of the auxiliary pictures with various ways of HLS design, this proposal focuses on supporting depth coding in HTM. Simulcast, i.e. no dependent coding of depth was used. It is verbally reported that the gain would be around 2% by employing MV-HEVC for the depth maps. VSO was used for both. Comparison was made against 3D-HEVC. Average increase for 3-view case is 18%. (alternatively, the decrease of 3D-HEVC compared to MV-HEVC with depth simulcast is around 16%). What the proposal is investigating in terms of compression performance, would approximately reflect the situation when depth maps are coded as auxiliary pictures. Joint meeting with JCT-VC on HLS and auxiliary picture issues: it was agreed to proceed with specification of auxiliary pictures including depth. What to do about the software? It was mentioned by the proponents that it would still be useful to have this software and its capabilities even though the HLS is not aligned with the MV-HEVC spec. It would be relatively straightforward to align the HLS from the provided software. F0031 contribution has started to implement auxiliary pictures based on SHM software. It was agreed to support this functionality in the HTM software, and include as part of software integration work plan. The details should be decided offline, i.e., whether it is better to first integrate F0122 with HLS misaligned, then update to auxiliary picture syntax later, or wait for HLS for auxiliary pictures to be put in place, then add depth simulcast functionality with VSO. Decision(SW): Adopt (alignment with auxiliary picture syntax will be done after the implementation of HLS for auxiliary picture; restrictions may apply in the software implementation such that inter-view prediction of depth maps is not possible). Note: The normative aspect of the proposal, restricting inter-view prediction for the depth (which is in principle possible for auxiliary pictures) is not adopted. 14.1.1.1.1.1.1.1.245JCT3V-F0146 Illumination Compensation for View Synthesis Prediction Candidate for 3D-HEVC [M. W. Park, J. Y. Lee, H.-C. Wey, C. Kim (Samsung)] Was reviewed in context of CE3. 14.1.1.1.1.1.1.1.246JCT3V-F0213 Cross-check of Illumination Compensation for View Synthesis Prediction Candidate (JCT3V-F0146) [T. Ikai (Sharp)] [late] 14.1.1.1.1.1.1.1.247JCT3V-F0151 Removal of IC in depth coding and IC flag signalling in 3D-HEVC [J. Y. Lee, M. W. Park, Y. Cho, C. Kim (Samsung)] In current 3D-HEVC, Illumination compensation (IC) is used in both texture and depth image coding. It compensates the illumination difference between dependent views. However, it is observed that the depth IC gives the negative impact on the overall coding performance and the encoding complexity. Therefore, the proposed method removes the depth IC in 3D-HEVC. In addition, IC flag is defined in VPS extension. It enables or disables the IC tool and control slice_ic_flag in slice header. By the time when IC was adopted for depth maps, it gave approx 0.1% BR reduction. In the meantime, IC has been changed to remove the parsing dependency and simplify further; obviously now, it is not of value for depth maps any more (BR increase by 0.1%). Decision: Remove IC for depth map coding, no change for texture coding. The second aspect, IC enable flag in VPS, was already proposed in E0160. Benefit of this not obvious, no action. 14.1.1.1.1.1.1.1.248JCT3V-F0214 Cross-check of Removal of IC in depth coding and IC flag signalling (JCT3V-F0151) [T. Ikai (Sharp)] [late]
This contribution presents an adaptive context model selection method for illumination compensation (IC) flag. This contribution adaptively uses three context models for IC CU flag coding derived from neighbouring blocks. The proposed method provides 0.2% coding gain in the common test condition (CTC). Currently, only one context model is used. Method similar to the coding of the ARP flag. Several experts supported the proposal, no objections were raised. Decision: Adopt. 14.1.1.1.1.1.1.1.250JCT3V-F0208 Cross check of illumination compensation flag coding (JCT3V-F0160) [J. Y. Lee, C. Kim (Samsung)] [late]
|