Device and method for video decoding and video encoding

Abstract

Systems, methods, and means for processing history-based motion vector prediction (HMVP) are disclosed. A video coding apparatus generates a list of history-based motion vector predictions (HMVPs) for a current block. The video coding apparatus derives HMVP candidates from previously coded blocks. The HMVP candidates may include motion information associated with neighboring blocks of the current block, one or more reference indices, and a dual prediction weight index. The video coding apparatus can add the HMVP candidate to the HMVP list for motion compensation prediction of motion vectors associated with the current block. The video coding apparatus uses an HMVP selected from the HMVP list to perform motion compensation prediction for the current block. The motion compensation prediction can be performed using the motion information associated with the neighboring blocks of the current block, the one or more reference indices, and the dual prediction weight index.

Description

Technical Field

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

[0002] Video coding systems are widely used to compress digital video signals to reduce storage requirements and / or transmission bandwidth. Among various types of video coding systems (e.g., block-based, wavelet-based, and object-based systems), block-based hybrid video coding systems are widely used and deployed. Video coding can be performed using various video coding techniques, including, for example, history-based motion vector prediction. Potential interactions between this video coding technique and other coding tools in video coding standards may not be utilized. This could lead to a significant degrade in coding performance of the video coding technique. Summary of the Invention

[0003] Systems, methods, and means for processing history-based motion vector prediction (HMVP) are disclosed. A video coding apparatus can generate an HMVP list for the current block. The video coding apparatus can derive HMVP candidates from previously coded blocks. The HMVP candidates may include motion information associated with previously coded blocks (e.g., neighboring blocks of the current block), one or more reference indices, and bi-prediction weight indices. The motion information may include at least one or more motion vectors. The bi-prediction weight indices may include one or more weight indices associated with the neighboring blocks. One or more weights may be applied to the prediction signal generated by performing motion compensation prediction on the current block.

[0004] The video coding device can add the HMVP candidate to the HMVP list for motion compensation prediction of the motion vector associated with the current block. The video coding device can use the HMVP selected from the HMVP list to perform motion compensation prediction for the current block. The motion information associated with the neighboring blocks of the current block, the one or more reference indices, and the dual prediction weight index can be used to perform the motion compensation prediction.

[0005] The video coding device can perform pruning by determining whether the HMVP candidate is the same as an HMVP in the current block's HMVP list. If the HMVP candidate is the same as any HMVP in the multiple HMVPs in the HMVP list, the video coding device can remove the HMVP from the HMVP list. The video coding device can add the HMVP candidate to the end of the HMVP list. The video coding device can shift one or more HMVPs following the removed HMVP in the HMVP list forward one position. In one example, if the HMVP candidate and an HMVP in the HMVP list have the same motion vector and the same reference index, then the HMVP candidate is considered the same as the HMVP in the HMVP list. In one example, if the HMVP candidate and an HMVP in the HMVP list have the same motion vector, the same reference index, and the same Universal Bi-Prediction (GBi) weights or Bi-Prediction (BCW) weights using CU hierarchical weights, then the HMVP candidate is considered the same as the HMVP in the HMVP list.

[0006] If the HMVP candidate is not the same as any HMVP in the HMVP list, then, for example, if the HMVP list is full, the video coding device can remove the oldest HMVP entry from the HMVP list. The video coding device can also add the HMVP candidate to the end of the HMVP list. When coding a new coding tree unit (CTU) line begins, the video coding device can reset the HMVP list. Simple Explanation of the Diagram

[0007] Figure 1 shows an exemplary diagram of a block-based video encoder. Figure 2 shows an exemplary block partition in a multi-type tree structure. Figure 3 shows an exemplary diagram of a block-based video decoder. Figure 4 illustrates an exemplary history-based motion vector prediction (HMVP) coding procedure. Figure 5 shows examples of motion compensation prediction based on diagonal triangular partitioning and examples of motion compensation prediction based on inverse diagonal triangular partitioning. Figure 6 illustrates an example of generating a uni-prediction motion vector (MV) in a triangular pattern, for instance. Figure 7 shows an exemplary flowchart for generating a single predicted MV list based on one or more merged candidates. Figure 8A shows an example of adding HMVP candidates to the HMVP list while taking GBi weights into account. Figure 8B shows an example of adding HMVP candidates to the HMVP list using a first-in-first-out (FIFO) scheme. Figure 9 shows an example of adding an HMVP candidate to the HMVP list. Figure 10 shows an exemplary flowchart for generating a list of single-predictive MVs for triangular patterns based on spatial / temporal candidates and HMVP candidates. Figure 11 shows an exemplary flowchart of generating a list of single-predictive MVs for triangular patterns by interleaving single-predictive MVs of spatial / temporal candidates and single-predictive MVs of HMVP candidates. Figure 12A is a system diagram of an exemplary communication system in which one or more of the disclosed embodiments may be implemented. Figure 12B is a system diagram of an exemplary wireless transmit / receive unit (WTRU) that can be used in the communication system shown in Figure 12A. Figure 12C 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 in Figure 12A. Figure 12D is a system diagram of another exemplary RAN and another exemplary CN that can be used within the communication system shown in Figure 12A. Implementation

[0008] A detailed description of illustrative embodiments will now be described with reference to the accompanying drawings. While this description provides detailed examples of possible implementations, it should be noted that these details are intended to be exemplary and do not limit the scope of this application in any way.

[0009] One or more video coding devices in a video coding system can compress digital video signals, for example, to reduce the storage space and / or transmission bandwidth associated with storing and / or delivering such signals. The video coding device may be based on a block-based hybrid video coding framework. A block partitioning structure based on multiple tree types may be employed. It may include one or more coding modules, such as intra-frame prediction modules, inter-frame prediction modules, transform / inverse transform modules, and quantization / dequantization modules. The video coding device may include in-loop filters.

