Organisation internationale de normalisation
Merge list construction (7)
Yüklə 9,04 Mb.
|
Merge list construction (7)(Chaired by JRO, Sunday morning) 13.0.1.1.1.1.1.1.25JCT3V-J0024 Simplification of merge candidates list construction [T. Ikai, T. Tsukuba (Sharp)] This contribution proposes to simplify the 3D-HEVC merge mode by - Change Shift candidates position - Remove B1 pruning and some A1 pruning - A1 VSP inheritance only (Remove non A1 VSP inheritance) By removing the pruning process, in one sequence loss of 0.2% occurs. Some doubt is raised whether the first two changes would be beneficial in re-using existing version 1 designs (particularly in hardware). Benefit of the simplification not huge. For the third change, a similar idea is in J0039. 13.0.1.1.1.1.1.1.26JCT3V-J0084 Crosscheck on simplification of merge candidates list construction (JCT3V-J0024) [X. Zhang, J.-L. Lin (MediaTek)] [late] 13.0.1.1.1.1.1.1.27JCT3V-J0039 Removal of redundant VSP candidates in Merge mode [J. Y. Lee, M. W. Park, C. Kim (Samsung)] At the last meeting, several proposals (I0053, I0087, I0112, I0106, and I0130) tried to restrict the VSP inheritances from the neighboring blocks for the simplification of the Merge mode construction. However, it showed that the restriction results in bit rate increase for dependent views, especially in CG sequences. This contribution proposes to restrict the VSP inheritance in terms of the potential coding performance. Since the inherited and default VSP candidates have same DV, the Merge mode can include the redundant VSP candidates. It is possible that all the candidates are VSP in the Merge mode. Therefore, the proposed method (a) disallows the VSP inheritance or (b) only allows the VSP inheritance from the left block and the default VSP is disabled if the inherited VSP exists. The results demonstrate that the proposed method removes the redundant VSP candidates without the coding loss. In addition, when the proposed method disallows the VSP inheritance, the VSP storage can be completely removed. The presentation deck was requested to be uploaded. Two methods: Method 1 removes the VSP inheritance from neighboring blocks completely. Method 2 only allows the VSP inheritance from A1 and the default VSP is disabled if the inherited VSP exists. The default VSP is placed between B1 and IVDC. Method 2 consistently provides a small gain or no loss over all sequences and slightly simplifies. Several experts expressed support for method 2. Decision: Adopt J0039 method 2. Crosschecker confirms that the text is mature. 13.0.1.1.1.1.1.1.28JCT3V-J0092 Cross-check on Removal of redundant VSP candidates in Merge mode (JCT3V-J0039) [T. Ikai (Sharp)] [late] 13.0.1.1.1.1.1.1.29JCT3V-J0042 Simplification of depth merge candidate list [S. Yoo, S. Yea (LGE)] In the current 3D-HEVC, DDD (Disparity derived depth) and IvMC are performed as the second and third depth merge candidates, respectively. For DDD, the disparity from the collocated texture is converted to depth data and included to the merge list. If the IvMC is selected, motion vectors in the reference view are derived by a converted disparity of the median depth value of the current bitdepth (1< Decision: Agreed to remove DDD as proposed in JCT3V-J0042 and JCT3V-J0030. This removes significant parts from the draft text and reduces implementation complexity.
Cross-checkers confirmed that the text modification is correct. Several experts suggested to keep IvMC for depth. It does not incur a complexity problem, and removing it would consistently imply some minor loss over all sequences
13.0.1.1.1.1.1.1.30JCT3V-J0068 Cross check of simplification of depth merge candidate list (JCT3V-J0042) [J. Y. Lee, C. Kim (Samsung)] [late] In the current 3D-HEVC, there are two candidates for inter-view disparity compensation in the merge list. First, IvDC candidate is derived by depth oriented neighbouring block based disparity vector (DoNBDV). Second, IvDCShift candidate is set to IvDC candidate shifted by 4. IvDC and IvDCShift candidates are derived for each List 0 and List1. However, motion information for List 0 and List 1 are exactly same in the specification. In this contribution, restriction of bi-directional for IvDC and IvDCShift candidates is proposed. The proposed method is to use a uni-directional prediction for IvDC and IvDCShift candidates. The experimental results are no impact under the common test conditions. There is a small deviation in the results due to the fact that with ARP uni prediction and bi prediction with identical references are not equivalent
It could also occur that in fact different are used in list 0 and list 1, such that the restriction gives up some degree of freedom. The restriction would not have impact on critical worst case complexity, but would allow removing some lines of text.
Question is raised whether it would have larger loss in IBP case? One expert would support it if it would not have loss for IBP. Advantage not obvious enough to take action.
13.0.1.1.1.1.1.1.32JCT3V-J0085 Crosscheck on restriction of bi-prediction for IvDC and IvDCShift candidates (JCT3V-J0048) [X. Zhang (MediaTek)] [late] In 3D-HEVC, to improve the coding efficiency and explore the inter-view and inter-component correlation, 3D extra merge candidates are included in the merge candidate list. The enabling of those extra merge candidates are controlled by three flags transmitted in the VPS extension 2 including iv_mv_pred_flag, mpi_flag, and view_synthesis_pred_flag. In order to utilize those 3D extra merge candidates in the merge candidate list, the size of the 3D extra merge candidate list is increased by 1 for the dependent texture and depth map. However, in current Draft Text, the determination of whether to increase the merge candidate list size depends only on the iv_mv_pred_flag and mpi_flag. The view_synthesis_pred_flag is missed in the decision. To fix this issue, it is proposed to include the view_synthesis_pred_flag in the determination. Decision (BF): Adopt J0059 (text and software)
Yüklə 9,04 Mb. Dostları ilə paylaş:
|