JCTVC-I0036 Parallel AMVP candidate list construction [Q. Yu, S. Ma (Peking Univ.), H. Liu, J. Jia (LG)]
no presenter available 04-28 17:00 & 19:10
JCTVC-I0410 Cross-check of parallel AMVP candidate list construction (JCTVC-I0036) [J. Xu (Microsoft)] [miss]
JCTVC-I0321 Crosscheck of Parallel AMVP Candidate List Construction (JCTVC-I0036) [Y. Chiu, W. Zhang, L. Xu, Y. Han (Intel)] [late]
JCTVC-I0084 Reduced number of checking scaled MV candidates in AMVP list construction [Y. Lin, L. Liu (HiSilicon)]
One modification is proposed to simplify spatial AMVP derivation by reducing number of checking scaled MV candidates. The number of candidate positions used for deriving the scaled MV candidate is reduced from 5 to 2. Simulation results show that the proposed modification achieves coding efficiency of 0.0%, 0.0% and 0.0% for both random access and low-delay configurations under common test conditions. It is recommended to adopt the proposal.
Not seen as a relevant simplification (particularly understandability text is not becoming simpler, and it does not give a relevant benefit in critical processing path)
(it is also mentioned that H0243 of last meeting was similar and not adopted)
No action.
JCTVC-I0478 Cross check of Hisilicon and Huawei's proposal JCTVC-I0084 [J. Kim LGE)] [late]
JCTVC-I0097 Reports on TMVP off versus TMVP on [H. Choi, J. Nam, D. Sim (KWU)]
This contribution reports on TMVP off versus TMVP on. According to this contribution, about 2~3% BD-Bitrate increases are founded in TMVP off case, compared to TMVP on. To compensate for the significant coding loss by TMVP off, this contribution suggests a method which improves the coding gain while keeping guarantee of error robustness. Therefore, this contribution proposes to send an auxiliary vector at each P and B slice header or PPS.
Compared to TMVP off, the suggested technique performs 0.3-0.4% better. The maximum gain is observed in class F, where panning motion occurs, such that the additional vector is useful.
Claimed to be beneficial in lossy environment.
additional encoder complexity? Unknown.
JCTVC-I0116 Temporal merging candidate derivation with reduced complexity [M. Zhou (TI)]
This contribution proposes to fix the reference index for temporal merging candidate (TMVP) of the merging candidate list to 0. Such a simplification increases the cache efficiency of buffering reference block for merge motion estimation, and facilitates low-complexity TMVP derivation on both encoder and decoder side by leveraging the motion data down-sampling in the HEVC. To compensate the slight loss (0.1%) in LB-Main and LP-Main, it is also proposed to add a simple pruning process (maximum one additional MVP comparison) for the TMVP; the TMVP is pruned against the first available spatial merging candidate before appending to the merging candidate list. Adding both changes together leads to a slight gain (0.1% to 0.2%) in various sequence classes and configurations when compared to the HM6.0.
Presentation not uploaded.
Similar proposals on setting TMVP refidx = 0 were made in previous meetings but were not adopted as they usually produced loss on BQSquare, which is no longer the case here.
Decision: Adopt the part of I0116 which proposes the TMVP ref index 0 as a desirable simplification.
JCTVC-I0411 Cross-check of temporal merging candidate derivation with reduced complexity (JCTVC-I0116) [J. Xu (Microsoft)]
JCTVC-I0134 On MVP candidate list for AMVP/Merge [T. Sugio, T. Nishi (Panasonic)]
In the HEVC CD text, decoding process is not defined for the case that entry of MVP candidate list is empty even though the entry can be illegally indicated by merge_idx/amvp_idx in the syntax. In this contribution, it was proposed to use predetermined MVP candidate for all empty entries in the MVP candidate list to eliminate the undefined decoder behaviour. Experimental result reportedly showed no loss for all test conditions relative to HM6.0.
Decision: Adopt. Several experts express the opinion that this was understood to have been included earlier (filling non-available candidates by zero), so it is an obvious bug fix.
JCTVC-I0119 Cross-verification of Panasonic proposal JCTVC-I0134 “On MVP candidate list for AMVP/Merge” [M. Zhou (TI)]
JCTVC-I0181 MVP and merge candidate initialization [T.-D. Chuang, J.-L. Lin, Y.-W. Chen, Y.-W. Huang, S. Lei (MediaTek)]
Very similar to JCTVC-I0134 and JCTVC-I0314 proposal 1 which was already adopted. In case of B slices, zero vectors should be inserted in both directions. Proponents to suggest one text for inclusion in the DIS, left to the discretion of editor to further align/improve it with the spec.
JCTVC-I0180 Parallel NxN merge mode [J.-L. Lin, Y.-W. Chen, Y.-W. Huang, S. Lei (MediaTek)]
no presenter available 04-28 18:30 (attends BoG).
Note: Seems to be similar with H0091 which was not adopted due to the functionality is already covered through parallel. Revisit: Still to be presented, proponent should highlight what is different here, and what the benefit over the current parallel merge is.
JCTVC-I0182 Constrained motion data compression [T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S. Lei (MediaTek), W. Wan, T. Hellman, P. Chen (Broadcom)]
In HM-6.0, the motion data in the upper LCU row are 2:1 down-sampled to reduce the motion data line buffer size. The motion data compression is always performed regardless the minimum PU width. However, the motion data compression for minimum PU width equal to or larger than 8 cannot reduce any line buffer due to the need to support the worst case that happens when the minimum PU width is 4. In this proposal, a new constraint is added: the motion data compression is performed only when the minimum PU width equal to 4. In common test conditions, this constraint will not cause any difference.
Presentation not uploaded.
Decision: Adopt. This also covers one of the US NB comments.
JCTVC-I0256 When MaxNumMergeCand equals zero [Y. H. Tan, C. Yeo, Z. Li (I2R)]
The MaxNumMergeCand syntax in the slice header limits the maximum number of merge candidates available for merge operations within the slice. This proposal presents several ways of clarifying the behavior of the decoder when MaxNumMergeCand == 0. Including a zero motion merge candidate with reference index zero can help alleviate the coding performance degradation (by ~2% on average) when SKIP and MERGE are not used, providing a low complexity alternative. The low-complexity SKIP/MERGE mode can be signaled by setting MaxNumMergeCand == 0.
Difference compared to I0314:?
Both proposals include a new operating point of zero candidates (skip/merge with zero MV value). This needs additional implementation at the decoder.
The proposed solution performs worse than the current maxNumMergeCand == 1. Is an operating point for low-complexity encoder which is likely to be less complex at the encoder still needed?
Conclusion: Fix the current bug (maxNumMergeCand == 1..5 and disallow 0), but no adoption of the two proposals.
JCTVC-I0482 Crosscheck of JCTVC_I0256 - On Intensity Dependent Quantization in the HEVC codec Rik Allen [late]
JCTVC-I0293 Merge candidate refinement for uni-predictive block [T. Yamamoto, T. Ikai (Sharp)]
This contribution proposes alternative merge candidates for uni-predictive block which replace combined merge candidate in bi-predictive block. The proposed method aims to improve coding efficiency of P Slice without introducing additional worst case computation increase in B Slice. The experimental results show that the proposed method introduces coding efficiency improvement of 0.3 % and 0.3 % for LP Main and LP HE10 cases respectively.
Gain of 1% for Kimono.
No support, no action.
JCTVC-I0074 Cross-check report for Sharp's merge candidate refinement for uni-predictive block (JCTVC-I0293) [T. Chujoh (Toshiba)]
Change is small (adds 27 lines of code).
JCTVC-I0298 Simplification of spatial motion vector scaling process [S. Fukushima (JVC Kenwood), I.-K Kim (Samsung)]
In the HM6.0 and the CD, there is a process for AMVP scaling for the group B (Above). AMVP candidate derivation for the group B needs to check whether the group A has at least one inter coded PU or not.
In this proposal, AMVP scaling candidate derivation of the group A is removed. The scaling candidate is never derived from the group A. The simulation results report that the proposed modification provides average 0.0% coding loss.
JCTVC-H0243 was very similar (above group was restricted, now left group is restricted).
Benefit not obvious (would be better to remove scaling totally).
No action.
JCTVC-I0092 Crosscheck report for JCTVC-I0298 [Hendry, B. Jeon (LG)] [late]
JCTVC-I0314 Default values for skip/merge and AMVP [H. Nakamura, S. Fukushima, H. Takehara (JVC Kenwood)]
Merge indices and MVP indices are coded within maximum number for robustness. However, all indices cannot be always selected because some indices sometimes have invalid value.
Those invalid values may cause decoding error in terms of conformance.
This contribution recommends that invalid candidates are replaced by the default candidates in merge and mvp candidate lists.
In addition, when MaxNumMergeCand is equal to 0, skip_flag and merge_flag cannot be set equal to 1 in current HEVC spec.
This contribution recommends that skip and merge mode can be enabled by default inter prediction value without constructing merge candidate list when MaxNumMergeCand is equal to 0.
1st part same as JCTVC-I0134.
2nd part related to re-defining the decoder operation for MaxNumMergeCand = 0 with an “MPEG-2 style skip” and similar merge mode where the MV associated to skip/merge is zero.
This would apply to the case of low-complexity encoders only.
Note: Currently a ticket (#354) is open related to MaxNumMergeCand = 0 (inconsistent semantics “five-minus”, case 0 undefined), software crashes when it is set to zero. This is different from the original intention of JCTVC-G0091. This should first be fixed before taking action
Similar method is proposed in JCTVC-I0256 (see further conclusions there).
JCTVC-I0437 Cross-check report of Default value for skip/merge and AMVP (JCTVC-I0314) [T. Sugio (Panasonic)] [late]
JCTVC-I0350 Splitting contexts for MVD coding [V. Seregin, J. Chen, X. Wang, M. Karczewicz (Qualcomm)]
Revisit: Still to be presented. There seems to be practically no gain, what is the benefit?
JCTVC-I0414 Removal of the restriction on the number of combined merge candidates [O. Bici, K. Ugur, J. Lainema (Nokia)]
In HM6, the number of combined merge candidates is restricted to 5. When this limit on the maximum number of combined candidates was introduced, the design was such that each additional candidate would have a redundancy check with the previous candidates. Therefore, the motivation of the limiting was to limit the worst case redundancy checks. However, in the current design, there is no redundancy check for the additional candidates after the adoption of JCTVC-G397. Therefore, as this limit is obsolete and the number of combined candidates used can never reach 5, it is proposed to remove the aforementioned restriction as a clean-up for the design. Experimental results with common test conditions indicate no coding efficiency difference.
Decision: Adopt. Also trace the draft text for occurences of CombCount which could be removed elsewhere as well.
JCTVC-I0522 Cross-check report for JCTVC-I0414 [S. Esenlik (Panasonic)] [late]
JCTVC-I0490 Combination of JCTVC-I0084 and JCTVC-I0298 on simplified MV scaling process for spatial AMVP derivation [Y. Lin, L. Liu (HiSilicon)] [late]
No need to present, as both proposals were not adopted.
JCTVC-I0548 Cross-verification of simplified MV scaling process for spatial AMVP derivation (JCTVC-I0490) [S. Sakazume, S. Fukushima (JVC Kenwood)] [late] [miss]
Dostları ilə paylaş: | 