[0010] The video coding apparatus may include one or more coding tools that provide high coding efficiency and moderate implementation complexity. These coding tools may include one or more of the following: affine motion models, alternative temporal motion vector prediction (ATMVP), integer motion vectors (IMV), universal double prediction (GBi) or double prediction (BCW) using CU-level weights (BCW), bidirectional optical flow (BDOF), combined inter-frame merging / intra-frame prediction, merging with motion vector difference (MMVD), pairwise average merging candidates, triangular inter-frame prediction for inter-frame coding; cross-component linear model (CCM), multi-line intra-frame prediction, current image reference (CPR) for intra-frame prediction; enhanced multiple transform (EMT), correlation quantization for quantization and transform coding, and adaptive loop filtering (ALF) for in-loop filters.

[0011] Exemplary block-based video coding systems may include a block-based hybrid video coding framework. Figure 1 shows an exemplary block diagram of a block-based hybrid video coding system. As shown in Figure 1, the input video signal 1002 can be processed block by block. An expanded block size (e.g., referred to as a coding unit or CU) can be used to compress high-resolution (e.g., 1080p and / or higher) video signals. CUs may include sizes up to 128 × 128 pixels. Blocks may be partitioned based on a quadtree. Coding Tree Units (CTUs) may be partitioned into multiple CUs based on quadtrees / binary / tritrees to accommodate varying local characteristics. CUs may or may not be partitioned into prediction units or PUs to which individual predictions can be applied. CUs may be used as (e.g., always used) basic units for prediction and transformation without other partitions. In a multi-type tree structure, (e.g., one) a CTU may be partitioned by a quadtree structure (e.g., may be partitioned initially). Quad-tree leaf nodes (e.g., each quad-tree leaf node) can be further partitioned by binary and ternary tree structures. As shown in Figure 2, there can be one or more (e.g., five) partitioning types, including, for example, quad partitioning, horizontal binary partitioning, vertical binary partitioning, horizontal ternary partitioning, and vertical ternary partitioning.

[0012] Referring to Figure 1, input video blocks (e.g., macro blocks (MBs) and / or CUs) can be performed, along with spatial prediction 1060 and / or temporal prediction 1062. Spatial prediction 1060 (e.g., intra-frame prediction) can use pixels from samples (e.g., reference samples) of writable neighboring blocks in the video image / slice to predict the current video block. This spatial prediction 1060 can reduce, for example, the spatial redundancy inherent in the video signal. Motion prediction 1062 (e.g., inter-frame prediction and / or temporal prediction) can use reconstructed pixels (e.g., from the writable video image) to predict the current video block. This motion prediction 1062 can reduce, for example, the temporal redundancy inherent in the video signal. Motion prediction signals (e.g., temporal prediction signals) of the video blocks (e.g., CUs) can be communicated via one or more motion vectors (MVs). These MVs can indicate the amount and / or direction of motion between the current block and / or a reference block or a temporal reference of the current block. If multiple reference images are supported for a single (e.g., each) video block, the encoder can send the reference image index for that video block. This reference image index can be used to identify which reference image in the reference image storage 1064 the motion prediction signal can be derived from.

[0013] Following spatial prediction 1060 and / or motion prediction 1062, the mode decision block 1080 in the encoder may determine a prediction mode (e.g., the optimal prediction mode) based, for example, rate distortion optimization. At 1016, the prediction block may be subtracted from the current video block, and / or the prediction residual may be decorrelated using transform 1004 and / or quantization 1006 to achieve a bit rate, such as a target bit rate. The quantized residual coefficients may be dequantized at inverse quantization 1010 and / or inverse transformed at transform 1012, for example, to form a reconstructed residual, which may be added to the prediction block at 1026, for example, to form a reconstructed video block. Before the reconstructed video block may be placed in the reference image storage 1064 and / or used for coding the video block (e.g., a future video block), an in-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. In order to form the output video bitstream 1020, the coding mode (e.g., inter-frame or intra-frame), prediction mode information, motion information and / or quantized residual coefficients can be sent (e.g., all of them can be sent) to the entropy coding module 1008, for example, to be compressed and / or compressed to form the bitstream.

[0014] Figure 3 shows a block diagram of an exemplary block-based video decoding framework for the decoder. The video bitstream 1102 (e.g., the video bitstream 1020 in Figure 1) can be decompressed (e.g., decompressed first) and / or entropy decoded at entropy decoding module 1108. The write-code pattern and prediction information can be sent to spatial prediction module 1170 (e.g., if in-frame write-code) and / or motion compensation prediction module 1172 (e.g., if inter-frame write-code and / or temporal write-code) to form a prediction block. Residual transform coefficients can be sent to inverse quantization module 1110 and / or inverse transform module 1112, for example, to reconstruct the residual block. At 1126, the prediction block and / or the residual block can be added together. For example, the reconstructed block can be in-loop filtered at loop filter 1176 before being stored in reference image memory 1174. The reconstructed video 1120 in the reference image storage 1174 can be sent to drive a display device and / or used to predict video blocks (e.g., future video blocks).

[0015] One or more write-code modules (e.g., write-code modules associated with inter-frame prediction) can be enhanced to improve inter-frame write-code efficiency. For example, as described herein, write-code efficiency for history-based motion vector prediction (HMVP) can be improved.

[0016] One or more mechanisms, as described herein, can be used to communicate the motion vector prediction (MV) of a write-through block. For example, an Advanced Motion Vector Prediction (AMVP) mode or a merging mode can be used to communicate the MV of the write-through block. In the AMVP mode, the difference between the actual MV and the MV predictor (MVP), a reference index, and an MVP index referencing a list of AMVP candidates can be communicated. For the merging mode, a merge index referencing a list of merge candidates can be communicated. Motion information associated with a merge candidate can be inherited from the communicated merge candidate. Motion information (e.g., motion information for both AMVP and merge candidates) can be derived from multiple spatial blocks adjacent to a control unit (CU). For example, these spatial blocks can be directly adjacent to (e.g., adjacent to) collocated blocks in the current CU or a temporal reference image. 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] HMVP can be used to explore the correlation between MVs of neighboring blocks. For example, HMVP can be used to explore the correlation between spatially non-adjacent blocks. Although this article refers to HMVPs utilized by spatially non-adjacent neighboring blocks, those skilled in the art will understand that these neighboring blocks may also include blocks that are adjacent blocks.

