History-based motion vector prediction

Abstract

To provide a system, a method, and a device for processing history-based motion vector prediction (HMVP).SOLUTION: A video encoding device generates a history-based motion vector prediction (HMVP) list for a current block and derives HMVP candidates from previously encoded blocks. The HMVP candidates include motion information associated with neighboring blocks of the current block, one or more reference indexes, and bidirectional prediction weight indexes, and adds the HMVP candidates to the HMVP list for motion-compensated prediction of a motion vector associated with the current block. The video encoding device also uses one HMVP selected from the HMVP list to perform motion-compensated prediction of the current block. The motion-compensated prediction is performed using motion information associated with neighboring blocks of the current block, one or more reference indexes, and bidirectional prediction weight indexes.SELECTED DRAWING: None

Description

Technical Field

[0001] Cross - Reference to Related Applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 786,429, filed on December 29, 2018, the contents of which are incorporated herein by reference.

Background Art

[0002] Background

[0002] Video encoding systems are widely used to compress digital video signals to reduce the storage requirements and / or transmission bandwidth of such signals. Among various types of video encoding systems, such as block - based systems, wavelet - based systems, and object - based systems, block - based hybrid video encoding systems are widely used and deployed. To perform video encoding, various video encoding techniques can be utilized, for example, history - based motion vector prediction. The expected interaction of video encoding techniques with other encoding tools of video encoding standards may not be utilized. For this reason, the encoding performance of video encoding techniques can be significantly degraded.

Summary of the Invention

[0003] Summary

[0003] A system, method, and apparatus for processing history-based motion vector prediction (HMVP) are disclosed. A video encoding device may generate an HMVP list for a current block. The video encoding device may derive HMVP candidates from previously encoded blocks. The HMVP candidates may include motion information associated with a previously encoded block (e.g., an adjacent block of the current block), one or more reference indices, and a bidirectional prediction weight index. The motion information may include at least one or more motion vectors. The bidirectional prediction weight index may include one or more weight indices associated with an adjacent block. One or more weights may be applied to a prediction signal generated by performing motion compensation prediction of the motion vectors associated with the current block.

[0004]

[0004] The video encoding device may add an HMVP candidate to the HMVP list for motion compensation prediction of the motion vectors associated with the current block. The video encoding device may use an HMVP selected from the HMVP list to perform motion compensation prediction of the current block. The motion compensation prediction may be performed using motion information associated with an adjacent block of the current block, one or more reference indices, and a bidirectional prediction weight index.

[0005]

[0005] The video encoding device can perform pruning by determining whether the HMVP candidate is the same as the HMVP in the current block's HMVP list. If the HMVP candidate is the same as any of the HMVP in the HMVP list, the video encoding device can delete that HMVP from the HMVP list. The video encoding device can add the HMVP candidate to the end of the HMVP list. The video encoding device can move one or more HMVP after the deleted HMVP in the HMVP list forward by only one position. In one example, if the HMVP candidate and the HMVP in the HMVP list have the same motion vector and the same reference index, it can be said that the HMVP candidate is the same as the HMVP in the HMVP list. In one example, if the HMVP candidate and the HMVP in the HMVP list have the same motion vector, the same reference index, and the same generalized bi-directional prediction (GBi) weight or the bi-directional prediction (BCW) weight using the CU-level weight, it can be said that the HMVP candidate is the same as the HMVP in the HMVP list.

[0006]

[0006] If the HMVP candidate is not the same as any of the HMVP in the HMVP list, the video encoding device can delete the oldest HMVP entry in the HMVP list, for example, if the HMVP list is full. The video encoding device can add the HMVP candidate to the end of the HMVP list. The video encoding device can reset the HMVP list when the encoding of a new coding tree unit (CTU) line starts.

Brief Description of the Drawings

[0007] Brief Description of the Drawings

Figure 1

[0007] An exemplary diagram of a block-based video encoder is shown.

Figure 2

[0001] An exemplary block splitting in a multi-type tree structure is shown.

Figure 3

[0008] An exemplary diagram of a block-based video decoder is shown.

Figure 4

[0009] Shows an exemplary history-based motion vector prediction (HMVP) encoding procedure.

Figure 5

[0010] Shows an example of diagonal triangle partition-based motion compensation prediction and an example of inverse diagonal triangle partition-based motion compensation prediction.

Figure 6

[0011] Shows an example of generating a unidirectional prediction motion vector (MV) in, for example, a triangle mode.

Figure 7

[0012] Shows an exemplary flowchart for generating a unidirectional prediction MV list based on one or more merge candidates.

Figure 8A

[0013] Shows an example of adding an HMVP candidate to the HMVP list while considering the GBi weight.

Figure 8B

[0014] Shows an example of adding an HMVP candidate to the HMVP list using a first-in first-out (FIFO) method.

Figure 9

[0015] Shows an example of adding an HMVP candidate to the HMVP list.

Figure 10

[0016] Shows an exemplary flowchart for generating a unidirectional prediction MV list for the triangle mode based on spatial / temporal candidates and HMVP candidates.

Figure 11

[0017] Shows an exemplary flowchart for generating a unidirectional prediction MV list for the triangle mode based on interleaving the spatial / temporal candidates and the unidirectional prediction MVs of the HMVP candidates.

Figure 12A

[0018] Is a system diagram of an exemplary communication system in which one or more disclosed embodiments may be implemented.

Figure 12B

[0019] Is a system diagram of an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 12A.

Figure 12C

[0020] FIG. 12A is a system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown.

Figure 12D

[0021] FIG. 12A is a system diagram of a further exemplary RAN and a further exemplary CN that can be used within the communication system shown.

DETAILED DESCRIPTION OF THE INVENTION

[0008] DETAILED DESCRIPTION

[0022] Here, a detailed description of exemplary embodiments will be given with reference to various drawings. It should be noted that this description shows detailed examples of possible implementations, but the details are intended as examples and in no way limit the scope of the present application.

[0009]

[0023] One or more video encoding devices in a video encoding system can compress a digital video signal to reduce, for example, the storage space and / or transmission bandwidth associated with the storage and / or distribution of such a signal. The video encoding device can be based on a block-based hybrid video encoding framework. A multi-type tree-based block partitioning structure may be adopted. One or more of the encoding modules, for example, an intra prediction module, an inter prediction module, a transform / inverse transform module, and a quantization / inverse quantization module may be included. The video encoding device may include an in-loop filter.

[0010]

