Of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11

5.11Motion and mode coding

JCTVC-I0036 Parallel AMVP candidate list construction [Q. Yu, S. Ma (Peking Univ.), H. Liu, J. Jia (LG)]

This contribution proposes three schemes for parallel construction of AMVP candidate list (AMVPCL) at different parallel levels. Method one is a CU-based approach and it constructs AMVPCL of all PUs in the same CU in parallel. Method two is also a CU-based approach but it generates a single AMVPCL for all PUs inside a CU. Method three is a region-based approach, in which AMVPCL of all PUs in the same region are constructed in parallel. Method two and solution three are designed to be compatible with the parallel merge/skip mode in HM6.0. It is reported that average BD-rate loss of Y, U and V is 0.3%, 0.3% and 0.3% for method 1, 0.1%, 0.1%, and 0.1% for method 2, and 0.1 %, 0.1% and 0.0% for the method 3.

One expert raises doubt that a non-normative solution may achieve similar results for parallel processing at encoder. Restriction for small block sizes may help.

Among the suggested solutions, #3 would be closest to the intended goal.

No action.

JCTVC-I0410 Cross-check of parallel AMVP candidate list construction (JCTVC-I0036) [J. Xu (Microsoft)] [late]
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.

(I0314 proposal 1 is identical.)

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)]

In HM-6.0, reference indices for temporal merging candidates of non-first PUs are set to zero, and the spatial merging candidates located in the first PU are excluded from the merging candidate list for 2NxN, Nx2N, and AMP partitions to remove the motion data dependency in merge mode. However, for the NxN merge mode, the spatial merging candidates located in other NxN PUs are still included in the merging candidate list, which prevents the NxN merge mode from being processed in parallel. Although the NxN merge is not allowed in the common test conditions, it is still allowed by CD (and by the Main Profile). In this contribution, the spatial merging candidates located in the other NxN PUs are excluded to remove data dependency between NxN PUs. Simulation results reportedly show no essentially coding efficiency loss, while all partition types in merge mode can be processed in parallel.

Note: Seems to be similar with H0091 which was not adopted due to the functionality is already covered through parallel mode. Proponent was requested to highlight what is different here, and what the benefit over the current parallel merge is. After discussion, no benefit seemed apparent.

No action.

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 (BF): Adopt (is matching the original intent and matches text and software). This also covers one of the US NB comments.

(Note: some more study and clarification may be needed to make the text and software consistent in motion data downsampling).

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-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)]

In HM6.0, the first two binarized bins of motion vector difference (MVD) are coded with adaptive context and the remaining bins are coded with bypass mode; and there is no MVD signaling for list L1 if mvd_l1_zero_flag is signaled as true. Contexts for the first two bins are shared for all blocks regardless of their associated inter prediction direction or reference lists. However, MVD from different directions may have very different statistical properties, in which case context sharing may not be suitable. That is true especially if motion estimation is unbalanced at encoder side, for example some MVDs are set to zero for a particular list. This contribution proposes assigning a separate context to the first MVD bin with respect to uni-predicted, bi-predicted list L0 and bi-predicted list L1 MVD.

The same idea was proposed in previous meeting

There seemed to be practically no gain – the assertion of benefit was questioned. Adds encoder flexibility, but no real benefit was apparent.

No action.

JCTVC-I0554 Cross-verification of JCTVC-I0350 [P. Chen, W. Wan (Broadcom)] [late]
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 (editorial improvement). Also trace the draft text for occurencesoccurrences of CombCount which could be removed elsewhere as well.

Question: Is this just editorial, or is there a technical change here? Why would there be experiment results for an editorial change?

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]