[0018] HMVP candidates can represent motion information from previously written CUs. This motion information can include one or more of the following: MV and reference image index. A table of multiple HMVP candidates can be maintained at the encoder and / or decoder. When writing a new CTU line begins, the HMVP candidate table can be reset (e.g., reset to empty). After writing to an inter-frame CU that does not contain multiple subblocks (e.g., ATMVP and affine-coded CUs), associated motion information can be added to an entry (e.g., the last entry in the HMVP candidate table) based on rules (e.g., a constrained first-in-first-out (FIFO) rule). Redundancy checks can be applied to identify if there is an existing HMVP candidate that is the same as the new motion candidate (e.g., before adding the motion candidate to the HMVP candidate table or list). If an existing HMVP candidate that is the same as the new motion candidate is found, the same HMVP candidate can be removed from the HMVP candidate table or list, and the HMVP candidate can be moved forward one position, for example, by decrementing the HMVP candidate table index by one. Figure 4 illustrates a demonstrative decoding workflow when applying HMVP to predict MV. As shown in Figure 4, at 402, an existing HMVP candidate can be loaded into the list of existing HMVP candidates. At 404, the MV associated with the current block can be decoded from the HMVP candidate. At 406, the HMVP candidate list can be updated based on the decoded MV.

[0019] Generalized double prediction (GBi) or double prediction using CU-level weights (BCW) can be performed. For example, GBi or BCW can be performed to improve the efficiency of double prediction when predicting a CU using two temporal prediction blocks reconstructed from a reference image. In double prediction mode, the predicted signal at sample x can be calculated as the average of the two predicted signals, as shown in equation (1). P[ [x]] = / 2. (1)

[0020] Referring to equation (1): P[x] can be the predicted signal obtained from the sample x at image position x, and P1[x+v1] can be the motion-compensated predicted signal of x using the motion vector (MV) v1 of the i-th list (e.g., list 0, list 1). GBi can apply various weight values ​​(e.g., w0 and w1) to the two predicted signals from list 0 and list 1. One or more configurations of w0 and w1 can imply prediction similarity with single prediction and double prediction (e.g., the same prediction as regular single prediction and double prediction). For example, prediction similarity with single prediction and double prediction can exist when (w0, w1) equals the following values: (1, 0), for single prediction using reference list L0; (0, 1), for single prediction using reference list L1; and (0.5, 0.5), for regular double prediction using both reference lists. In GBi, weights can be applied to the predicted signals from lists L0 and L1 for each CU signal. A constraint can be applied such that the sum of w0 and w1 is 1, for example, w0 + w1 = 1. This constraint can be applied to reduce communication overhead. Given this constraint, a single weight can be communicated, and the final double prediction signal when applying GBi can be calculated, for example, using equation (2). P[ [x]] = . (2) []

[0021] Referring 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}, so that each weight value can be represented by an index value within a small, finite range. Discretization using a small range of w1 can be used to reduce transmission overhead. The weight values ​​{1 / 4, 3 / 8, 1 / 2, 5 / 8, 3 / 4} can be applied to inter-frame images (e.g., all inter-frame images), while the weight values ​​{-1 / 4, 5 / 4} can be applied to low-latency images. This weight value can be applied to low-latency images that can be predicted by using reference images that precede the current image in the display order.

[0022] Triangular inter-frame prediction can 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 approximate accurately by rectangular blocks. Therefore, triangular prediction can be applied, for example, to enable triangular partitioning for motion compensation prediction. As shown in Figure 5, triangular prediction can (e.g.) divide a CU into one or more (e.g., two) triangular prediction units in a diagonal direction (502) or an anti-diagonal direction (504). The triangular prediction unit in the CU (e.g., each triangular prediction unit) can be inter-frame predicted using its single-predicted motion vector and a reference frame index. The single-predicted motion vector and the reference frame index can be derived from a list of single-predicted candidates.

[0023] The single-prediction candidate list may include one or more (e.g., five) single-prediction motion vector candidates. Single-prediction motion vector candidates may be derived from spatial / temporal neighbor blocks that are similar to (e.g., identical to) the spatial / temporal neighbor blocks used in the merging process (e.g., the merging process of HEVC). As shown in Figure 6, single-prediction MV candidates may be derived from five spatial neighbor blocks and two temporally juxtaposed blocks. Referring to Figure 6, motion vectors from seven neighbor blocks may be collected and stored in the single-prediction MV candidate list in the following order: the L0 motion vector of the neighbor block, the L1 motion vector of the neighbor block, and the average motion vector of the L0 and L1 motion vectors of the neighbor block (e.g., if the neighbor block is double-predicted). If the number of MV candidates is less than five, zero (0) motion vectors may be added to the MV candidate list.

[0024] Figure 7 illustrates a flowchart for adding a single-prediction MV of a merge candidate to the single-prediction MV list of a CU coded using a triangular prediction pattern. At 702, the video coding device determines whether the merge candidate includes an L0 MV. If so, at 704, the video coding device adds the L0 MV associated with the merge candidate to the single-prediction MV list. At 708, the video coding device checks whether the spatial / temporal candidate is the last one in the list. At 710, the video coding device determines whether the merge candidate includes an L1 MV. If so, at 712, the video coding device adds the L1 MV associated with the merge candidate to the single-prediction MV list. At 714, the video coding device checks whether the spatial / temporal candidate is the last one in the list. At 716, the video coding device determines whether the merge candidate includes both L0 and L1 MVs. If so, then at 718, the video coding device can add the average of the L0 MV and L1 MV associated with the merge candidate to the single predicted MV list. At 720, the video coding device can check whether the spatial / temporal candidate is the last one in the list.