[0024] The video encoding device may include one or more encoding tools that can provide higher encoding efficiency and appropriate implementation complexity. The encoding tools include an affine motion model, alternative temporal motion vector prediction (ATMVP), integer motion vector (IMV), generalized bi-prediction (GBi) or bi-prediction with CU-level weights (BCW), bi-directional optical flow (BDOF), combined inter merge / intra prediction, merge with motion vector difference (MMVD), pairwise average merge candidate, triangular inter prediction for inter coding, cross-component linear model (CCLM), multi-line intra prediction, current picture referencing (CPR) for intra prediction, enhanced multiple transform (EMT), dependent quantization for quantization and transform coding, adaptive loop filtering (ALF) for in-loop filtering, and may include one or more of them.

[0011]

[0025] An exemplary block-based video encoding system may include a block-based hybrid video encoding framework. FIG. 1 shows an exemplary block diagram of a block-based hybrid video encoding system. As shown in FIG. 1, an input video signal 1002 may be processed block by block. An extended block size (e.g., called a coding unit or CU) may be used to compress high-resolution (e.g., 1080p and / or over 1080) video signals. The CU may include a size of up to 128×128 pixels. The block may be divided based on a quadtree. One coding tree unit (CTU) may be divided into CUs so as to adapt to various local characteristics based on the quadtree / binary tree / trinary tree. The CU may or may not be divided into a prediction unit or PU to which another prediction may be applied. The CU may be used as a basic unit for prediction and conversion without further division (e.g., may always be used). In a multi-type tree structure, a certain (e.g., one) CTU may be divided by a quadtree structure (e.g., may be divided first). A quadtree leaf node (e.g., each quadtree lead node) may be further divided by a binary tree and a trinary tree structure. As shown in FIG. 2, for example, there may be one or more (e.g., five) division types including quadtree division, horizontal binary tree division, vertical binary tree division, horizontal trinary tree division, and vertical trinary tree division.

[0012]

[0026] Referring to FIG. 1, an input video block (e.g., a macroblock (MB) and / or a coding unit (CU)), spatial prediction 1060 and / or temporal prediction 1062 can be performed. Spatial prediction 1060 (e.g., intra prediction) can predict a current video block using pixels from samples of encoded adjacent blocks (e.g., reference samples) within a video image / slice. Spatial prediction 1060 can reduce spatial redundancy, which may be inherent in a video signal, for example. Motion prediction 1062 (e.g., inter prediction or temporal prediction) can predict a current video block, for example, using reconstructed pixels from an encoded video image. Motion prediction 1062 can reduce temporal redundancy, which may be inherent in a video signal, for example. A motion prediction signal (e.g., a temporal prediction signal) of a video block (e.g., a CU) can be signaled by one or more motion vectors (MVs). An MV can indicate the amount and / or direction of motion between a current block and / or a reference block of the current block or its temporal reference. If multiple reference images are supported for a (e.g., each) video block, a reference image index of the video block can be transmitted by an encoder. The reference image index can be used to identify from which reference image within a reference image store 1064 the motion prediction signal can be derived.

[0013]

[0027] After spatial prediction 1060 and / or motion prediction 1062, the mode determination block 1080 in the encoder may determine a prediction mode (e.g., the best prediction mode), for example, based on rate distortion optimization. The prediction block may be subtracted from the current video block at 1016, and / or the prediction residual may be decorrelated using transformation 1004 and / or quantization 1006 to achieve a bit rate such as a target bit rate. The quantized residual coefficients are inverse quantized at inverse quantization 1010 and / or inverse transformed at transformation 1012 to form, for example, a reconstructed residual, and the reconstructed residual may be added to the prediction block at 1026 to form, for example, a reconstructed video block. A loop filter (e.g., a deblocking filter and / or an adaptive loop filter) may be applied to the reconstructed video block at loop filter 1066 before the reconstructed video block may be placed in the reference picture store 1064 and / or used to encode a video block (e.g., a future video block). To form the output video bit stream 1020, the encoding mode (e.g., inter or intra), prediction mode information, motion information, and / or the quantized residual coefficients are sent (e.g., all sent) to the entropy encoding module 1008, where they may be compressed and / or packed to form a bit stream.

[0014]

[0028] FIG. 3 shows a block diagram of an exemplary block-based video decoding framework for a decoder. Video bitstream 1102 (e.g., video bitstream 1020 of FIG. 1) can be unpacked (and / or entropy decoded) in entropy decoding module 1108. Encoding mode and prediction information can be sent to spatial prediction module 1170 to form prediction blocks (e.g., in the case of intra encoding) and / or to motion compensation prediction module 1172 (e.g., in the case of inter and / or temporal encoding). Residual transform coefficients can be sent to inverse quantization module 1110 and / or inverse transform module 1112, e.g., to reconstruct residual blocks. Prediction blocks and / or residual blocks can be added together at 1126. The reconstructed blocks can pass through loop filter 1176 for in-loop filtering, e.g., before the reconstructed blocks are stored in reference picture store 1174. Reconstructed video 1120 within reference picture store 1174 can be sent to drive a display device and / or can be used to predict video blocks (e.g., future video blocks).

[0015]

[0029] One or more coding modules, e.g., coding modules associated with inter prediction, can be enhanced to improve inter coding efficiency. For example, as described herein, the coding efficiency of history-based motion vector prediction (HMVP) can be improved.

[0016]

[0030] The MV of an inter-coded block can be signaled using one or more mechanisms as described herein. For example, the MV of an inter-coded block can be signaled using the Advanced Motion Vector Prediction (AMVP) mode or the merge mode. In the AMVP mode, the difference between the actual MV and the Motion Vector Predictor (MVP), the reference index, and the MVP index referring to the AMVP candidate list can be signaled. In the merge mode, the merge index referring to the merge candidate list can be signaled. The motion information associated with the merge candidate can be inherited from the signaled merge candidate. The motion information can be derived from spatial blocks adjacent to the CU, for example, for AMVP and merge candidates. For example, the spatial block can be directly adjacent (e.g., neighbor) to a block located at the same position in the current CU or the temporally-referenced picture (e.g., adjacent). One or more merge candidates (e.g., up to six merge candidates) and one or more AMVP candidates (e.g., up to two AMVP candidates) can be added to the candidate list for motion vector prediction.

[0017]

[0031] HMVP can be used to examine the correlation between the MVs of adjacent blocks. For example, HMVP can be used to examine the correlation between adjacent spatially non-adjacent blocks. Although reference is made herein to HMVP utilized by adjacent spatially non-adjacent blocks, it will be understood by those skilled in the art that the adjacent blocks can also include blocks that are adjacent blocks, i.e., proximate blocks.

[0018]