[0025] The order of the one or more neighboring blocks (e.g., the order in which candidate blocks are examined and considered to be added to the candidate list) may include one or more spatially neighboring blocks (e.g., 1 to 5), followed by one or more temporally juxtaposed blocks (6 to 7). Referring to Figure 6, motion vectors of seven neighboring blocks (e.g., A1, A0, B0, B1, B2, T0, T1) can be collected and stored in a single-prediction candidate list according to the order of single-predicted motion vectors, L0 motion vectors of double-predicted motion vectors, L1 motion vectors of double-predicted motion vectors, and the average motion vector of the L0 and L1 motion vectors of double-predicted motion vectors. If the number of candidates is less than five, a zero motion vector is added to the list.

[0026] For example, HMVP write gain can be improved by extending its application to other write tools (e.g., general double prediction and / or triangular inter-frame prediction). HMVP can be used to determine the MV correlation between neighboring blocks. For example, HMVP can be used to determine the MV correlation between adjacent spatially non-adjacent blocks. Although HMVP is referred to herein as being used to determine the MV correlation between spatially non-adjacent neighboring blocks, those skilled in the art will understand that the neighboring block can include blocks that are adjacent blocks. HMVP can be used to determine the MV correlation by maintaining a table of one or more MV candidates. The table can be maintained at the encoding and / or decoding apparatus. HMVP candidates can be defined based on motion information including one or more of the following: a reference image index (e.g., one or multiple reference image indices), a reference list (e.g., one or multiple reference lists), or a motion vector (e.g., one or multiple motion vectors) associated with a previously written block.

[0027] In one example, HMVP candidates can be used to derive the predicted signal for a GBi-deactivated CU. In this case, equal weights can be applied to the two predicted signals associated with list 0 and list 1.

[0028] In one example, HMVP and GBi can be enabled, for instance, by associating GBi with an HMVP index. The GBi can be enabled by associating at least one GBi index with an HMVP entry or each of the HMVP indexes. This can lead to improved write efficiency for HMVP. The GBi index can also be called a double-predictive-weighted index.

[0029] In one example, for each HMVP candidate, in addition to the motion information, the at least one GBi index may be created based on one or more of the following: When an HMVP candidate is derived from an inter-frame CU (inter-CU) with transmitted GBi weights, the GBi weight of the HMVP candidate may be set to the transmitted GBi weights. When an HMVP candidate is derived from a spatial merge candidate, the GBi weight of the HMVP candidate may be set to the GBi weight of the spatial candidate. When an HMVP candidate is derived from a temporal merge candidate, the GBi weight of the HMVP candidate may be set to the GBi weight of the juxtaposed block in the temporally juxtaposed image. When an HMVP candidate is derived from an average merge candidate, the GBi weight of the HMVP candidate may be set to a fixed value (e.g., 0.5).

[0030] As described herein, pruning can be performed at one or more different stages of the HMVP processing procedure. For example, when an MV candidate or HMVP candidate is added to the HMVP list, pruning can be performed to remove redundant entries from the HMVP list. In one example, pruning can be performed after it has been determined that an entry in the HMVP list is identical to the MV candidate or the HMVP candidate. If an identical candidate is found in the HMVP list, the identical HMVP is removed from the HMVP list. In one example, if the motion information associated with an HMVP candidate is similar to the motion information associated with the HMVP entry in the HMVP list, then the HMVP candidate is considered identical to the HMVP entry in the HMVP list. The motion information being compared can include one or more of the following: motion vectors (e.g., one or more motion vectors), a reference list (e.g., one or more reference indices), and reference image indices (e.g., one or more reference image indices).

[0031] In one example, in addition to the motion vector information, GBi weights can be considered when determining whether to add an HMVP candidate to the HMVP candidate list. Figure 8A illustrates an example of considering GBi weights when adding an HMVP candidate to the HMVP candidate list. As shown in Figure 8A, when the motion information and GBi weights of the second entry in the existing HMVP list (e.g., HMV P1) are similar to those of the new HMVP candidate (e.g., Cl-1), the second entry in the HMVP list and the new HMVP candidate to be added to the HMVP list can be considered the same. In this example, before adding the HMVP candidate Cl-1 to the end of the HMVP list, the matching HMVP entry HMVP1 in the HMVP list can be removed from the list, and the HMVP entries following the first HMVP entry (e.g., HMVP2 to HMVP1-1) can be shifted forward as indicated by the arrows. This can be achieved, for example, by decrementing the respective indices by one.

[0032] Figure 8B illustrates an example where an HMVP candidate can be considered different from entries in the HMVP list. As shown in Figure 8B, even if HMVP1 and Cl-1 have the same motion information, HMVP1 and Cl-1 are considered different because their respective GBi weights are unequal. A FIFO procedure (e.g., a default FIFO procedure) can be applied. As shown in Figure 8B, this FIFO procedure can include removing the first HMVP candidate (e.g., HMVP0) from the table, shifting the position of each entry by one as indicated by the arrow in Figure 8B to create an empty position at the end of the HMVP list, and adding the new candidate Cl-1 to that empty position at the end of the HMVP list.

[0033] HMVP candidates (e.g., each of which may be associated with a GBi weight) can be used as candidates for the merge pattern and / or AMVP pattern. HMVP candidates (e.g., all HMVP candidates from the last entry to the first entry in the HMVP table) can be inserted, for example, after the TMVP candidate. When HMVP is applied to the merge pattern, pruning can be applied to remove candidates with similar (e.g., the same) motion information and similar (e.g., the same) GBi weights.

[0034] The GBi index can be used for motion compensation prediction and the HMVP pruning process. This motion compensation prediction and HMVP pruning process can improve write coding gain and increase the complexity of the pruning process. The complexity of the HMVP pruning process can increase when examining the motion information and GBi weights of HMVP candidates (e.g., each HMVP candidate in the list). In one example, the GBi weights of each of the HMVP candidates (e.g., all HMVP candidates) can be used for motion compensation prediction. A subset of the HMVP candidates can be used for the HMVP pruning process. As described herein, HMVP candidates can be associated with GBi indices (e.g., each HMVP candidate can be associated with one GBi index). These associated GBi weights can be used to generate a predicted signal for the CU (e.g., rather than determining whether two HMVP candidates are the same).

[0035] Figure 9 illustrates an example of adding an HMVP candidate to the HMVP list, where GBi weights are not considered when adding an HMVP candidate. In the example provided in Figure 9, the GBi index of the second entry in the existing HMVP list (e.g., HMVP1) is different from that of the new HMVP candidate (e.g., Cl-1), while the motion information of the second entry in the existing HMVP list (e.g., HMVP1) is the same as that of the new HMVP candidate (e.g., Cl-1). In this example, if the motion information of the second entry in the existing HMVP list (e.g., HMVP1) is the same as that of the new HMVP candidate (e.g., Cl-1), and the GBi indexes of the second entry in the existing HMVP list (e.g., HMVP1) and the new HMVP candidate (e.g., Cl-1) are different, then the second entry in the HMVP list can be considered the same as the new HMVP candidate. As shown in Figure 9, HMVP1 can be removed from the HMVP candidate list, and subsequent HMVP candidates (e.g., HMVP2 to HMVP1-1) can be shifted forward, for example, by decrementing the index by one as shown by the arrow. Then, C1-1 can be added to the end of the HMVP list.

[0036] This HMVP can be used to perform triangular inter-frame prediction. In triangular inter-frame prediction, the MV in the single prediction candidate list can be derived from temporal and spatial neighbors. For example, traditional spatial and temporal neighbors can be neighbors of the merged pattern used in HEVC. For example, triangular inter-frame prediction can derive the MV in the single prediction candidate list from five spatial neighbors and two temporal neighbors, as shown in Figure 6. In one example, MV derivation may not consider the correlation between MVs of blocks that are not direct spatial neighbors (e.g., non-adjacent blocks). In this case, MV derivation may not produce accurate single prediction MV candidates (e.g., the most accurate single prediction MV candidates) to capture the true motion of the two triangular partitions. In the example, motion information of neighboring blocks along the occlusion boundary may be irrelevant (e.g., due to occlusion of objects that may typically exist in content such as natural video content). If the motion information of neighboring blocks along the occlusion boundary is irrelevant, the MV from spatial neighbors on that occlusion boundary may be inaccurate (e.g., not accurate enough) to be used as the MV predictor for the current CU. This may reduce the efficiency of inter-frame coding. In one example, HMVP candidates (e.g., in addition to existing spatial and temporal MV candidates) can be used to derive a list of single-prediction MV candidates for triangular prediction patterns, for example, to explore the correlation between MVs of one or more neighboring blocks (e.g., spatially non-neighboring blocks).

[0037] The single-predictive MVs of HMVP candidates can be placed at different positions in the candidate list of single-predictive MVs used for triangular patterns (e.g., the final candidate list). In one example, single-predictive MVs associated with one or more HMVP candidates can be examined and inserted into the list after spatial and / or temporal candidates. MVs associated with HMVP candidates can be examined (e.g., checking if the MV of an HMVP candidate is the same as an MV in the single-predictive MV list) and inserted into that single-predictive candidate list (e.g., after spatial and temporal candidates). The MVs of the candidate block can be collected in the order of five spatial neighbors (e.g., A1, A0, B1, B0, and B2) followed by two temporal neighbors (e.g., T0 and T1) (as shown in Figure 6) and N HMVP candidates.

[0038] A single prediction MV for a triangular pattern can be generated as described herein. In one instance, the single prediction MV for the triangular pattern can be generated by adding L0 MVs associated with one or more of the spatial / temporal candidates and HMVP candidates. In one example, the single prediction MV for the triangular pattern can be generated by adding L1 MVs associated with one or more spatial / temporal candidates and HMVP candidates. In one example, for instance, if the HMVP candidate is bipredictable, the single prediction MV for the triangular pattern can be generated by averaging the L0 MVs and L1 MVs of the spatial / temporal candidates and HMVP candidates.

[0039] Figure 10 illustrates an example associated with the list of single-predictive MVs for inserting merge candidates' single-predictive MVs into the triangle CU. As shown in Figure 10, at 1030, the video coding device determines whether a candidate (e.g., the i-th merge candidate) includes an L0 MV. If so, at 1032, the video coding device adds the L0 MV associated with that candidate to the single-predictive MV list. At 1034, the video coding device checks whether the spatial / temporal candidate or HMVP candidate is the last one in the list. At 1036, the video coding device determines whether the candidate includes an L1 MV. If so, at 1038, the video coding device adds the candidate's L1 MV to the single-predictive MV list. At 1040, the video coding device checks whether the spatial / temporal candidate or HMVP candidate is the last one in the list. At 1042, the video coding device determines whether the candidate includes both L0 MV and L1 MV. If so, at 1044, the video coding device adds the average of the candidate's L0 MV and L1 MV to the single predicted MV list. At 1046, the video coding device checks whether the spatial / temporal candidate or HMVP candidate is the last one in the list.

[0040] The motion of spatial and temporal neighbors (e.g., motion information) can be correlated with the current motion of the CU (e.g., motion information) (e.g., more correlated than the motion of the HMVP candidate). A higher priority can be given to the single-predicted MV of the spatial and temporal candidate than that of the HMVP candidate (e.g., to reduce the overhead of the messenger candidate MV). In an example, the single-predicted MVs of the spatial / temporal candidates can be interleaved with those of the HMVP candidate.

[0041] A list of single-predictive MVs for a triangular CU (e.g., the final list of single-predictive MVs) can be generated. In one example, this list of single-predictive MVs for a triangular CU can be generated by inserting the L0 MV of each spatial / temporal candidate into the list of single-predictive MVs. In one example, this list of single-predictive MVs for a triangular CU can be generated by inserting the L1 MV of each spatial / temporal candidate into the list of single-predictive MVs. In one example, this list of single-predictive MVs for a triangular CU can be generated by inserting the L0 MV of each HMVP candidate into the list of single-predictive MVs. In one example, this list of single-predictive MVs for a triangular CU can be generated by inserting the L1 MV of each HMVP candidate into the list of single-predictive MVs.