[0032] The HMVP candidates may indicate the motion information of previously encoded CUs. The motion information may include one or more of the MV and the reference picture index. A table of multiple HMVP candidates may be maintained in the encoder and / or decoder. The table of HMVP candidates may be reset (e.g., reset to be empty) when the encoding of a new CTU line starts. After an inter-CU that does not include multiple sub-blocks (e.g., ATMVP and affine-encoded CUs) is encoded, the relevant motion information may be added to an entry (e.g., the last entry in the HMVP candidate table) based on a rule (e.g., a constrained first-in first-out (FIFO) rule). A redundancy check may be applied to identify whether there is an existing HMVP candidate that is the same as the new motion candidate (e.g., before adding the motion candidate to the table or list of HMVP candidates). If an existing HMVP candidate that is the same as the new motion candidate is found, the same HMVP candidate may be deleted from the HMVP candidate table or list, and the HMVP candidate may be moved forward by reducing only one position, e.g., by reducing only one HMVP candidate table index. FIG. 4 shows an exemplary workflow decoding when HMVP is applied to predict the MV. As shown in FIG. 4, at 402, the existing HMVP candidates may be loaded into the list of existing HMVP candidates. At 404, the MV associated with the current block may be decoded from the HMVP candidates. At 406, the HMVP candidate list may be updated based on the decoded MV.

[0019]

[0033] Generalized bi-directional prediction (GBi) or bi-directional prediction using CU-level weights (BCW) may be performed. For example, GBi or BCW may be performed to improve the efficiency of bi-directional prediction when one CU is predicted by two temporal prediction blocks from the reconstructed reference pictures. In the bi-directional prediction mode, the predicted signal at sample x may be calculated as the average of two predicted signals as shown in Equation (1). P[x]=(P0[x+v0]+P1[x+v1]) / 2 (1)

[0020]

[0034] In Equation (1), P[x] can be a predicted signal obtained as a result of sample x placed at image position x, and P1[X+v1] can be a motion-compensated predicted signal of x using motion vector (MV) v1 for the i-th list (e.g., list 0, list 1). GBi can apply various weight values (e.g., w0 and w1) to two predicted signals from list 0 and list 1. One or more configurations of w0 and w1 can imply prediction similarity for uni-directional prediction and bi-directional prediction (e.g., the same prediction as conventional uni-directional prediction and bi-directional prediction). For example, when (w0, w1) is equal to (1, 0) for uni-directional prediction by reference list L0, (0, 1) for uni-directional prediction by reference list L1, and (0.5, 0.5) for conventional bi-directional prediction by two reference lists, prediction similarity can exist for uni-directional prediction and bi-directional prediction. In GBi, the weights applied to the predicted signals from lists L0 and L1 can be signaled for each CU. Constraints can be applied such that the sum of w0 and w1 is 1, e.g., w0 + w1 = 1. The constraints can be applied to reduce signaling overhead. Given such constraints, a single weight may be signaled, and the final bi-directional predicted signal when GBi is applied can be calculated, for example, using Equation (2). P[x]=(1 - w1)*P0[x + v0]+w1*P1[x + v1] (2)

[0021]

[0035] According to (2), w1 can be discretized, for example, using the values {-1 / 4, 1 / 4, 3 / 8, 1 / 2, 5 / 8, 3 / 4, 5 / 4}, whereby each weight value can be represented by an index value within a limited range of small values. The discretization of w1 using a small range can be utilized to reduce signaling overhead. The weight values {1 / 4, 3 / 8, 1 / 2, 5 / 8, 3 / 4} can be applied between images (e.g., between all images), and the weight values {-1 / 4, 5 / 4} can be applied to low-delay images. The weight values can be applied to low-delay images that can be predicted using reference images preceding the current image according to the display order.

[0022]

[0036] Triangle prediction may be performed. In some video content (e.g., natural video content), the boundary between two moving objects may not be horizontal or vertical (e.g., purely horizontal or vertical). Such non-horizontal or non-vertical boundaries may be difficult to accurately approximate with rectangular blocks. Therefore, triangle prediction may be applied, for example, to enable triangle partitioning for motion compensation prediction. As shown in FIG. 5, triangle prediction may divide a CU into one or more (e.g., two) triangle prediction units, for example, in a diagonal direction (502) or an anti-diagonal direction (504). The triangle prediction unit of the CU (e.g., each triangle prediction unit) may be inter-predicted using its unidirectional prediction motion vector and reference frame index. The unidirectional prediction motion vector and reference frame index may be derived from a unidirectional prediction candidate list.

[0023]

[0037] The unidirectional prediction candidate list may include one or more (e.g., five) unidirectional prediction motion vector candidates. The unidirectional prediction motion vector candidates may be derived from spatially / temporally adjacent blocks similar to (e.g., the same as) those used in a merge process (e.g., the merge process of HEVC). The unidirectional prediction MV candidates may be derived from five spatially adjacent blocks and two temporally co-located blocks as shown in FIG. 6. Referring to FIG. 6, the motion vectors of the seven adjacent blocks may be collected, for example, in the order of the L0 motion vector of the adjacent block, the L1 motion vector of the adjacent block, and the average motion vector of the L0 motion vector and the L1 motion vector of the adjacent block when the adjacent block is bi-directionally predicted, and stored in the unidirectional prediction MV candidate list. If the number of MV candidates is less than five, zero (0) motion vectors may be added to the MV candidate list.

[0024]

[0038] FIG. 7 shows a flowchart for adding a unidirectional prediction MV of a merge candidate to a unidirectional prediction MV list of a CU encoded in a triangular prediction mode. At 702, the video encoding device may determine whether the merge candidate includes an L0MV. If it does, at 704, the video encoding device may add the L0MV associated with the merge candidate to the unidirectional prediction MV list. At 708, the video encoding device may check whether the spatial / temporal candidate is at the end of the list. At 710, the video encoding device may determine whether the merge candidate includes an L1MV. If it does, at 712, the video encoding device may add the L1MV associated with the merge candidate to the unidirectional prediction MV list. At 714, the video encoding device may check whether the spatial / temporal candidate is at the end of the list. At 7, the video encoding device may determine whether the merge candidate includes an L0MV and an L1MV. If it does, at 718, the video encoding device may add the average of the L0MV and the L1MV associated with the merge candidate to the unidirectional prediction MV list. At 720, the video encoding device may check whether the spatial / temporal candidate is at the end of the list.

[0025]

[0039] The order of one or more adjacent blocks (e.g., the order in which candidate blocks may be checked and considered for addition to the candidate list) may include one or more spatially adjacent blocks (e.g., 1 to 5) followed by one or more blocks at the same temporal position (6 to 7). Referring to FIG. 6, the motion vectors of seven adjacent blocks (e.g., A1, A0, B0, B1, B2, T0, T1) may be collected in the order of a unidirectional prediction motion vector, an L0 motion vector of a bidirectional prediction motion vector, an L1 motion vector of a bidirectional prediction motion vector, and an average motion vector of the L0 motion vector and the L1 motion vector of the bidirectional prediction motion vector, and may be stored in a unidirectional prediction candidate list. If the number of candidates is less than 5, zero motion vectors may be added to the list.