[0042] In one example, the single-prediction MV list of a triangular CU can be generated by averaging the L0 MV and L1 MV of spatial / temporal candidates (e.g., each spatial / temporal candidate if it is bipredictable) into the single-prediction MV list. In another example, the single-prediction MV list of a triangular CU can be generated by averaging the L0 MV and L1 MV of HMVP candidates (e.g., each HMVP candidate if it is bipredictable) into the single-prediction MV list.

[0043] Figure 11 illustrates an example of a single-prediction MV list generating a triangular pattern when the single-prediction MVs of spatial / temporal candidates and HMVP candidates are interleaved. As shown in Figure 11, at 1130, the video coding device determines whether a candidate (e.g., the i-th merged candidate) includes an L0 MV. If so, at 1132, the video coding device adds the L0 MV associated with that candidate to the single-prediction MV list. At 1134, the video coding device checks whether the spatial / temporal candidate is the last one in the list. At 1136, the video coding device determines whether a candidate includes an L1 MV. If so, at 1138, the video coding device adds the L1 MV associated with that candidate to the single-prediction MV list. At 1140, the video coding device checks whether the spatial / temporal candidate is the last one in the list. At 1142, the video coding device determines whether a candidate includes an L0 MV. If so, at 1144, the video coding device can add the L1 MV associated with the candidate to the single prediction MV list. At 1146, the video coding device can check if the HMVP candidate is the last one in the list. At 1148, the video coding device can determine if the candidate includes L1 MV. If so, at 1150, the video coding device can add the L1 MV associated with the candidate to the single prediction MV list. At 1152, the video coding device can check if the HMVP candidate is the last one in the list. At 1154, the video coding device can determine if the candidate includes both L0 MV and L1 MV. If so, at 1156, the video coding device can add the average of the L0 MV and L1 MV associated with the candidate to the single prediction MV list. At 1158, the video coding device can check if the spatial / temporal candidate is the last one in the list. At 1160, the video coding device determines whether the candidate contains both L0 MV and L1 MV. If so, at 1162, the video coding device adds the average of the L0 MV and L1 MV associated with the candidate to the single predicted MV list. At 1164, the video coding device checks whether the HMVP candidate is the last one in the list.

[0044] Figure 12A is a diagram illustrating an exemplary communication system 100 that may implement one or more of the disclosed embodiments. For example, one or more features associated with the video coding apparatus described herein may be included in one or more of the WTRUs 102a, 102b, 102c, 102d of the communication system 100. The communication system 100 may be a multiple access system providing voice, data, video, messaging, broadcasting, and other content to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may use 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), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word DFT-Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtering OFDM, and Filter Bank Multicarrier (FBMC), etc.

[0045] As shown in Figure 12A, the communication system 100 may 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. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0046] The communication system 100 may also include base stations 114a and / or 114b. Each base station 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to enable it to access one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112). For example, base stations 114a, 114b may be base transceiver stations (BTS), node B, e-node B, local node B, local e-node B, gNB, NR node B, site controller, access point (AP), and wireless routers, etc. Although each base station 114a, 114b is described as a single element, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0047] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies called cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide radio service coverage for a specific geographic area that is relatively fixed or may change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, that is, one transceiver for each sector of the cell. In embodiments, base station 114a may use multiple-input multiple-output (MIMO) technology and may use 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] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via an air interface 116, wherein the air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish the air interface 116.

[0049] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use wideband CDMA (WCDMA) to establish air interface 115 / 116 / 117. 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] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), wherein the technology may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTA Pro (LTE-A Pro) to establish the air interface 116.

[0051] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, wherein the radio technology may use novel radio (NR) to establish the space interface 116.

[0052] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together (e.g., using the dual connectivity (DC) principle). Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to and from various types of base stations (e.g., eNBs and gNBs).

[0053] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement the following radio technologies, such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN), etc.

[0054] Base station 114b in Figure 12A can be a wireless router, local node B, local e-node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in local areas such as business premises, residences, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), and roads. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can use cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in Figure 12A, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0055] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. The data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or can perform advanced security functions such as user authentication. Although not shown in Figure 12A, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to connecting with RAN 104 / 113 which uses NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0056] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). Internet 110 may include a globally interconnected computer network system using common communication protocols (such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite). Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, wherein the one or more RANs may use the same RAT as RAN 104 / 113 or a different RAT.

[0057] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links). For example, the WTRU 102c shown in Figure 12A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and with base station 114b, which may use IEEE 802 radio technology.

[0058] Figure 12B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 12B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that the WTRU 102 may also include any sub-combination of the foregoing elements while maintaining compliance with the embodiments.

[0059] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a complex microprocessor, one or more microprocessors associated 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. Processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmit / receive element 122. Although Figure 12B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 may also be integrated together in an electronic component or chip.

[0060] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in an embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In an embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0061] Although the transmit / receive element 122 is depicted as a single element in Figure 12B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0062] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate via various RATs (e.g., NR and IEEE 802.11).

[0063] The processor 118 of 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) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from these components. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from and store data in any suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a SIM card, a memory stick, a secure SD card, etc. In other embodiments, processor 118 may access information from and store data in memories that are not actually located in WTRU 102, for example, such memories may be located in a server or home computer (not shown).

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

[0065] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. As a supplement to or alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via an air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may use any suitable positioning method to obtain location information.

[0066] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[0067] WTRU 102 may include a full-duplex radio device for which the reception or transmission of some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio device may include an interference management unit that reduces and / or substantially eliminates self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio device for transmitting and receiving some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) or downlink (e.g., for reception).

[0068] Figure 12C is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can use E-UTRA radio technology on the air intermediate surface 116 to communicate with WTRUs 102a, 102b, and 102c. RAN 104 can also communicate with CN 106.

[0069] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each eNodeB 160a, 160b, and 160c may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c on the air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0070] Each eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 12C, eNodeB 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0071] The CN 106 shown in Figure 12C may include a Mobility Management Entity (MME) 162, a Service Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is described as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0072] The MME 162 can be connected to each eNodeB 162a, 162b, 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, performing bearer initiation / deactivation, and selecting specific service gateways during the initial connection of WTRUs 102a, 102b, 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) using other radio technologies (such as GSM and / or WCDMA).