[0026]

[0040] The HMVP symbolization gain can be improved, for example, by extending the application of HMVP to other coding tools such as generalized bidirectional prediction and / or triangular inter prediction. HMVP can be used to determine the MV correlation relationship between adjacent blocks. For example, HMVP can be used to determine the MV correlation relationship between adjacent blocks that are not spatially adjacent. In this specification, reference is made to HMVP utilized to determine the MV correlation relationship between adjacent blocks that are not spatially adjacent, but those skilled in the art will understand that the adjacent blocks may include blocks that are adjacent blocks. HMVP can be utilized to determine the MV correlation relationship by maintaining a table of one or more MV candidates. The table can be maintained in an encoding device and / or a decoding device. The HMVP candidate can be defined based on motion information including one or more of a motion vector (e.g., one or more motion vectors), a reference list (e.g., one or more reference lists), or a reference picture index (e.g., one or more reference picture indexes) associated with a previously encoded block.

[0027]

[0041] In one example, the HMVP candidate can be used to derive the prediction signal of a CU with GBi disabled. In such a case, equal weights can be applied to the two prediction signals associated with list 0 and list 1.

[0028]

[0042] In one example, HMVP and GBi can be enabled, for example, by associating GBi with an HMVP index. GBi can be enabled by associating at least one GBi index with each of the HMVP entry or HMVP index. As a result, the coding efficiency of HMVP can be improved. The GBi index can also be referred to as a bidirectional prediction weight index.

[0029]

[0043] In one example, for each HMVP candidate, in addition to the motion information, at least one GBi index can be created based on one or more of the following. When the HMVP candidate is derived from an inter CU for which the GBi weight is signaled, the GBi weight of the HMVP candidate can be set to the signaled GBi weight. When the HMVP candidate is derived from a spatial merge candidate, the GBi weight of the HMVP candidate can be set to the GBi weight of the spatial candidate. When the HMVP candidate is derived from a temporal merge candidate, the GBi weight of the HMVP candidate can be set to the GBi weight of the block at the same position in the image at the temporally same position. When the HMVP candidate is derived from an average merge candidate, the GBi weight of the HMVP candidate can be set to a certain fixed value (e.g., 0.5).

[0030]

[0044] As described herein, pruning can be performed at one or more different stages of the HMVP processing procedure. For example, pruning can be performed to remove redundant entries in the HMVP list when adding an MV candidate or an HMVP candidate to the HMVP list. In one example, pruning can be performed after determining whether an entry in the HMVP list is the same as an MV candidate or an HMVP candidate. If the same candidate in the HMVP list is found, the same HMVP is removed from the HMVP list. In one example, an HMVP candidate can be said to be the same as an HMVP entry in the HMVP list if the motion information associated with the HMVP candidate is similar to the motion information associated with the HMVP entry in the HMVP list. The motion information to be compared can include one or more of a motion vector (e.g., one or more motion vectors), a reference list (e.g., one or more reference indices), and a reference image index (e.g., one or more reference image indices).

[0031]

[0045] In one example, when determining whether to add an HMVP candidate to the HMVP candidate list in addition to the motion vector information, the GBi weight can be considered. FIG. 8A shows an example of considering the GBi weight when adding an HMVP candidate to the HMVP candidate list. As shown in FIG. 8A, for the second entry of the HMVP list and the new HMVP candidate to be added to the HMVP list, when the motion information and GBi weight of the second entry of the existing HMVP list (e.g., HMVP1) are the same as those of the new HMVP candidate (e.g., C l-1 ), they can be treated as the same. In such an example, before adding the HMVP candidate C l-1 to the end of the HMVP list, the matched HMVP entry HMVP1 in the HMVP list can be deleted from the list, and the subsequent HMVP entries (e.g., from HMVP2 to HMVP l-1 ) can be moved forward as indicated by the arrow. This can be achieved, for example, by reducing each index by one only.

[0032]

[0046] FIG. 8B shows an example where an HMVP candidate can be treated as not being the same as an entry in the HMVP list. As shown in FIG. 8B, even if the motion information of HMVP1 and C l-1 is the same, since their respective GBi weights are not equal, HMVP1 and C l-1 are said to be not the same. A FIFO process (e.g., the default FIFO process) can be applied. As shown in FIG. 8B, the FIFO procedure includes deleting the first HMVP candidate (e.g., HMVP0) from the table, moving the position of each entry by one only to create an empty position at the end of the HMVP list as indicated by the arrow in FIG. 8B, and adding the new candidate C l-1 to the empty position at the end of the HMVP list.

[0033]

[0047] (For example, which can be respectively associated with each GBi weight) The HMVP candidates can be used as candidates for the merge mode and / or the AMVP mode. The HMVP candidates (for example, all HMVP candidates from the last entry to the first entry of the HMVP table) can be inserted, for example, after the TMVP candidates. When HMVP is applied to the merge mode, pruning can be applied to remove candidates having similar (for example, the same) motion information and similar (for example, the same) GBi weights.

[0034]

[0048] The GBi index can be used for motion compensation prediction and the HMVP pruning process. The motion compensation prediction and the HMVP pruning process can increase the coding gain and increase the complexity of the pruning process. When the motion information and GBi weights of the HMVP candidates (for example, each HMVP candidate in the list) are checked, the complexity of the HMVP pruning process can increase. In one example, the respective GBi weights of the HMVP candidates (for example, all HMVP candidates) can be utilized for motion compensation prediction. A subset of the HMVP candidates can be utilized for the HMVP pruning process. As described herein, the HMVP candidates can be associated with the GBi index (for example, each HMVP candidate can be associated with one GBi index). The associated GBi weights can be utilized to generate the prediction signal of the CU (for example, rather than determining whether two HMVP candidates are the same).

[0035]

[0049] FIG. 9 shows an example of adding HMVP candidates to the HMVP candidate list, where the GBi weight is not considered when adding HMVP candidates to the HMVP list. In the example presented in FIG. 9, the GBi index of the second entry of the existing HMVP list (for example, HMVP1) and the new HMVP candidate (for example, C l-1 ) is not the same, but the motion information of the second entry of the existing HMVP list (for example, HMVP1) and the new HMVP candidate (for example, C l-1 ) is the same. In this example, the second entry of the existing HMVP list (for example, HMVP1) and the new HMVP candidate (for example, C l-1) has the same motion information as, and the GBi index of the second entry (e.g., HMVP1) in the existing HMVP list is not the same as that of the new HMVP candidate (e.g., C l-1 ), the second entry in the HMVP list and the new HMVP candidate can be treated as the same. As shown in FIG. 9, HMVP1 can be deleted from the HMVP candidate list, and subsequent HMVP candidates (e.g., from HMVP2 to HMVP l-1 ) can be moved forward with their indices decreased by one, for example, as indicated by the arrow. Then, C l-1 can be added to the end of the HMVP list.

[0036]

[0050] Triangle inter prediction may be performed by HMVP. In triangle inter prediction, the MVs in the unidirectional prediction candidate list can be derived from those that are temporally and spatially adjacent. For example, the conventional temporally and spatially adjacent ones can be the adjacent ones used in the merge mode of HEVC. For example, triangle inter prediction can derive the MVs in the unidirectional prediction candidate list from five spatially adjacent ones and two temporally adjacent ones, as shown in FIG. 6. In one example, the derivation of the MVs may not consider the correlation between the MVs of blocks that are not directly spatially adjacent (e.g., non-adjacent blocks). In such a case, the derivation of the MVs may not generate accurate unidirectional prediction MV candidates (e.g., the most accurate unidirectional prediction MV candidates) for capturing the true motion of the two triangle partitions. In one example, the motion information of adjacent blocks along the occlusion boundary may not be correlated (e.g., due to occlusion of an object, which may commonly exist in content such as natural video content). When the motion information of adjacent blocks along the occlusion boundary is not correlated, the MVs from spatially adjacent ones on the occlusion boundary may not be accurate (e.g., not accurate enough) to function as the MV predictor for the current CU. This can reduce the efficiency of inter coding. In one example, HMVP candidates (e.g., separate from the existing temporal and spatial MV candidates) can be used to derive the unidirectional prediction MV candidate list for the triangle prediction mode to examine the correlation between the MVs of one or more adjacent blocks (e.g., blocks that are not spatially close).

[0037]

[0051] The unidirectional prediction MVs of the HMVP candidates can be placed at different positions in the candidate list (e.g., the final candidate list) of the unidirectional prediction MVs in the triangular mode. In one example, the unidirectional prediction MVs associated with one or more HMVP candidates are checked and can be inserted after the spatial and / or temporal candidates in the list. The MVs associated with the HMVP candidates are checked (e.g., check whether the MVs of the HMVP candidates are the same as the MVs in the unidirectional prediction MV list) and can be inserted into the unidirectional prediction candidate list (e.g., after the spatial and temporal candidates). The MVs of the candidate blocks can be collected in the order of five spatially adjacent ones (e.g., A1, A0, B1, B0, and B2), two temporally adjacent ones (e.g., T0 and T1), and N HMVP candidates, as shown in FIG. 6.

[0038]

[0052] The unidirectional prediction MVs used in the triangular mode can be generated as described herein. In one example, the unidirectional prediction MVs used in the triangular mode can be generated by adding the L0MVs associated with one or more of the spatial / temporal candidates and HMVP candidates. In one example, the unidirectional prediction MVs used in the triangular mode can be generated by adding the L1MVs associated with one or more of the spatial / temporal candidates and HMVP candidates. In one example, when the HMVP candidates are bidirectionally predicted, the unidirectional prediction MVs used in the triangular mode can be generated by adding the average of the L0MV and L1MV of the spatial / temporal candidates and HMVP candidates.

[0039]

[0053] Figure 10 shows an example associated with inserting a unidirectional prediction MV of a merge candidate into the unidirectional prediction MV list of triangle CU. As shown in Figure 10, at 1030, the video encoding device may determine whether a candidate (e.g., the i-th merge candidate) includes L0MV. If it does, at 1032, the video encoding device may add the L0MV associated with the candidate to the unidirectional prediction MV list. At 1034, the video encoding device may check whether the spatial / temporal candidate or the HMVP candidate is the last in the list. At 1036, the video encoding device may determine whether the candidate includes L1MV. If it does, at 1038, the video encoding device may add the L1MV of the candidate to the unidirectional prediction MV list. At 1040, the video encoding device may check whether the spatial / temporal candidate or the HMVP candidate is the last in the list. At 1042, the video encoding device may determine whether the candidate includes L0MV and L1MV. If it does, at 1044, the video encoding device may add the average of the L0MV and L1MV of the candidate to the unidirectional prediction MV list. At 1046, the video encoding device may check whether the spatial / temporal candidate or the HMVP candidate is the last in the list.

[0040]

[0054] The motions (e.g., motion information) of spatially and temporally adjacent ones can be correlated with the motion (e.g., motion information) of the current CU, which is more correlated (e.g., than the motion of the HMVP candidate). The unidirectional prediction MVs of the spatial and temporal candidates may be given a higher priority than the unidirectional prediction MVs of the HMVP candidates (e.g., to reduce the overhead when signaling the MVs of the candidates). In the example, the unidirectional prediction MVs of the spatial / temporal candidates may be interleaved with the unidirectional prediction MVs of the HMVP candidates.

[0041]

[0055] A unidirectional prediction MV list (e.g., the final unidirectional prediction MV list) of a triangular CU may be generated. In one example, the unidirectional prediction MV list of a triangular CU may be generated by inserting the L0MV of each spatial / temporal candidate into the unidirectional prediction MV list. In one example, the unidirectional prediction MV list of a triangular CU may be generated by inserting the L1MV of each spatial / temporal candidate into the unidirectional prediction MV list. In one example, the unidirectional prediction MV list of a triangular CU may be generated by inserting the L0MV of each HMVP candidate into the unidirectional prediction MV list. In one example, the unidirectional prediction MV list of a triangular CU may be generated by inserting the L1MV of each HMVP candidate into the unidirectional prediction MV list.

[0042]

[0056] In one example, the unidirectional prediction MV list of a triangular CU may be generated by inserting the average of the L0MV and L1MV of a spatial / temporal candidate (e.g., each spatial / temporal candidate if the candidate is bi-directionally predicted) into the unidirectional prediction MV list. In one example, the unidirectional prediction MV list of a triangular CU may be generated by inserting the average of the L0MV and L1MV of an HMVP candidate (e.g., each HMVP candidate if the candidate is bi-directionally predicted) into the unidirectional prediction MV list.

[0043]