[0073] The SGW 164 can be connected to each eNodeB 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes user data packets to WTRUs 102a, 102b, and 102c and forwards user data packets from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0074] SGW 164 can be connected to PGW 166, which can provide packet switching network (e.g., Internet 110) access for WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0075] CN 106 can facilitate communication with other networks. For example, CN 106 can provide circuit-switched network (e.g., PSTN 108) access for WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may act as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0076] Although the WTRU is described as a wireless terminal in Figures 12A to 12D, it should be understood that in some typical embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0077] In a typical embodiment, the other network 112 may be a WLAN.

[0078] A WLAN employing an Infrastructure Basic Services Set (BSS) model may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access or interface with a Distributed System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA may arrive via the AP and be delivered to the STA. Traffic originating from a STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent via the AP; for example, a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. This point-to-point traffic may be sent between the source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some typical embodiments, the DLS may use 802.11e DLS or 802.11z Channelized DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or those using the IBSS (e.g., all STAs) can communicate directly with each other. Here, the IBSS communication mode is sometimes referred to as an "ad-hoc" communication mode.

[0079] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). This primary channel can have a fixed bandwidth (e.g., 20 MHz) or a bandwidth dynamically set via communication. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some typical embodiments (e.g., in an 802.11 system), Carrier-Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can fall back. Within a given BSS, a single STA (e.g., only one station) can transmit at any given time.

[0080] High-throughput (HT) STAs can use 40 MHz wide channels for communication (e.g., by combining a 20 MHz wide main channel with 20 MHz wide adjacent or non-adjacent channels to form a 40 MHz wide channel).

[0081] Ultra-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 can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels (this combination is referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is passed through a segmented parser that divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed individually on each stream. This stream can be mapped onto two 80 MHz channels, and the data can be transmitted by a transmit STA. On the receiver of a receive STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0082] 802.11af and 802.11ah support sub-1 GHz operating modes. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to some typical embodiments, 802.11ah can support instrument-type control / machine-type communications, such as MTC devices in a macro coverage area. The MTC may have certain capabilities, such as limited capabilities that include support (e.g., only support) certain and / or limited bandwidths. The MTC device may include a battery with a battery life exceeding a critical value (e.g., for maintaining a very long battery life).

[0083] WLAN systems that support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of this primary channel can be 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 limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes, the primary channel can be 1 MHz wide for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the main channel is busy (for example, because the STA (which only supports 1 MHz operating mode) is transmitting to the AP), then the entire available band can be considered busy even if most of the band remains idle and available.

[0084] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah is from 6 MHz to 26 MHz.

[0085] Figure 12D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can use NR radio technology on the air intermediate surface 116 to communicate with WTRUs 102a, 102b, and 102c. RAN 113 can also communicate with CN 115.

[0086] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, and 180c may include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit and / or receive signals to and / or from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0087] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable parameter set (numerology). For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0088] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as their action anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-standalone configuration, WTRUs 102a, 102b, and 102c communicate / connect with gNBs 180a, 180b, and 180c simultaneously with another RAN (e.g., eNodeBs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, and one or more eNodeBs 160a, 160b, and 160c. In a non-standalone configuration, eNodeBs 160a, 160b, and 160c can act as operational anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0089] Each gNB 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network segmentation, implement dual connectivity, implement interoperability processing between NR and E-UTRA, route user plane data to User Plane Functions (UPF) 184a and 184b, and route control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. As shown in Figure 12D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0090] The CN 115 shown in Figure 12D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include Data Network (DN) 185a, 185b. Although each of the foregoing elements is described as a part of CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0091] AMF 182a and 182b can be connected to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network segmentation (e.g., handling different PDU conversations with different needs), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS communications, and mobility management, etc. AMF 182a and 182b can use network slicing to customize the CN support provided to WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services relying on Ultra Reliable Low Latency Communication (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and / or services for Machine Type Communication (MTC) access, etc. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) using other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0092] SMFs 183a and 183b can be connected to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also be connected to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and can configure traffic routing via UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU conversations, controlling policy enforcement and QoS, and providing downlink data notifications, etc. PDU conversation types can be IP-based, non-IP-based, and Ethernet-based, etc.

[0093] UPF 184a and 184b can be connected to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface, thus providing WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, caching downlink packets, and providing mobility anchors, etc.

[0094] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108, or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via an N3 interface that interfaces with UPFs 184a and 184b and an N6 interface that is between UPFs 184a and 184b and data networks (DNs) 185a and 185b.

[0095] Based on the descriptions in Figures 12A to 12D and their corresponding descriptions, one or more of the functions described herein, along with one or more of the functions described, can be performed by one or more emulation devices (not shown): WTRU 102a-d, base stations 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other devices described herein. These emulation devices can be one or more devices configured to emulate one or more of the functions described herein. For example, these emulation devices can be used to test other devices and / or to simulate network and / or WTRU functions.

[0096] The simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all of their functions while being implemented and / or deployed, wholly or partially, as part of a wired and / or wireless communication network, to test other devices within the communication network. The one or more simulation devices can perform one or more or all of their functions while being implemented / deployed, temporarily, as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device to perform tests, and / or can use over-the-air wireless communication to perform tests.

[0097] The one or more simulation devices can perform one or more functions, including all functionalities, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or test scenarios where a wired and / or wireless communication network is not deployed (e.g., for testing) to perform tests on one or more components. The one or more simulation devices can be test equipment. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (as an example, which may include one or more antennas).