[0057] FIG. 11 shows an example of generating a unidirectional prediction MV list in a triangle mode when the spatial / temporal candidates and the unidirectional prediction MVs of the HMVP candidates are interleaved. As shown in FIG. 11, at 1130, the video encoding device may determine whether a candidate (e.g., the i-th merge candidate) includes an L0MV. If it does, at 1132, the video encoding device adds the L0MV associated with the candidate to the unidirectional prediction MV list. At 1134, the video encoding device may check whether the spatial / temporal candidate is the last in the list. At 1136, the video encoding device may determine whether the candidate includes an L1MV. If it does, at 1138, the video encoding device may add the L1MV associated with the candidate to the unidirectional prediction MV list. At 1140, the video encoding device may check whether the spatial / temporal candidate is the last in the list. At 1142, the video encoding device may determine whether the candidate includes an L0MV. If it does, at 1144, the video encoding device may add the L1MV associated with the candidate to the unidirectional prediction MV list. At 1146, the video encoding device may check whether the HMVP candidate is the last in the list. At 1148, the video encoding device may determine whether the candidate includes an L1MV. If it does, at 1150, the video encoding device may add the L1MV associated with the candidate to the unidirectional prediction MV list. At 1152, the video encoding device may check whether the HMVP candidate is the last in the list. At 1154, the video encoding device may determine whether the candidate includes an L0MV and an L1MV. If it does, at 1156, the video encoding device may add the average of the L0MV and the L1MV associated with the candidate to the unidirectional prediction MV list. At 1158, the video encoding device may check whether the spatial / temporal candidate is the last in the list. At 1160, the video encoding device may determine whether the candidate includes an L0MV and an L1MV. If it does, at 1162, the video encoding device may add the average of the L0MV and the L1MV associated with the candidate to the unidirectional prediction MV list. At 1164, the video encoding device may check whether the HMVP candidate is the last in the list.

[0044]

[0058] FIG. 12A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. For example, one or more of the features associated with a video encoding device as described herein may be included in one or more of WTRUs 102a, 102b, 102c, and 102d of communication system 100. Communication system 100 can be a multi-connection system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. Communication system 100 can enable a plurality of wireless users to access such content through sharing of system resources including radio bandwidth. For example, communication system 100 can utilize one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), and single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0045]

[0059] As shown in FIG. 12A, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may also be referred to as either a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may be a user equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular telephone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, wristwatch or other wearable, head-mounted display (HMD), vehicle, drone, medical device and application (e.g., remote surgery), industrial device and application (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics device, device operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may alternatively be referred to as a UE.

[0046]

[0060] The communication system 100 can also include base station 114a and / or base station 114b. Each of base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN106 / 115, the Internet 110, and / or other network 112. By way of example, base stations 114a, 114b can be a base transceiver station (BTS), Node-B, eNodeB, home NodeB, home eNodeB, gNB, NR NodeB, a site controller, an access point (AP), and a wireless router, among others. Although base stations 114a, 114b are each shown as a single element, it will be understood that base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0047]

[0061] The base station 114a can be part of the RAN 104 / 113, and the RAN 104 / 113 can also include other base stations and / or network elements (not shown) such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies, sometimes called a cell (not shown). These frequencies can be in an authorized spectrum, an unauthorized spectrum, or a combination of an authorized spectrum and an unauthorized spectrum. A cell can provide wireless service coverage to a specific geographic area that may be relatively fixed or may change over time. A cell can be further divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one for each sector of the cell. In one embodiment, the base station 114a can utilize multiple-input multiple-output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0048]

[0062] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via a wireless interface 116, and the wireless interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The wireless interface 116 can be established using any suitable radio access technology (RAT).

[0049]

[0063] More specifically, as described above, the communication system 100 can be a multi-connection system and can utilize one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a within RAN104 / 113 and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish radio interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0050]

[0064] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS Terrestrial Radio Access (E-UTRA) that can establish radio interface 116 using Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0051]

[0065] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access that can establish radio interface 116 using New Radio (NR).

[0052]

[0066] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for example, using the principle of dual connectivity (DC). Thus, the radio interfaces utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions that are transmitted and received between multiple types of base stations (e.g., eNBs and gNBs).

[0053]

[0067] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM) in Europe, Enhanced Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0054]

[0068] The base station 114b in Fig. 12A can be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and can utilize any suitable RAT for facilitating wireless connections in local areas such as workplaces, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in Fig. 12A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0055]

[0069] RAN 104 / 113 can communicate with CN 106 / 115, and CN 106 / 115 can be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, Internet connections, video distribution, etc., and / or can perform high-level security functions such as user authentication. Although not shown in FIG. 12A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that utilize the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to connecting to RAN 104 / 113 that may utilize New Radio (NR) radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0056]

[0070] CN106 / 115 can also act as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides basic telephone service (POTS). The Internet 110 can include a global system composed of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) within the TCP / IP Internet protocol suite. The network 112 can include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 can include another CN connected to one or more RANs that may utilize the same or a different RAT as the RAN104 / 113.

[0057]

[0071] Some or all of the WTRU102a, 102b, 102c, 102d within the communication system 100 can include multimode functionality (e.g., the WTRU102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in FIG. 12A can be configured to communicate with a base station 114a that may utilize cellular-based wireless technology and with a base station 114b that may utilize IEEE802 wireless technology.

[0058]

[0072] Figure 12B is a system diagram showing an exemplary WTRU 102. As shown in Figure 12B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 can include any sub-combination of the above elements while maintaining consistency with the embodiments.

[0059]

[0073] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors cooperating with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 12B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0060]

[0074] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the radio interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0061]

[0075] In Figure 12B, the transmit / receive element 122 is shown as a single element, but the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the radio interface 116.

[0062]

[0076] The transceiver 120 can be configured to modulate signals transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 can have a multimode function. Thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

[0063]

[0077] The processor 118 of the WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can obtain information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 can include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 can access information from and store data in a memory located, for example, on a server or a home computer (not shown) instead of a memory physically disposed on the WTRU 102.

[0064]

[0078] The processor 118 can receive power from a power supply 134 and can be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 can include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, and a fuel cell, among others.

[0065]

[0079] Processor 118 can also be coupled to a GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 can receive location information from a base station (e.g., base stations 114a, 114b) via the radio interface 116, and / or can determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 can obtain location information using any suitable positioning method while maintaining consistency with the embodiments.

[0066]

[0080] Processor 118 can further be coupled to other peripheral devices 138, which can include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, and an activity tracker, among others. The peripheral devices 138 can include one or more sensors, which can be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0067]

[0081] The WTRU 102 can include a full-duplex radio in which some or all of the transmission and reception of signals associated with a particular subframe (e.g., for both UL (e.g., for transmission) and downlink (e.g., for reception)) can occur in parallel and / or simultaneously. The full-duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference via either hardware (such as a choke) or signal processing by a processor (e.g., via another processor (not shown) or processor 118). In one embodiment, the WTRU 102 can include a half-duplex radio for some or all of the transmission and reception of signals associated with a particular subframe (e.g., either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0068]

[0082] Figure 12C is a system diagram showing the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may employ the E-UTRA radio technology to communicate with the WTRU 102a, 102b, 102c via the radio interface 116. Also, the RAN 104 may communicate with the CN 106.

[0069]

[0083] The RAN 104 may include eNode-Bs 160a, 160b, 160c, but it should be understood that the RAN 104 may include any number of eNode-Bs while maintaining consistency with the embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the radio interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit a radio signal to the WTRU 102a and / or receive a radio signal from the WTRU 102a.

[0070]

[0084] Each of eNode-Bs 160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle decisions on radio resource management, handover decisions, user scheduling in UL and / or DL, etc. As shown in FIG. 12C, eNode-Bs 160a, 160b, and 160c may communicate with each other via the X2 interface.

[0071]

[0085] CN106 shown in FIG. 12C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the above elements is depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0072]

[0086] MME162 may be connected to each of eNode-Bs 162a, 162b, and 162c of RAN104 via the S1 interface and may function as a control node. For example, MME162 may be involved in user authentication of WTRUs 102a, 102b, 102c, activation / deactivation of bearers, selection of a specific serving gateway at the initial attach of WTRUs 102a, 102b, 102c, etc. MME162 may provide control plane functions for switching between RAN104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0073]

[0087] SGW164 can be connected to each of the eNode-Bs 162a, 160b, and 160c of RAN104 via the S1 interface. SGW164 can generally route and transfer user data packets between the WTRUs 102a, 102b, and 102c. SGW164 can perform other functions such as anchoring the user plane during handover between eNode-Bs, triggering paging when DL data is available at the WTRUs 102a, 102b, and 102c, and managing and storing the contexts of the WTRUs 102a, 102b, and 102c.

[0074]

[0088] SGW164 can be connected to a PGW166 that can provide the WTRUs 102a, 102b, and 102c access to a packet switched network such as the Internet 110 in order to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0075]

[0089] CN106 can facilitate communication with other networks. For example, CN106 can provide the WTRUs 102a, 102b, and 102c access to a circuit switched network such as the PSTN 108 in order to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional fixed telephone communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and the PSTN 108. Additionally, CN106 can provide the WTRUs 102a, 102b, and 102c access to other networks 112 that may include other wired and / or wireless networks owned and / or operated by other service providers.

[0076]

[0090] In FIGS. 12A - 12D, the WTRU is described as a wireless terminal, but in certain representative embodiments, it is contemplated that such a terminal can use a wired communication interface to the communication network (e.g., temporarily or permanently).

[0077]

[0091] In a representative embodiment, the other network 112 can be a WLAN.

[0078]

[0092] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to another type of wired / wireless network that carries traffic between the distribution system (DS) or the BSS. Traffic arriving from outside the BSS to an STA can arrive via the AP and be delivered to the STA. Traffic arriving from an STA and destined outside the BSS can be sent to the AP to be delivered to their respective destinations. Traffic between STAs within the BSS can be sent via the AP. For example, the source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or called peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly between the source STA and the destination STA) using a direct link setup (DLS). In certain representative embodiments, the DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode does not have an AP, and STAs within or using the IBSS (e.g., all STAs) can communicate directly with each other. In this specification, the communication mode of the IBSS may be referred to as the "ad hoc" communication mode.

[0079]

[0093] When using the operating mode of the 802.11ac infrastructure or a similar operating mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth), or may have a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, the Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) method may be implemented. In CSMA / CA, STAs including the AP (e.g., all STAs) can sense the primary channel. If a particular STA detects / determines that the primary channel is busy, the particular STA may yield. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0080]

[0094] A High Throughput (HT) STA may use a 40 MHz bandwidth channel for communication, for example, via a combination of a primary 20 MHz channel and a 20 MHz channel that is adjacent or non - adjacent to form a 40 MHz bandwidth channel.

[0081]

[0095] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels, which is sometimes called the 80 + 80 configuration. In the 80 + 80 configuration, the data after channel encoding can be passed through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time - domain processing can be performed separately for each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above - mentioned 80 + 80 configuration can be performed in reverse, and the combined data can be transmitted to the Media Access Control (MAC).

[0082]

[0096] Sub - 1 GHz operation modes are supported by 802.11af and 802.11ah. In 802.11af and 802.11ah, the channel operating bandwidth and carriers are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS), and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using frequency bands other than the TVWS. According to an exemplary embodiment, 802.11ah can support meter - type control / machine - type communication such as MTC devices in a macro - coverage area. MTC devices can have limited capabilities including certain and / or limited bandwidth support (e.g., support only for that). MTC devices can include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0083]

[0097] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by the STA that supports the minimum bandwidth operating mode among all STAs when operating in the BSS. In the example of 802.11ah, even when the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel can be 1MHz wide for an STA (e.g., an MTC type device) that supports the 1MHz mode (e.g., supports only that). Carrier sensing and / or setting of the Network Allocation Vector (NAV) can depend on the status of the primary channel. For example, if the primary channel is busy due to an STA (supporting only the 1MHz operating mode), it can be considered busy for the AP to transmit over the entire available frequency band, even if most of the frequency band remains idle and available.

[0084]

[0098] In the United States, the available frequency band that can be used by 802.11ah is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. The total available bandwidth in 802.11ah is from 6MHz to 26MHz depending on the country code.

[0085]

[0099] FIG. 12D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, 102c via wireless interface 116. Also, RAN113 can communicate with CN115.

[0086]

[0100] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while maintaining consistency with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via radio interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit wireless signals to WTRU 102a and / or receive wireless signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0087]

[0101] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary according to different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including a varying number of OFDM symbols and / or lasting for various lengths of absolute time).

[0088]

[0102] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, the WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c, etc.). In a stand-alone configuration, the WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, the WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, the WTRUs 102a, 102b, and 102c may communicate with / connect to gNBs 180a, 180b, and 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, and 160c. For example, the WTRUs 102a, 102b, and 102c may implement a DC principle to communicate with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, the eNode-Bs 160a, 160b, and 160c may function as a mobility anchor for the WTRUs 102a, 102b, and 102c, and the gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for servicing the WTRUs 102a, 102b, and 102c.

[0089]

[0103] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle decisions for radio resource management, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interconnection between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 12D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0090]

[0104] CN115 shown in FIG. 12D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the above elements is depicted as part of CN115, it should be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0091]

[0105] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b can authenticate users of WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), select specific SMF183a and 183b, manage the registration area, terminate NAS signaling, and be involved in mobility management, etc. Network slicing can be used by AMF182a and 182b to customize the support of the CN for WTRU102a, 102b, and 102c based on the type of service utilized by WTRU102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and / or services for machine-type communication (MTC) access. AMF162 can provide control plane functions for switching between RAN113 and other RANs (not shown) adopting other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0092]