[0098] The processes described herein can be implemented in computer programs, software, and / or firmware incorporated in computer-readable media 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), temporary registers, cache memory, semiconductor memory devices, magnetic media (e.g., but not limited to internal hard disks and removable disks), magneto-optical media, and / or optical media (e.g., CD-ROM discs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement radio frequency transceivers for WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0099] 100: Communication System 102, 102a, 102b, 102c, 102d: Wireless Transmit / Receive Unit (WTRU) 104, 113: Radio Access Network (RAN) 106, 115: Core Network (CN) 108: Public Switched Telephone Network (PSTN) 110: Internet 112: Other networks 114a, 114b: Base stations 116: Empty Intermediate Surface 118: Processor 120: Transceiver 122: Transmit / receive element 124: Speaker / Microphone 126: Numeric keypad 128: Monitor / Touchpad 130: Non-removable memory 132: Removable Memory 134: Power Supply 136: Global Positioning System (GPS) Chipset 138: Peripheral Equipment 160a, 160b, 160c: Node B 162: Mobility Management Entity (MME) 164: Service Gateway (SGW) 166: Packet Data Network (PDN) Gateway (or PGW) 180a, 180b, 180c:gNB 182a, 182b: Mobility Management Function (AMF) 183a, 183b: Dialogue Management Function (SMF) 184a, 184b: User Plane Function (UPF) 185a, 185b: Data Network (DN) 1002: Input video signal 1004: Transformation 1006: Quantitative Analysis 1008: Entropy Write Code Module 1010: Dequantization 1012: Inverse Transformation 1020: Bit Stream 1060: Spatial Prediction 1062: Time Prediction 1064: Image storage 1066: Loop Filter 1080: Pattern Decision Block 1102: Bit Stream 1108: Entropy Decoding Module 1110: Inverse Quantization Module 1112: Inverse Transform Module 1120: Reconstructing the video feed 1170: Spatial Prediction Module 1172: Motion Compensation Prediction Module 1174: Reference Image Storage 1176: Loop Filter HMVP: Historical Motion Vector Prediction N2, N3, N4, N6, N11, S1, X2, Xn: Interface

Claims

1. An apparatus for video decoding, the apparatus comprising: A processor is configured to: generate a candidate list for performing a motion compensation prediction associated with a current block, wherein the current block is partitioned into a first triangular partition and a second triangular partition; add at least one of a spatial candidate or a temporal candidate to the candidate list; derive a history-based motion vector prediction (HMVP) candidate from a previously coded block; add the HMVP candidate to the candidate list; and decode the current block, including the first triangular partition and the second triangular partition, based on the candidate list.

2. The apparatus as claimed in claim 1, wherein the HMVP candidate is added to the candidate list after at least one of the spatial candidates or the temporal candidates.

3. The apparatus of claim 1, wherein the processor is further configured to: interleave the HMVP candidate with at least one of the spatial candidate or the temporal candidate.

4. The apparatus of claim 1, wherein a first candidate from the candidate list is associated with the first partition of the triangle and a second candidate from the candidate list is associated with the second partition, and the current block is decoded based on the first candidate associated with the first partition of the triangle and the second candidate associated with the second partition.

5. The apparatus of claim 1, wherein a first candidate is identified from the candidate list, and a second candidate is identified from the candidate list, wherein: The HMVP candidate is associated with the first partition of the triangle, and the spatial candidate or the temporal candidate is associated with the second partition, and the current block is decoded based on the HMVP candidate associated with the first partition of the triangle and the spatial candidate or the temporal candidate associated with the second partition.

6. The apparatus as claimed in claim 1, wherein the HMVP candidate includes motion information and a reference index.

7. The apparatus as claimed in claim 1, wherein the candidate list is a single predicted motion vector candidate list.

8. A method for video decoding, the method comprising: Generate a candidate list for performing a motion compensation prediction associated with a current block, wherein the current block is partitioned into a first triangular partition and a second triangular partition; add at least one of a spatial candidate or a temporal candidate to the candidate list; derive a history-based motion vector prediction (HMVP) candidate from a previously coded block; add the HMVP candidate to the candidate list; and decode the current block including the first triangular partition and the second triangular partition based on the candidate list.

9. The method as described in claim 8, wherein the HMVP candidate is added to the candidate list after at least one of the spatial candidates or the temporal candidates.

10. The method as described in claim 8, further comprising: Interleave the HMVP candidate with at least one of the spatial candidate or the temporal candidate.

11. The method as described in claim 8, wherein a first candidate from the candidate list is associated with the first partition of the triangle and a second candidate from the candidate list is associated with the second partition, and the current block is decoded based on the first candidate associated with the first partition of the triangle and the second candidate associated with the second partition.

12. The method of claim 8, wherein the HMVP candidate is associated with the first partition of the triangle, and the spatial candidate or the temporal candidate is associated with the second partition, and the current block is decoded based on the HMVP candidate associated with the first partition of the triangle and the spatial candidate or the temporal candidate associated with the second partition.

13. The method as described in claim 8, wherein the HMVP candidate includes motion information and a reference index.

14. The method as described in claim 8, wherein the candidate list is a single predicted motion vector candidate list.

15. An apparatus for video encoding, the apparatus comprising: A processor is configured to: generate a candidate list for performing a motion compensation prediction associated with a current block, wherein the current block is partitioned into a first triangular partition and a second triangular partition; add at least one of a spatial candidate or a temporal candidate to the candidate list; derive a history-based motion vector prediction (HMVP) candidate from a previously coded block; add the HMVP candidate to the candidate list; and, based on the candidate list, encode the current block including the first triangular partition and the second triangular partition.

16. The apparatus of claim 15, wherein the HMVP candidate is added to the candidate list after at least one of the spatial candidates or the temporal candidates.

17. The apparatus of claim 15, wherein the processor is further configured to: interleave the HMVP candidate with at least one of the spatial candidate or the temporal candidate.

18. A method for video encoding, the method comprising: Generate a candidate list for performing a motion compensation prediction associated with a current block, wherein the current block is partitioned into a first triangular partition and a second triangular partition; add at least one of a spatial candidate or a temporal candidate to the candidate list; derive a history-based motion vector prediction (HMVP) candidate from a previously coded block; add the HMVP candidate to the candidate list; and based on the candidate list, encode the current block including the first triangular partition and the second triangular partition.

19. The method of claim 18, wherein the HMVP candidate is added to the candidate list after at least one of the spatial candidates or the temporal candidates.

20. The method of claim 18, wherein the processor is further configured to: interleave the HMVP candidate with at least one of the spatial candidate or the temporal candidate.

Images