[0106] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure traffic routing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating the UE's IP address, managing the PDU session, enforcing policies and controlling QoS, and providing notifications for downlink data. The type of PDU session can be IP-based, non-IP-based, Ethernet-based, etc.

[0093]

[0107] UPF184a and 184b can be connected to one or more of gNB180a, 180b, 180c in RAN113 via an N3 interface that can provide WTRU102a, 102b, 102c with access to a packet switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and an IP - compatible device. UPF184, 184b can perform other functions such as routing and forwarding packets, enforcing user - plane policies, supporting multi - home PDU sessions, handling user - plane QoS, buffering downlink packets, and providing mobility anchoring.

[0094]

[0108] CN115 can facilitate communication with other networks. For example, CN115 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and the PSTN108. Additionally, CN115 can provide WTRU102a, 102b, 102c with access to another network 112 that can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c can be connected to local data networks (DN) 185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0095]

[0109] In view of FIGS. 12A-12D and the corresponding descriptions of FIGS. 12A-12D, one or more of the functions described herein with respect to one or more of WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0096]

[0110] An emulation device may be designed to perform one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may be fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network and may perform one or more or all of the functions. One or more emulation devices may be temporarily implemented / deployed as part of a wired and / or wireless communication network and may perform one or more or all of the functions. An emulation device may be directly coupled to another device for testing purposes and / or may perform tests using wireless communication.

[0097]

[0111] One or more emulation devices may perform one or all of a plurality of functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be utilized in a test scenario in a test lab and / or in a wired and / or wireless communication network that is not deployed (e.g., is being tested) to perform tests on one or more components. One or more emulation devices may be test equipment. Wireless communication via direct RF coupling and / or an RF circuit (which may include one or more antennas) may be used by an emulation device to transmit and / or receive data.

[0098]

[0112] The processes and techniques described herein may be implemented in a computer program, software, and / or firmware incorporated within a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROM disks and / or digital versatile disks (DVDs), among others. A processor working in conjunction with software may be used to implement a radio transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. At least, generate a history-based motion vector prediction (HMVP) list for the current block, derive an HMVP candidate from a previously encoded block, the HMVP candidate including motion information associated with an adjacent block of the current block, one or more reference indices, and a bidirectional prediction weight index, add the HMVP candidate to the HMVP list for motion compensation prediction of the motion vector associated with the current block, use one HMVP selected from the HMVP list to perform motion compensation prediction for the current block, the motion compensation prediction being performed using the motion information associated with the adjacent block of the current block, the one or more reference indices, and the bidirectional prediction weight index A processor configured as A video encoding device comprising.

2. The processor is determine whether the HMVP candidate is the same as the HMVP in the HMVP list of the current block, delete the HMVP from the HMVP list on the condition that the HMVP candidate is the same as any HMVP in the HMVP list, and add the HMVP candidate to the end of the HMVP list, delete the oldest HMVP entry in the HMVP list and add the HMVP candidate to the end of the HMVP list if the HMVP list is full on the condition that the HMVP candidate is not the same as any HMVP in the HMVP list The video encoding device according to claim 1, further configured as.

3. The video encoding device according to claim 2, wherein the adjacent blocks are non-spatially adjacent blocks.

4. The video encoding device according to claim 2, wherein when the HMVP candidate is the same as the HMVP in the HMVP list, move one or more HMVP after the deleted HMVP in the HMVP list forward by only one position.

5. The video encoding device according to claim 2, wherein when the HMVP candidate and the HMVP in the HMVP list have the same motion vector and the same reference index, the HMVP candidate is the same as the HMVP in the HMVP list.

6. The video encoding device according to claim 2, wherein when the HMVP candidate and the HMVP in the HMVP list have the same motion vector, the same reference index, and the same bidirectional prediction weight index, the HMVP candidate is the same as the HMVP in the HMVP list.

7. The video encoding device according to claim 1, wherein the motion information includes at least one or a plurality of motion vectors.

8. The video encoding device according to claim 1, wherein the bidirectional prediction weight index includes one or a plurality of weight indexes associated with the adjacent blocks.

9. The video encoding device according to claim 8, wherein one or a plurality of weights based on the one or a plurality of weight indexes are applied to a prediction signal generated by performing motion compensation prediction of the current block.

10. The video encoding device according to claim 1, wherein the processor is further configured to reset the HMVP list when encoding of a new coding tree unit (CTU) line is started.

11. Generating a history-based motion vector prediction (HMVP) list for the current block; Deriving an HMVP candidate from a previously encoded block, the HMVP candidate including motion information associated with an adjacent block of the current block, one or a plurality of reference indexes, and a bidirectional prediction weight index; Adding the HMVP candidate to the HMVP list for motion compensation prediction of the motion vector associated with the current block; Using one HMVP selected from the HMVP list to perform motion compensation prediction of the current block, the motion compensation prediction being performed using the motion information associated with the adjacent block of the current block, the one or a plurality of reference indexes, and the bidirectional prediction weight index; A video encoding method comprising the above.

12. Determining whether the HMVP candidate is the same as the HMVP in the HMVP list of the current block; Deleting the HMVP from the HMVP list and adding the HMVP candidate to the end of the HMVP list on the condition that the HMVP candidate is the same as any HMVP in the HMVP list; Under the condition that the HMVP candidate is not the same as any of the HMVP in the HMVP list, when the HMVP list is full, delete the oldest HMVP entry in the HMVP list and add the HMVP candidate to the end of the HMVP list The method according to claim 11, comprising:

13. The method according to claim 11, wherein the adjacent blocks are non-spatially adjacent blocks.

14. The method according to claim 12, wherein when the HMVP candidate is the same as the HMVP in the HMVP list, move one or more HMVP after the deleted HMVP in the HMVP list forward by one position.

15. The method according to claim 12, wherein when the HMVP candidate and the HMVP in the HMVP list have the same motion vector and the same reference index, the HMVP candidate is the same as the HMVP in the HMVP list.

16. The method according to claim 12, wherein when the HMVP candidate and the HMVP in the HMVP list have the same motion vector, the same reference index, and the same bidirectional prediction weight index, the HMVP candidate is the same as the HMVP in the HMVP list.

17. The method according to claim 11, wherein the motion information includes at least one or more motion vectors.

18. The method according to claim 11, wherein the bidirectional prediction weight index includes one or more weight indexes associated with the adjacent blocks.

19. The method according to claim 18, wherein one or more weights based on the one or more weight indexes are applied to the prediction signal generated by performing motion compensation prediction of the current block.

20. The method according to claim 11, comprising resetting the HMVP list when encoding of a new coding tree unit (CTU) line is started.

Images