Shared Shortlist

Abstract

A video codec is provided that uses a shared candidate list to encode or decode a plurality of pixel blocks within a shared boundary. The video codec identifies a shared boundary of a plurality of pixel blocks of a current picture in a video sequence. The video codec identifies one or more prediction candidates as a shared candidate list based on the adjacency of an area defined by the shared boundary. The video codec encodes or decodes the one or more pixel blocks surrounded by the shared boundary by using one or more prediction candidates selected from the shared candidate list.

Description

[0001] [Cross-reference to related applications]

[0002] This application is part of a non-provisional application claiming priority to U.S. Provisional Patent Application No. 62 / 719,175 filed on August 17, 2018, U.S. Provisional Patent Application No. 62 / 733,101 filed on September 19, 2018, U.S. Provisional Patent Application No. 62 / 740,430 filed on October 03, 2018, U.S. Provisional Patent Application No. 62 / 789,566 filed on January 8, 2019, and U.S. Patent Application No. 16 / 541,627 filed on August 15, 2019. The contents of the above-listed applications are incorporated herein by reference in their entirety. [Background technology]

[0004] Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims and are not admitted to be prior art by inclusion in this section.

[0005] High Efficiency Video Coding (HEVC) is a video coding standard developed by the Joint Collaboration Team on Video Coding (JCT-VC). In HEVC, a coded picture is partitioned into non-overlapping square block areas represented by coding tree units (CTUs). A coded picture can be represented by a set of slices, each slice comprising an integer number of CTUs. Each CTU in a slice is processed in raster scan order. Bi-predictive (B) slices can be decoded using intra prediction or inter prediction using up to two motion vectors and reference indices to predict the sample values ​​of each block. Intra (I) slices are decoded using only intra prediction. Predictive (P) slices are decoded using intra prediction or inter prediction using up to one motion vector and reference index to predict the sample values ​​of each block.

[0006] One or more prediction units (PUs) are specified for each coding unit (CU). A prediction unit, together with the associated CU syntax, serves as the basic unit for signaling prediction sub-information. The specified prediction process is applied to predict the values ​​of the related pixel samples inside the PU. Depending on the selected PU type, a CU can be divided into one, two, or four PUs. HEVC defines eight types of partitions for dividing a CU into PUs.

[0007] The CU can be further partitioned using a residual quadtree (RQT) structure to represent the associated prediction residual signals. The leaf nodes of the RQT correspond to the resulting transform units (TUs). A transform unit consists of a transform block (TB) of luminance samples of size 8x8, 16x16, or 32x32, or a transform block of four luminance samples of size 4x4 and two corresponding transform blocks of chrominance samples for pictures in 4:2:0 color format. An integer transform is applied to the transform block, and the quantized coefficient values ​​are encoded in the bitstream. The minimum and maximum transform block sizes are specified in the sequence parameter set.

[0008] In HEVC, the terms coding tree block (CTB), coding block (CB), prediction block (PB), and transform block (TB) are defined to refer to a two-dimensional array of samples of one color component from the associated CTU, CU, PU, ​​and TU, respectively. Thus, a CTU consists of one luma CTB, two chroma CTBs, and related syntax elements in color pictures that are not coded using three separate color planes. The signaled coding tree partitioning generally applies to luma blocks and chroma blocks, although there are some exceptions when certain minimum size constraints are met. [Summary of the invention]

[0009] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce the concepts, highlights, benefits, and advantages of the novel and non-obvious technologies described herein. Selected but not all implementations will be further described in the detailed description below. Therefore, the following summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.

[0010] Some embodiments of the present disclosure provide a video codec that uses a shared candidate list to encode and decode (e.g., encode or decode) multiple pixel blocks within a shared boundary. The video codec identifies a shared boundary of multiple pixel blocks of a current picture in a video sequence. The video codec identifies one or more prediction candidates as a shared candidate list based on the spatial or temporal proximity of the area defined by the shared boundary. The video codec encodes and decodes one or more pixel blocks surrounded by the shared boundary by using one or more prediction candidates selected from the shared candidate list. When encoding one or more pixel blocks, a first pixel block and a second pixel block can be encoded in parallel by using the shared candidate list.

[0011] In some embodiments, the area defined by the shared boundary is part of a coding tree unit (CTU), the shared boundary corresponds to the root of a subtree of the CTU, and the pixel block being encoded corresponds to a leaf CU of the CTU. In some embodiments, the shared candidate list includes a motion vector that is used to encode adjacent blocks of the area defined by the shared boundary. The area may correspond to a CU, and the shared candidate list is a merge or AMVP candidate list of the CU. The motion vectors included in the shared candidate list may include various types of merge or AMVP candidates, such as affine candidates, IBC candidates, sub-PU candidates, history-based candidates, non-adjacent candidates, and the like.

[0012] In some embodiments, a shared boundary is identified by traversing a coding tree unit (CTU) that is split into a hierarchy of coding units (CUs) to identify a CU that is greater than or equal to a threshold and that is a parent CU of a child CU that is less than a threshold. In some embodiments, a shared boundary is identified by traversing a coding tree unit (CTU) that is split into a hierarchy of coding units (CUs) to identify a CU that is less than or equal to a threshold and that is a child CU of a parent CU that is greater than a threshold.

Brief Description of the Drawings

[0013] The accompanying drawings are included to provide a further understanding of the present disclosure and are incorporated into and constitute a part of the present disclosure. The accompanying drawings illustrate embodiments of the present disclosure and together with the description are used to explain the principles of the present disclosure. It is understood that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to the size in actual implementation in order to clearly illustrate the concepts of the present disclosure.

[0014] Figure 1 A coding tree built on a quadtree (QT) partition structure is shown, which represents the partitioning of a coding tree unit (CTU) into CUs.

[0015] Figure 2 Partitioning of coding units (CUs) by binary tree partitioning is conceptually shown.

[0016] Figure 3 Partitioning of a CU by quadtree partitioning and binary tree partitioning is conceptually illustrated.

[0017] Figure 4 Several partitioning types or modes are shown for partitioning CTUs in the MTT structure.

[0018] Figure 5 A decision tree is shown for signaling the partition structure of a CTU in some embodiments.

[0019] Figure 6MVP candidates set for inter prediction mode are shown.

[0020] Figure 7 A merge candidate list including merged bi-predictive merge candidates is shown.

[0021] Figure 8 A merge candidate list including scaled merge candidates is shown.

[0022] Fig. 9 An example of adding a zero vector candidate to a merge candidate list or an AMVP candidate list is shown.

[0023] Fig.10 A four-parameter affine motion model is shown.

[0024] Fig.11 The MVP derivation for the affine inter mode is shown.

[0025] Fig.12 Several examples are shown for defining or identifying sharing boundaries for a sharing candidate list.

[0026] Fig.13 Subtrees of the partition tree are shown, corresponding to CUs in the sharing boundary that can be encoded by the sharing candidate list.

[0027] Fig.14 Sharing boundaries used to identify a sharing candidate list are shown.

[0028] Fig.15a and Fig.15b The use of a CU size threshold to identify a sharing boundary of a sharing candidate list is shown.

[0029] Fig.16 An example of a group of CU nodes is shown.

[0030] Fig.17 An example video encoder is shown that can use a shared candidate list to encode multiple CUs within a CTU.

[0031] Fig.18 A portion of a video encoder's implementation of a shared candidate list is shown.

[0032] Fig.19 The process of encoding multiple CUs using a shared candidate list is conceptually illustrated.

[0033] Fig. 20 An example video decoder implementing a shared candidate list is shown.

[0034] Fig.21 A portion of a video decoder implementing a shared candidate list is shown.

[0035] Fig. 22The process of decoding multiple CUs using a shared candidate list is conceptually illustrated.

[0036] Fig.23 An electronic system for implementing some embodiments of the present disclosure is conceptually illustrated. [Specific implementation method]

[0037] In the detailed description below, many specific details are set forth by way of example to provide a thorough understanding of the relevant teachings. Any changes, derivations, and / or extensions based on the teachings described herein are within the scope of protection of the present disclosure. In some cases, well-known methods, processes, components, and / or circuits related to one or more example implementations disclosed herein may be described at a relatively high level without detailed description to avoid unnecessary confusion of various aspects of the teachings of the present disclosure.

[0038] I. Partition Structure

[0039] In HEVC, pictures consist of slices, and slices consist of CTUs. CTUs are squares of size 8x8, 16x16, 32x32, and 64x64. One CTU is divided into several coding units (CUs). A quadtree structure is used to divide CTUs. CTU size is MxM (M is one of the values ​​64, 32, or 16). A CTU can be a single CU or divided into 4 units of size M / 2xM / 2, which are coding tree nodes. If the units are leaf nodes, they become CUs. Otherwise, the quadtree can be split further until the size of the node reaches the minimum CU size specified in the SPS. Figure 1 The CTU is divided into a quadtree. The solid line is the CU boundary. There are one or more PUs (prediction units) in each CU.

[0040] PU is coupled with CU and is a basic block for sharing prediction information. Inside each PU, the same prediction process is applied. Depending on the PU partition type, CU can be divided into 1, 2 or 4 PUs. PU can only be split once. Alternatively, a binary tree (BT) partition structure can be used. Specifically, a block can be recursively divided into 2 smaller blocks. Symmetrical horizontal and vertical partitioning is the most effective and simplest type of partitioning. In some embodiments, only these two types of partitioning are used. The binary tree partitioning process can be recursively divided until the width or height of the partitioned block reaches the minimum block width or height that can be defined in the video bitstream with high-level syntax.

[0041] Figure 2An example of the partitioning process (left) and its binary tree (right) is shown. In each partitioned non-leaf node of the binary tree, a flag indicates whether horizontal or vertical is used, 0 indicates horizontal partitioning, and 1 indicates vertical partitioning. The binary tree partitioning structure can be used to partition a CTU into a CU, that is, the root node is the CTU and the leaf node is the CU. And for simplicity, as another embodiment, there is no further partitioning from the CU to the PU. This means that the CU is equal to the PU, and therefore, it is equal to the leaf node of the binary tree is the basic unit of prediction.

[0042] In some embodiments, a QTBT structure (quadtree plus binary tree structure) is used. It combines a quadtree and a binary tree. In the QTBT structure, first, the block is partitioned by a quadtree partitioning process, and the quadtree (QT) partitioning process can be iterated until the size reaches the minimum leaf node size. Secondly, if the leaf quadtree block is not larger than the maximum allowed binary tree root node size, the leaf quadtree block can be further divided into a binary tree (BT) partition, and the binary partitioning can be iterated until the width or height of the partition block reaches the minimum allowed width or height, or the binary tree partition depth reaches the maximum allowed depth. Figure 3 An example of a QTBT structure is shown. The QTBT structure can be used to partition a CTU into a CU, that is, the root node is a CTU divided into multiple CUs by the QTBT structure, and the CU is further processed by prediction and transform coding. And for simplicity, as another embodiment, there is no further partitioning from CU to PU. This means that CU is equal to PU, and therefore, it is equal to the leaf node of the QTBT tree is the basic unit for prediction.

[0043] For I slices, the QTBT structure is applied to luma and chroma separately. For P and B slices, the QTBT structure is applied to both luma and chroma (except when chroma reaches certain minimum sizes). In other words, in an I slice, the block partition tree of the QTBT structure is different between the luma CTB and the two chroma CTBs. Specifically, the luma CTB has a block partition of the QTBT structure, and the two chroma coding tree units (CTBs) have a block partition of another QTBT structure.

[0044] Compared with the quadtree (QT) structure in HEVC, flexible CU structures such as quadtree-binary tree (QTBT) show good coding performance. Figure 3 As shown, in QTBT, CTU is first partitioned by a quadtree structure. The quadtree leaf nodes are further partitioned by a binary tree structure. In order to recursively divide a block into two smaller blocks, in addition to the conventional symmetric horizontal and vertical partition types, asymmetric horizontal and vertical partition types can also be selected. After constructing the binary tree structure, the binary tree leaf nodes are represented as CUs and can be used for prediction and transformation without any further partitioning.

[0045] To further support more partition shapes for more flexible partitioning, the ternary tree (TT) partitioning method is designed to capture objects located at the center of the block, while the quadtree (QT) and binary tree (BT) partitioning methods always partition along the block center.

[0046] Multi-Type-Tree (MTT) block partitioning extends the concept of a two-level tree structure in QTBT by allowing binary and ternary tree partitioning methods in the second level of MTT. The two tree levels in MTT are called region tree (RT) and prediction tree (PT). The first-level RT is always a quadtree (QT) partition, while the second-level PT can be a binary tree (BT) partition or a ternary tree (TT) partition. For example, a CTU is first partitioned by RT, which is a QT partition, and each RT leaf node can be further divided by PT, which is a BT or TT partition. Blocks partitioned by PT can be further divided by PT until the maximum PT depth is reached. For example, a block can be first partitioned by vertical BT partitioning to generate left and right subblocks, and the left subblock is further divided by horizontal TT partitioning, while the right subblock is further divided by horizontal BT partitioning. PT leaf nodes are basic CUs used for prediction and transformation and are not further divided.

[0047] Figure 4 Several partition types or modes (a)-(e) for partitioning CTUs in an MTT structure are shown. Partition types (a), (b), and (c) correspond to quadtree partitioning, vertical binary tree partitioning, and horizontal binary tree partitioning, respectively. Partition types (d) and (e) are called ternary tree (or ternary tree) partitioning types, which can divide a block into three smaller blocks. The three smaller blocks of the ternary tree partition have a reduced size in one spatial dimension while maintaining the same size in another spatial dimension. By allowing one-quarter vertical or horizontal partitions, the ternary tree partitioning method can provide the ability to locate small objects faster along block boundaries.

[0048] Figure 5An example of tree signaling for block partitioning according to MTT block partitioning is shown. RT signaling can be similar to quadtree signaling in QTBT block partitioning. In order to signal a PT node, an additional bit sub-bin is signaled to indicate whether it is a binary tree partition or a ternary tree partition. For a block partitioned by RT, a first bit sub-bin is signaled to indicate whether there is another RT partition, and if the block is not further partitioned by RT (i.e., the first bit sub-bin is 0), a second bit sub-bin is signaled to indicate whether there is a PT partition. If the block is not further partitioned by PT (i.e., the second bit sub-bin is 0), the block is a leaf node. If the block is further partitioned by PT (i.e., the second bit sub-bin is 1), a third bit sub-bin is sent to indicate horizontal or vertical partitioning, and then a fourth bit sub-bin is sent to distinguish between binary tree (BT) or ternary tree (TT) partitions.

[0049] After constructing the MTT block partition, the MTT leaf node is a CU and can be used for prediction and transformation without further partitioning. In MTT, the tree structure is coded separately for luma and chroma in I slices, and is applied to luma and chroma in P and B slices simultaneously (except when certain minimum sizes of chroma are reached). That is, in an I slice, the luma CTB has a block partition of its QTBT structure, and the two chroma CTBs have a block partition of another QTBT structure.

[0050] II. Inter-prediction mode candidates

[0051] a. Merge mode and AMVP mode

[0052] In order to obtain the best coding efficiency of the hybrid coding architecture, HEVC uses intra prediction and / or inter prediction mode for each PU. For intra prediction mode, spatially adjacent reconstructed pixels can be used to generate directional predictions in 35 directions. For inter prediction mode, motion information is used to reconstruct the temporal reference frame, which is used to generate motion compensated predictions. Motion information may include motion vectors, motion vector predictors, motion vector differences, reference indexes for selecting reference frames, etc.

[0053] When a PU is encoded in inter-frame AMVP mode, motion compensated prediction is performed using the transmitted motion vector difference (MVD), which can be used together with the motion vector predictor (MVP) to derive the motion vector (MV). In order to determine the MVP in inter-frame AMVP mode, the advanced motion vector prediction (AMVP) scheme is used to select a motion vector predictor from an AMVP candidate set including two spatial MVPs and one temporal MVP. Therefore, in AMVP mode, the MVP index and the corresponding MVD of the MVP need to be encoded and transmitted. In addition, the inter-frame prediction direction that specifies the prediction direction in the bidirectional prediction and unidirectional prediction of list 0 (L0) and list 1 (L1) is also specified and sent, as well as the reference frame index for each list.

[0054] When a PU is encoded in Skip or Merge mode, no motion information is sent except the Mergeindex of the selected candidate. This is because the "Skip" and "Merge" modes use motion inference methods (MV=MVP+MVD, where MVD is zero) to obtain motion information from spatial neighboring blocks (spatial candidates) or temporal blocks (temporal candidates) of the same-positioned picture, where the same-positioned picture is the first reference picture in List 0 or List 1, which is signaled in the slice header. In the case of Skip PU, the residual signal is also omitted. In order to determine the Mergeindex for Skip and Merge mode, a merge scheme is used to select a motion vector predictor from a merge candidate set containing four spatial MVPs and one temporal MVP.

[0055] Figure 6 MVP candidate sets for inter prediction modes (i.e., skip, merge, and AMVP) are shown. The figure shows a current block 600 of a video picture or frame being encoded or decoded. The current block 600 (which can be a PU or CU) references neighboring blocks to derive spatial and temporal MVPs into an MVP list or candidate list for AMVP mode, merge mode, or skip mode.

[0056] For AMVP mode, the left MVP is the first available one among A0 and A1, the top MVP is the first available one among B0, B1 and B2, and the time MVP is T BR or T CTR The first available one (use T first BR If there is no T BR , then use T CTR). If the left MVP is not available and the top MVP is not a scaled MVP, a second top MVP can be derived when there is a scaled MVP between B0, B1, and B2. Therefore, after the derivation process of two spatial MVPs and one temporal MVP, only the first two MVPs can be included in the candidate list. If the number of available MVPs is less than two after removing redundancy, a zero vector candidate is added to the candidate list.

[0057] For skip mode and merge mode, up to four spatial merge indices are derived from A0, A1, B0, and B1, and from T BR or T CTR Export a time merge index (first use T BR , if T BR If not available, use T CTR ). If any of the four spatial merge indexes is unavailable, position B2 is used to derive the merge index as a replacement. After deriving four spatial merge indexes and one temporal merge index, the redundant merge index is deleted. If the number of non-redundant merge indexes is less than five, additional candidates can be derived from the original candidates and added to the candidate list. There are three types of derived candidates:

[0058] 1. Combined bidirectional prediction merge candidate (derived candidate type 1)

[0059] 2. Scaled bidirectional prediction merge candidates (derive candidate type 2)

[0060] 3. Zero vector merge / AMVP candidate (derive candidate type 3)

[0061] For derivation candidate type 1, a combined bi-predictive merge candidate is created by combining the original merge candidates. Specifically, if the current slice is a B slice, a further merge candidate can be generated by combining candidates from list 0 and list 1. Figure 7 A merge candidate list including a merged bi-predictive merge candidate is shown. As shown, two original candidates with mvL0 (motion vector in list 0) and refIdxL0 (reference picture index in list 0) or mvL1 (motion vector in list 1) and refIdxL1 (reference picture index in list 1) are used to create a bi-predictive merge candidate.

[0062] For derivation candidate type 2, a scaled merge candidate is created by scaling the original merge candidate. Figure 8A merge candidate list including scaled merge candidates is shown. As shown, the original merge candidate has mvLX (motion vector in list X, X can be 0 or 1) and refIdxLX (reference picture index in list X, X can be 0 or 1). For example, the original candidate A is a list 0 unidirectional prediction MV with mvL0_A and reference picture index ref0. Candidate A is first copied to list L1 with reference picture index ref0'. The scaled MV mvL0'_A is calculated by scaling mvL0_A based on ref0 and ref0'. A scaled bidirectional prediction merge candidate with mvL0_A and ref0 in list L0, and mvL0'_A and ref0' in list L1 is created and added to the merge candidate list. Similarly, a scaled bidirectional prediction merge candidate with mvL1'_A and ref1' in list 0, and mvL1_A, ref1 in list 1 is created and added to the merge candidate list.

[0063] For derived candidate type 3, a zero vector candidate is created by combining the zero vector and the reference index. If the created zero vector candidate is not a duplicate, it is added to the merge / AMVP candidate list. Fig. 9 An example of adding a zero vector candidate to a merge candidate list or an AMVP candidate list is shown.

[0064] b. Sub-PU Temporal Motion Vector Prediction (ATMVP)

[0065] ATMVP (Advanced Temporal Motion Vector Prediction) mode (or also known as Sub-PU Temporal Motion Vector Prediction (SbTMVP)) is a sub-PU based mode for merge candidates. ATMVP mode uses spatial neighbors to obtain the initial vector, which is used to obtain the coordinates of the collocated block on the collocated picture. The sub-CU (usually 4x4 or 8x8) motion information of the collocated block on the collocated picture is extracted and filled into the sub-CU (usually 4x4 or 8x8) motion buffer of the current merge candidate. There are several implementations of ATMVP. The description of ATMVP is as follows: Joint Video Exploration Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11: 3rd Meeting: May 26-June 1, 2016, Geneva, Switzerland, Title: "Algorithm Description of Joint Exploration Test Model 3". ATMVP is also described in: ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, Joint Video Experts Group (JVET) 11th Meeting: Ljubljana, SI, 10-18 July 2018, JVET-K0346-v3, title: “CE4-related: One simplified design of advanced temporal motion vector prediction (ATMVP)”.

[0066] c. Spatial-Temporal Motion Vector Prediction (STMVP)

[0067] STMVP mode is a sub-PU based mode for merging candidates. The motion vectors of the sub-PUs are generated recursively in raster scan order. The MV derivation of the current sub-PU determines two spatial neighbors and one temporal neighbor before MV scaling. After extracting and scaling the MV, all available motion vectors (up to 3) are averaged and assigned as the motion vector of the current sub-PU. The description of STMVP is as follows: Joint Video Exploration Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11: 3rd Meeting: Geneva, Switzerland, May 26-June 1, 2016, title: "Algorithm Description of Joint Exploration Test Model 3", in particular Section 2.3.1.2: Spatial-Temporal Motion Vector Prediction (STMVP).

[0068] d. History-based consolidation model and AMVP

[0069] A video codec implementing a history-based merge mode may store merge candidates for some previous CUs in a history array. For a CU currently being encoded or decoded, the video codec may enhance the original merge mode candidates using one or more candidates in the history array. The history-based approach also applies to the AMVP candidate list. The history-based merge mode is described in the following document: Joint Video Experts Group (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 11th Meeting: Ljubljana, SI, July 10-18, 2018, document: JVET-K0104, “CE4-related: History-based Motion Vector Prediction”.

[0070] e. Non-adjacent merging mode and AMVP

[0071] Non-adjacent merge candidates use some spatial candidates far away from the current CU. Non-adjacent based methods can also be applied to the AMVP candidate list. An example of non-adjacent merge mode is as follows: Joint Video Experts Group (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC29 / WG 11, 11th Meeting: Ljubljana, SI, July 10-18, 2018, Document: JVET-K0228, Title: “CE 4-2.1: Adding non-adjacent spatial merge candidates”. An example of non-adjacent merge candidates is as follows: Joint Video Experts Group (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 11th Meeting: Ljubljana, SI, July 10-18, 2018, Document: JVET-K0286, Title: “CE4: Additional merge candidates (Test 4.2.13)”.

[0072] f. Affine merge mode

[0073] HEVC only uses the translational motion model for motion compensated prediction. There are many other types of motion in the real world, such as zooming in and out, rotation, perspective motion, and other irregular motions. Some of these other types of motion can be represented by affine transformations or affine motions, which can preserve points, lines, and planes. Affine transformations do not necessarily preserve the angles between lines or the distances between points, but they do preserve the ratio of the distances between points on a line. When an affine motion block is moving, the motion vector field (vectorfield) of the block can be described by two control point motion vectors or four parameters, as shown below:

[0074]

[0075] The transformed block is a rectangular block. The motion vector field of each point in this motion block can be described by the following formula:

[0076]

[0077] Among them, (v 0x , v 0y ) is the motion vector of the control point in the upper left corner, (v 1x , v 1y ) is another control point motion vector of the upper right corner of the block. In some embodiments, for inter-mode coded CUs, when the CU size is equal to or greater than 16×16, affine_flag is signaled to indicate whether affine inter mode is applied. If the current CU is in affine inter mode, the candidate MVP pair list is constructed using adjacent valid reconstructed blocks. Fig.10 A four-parameter affine motion model is shown.

[0078] Fig.11 The MVP derivation for the affine inter mode is shown. Fig.11 As shown, v0 is selected from the motion vectors of blocks A0, A1 or A2, and v1 is selected from the motion vectors of blocks B0 and B1. The index of the candidate MVP pair is signaled in the bitstream. The MV difference (MVD) of the two control points is encoded in the bitstream.

[0079] In some embodiments, if the current PU is a merged PU, the adjacent five blocks ( Fig.11 If yes, then affine_flag is signaled to indicate whether the current PU is in affine mode. When the current PU is encoded in affine merge mode, the first block from the valid neighboring reconstructed blocks is encoded in affine mode. Fig.11 As shown, the order of selecting candidate blocks is from left, top, top right, bottom left to top left (C0→B0→B1→C1→A0). The affine parameters of the first affine coding block are used to derive v0 and v1 of the current PU.

[0080] g. Current Picture Referencing (CPR)

[0081] Current Picture Reference (CPR) is also known as Intra Block Copy (IBC). CPR (or IBC) motion vector refers to the motion vector of the reference sample that has been reconstructed in the current picture. CPR coded CUs are signaled as inter-coded blocks. The luminance motion (or block) vector of a CPR coded CU must be integer precision. The chrominance motion vectors are also clipped to integer precision. When used in conjunction with AMVR, CPR mode can switch between 1-pel and 4-pel motion vector precision. The current picture is at the end of the reference picture list L0. To reduce memory consumption and decoder complexity, CPR in VTM3 only allows the use of the reconstructed portion of the current CTU. This restriction allows the CPR mode to be implemented using local on-chip memory on the hardware.

[0082] On the encoder side, hash-based motion estimation is performed for CPR. The encoder performs RD checks on blocks with a width or height no greater than 16 luma samples. For non-merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return a valid candidate, a block matching-based local search is performed. In the hash-based search, the hash key matching (32-bit CRC) between the current block and the reference block is extended to all allowed block sizes. The hash key calculation for each position in the current picture is based on 4x4 sub-blocks. For current blocks of larger sizes, the hash key is determined to match the hash key of the reference block when all hash keys of all 4×4 sub-blocks match the hash keys in the corresponding reference positions. If the hash keys of multiple reference blocks are found to match the hash key of the current block, the block vector cost of each matching reference is calculated, and then the one with the smallest cost is selected.

[0083] In a block match search, the search range is set to N samples to the left and top of the current block in the current CTU. At the beginning of a CTU, if there is no temporal reference picture, the value of N is initialized to 128. If there is at least one temporal reference picture, the value of N is initialized to 64. The hash hit rate is defined as the percentage of samples in a CTU for which a match is found using a hash-based search. When encoding the current CTU, if the hash hit rate is less than 5%, N is reduced by half.

[0084] III. Shared Candidate List

[0085] In order to simplify the complexity of codec operation, some embodiments provide a method for encoding or decoding multiple pixel blocks using a shared candidate list. The candidate list refers to a merge mode or AMVP mode candidate list, or other types of prediction candidate lists (e.g., DMVR or bi-lateral refinement candidate lists, affine merge mode, sub-block merge mode, affine inter / AMVP mode, IBC merge, IBC AMVP). The shared candidate list is a candidate list generated based on a boundary larger than a leaf CU (e.g., a parent CU, or a root of a subtree in a QTBT or QTBTTT tree, or a node of a QT tree), and the generated candidate list can be shared by all leaf CUs within the boundary or within the subtree.

[0086] In some embodiments, the shared candidate list is a candidate list shared by CUs contained in or within a common shared boundary (also referred to as a shared boundary). For some embodiments, a "shared boundary" is defined as a rectangular area of ​​the smallest block aligned inside a picture (the smallest block is typically 4x4). Each CU within a "shared boundary" can use a common shared candidate list generated based on the "shared boundary". Specifically, the candidates for the shared candidate list include spatially adjacent positions and temporally adjacent positions based on the "shared boundary", or an area defined by a shared boundary. A shared boundary can be a square block or a non-square block. The size / depth / width / height of the shared boundary can be signaled in the bitstream at a sequence level, a picture level, or a slice level.

[0087] Fig.12 Several examples of sharing boundaries for defining or identifying a sharing candidate list are shown. These examples include: a square sharing boundary 1210 corresponding to an 8x8 CU partitioned into four 4x4 CUs by QT; a square sharing boundary 1220 corresponding to an 8x8 CU partitioned into two 4x8 CUs by BT; a rectangular sharing boundary 1230 corresponding to a 4x16 root CU partitioned into two 4x8CUs by BT; and a rectangular sharing boundary 1240 corresponding to a 4x16 CU partitioned into two 4x4 CUs and one 4x8 CU by TT. The CU corresponding to the sharing boundary is also referred to as the root CU of the sharing boundary.

[0088] In some embodiments, the shared candidate list is a candidate list shared by CUs within a subtree.A "subtree" may refer to a QTBT, a subtree of a QTBTTT, or another type of split tree. Fig.13A subtree of a partition tree is shown, which corresponds to a CU in a shared boundary that can be encoded by a shared candidate list. The figure shows a CTU 1300 whose partition structure is represented by a hierarchical tree 1350, which is a QTBT or QTBTTT partition tree. Within CTU 1300, a shared boundary 1310 defines a root CU, which is divided into several sub-CUs with various partition depths. The sub-CUs contained in the shared boundary 1310 correspond to nodes in a subtree 1360 in the partition tree 1350, and the leaf nodes in the subtree 1360 correspond to leaf CUs in the shared boundary 1310. In other words, the shared candidate list is shared by the leaf nodes of the subtree 1360.

[0089] The shared candidate list may be generated based on a shared block boundary (e.g., a root CU boundary such as shared boundary 1310 or subtree 1360). The shared candidate list is reused for some or all leaf CUs within the subtree. The shared candidate list is generated for the root of the subtree, i.e., the spatial and temporal neighboring positions of the candidates of the shared candidate list are identified based on the rectangular boundary (or shared boundary) of the root CU or the subtree.

[0090] The candidates of the shared candidate list are prediction candidates identified based on spatial or temporal proximity of the region defined by the shared boundary. Then, one or more CUs surrounded by the shared boundary are encoded using one or more prediction candidates selected from the shared candidate list.

[0091] Fig.14 A shared boundary 1400 for identifying a shared candidate list is shown. The shared boundary 1400 defines an area 1410. The area 1410 may correspond to a CU. The area 1410 may be part of a partition tree or CTU (e.g., BT, QT, MTT, etc.) and may be divided into sub-CUs such as CUs 1411, 1412, 1413, and 1414. The sub-CU may be a leaf CU that cannot be further divided. The sub-CU may also be divided into sub-CUs of a larger partition depth until a leaf CU is reached. In this example, the area 1410 defined by the shared boundary 1400 (or a root CU corresponding to the area 1410) is divided into several leaf CUs, including leaf CUs 1421, 1422, and 1423.

[0092] Leaf-CUs 1421, 1422, and 1423 are all encoded using a shared candidate list identified or defined based on the shared boundary 1400. The shared candidate list may be a merge mode list, an AMVP list, an IBC merge list, an IBC AMVP list, or other types of prediction candidate lists. The shared candidate list may include prediction candidate lists from neighbors of region 1410 (e.g., spatial MVPs from spatial neighbors A0, A1, B0, B1, B2 and prediction candidate lists from temporal neighbors T BR , TCTR The shared candidate list may also include one or more CPR or IBC candidates that reference reconstructed reference samples in the current picture.

[0093] Some embodiments of the present disclosure provide methods for identifying a shared boundary. In some embodiments, a CU size threshold SHARED_THD is defined for identifying a shared boundary. For any leaf CU, the largest root CU with a CU size <= SHARED_THD will be used as the root of the shared subtree, or the root of a subtree using a shared candidate list. Fig.12 In the example of , for the shared candidate list at the shared boundary 1240, two 4x4 CUs and one 4x8 CU belong to the same 4x16 CU. In this example, SHARED_THD is 64, so the 4x16 CU (size 64) is the root of the "shared subtree" whose boundary is the shared boundary 1240 (because the area defined by the shared boundary 1240 is the 4x16 CU). Therefore, the merge list is generated based on the 4x16 CU and is shared by all sub-CUs of the 4x16CU (in this example, 2 4x4 CUs and one 4x8 CU).

[0094] Fig.15a and Fig.15b The use of a CU size threshold to identify a shared boundary of a shared candidate list is shown. The example uses 32 as the CU size threshold (SHARED_THD). In some embodiments, identifying a shared boundary includes traversing the CTU to identify a CU that is less than or equal to the threshold and that is a child CU of a parent CU that is greater than the threshold. In some embodiments, identifying a shared boundary includes traversing the CTU to identify a CU that is greater than or equal to the threshold and that is a parent CU of a child CU that is less than the threshold. The figure shows identifying shared boundaries in three CTUs or CUs 1510, 1520, and 1530.

[0095] Fig.15a It is shown that the shared boundary is identified by identifying CUs that are less than or equal to SHARED_THD (32) and the identified CUs are child CUs of a parent CU that is greater than SHARED_THD. The video codec may traverse each CTU from a leaf CU to a CTU root.

[0096] For CTU or CU 1510, the traversal encounters a 4x4 CU 1511 of size 16 less than SHARED_THD 32, and CU 1512 is a QT child of an 8x8 CU 1512 of size 64 greater than 32. As a result, the video encoder identifies the 4x4 CU 1511 as the root CU of the shared candidate list, and identifies its boundary 1515 as Fig.15a Shared boundaries in the embodiment shown.

[0097] For a CTU or CU 1520, the traversal encounters a 4x4 CU 1521 of size 16, which is less than 32. The 4x4 CU 1521 is a BT child of an 8x4 CU 1522 of size 32, which is less than 32. The traversal continues to the 8x4 CU 1522, whose size is equal to 32. Therefore, the video encoder identifies the 8x4 CU 1522 as the root CU of the shared candidate list and identifies its boundary 1525 as Fig.15a Shared boundaries in the embodiment shown.

[0098] For a CTU or CU 1530, the traversal encounters a 4x4 CU 1531 of size 16 less than 32, and CU 1531 is a TT child of a 4x16 CU 1532 of size 64 greater than 32. As a result, Fig.15a In the illustrated embodiment, the video codec identifies the 4x4 CU 1531 as the root CU of the sharing candidate list and its boundary 1535 as the sharing boundary.

[0099] Fig.15b It is shown that the shared boundary is identified by identifying a CU that is greater than or equal to SHARED_THD and the identified CU is a parent CU of a child CU that is less than SHARED_THD.The video encoder may traverse each CTU from the CTU root to the leaf CU.

[0100] For CTU or CU 1510, the traversal encounters 8x8 CU 1512 whose size is 64, which is greater than 32. 8x8 CU 1512 is the QT parent of 4x4 CU 1511 whose size is 16, which is less than 32. As a result, in Fig.15b In the illustrated embodiment, the video encoder identifies the 8x8 CU 1512 as the root CU of the sharing candidate list and its boundary 1517 as the sharing boundary.

[0101] For CTU or CU 1520, the traversal encounters 8x4 CU 1522 of size 32. 8x4 CU 1522 is the BT parent of 4x4 CU 1521 of size 16 less than 32. The result is Fig.15bIn the illustrated embodiment, the video codec identifies the 8x4 CU 1522 as the root CU of the sharing candidate list and its boundary 1527 as the sharing boundary.

[0102] For CTU or CU 1530, the traversal encounters a 4x16 CU 1532 whose size is 64, which is greater than 32. The 4x16 CU 1532 is the TT parent of the 4x4 CU 1531 whose size is 16, which is less than 32. As a result, in the embodiment shown in FIG. 15b, the video encoder identifies the 4x16 CU 1532 as the root CU of the shared candidate list, and identifies its boundary 1537 as a shared boundary.

[0103] In some embodiments, the CU size threshold for identifying the shared boundary SHARED_THD is fixed and predefined for all picture sizes and all bitstreams. In some embodiments, SHARED_THD may vary depending on the picture size, i.e., SHARED_THD may be different for different picture sizes. In some embodiments, SHARED_THD may be signaled from the encoder to the decoder. The minimum size of the unit in signaling SHARED_THD may also be encoded separately at the sequence level, picture level, slice level, or PU level. In some embodiments, the selected or identified shared subtree root is required to be completely within the current picture. If the subtree root has some pixels outside the picture boundary, the subtree will not be used as a shared subtree root.

[0104] In some embodiments, the root CU (or parent CU) or size / depth / shape / width / height of the shared boundary is used to derive the shared candidate list. When deriving the shared candidate list, for any position-based derivation (e.g., deriving the reference block position based on the current block / CU / PU position / size / depth / shape / width / height), the position and shape / size / depth / width / height of the root CU or shared boundary are used.

[0105] In some embodiments, the size / depth / shape / area / width / height of the root CU or sharing boundary may be predefined or signaled at a sequence / picture / slice / tile / CTU row level or a predefined area (e.g., CTU or CTU row). The sharing boundary of the root CU or sharing candidate list may be square or non-square. The size / depth / shape / area / width / height of the root CU or sharing boundary may be predefined and / or depend on the size / depth / width / height of the input picture.

[0106] In some embodiments, if the current CU is larger than or equal to a defined threshold region / size / shape / area / width / height, and one of the sub-partitions or all of the sub-partitions or some of the sub-partitions is smaller than the defined threshold region / size / shape / area / width / height, then the current CU is a root CU or a shared boundary. In some embodiments, if the depth of the current CU is less than (e.g., shallower than) or equal to a defined threshold depth, and the depth of one of the sub-partitions or all of the sub-partitions or some of the sub-partitions is greater than (e.g., deeper than) a defined threshold depth, then the current CU is a root CU or a shared boundary.

[0107] In some embodiments, if the current CU is less than or equal to the defined threshold region / size / shape / area / width / height, and the parent CU of the current CU is larger than the defined threshold region / size / shape / area / width / height, the current CU is the root CU of the shared candidate list (i.e., shared boundary). For example, if the defined threshold region is 1024 and the current CU size is 64x32 (width is 64 and height is 32), vertical TT partitioning is used (64x32 CU is divided into 16x32 sub-CU, 32x32 sub-CU and 16×32 sub-CU), and in one embodiment, the 64×32 current CU is the root CU. The sub-CUs in this 64x32 CU use a shared candidate list based on the 64x32CU. The 64x32 current CU may not be identified as a root CU. Instead, 16x32 sub-CUs, 32x32 sub-CUs and 16x32 sub-CUs are identified as root CUs. In some embodiments, if the depth of the current CU is greater than (eg, deeper than) or equal to the defined depth, and the parent CU is less than (eg, shallower than) the defined depth, then the current CU is a root CU.

[0108] In some embodiments, when TT partitioning is performed on the current CU into three partitions of different sizes, the root CU or shared boundary area / size / depth / shape / area / width / height may be different in different TT partitions. For example, for a current CU divided into the first, second, and third partitions by TT, for the second partition, the threshold of the root CU or shared boundary area / size / depth / shape / area / width / height is the same as that of the CU. However, for the first and third partitions, the threshold of the root CU or shared boundary area / size / shape / area / width / height (or the threshold for identifying it) may be divided by 2 (or the depth increased by 1) relative to the second partition.

[0109] In some embodiments, a root CU or shared boundary is defined for a QT partition or QT partition CU. If the leaf QT CU is equal to or greater than a defined threshold area / size / QT depth / shape / area / width / height, the root CU or shared boundary is identified or defined as the leaf QT CU area / size / QT depth / shape / area / width / height. All sub-CUs within the QT leaf CU (e.g., partitioned or partitioned by BT or TT) use the QT leaf CU as the root CU or shared boundary. If the QT CU (not a QT leaf CU) is equal to a defined threshold area / size / QT depth / shape / area / width / height, this QT CU is used as the root CU or shared boundary. All sub-CUs within the QT CU (e.g., partitioned or partitioned by QT, BT or TT) use the QT CU as the root CU or shared boundary. In one example, the area / size / QT depth / shape / area / width / height of the root CU or shared boundary is used to derive the reference block position. In another example, the area / size / QT depth / shape / area / width / height of the current CU is used to derive the reference block position. If the reference block position is inside the root CU or shared boundary, the reference block position is moved to the outside of the root CU or shared boundary. In another example, the region / size / QT depth / shape / area / width / height of the current CU is used to derive the reference block position. If the reference block position is within the root CU or shared boundary, the reference block is not used.

[0110] In the above depth (or the defined threshold depth for identifying the sharing boundary of the root CU or the sharing candidate list), the depth may be equal to (((A*QT depth)>>C)+((B*MT depth)>>D)+E)>>F+G or ((((A*QT depth)>>C)+((B*BT depth)>>D)+E)>>F+G, where A, B, C, D, E, F, G are integers. For example, the depth may be equal to 2*QT depth+MT depth or 2*QT depth+BT depth or QT depth+MT depth or QT depth+BT depth.

[0111] Some embodiments provide a threshold definition (or a method for defining a threshold) for a shared candidate list or non-square merge estimation region (MER). Let the shared candidate (or MER) threshold be denoted by T. The shared boundary is an ancestor (e.g., parent) node in the CU partition tree, denoted by ANC_NODE. The shared boundary (or ANC_NODE) ​​is selected to satisfy the following conditions:

[0112] Condition 1: ANC_NODE (size) <= T

[0113] Condition 2: ANC_NODE's parent object (size) > T

[0114] Condition 3: The pixels of the ANC_NODE are within the current picture boundary. The video encoder searches for ANC_NODE that meets these conditions by: (i) tracing back (on the partition tree) from the leaf CU to the CTU root, or (ii) from the CTU root (on the partition tree) down to the leaf CU. In some embodiments, condition 2 may not exist. If the leaf CU is near the picture boundary, for a node, if conditions 1 and 2 are met, but condition 3 is not met, the node will not be an ANC_NODE, and the video codec turns to the child CU to search for ANC_NODE.

[0115] In some embodiments, the determination of the ANC_NODE is a search process from the CTU root down (on the partition tree) to the leaf-CU, and the shared boundary (or ANC_NODE) ​​is selected to satisfy these conditions:

[0116] Condition 1: ANC_NODE (size) >= T.

[0117] Condition 2: For decoding, the size of a splitting child (such as BT split or TT split or QT split) <T。

[0118] Condition 3: The pixels of ANC_NODE are located within the current picture boundary. In some embodiments, condition 1 may not exist. If the leaf CU is near the picture boundary, for a node, if conditions 1 and 2 are met but condition 3 is not met, the node will not be identified as ANC_NODE, and the video encoder will enter the sub-CU to search for ANC_NODE. For condition 2, the minimum partition sub-item of the current CU (if the current CU size = cur_size) is: for QT: cur_size / 4, for TT: cur_size / 4, for BT: cur_size / 2. In some embodiments, if conditions 1 and 2 are met but condition 3 is not met, the current CU is not ANC_NODE, and the video codec goes to the sub-CU to search for a node or sub-CU if conditions 1, 2 and 3 meet ANC_NODE. If conditions 1, 2 and 3 are not all met for a leaf CU, the leaf CU will not have a sharing mode (e.g., there is no sharing candidate list), and the video codec generates a merge mode list for the leaf CU itself. For example, if T=64 and the size of the current node or CU is 128, then on the decoder side, this node will be further divided into TT (child node 1 is 32, child node 2 is 64, and child node 3 is 32), then ANC_NODE is the current node (size 128). For another example, if T=64 and the size of the current node or CU is 128, then if on the decoder side this node is further divided into BT (child node 1 is 64, child node 2 is 64), then the current node is not ANC_NODE.

[0119] In some embodiments, the shared boundary is a CU node group (Group of CU node) of an ancestor (parent) node in the CU partition tree, represented as SHARED_BOUND. A "CU node group" is several non-overlapping CU / nodes (in a CU partition tree node) belonging to a common parent node or a common ancestor node, and these CU nodes can be merged into a rectangular area. In one embodiment, the CUs of the CU node group must all be "level 1" child nodes of the common parent node. In some embodiments, the CUs in the group of CU nodes can have the same ancestor node, but not necessarily a "level 1" common parent node. Fig.16 An example of a "CU node group" is shown. In the figure, a "CU node group" has 2 child CUs occupying half of the parent node. The determination of SHARED_BOUND is a search process from the CTU root down (on the partition tree) to the leaf CU.

[0120] Select a shared boundary (or SHARED_BOUND) to satisfy the following conditions:

[0121] Condition 1: SHARED_BOUND (size) >= T.

[0122] Condition 2: For decoding, a CU node in a "CU node group" <T。

[0123] Condition 3: The pixel of SHARED_BOUND is within the current picture boundary. In some embodiments, condition 1 may not exist near the picture boundary. This is because if the leaf CU is near the picture boundary, condition 1 may be abandoned or discarded near the picture boundary in order to meet condition 3.

[0124] In some embodiments, the shared list concept can be applied to CPR. The merge list of CPR can be shared and generated on a shared boundary or root CU (here the shared boundary refers to a shared root boundary or a shared rectangular boundary). The merge list can include CPR candidates or non-CPR candidates, but the shared list can store both types and can be generated on a shared boundary.

[0125] For dual-tree streams in CPR, in some cases, the luminance will run a leaf CU scan, and the chrominance will run again, that is, a leaf CU scan is performed on both luminance and chrominance. In this case, the shared boundaries of the luminance case and the chrominance case may be different. In some embodiments, a shared list of CPR for the luminance case is generated, and then a shared list of CPR for the chrominance case is generated. That is, the sharing thresholds for luminance and chrominance may be different, and their shared boundaries may be different. For multi-hypothesis merging (multi-hypothesis: merged inter frame + intra frame, or merged inter frame + merged inter frame, or merged inter frame + AMVP inter frame), post-processing is performed on the merged list to remove all CPR candidates. Removing CPR candidates (from the shared candidate list) can also be performed on the shared boundary.

[0126] Some embodiments provide a shared merge index and a shared reference index for merge mode based on a shared candidate list.A "sub-CU for sharing" may refer to a CU within a subtree or within a "sharing boundary" that uses a shared candidate list.

[0127] In order to use shared merge indexes, in merge mode, not only are the merge candidate lists of each "sub-CU for sharing" equal to each other (using shared merge candidate lists), but also the final selected merge indexes of each "sub-CU for sharing" are equal to each other (using shared merge candidate indexes). In order to use shared reference indexes for merge mode, in merge mode, not only are the merge candidate lists of each "sub-CU for sharing" equal to each other (using shared merge candidate lists), but each "sub-CU for sharing" has selected a merge index whose corresponding candidate has a reference index equal to the selected merge indexes of all other CUs of the "sub-CU for sharing".

[0128] For some embodiments, methods of sharing candidate lists, sharing merge indexes, and other shared attributes can be applied to other types of merge list construction methods, such as history-based merge mode construction and non-adjacent merge candidates. That is, shared attribute proposals or shared candidate lists are generally applicable to all merge mode algorithms and AMVP mode algorithms. In addition, in some embodiments, a signaling flag is used to turn on or off the candidate list sharing method. In some embodiments, a signaling flag can be used to indicate whether the shared candidate list is enabled. The minimum size of the unit in the signaling can also be encoded separately at the sequence level, picture level, slice level, or PU level.

[0129] IV. Example Video Encoder

[0130] Fig.17An example video encoder 1700 is shown that can use a shared candidate list to encode multiple CUs within a CTU. As shown, the video encoder 1700 receives an input video signal from a video source 1705 and encodes the signal into a bitstream 1795. The video encoder 1700 has several components or modules for encoding the signal from the video source 1705, including at least some components selected from the following: a transform module 1710, a quantization module 1711, an inverse quantization module 1714, an inverse transform module 1715, an intra-picture estimation module 1720, an intra-frame prediction module 1725, a motion compensation module 1730, a motion estimation module 1735, a loop filter 1745, a reconstructed picture buffer 1750, an MV buffer 1765, and an MV prediction module 1775, and an entropy encoder 1790. The motion compensation module 1730 and the motion estimation module 1735 are part of the inter-frame prediction module 1740.

[0131] In some embodiments, modules 1710 to 1790 are modules of software instructions executed by one or more processing units (e.g., processors) of a computing device or electronic device. In some embodiments, modules 1710-1790 are modules of hardware circuits implemented by one or more integrated circuits (ICs) of an electronic device. Although modules 1710-1790 are illustrated as separate modules, some modules may be combined into a single module.

[0132] The video source 1705 provides a raw video signal that presents pixel data for each video frame without compression. The subtractor 1708 calculates the difference between the raw video pixel data of the video source 1705 and the predicted pixel data 1713 from the motion compensation module 1730 or the intra-frame prediction module (shown as an intra-picture prediction module) 1725. The transform module 1710 converts the difference (or the remaining pixel data or residual signal 1709) into a transform coefficient 1716 (for example, by performing a discrete cosine transform (DCT)). The quantization module 1711 quantizes the transform coefficient into quantized data (or quantized coefficients) 1712, which is encoded into a bit stream 1795 by the entropy encoder 1790.

[0133] The inverse quantization module 1714 inversely quantizes the quantized data (or quantized coefficients) 1712 to obtain transform coefficients, and the inverse transform module 1715 performs an inverse transform on the transform coefficients to generate a reconstructed residual 1719. The reconstructed residual 1719 is added to the predicted pixel data 1713 to generate reconstructed pixel data 1717. In some embodiments, the reconstructed pixel data 1717 is temporarily stored in a line buffer (not shown) for intra-picture prediction and spatial MV prediction. The reconstructed pixels are filtered by the loop filter 1745 and stored in the reconstructed picture buffer 1750. In some embodiments, the reconstructed picture buffer 1750 is a memory external to the video encoder 1700. In some embodiments, the reconstructed picture buffer 1750 is a memory internal to the video encoder 1700.

[0134] The intra-picture estimation module 1720 performs intra-prediction based on the reconstructed pixel data 1717 to generate intra-prediction data. The intra-prediction data is provided to the entropy encoder 1790 to be encoded into a bitstream 1795. The intra-prediction data is also used by the intra-prediction module 1725 to generate predicted pixel data 1713.

[0135] The motion estimation module 1735 performs inter-frame prediction by generating MVs for reference pixel data of previously decoded frames stored in the reconstructed picture buffer 1750. These MVs are provided to the motion compensation module 1730 to generate predicted pixel data.

[0136] Instead of encoding the complete actual MV in the bitstream, the video encoder 1700 generates a predicted MV using MV prediction, and encodes the difference between the MV used for motion compensation and the predicted MV as residual motion data and stores in the bitstream 1795.

[0137] The MV prediction module 1775 generates a predicted MV based on a reference MV generated for encoding a previous video frame (i.e., a motion compensated MV for performing motion compensation). The MV prediction module 1775 retrieves a reference MV from a previous video frame in the MV buffer 1765. The video encoder 1700 stores the MV generated for the current video frame in the MV buffer 1765 as a reference MV for generating a predicted MV.

[0138] The MV prediction module 1775 creates a predicted MV using a reference MV. The predicted MV may be calculated by spatial MV prediction or temporal MV prediction. The entropy encoder 1790 encodes the difference (residual motion data) between the predicted MV and the motion compensated MV (MC MV) of the current frame into a bitstream 1795.

[0139] The entropy encoder 1790 encodes various parameters and data into a bitstream 1795 by using an entropy coding technique such as context adaptive binary arithmetic coding (CABAC) or Huffman coding. The entropy encoder 1790 encodes various header elements, flags, and quantized transform coefficients 1712 and residual motion data as syntax elements into the bitstream 1795. The bitstream 1795 is in turn stored in a storage device or sent to a decoder through a communication medium, such as a network.

[0140] The loop filter 1745 performs a filtering or smoothing operation on the reconstructed pixel data 1717 to reduce encoding artifacts, particularly at the boundaries of pixel blocks. In some embodiments, the filtering operation performed includes sample adaptive offset (SAO). In some embodiments, the filtering operation includes an adaptive loop filter (ALF).

[0141] Fig.18 1700 . The portion of the video encoder 1700 that implements the shared candidate list is illustrated. As shown, the motion compensation module 1730 includes one or more CU motion compensation modules (shown as CU MCs in the figure) 1831-1834. Each CU motion compensation module handles the encoding of a leaf CU. When encoding each CU of the CU motion compensation modules 1831-1834, the CU motion compensation modules 1831-1834 can access the contents of the shared candidate list 1800 and the contents of the reconstructed picture buffer 1750. Each CU motion compensation module selects a prediction candidate from the shared candidate list and extracts the corresponding samples from the reconstructed picture buffer 1750 to perform prediction through motion compensation. Predictions from different CU motion compensation modules 1831-1834 are used as predicted pixel data 1713.

[0142] It is important to note that even if the CUs being encoded are adjacent to each other, different CU compensation modules 1831-1834 can still perform motion compensation on their respective CUs in parallel. This is because there is no mutual dependency between the CUs using the shared candidate list, and therefore they may be encoded at the same time.

[0143] The contents of the shared candidate list 1800 are retrieved from the MV buffer 1765, which stores the respective adjacent motion vectors of the region defined by the shared boundary, which may correspond to the root CU or subtree of the CTU. The motion vectors included in the shared candidate list 1800 from the MV buffer 1765 may include various types of merge or AMVP candidates, such as affine candidates, IBC candidates, sub-PU candidates, history-based candidates, non-neighboring candidates, etc. The history-based candidates may be stored in the history buffer 1810, which is a FIFO that stores merge candidates for previously encoded CUs.

[0144] Fig.19 A process 1900 for encoding multiple CUs using a shared candidate list is conceptually illustrated. In some embodiments, one or more processing units (e.g., processors) of a computing device implementing the encoder 1700 perform the process 1900 by executing instructions stored in a computer-readable medium. In some embodiments, an electronic device implementing the video encoder 1700 performs the process 1900.

[0145] The video encoder receives (at step 1910) data of a CTU of a current picture in a video sequence. The data may be raw pixel data of an area corresponding to the CTU in the current picture from a video source. The CTU may be divided into CUs or sub-CUs as a QT, BT, or TT partition tree.

[0146] The video encoder identifies (at step 1920) a shared boundary of multiple CUs (or pixel blocks) in a CTU. The shared boundary may correspond to the root of a subtree of the CTU. The shared boundary may be identified based on a CU size threshold (SHARED_THD). In some embodiments, the shared boundary is identified by traversing the CTU to identify a CU that is greater than or equal to the CU size threshold and the CU is a parent CU of a child CU that is less than the threshold. In some embodiments, the shared boundary is identified by traversing the CTU to identify a CU that is less than or equal to the CU size threshold and the CU is a child CU of a parent CU that is greater than the threshold. The boundary of the identified CU is then defined as a shared boundary.

[0147] The video encoder identifies (at step 1930) one or more prediction candidates of a shared candidate list based on spatial or temporal contiguity of an area defined by a shared boundary. The area may correspond to a CU, and the shared candidate list may be used as a merge candidate list for the CU. The motion vectors included in the shared candidate list may include various types of merge or AMVP candidates, such as affine candidates, IBC candidates, sub-PU candidates, history-based candidates, non-adjacent candidates, etc.

[0148] The video encoder encodes one or more CUs contained in the shared boundary by using one or more prediction candidates selected from the shared candidate list (at step 1940). The selected prediction candidate is used to perform motion compensated prediction. The encoded CU is a leaf CU of the CTU. In some embodiments, not all leaf CUs within the shared boundary are encoded using the shared candidate list, but only leaf CUs having the same characteristics as the root CU can be encoded using the shared candidate list. The encoded CU is stored in the bitstream as a coded bit of a syntax element.

[0149] V. Example Video Decoder

[0150] Fig. 20An example video decoder 2000 implementing a shared candidate list is shown. As shown, the video decoder 2000 is a picture decoding or video decoding circuit that receives a bitstream 2095 and decodes the content of the bitstream into pixel data of a video frame for display. The video decoder 2000 has several components or modules for decoding the bitstream 2095, including some components selected from an inverse quantization module 2005, an inverse transform module 2010, an intra-frame prediction module (shown as an intra-picture prediction module) 2025, a motion compensation module 2030, a loop filter 2045, a decoded picture buffer 2050, an MV buffer 2065, an MV prediction module 2075, and a parser 2090. The motion compensation module 2030 is part of the inter-frame prediction module 2040.

[0151] In some embodiments, modules 2010-2090 are modules of software instructions executed by one or more processing units (e.g., processors) of a computing device. In some embodiments, modules 2010-2090 are modules of hardware circuits implemented by one or more ICs of an electronic device. Although modules 2010-2090 are illustrated as separate modules, some modules may be combined into a single module.

[0152] The parser 2090 (or entropy decoder) receives the bitstream 2095 and performs initial parsing according to the syntax defined by the video coding or picture coding standard. The parsed syntax elements include various header elements, flags, and quantized data (or quantized coefficients) 2012. The parser 2090 parses the various syntax elements by using entropy coding techniques such as context adaptive binary arithmetic coding (CABAC) or Huffman coding.

[0153] The inverse quantization module 2005 dequantizes the quantized data (or quantized coefficients) 2012 to obtain transform coefficients, and the inverse transform module 2010 performs inverse transform on the transform coefficients 2016 to generate a reconstructed residual signal 2019. The predicted pixel data 2013 from the intra prediction module 2025 or the motion compensation module 2030 is added to the reconstructed residual signal 2019 to generate decoded pixel data 2017. The decoded pixel data is filtered by the loop filter 2045 and stored in the decoded picture buffer 2050. In some embodiments, the decoded picture buffer 2050 is a memory external to the video decoder 2000. In some embodiments, the decoded picture buffer 2050 is a memory internal to the video decoder 2000.

[0154] The intra prediction module 2025 receives intra prediction data from the bitstream 2095 and generates predicted pixel data 2013 from the decoded pixel data 2017 stored in the decoded picture buffer 2050. In some embodiments, the decoded pixel data 2017 is also stored in a line buffer (not shown) for intra picture prediction and spatial MV prediction.

[0155] In some embodiments, the contents of the decoded picture buffer 2050 are used for display. The display device 2055 either fetches the contents of the decoded picture buffer 2050 for direct display or fetches the contents of the decoded picture buffer to a display buffer. In some embodiments, the display device receives pixel values ​​from the decoded picture buffer 2050 via pixel transfer.

[0156] The motion compensation module 2030 generates predicted pixel data 2013 from the decoded pixel data 2017 stored in the decoded picture buffer 2050 according to the motion compensated MV (MC MV). These motion compensated MVs are decoded by adding the residual motion data received from the bitstream 2095 to the predicted MV received from the MV prediction module 2075.

[0157] The MV prediction module 2075 generates a predicted MV based on a reference MV generated for decoding a previous video frame (e.g., a motion compensated MV for performing motion compensation). The MV prediction module 2075 retrieves the reference MV of the previous video frame from the MV buffer 2065. The video decoder 2000 stores the motion compensated MV generated for decoding the current video frame in the MV buffer 2065 as a reference MV for generating the predicted MV.

[0158] The loop filter 2045 performs filtering or smoothing operations on the decoded pixel data 2017 to reduce encoding artifacts, particularly at the boundaries of pixel blocks. In some embodiments, the filtering operations performed include sample adaptive offset (SAO). In some embodiments, the filtering operations include adaptive loop filtering (ALF).

[0159] Fig.212000. As shown, the motion compensation module 2030 includes one or more CU motion compensation modules 2131-2134. Each CU motion compensation module handles the decoding of a leaf CU. When decoding the corresponding CU of the CU motion compensation module 2131-2134, the CU motion compensation module 2131-2134 can access the contents of the shared candidate list 2100 and the contents of the decoded picture buffer 2050. Each CU motion compensation module selects a prediction candidate from the shared candidate list and extracts the corresponding sample from the decoded picture buffer 2050 to perform prediction through motion compensation. The predictions from different CU motion compensation modules 2131-2134 are used as predicted pixel data 2013.

[0160] It is worth noting that even if the encoded CUs are adjacent to each other, different CU motion compensation modules 2131-2134 can still perform motion compensation on their respective CUs in parallel. This is because there is no mutual dependency between the CUs using the shared candidate list, and thus they can be decoded simultaneously.

[0161] The contents of the shared candidate list 2100 are retrieved from the MV buffer 2065, which stores the motion vectors of each neighbor of the area defined by the shared boundary, which may correspond to the root CU or subtree of the CTU. The motion vectors included by the shared candidate list 2100 from the MV buffer 2065 may include various types of merge or AMVP candidates, such as affine candidates, IBC candidates, sub-PU candidates, history-based candidates, non-neighboring candidates, etc. History-based candidates may be stored in the history buffer 2110, which is a FIFO that stores merge candidates for previously decoded CUs.

[0162] Fig. 22 A process 2200 for decoding multiple CUs using a shared candidate list is conceptually illustrated. In some embodiments, one or more processing units (e.g., processors) of a computing device implementing the decoder 2000 perform the process 2200 by executing instructions stored in a computer-readable medium. In some embodiments, an electronic device implementing the video decoder 2000 performs the process 2200.

[0163] The video decoder receives (at step 2210) data for a CTU of a current picture in a video sequence. The data may be for a pixel block encoded or generated in a bitstream as a syntax element in the CTU. The CTU may be partitioned into CUs or sub-CUs as a QT, BT, or TT partition tree.

[0164] The video decoder identifies (at step 2220) a shared boundary of multiple CUs (or pixel blocks) contained in a CTU. The shared boundary may correspond to the root of a subtree of the CTU. The shared boundary may be identified based on a CU size threshold (SHARED_THD). In some embodiments, the shared boundary is identified by traversing the CTU to identify a CU that is greater than or equal to the CU size threshold and that is a parent CU of a child CU that is less than the threshold. In some embodiments, the shared boundary is identified by traversing the CTU to identify a CU that is less than or equal to the CU size threshold and that is a child CU of a parent CU that is greater than the threshold. The boundary of the identified CU is then defined as a shared boundary.

[0165] The video decoder identifies (at step 2230) one or more prediction candidates for a shared candidate list based on spatial or temporal contiguity of an area defined by a shared boundary. The area may correspond to a CU, and the shared candidate list may be used as a merge candidate list for the CU. The motion vectors included in the shared candidate list may include various types of merge or AMVP candidates, such as affine candidates, IBC candidates, sub-PU candidates, history-based candidates, non-adjacent candidates, etc.

[0166] The video decoder decodes (at step 2240) one or more CUs surrounded by the shared boundary by using one or more prediction candidates selected from the shared candidate list. The selected prediction candidates are used to perform motion compensated prediction. The decoded CU is a leaf CU of the CTU. In some embodiments, not all leaf CUs within the shared boundary are decoded using the shared candidate list, but only leaf CUs having the same characteristics as the root CU can be decoded using the shared candidate list. The decoded CU includes pixel data that can be displayed.

[0167] VI. Example Electronic System

[0168] Many of the above features and applications are implemented as software processes specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium). When these instructions are executed by one or more computing or processing units (e.g., one or more processors, cores of a processor, or other processing units), they cause the processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, random access memory (RAM) chips, hard drives, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0169] In this specification, the term "software" is intended to include firmware residing in a read-only memory or an application stored in a magnetic storage device, which can be read into the memory for processing by the processor. Similarly, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while retaining different software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that implement the software inventions described herein together are within the scope of this disclosure. In some embodiments, the software program, when installed to run on one or more electronic systems, defines one or more specific machine implementations for executing and implementing the operations of the software program.

[0170] Fig.23 An electronic system 2300 is conceptually shown that implements some embodiments of the present disclosure. The electronic system 2300 can be a computer (e.g., a desktop computer, a personal computer, a tablet computer, etc.), a phone, a PDA, or any other kind of electronic device. Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 2300 includes a bus 2305, (one or more) processing units 2310, a graphics processing unit (GPU) 2315, a system memory 2320, a network 2325, a read-only memory 2330, a permanent storage device 2335, an input device 2340, and an output device 2345.

[0171] Bus 2305 collectively represents all system, peripheral, and chipset buses that communicatively connect the many internal devices of electronic system 2300. For example, bus 2305 communicatively connects processing unit 2310 with GPU 2315, read-only memory 2330, system memory 2320, and permanent storage device 2335.

[0172] The processing unit 2310 retrieves instructions to be executed and data to be processed from these various storage units in order to perform the processes of the present disclosure. In different embodiments, one or more processing units may be a single processor or a multi-core processor. Some instructions are passed to and executed by the GPU 2315. The GPU 2315 may offload various calculations or supplement the image processing provided by the processing unit 2310.

[0173] The read-only memory (ROM) 2330 stores static data and instructions used by the processing unit 2310 and other modules of the electronic system. On the other hand, the permanent storage device 2335 is a read-write storage device. This device is a non-volatile storage unit that stores instructions and data even when the electronic system 2300 is turned off. Some embodiments of the present disclosure use a mass storage device (such as a magnetic disk or optical disk and its corresponding magnetic disk drive) as the permanent storage device 2335.

[0174] Other embodiments use removable storage devices (e.g., floppy disks, flash memory devices, etc., and their corresponding disk drives) as permanent storage devices. Like the permanent storage device 2335, the system memory 2320 is a read-write storage device. However, unlike the storage device 2335, the system memory 2320 is a volatile read-write memory, such as a random access memory. The system memory 2320 stores some instructions and data used by the processor at runtime. In some embodiments, processing according to the present disclosure is stored in the system memory 2320, the permanent storage device 2335 and / or the read-only memory 2330. For example, according to some embodiments, various storage units include instructions for processing multimedia clips. The processing unit 2310 retrieves instructions to be executed and data to be processed from these various storage units in order to perform the processing of some embodiments.

[0175] The bus 2305 is also connected to input and output devices 2340 and 2345. The input device 2340 enables a user to convey information to the electronic system and select commands. The input device 2340 includes an alphanumeric keyboard and a pointing device (also known as a "mouse control device"), a camera (e.g., a webcam), a microphone, or a similar device for receiving voice commands, etc. The output device 2345 displays pictures generated by the electronic system or outputs data. The output device 2345 includes a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), and a speaker or similar audio output device. Some embodiments include devices that act as both input devices and output devices, such as a touch screen.

[0176] Finally, if Fig.23 As shown, bus 2305 also couples electronic system 2300 to a network 2325 via a network adapter (not shown). In this manner, the computer can be part of a computer network, such as a local area network ("LAN"), a wide area network ("WAN"), or an intranet or a network of networks, such as the Internet. Any or all components of electronic system 2300 may be used in conjunction with the present disclosure.

[0177] Some embodiments include electronic components, such as microprocessors, memory and storage that stores computer program instructions in machine-readable or computer-readable media (or alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, compact disk-read only (CD-ROM), compact disk-recordable (CD-R), compact disk-rewritable (CD-RW), read-only bit versatile optical disk (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini-SD card, micro-SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable CD-ROM, ultra-density CD-ROM, any other optical or magnetic medium, and floppy disk. The computer readable medium may store a computer program executable by at least one processing unit, and the computer program includes a set of instructions for performing various operations. Examples of computer programs or computer code include machine code such as generated by a compiler, and files including high-level code executed by a computer, electronic component, or microprocessor using an interpreter.

[0178] Although the above discussion refers primarily to microprocessors or multi-core processors that execute software, many of the above features and applications are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuits themselves. In addition, some embodiments execute software stored in programmable logic devices (PLDs), ROM, or RAM devices.

[0179] As used in this specification and any claims of this application, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical devices. These terms do not include individuals or groups of people. For the purpose of this description, the terms "display" or "displayed" refer to displaying on an electronic device. As used in this specification and any claims of this application, the terms "computer-readable medium," "computer-readable media," and "machine-readable medium" are entirely limited to tangible physical objects that store information in a form that can be read by a computer. These terms do not include any wireless signals, wired download signals, and any other temporary signals.

[0180] Although the present disclosure has been described with reference to many specific details, those skilled in the art will recognize that the present disclosure may be embodied in other specific forms without departing from the spirit of the present disclosure. Fig.19 and Fig. 22) conceptually illustrates the processes. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in a continuous series of operations, and different specific operations may be performed in different embodiments. In addition, the process may be implemented using several sub-processes or as part of a larger macro process. Therefore, it will be understood by those skilled in the art that the present disclosure is not limited to the foregoing illustrative details, but is defined by the appended claims.

[0181] Additional Statement

[0182] The subject matter described herein sometimes shows different components contained in or connected to other different components. It should be understood that the architecture depicted in this way is only exemplary, and many other architectures that realize the same function can actually be implemented. In a conceptual sense, any arrangement of components that realize the same function is effectively "associated" so that the desired function is realized. Therefore, any two components that are combined to obtain a specific function in the text can be regarded as "associated" with each other to realize the desired function, regardless of the architecture or intermediate components. Similarly, any two components that are associated in this way can also be regarded as "operably connected" or "operably coupled" to each other to realize the desired function, and any two components that can be associated in this way can also be regarded as "operably coupled" to each other to realize the desired function. The specific examples of "operably coupled" include but are not limited to: components that can be physically connected and / or physically interact with each other, and / or components that can interact wirelessly and / or wirelessly interact, and / or components that can interact logically and / or logically interact.

[0183] Furthermore, with respect to the use of substantially any plural and / or singular terms herein, those having ordinary skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application.

[0184] Those of ordinary skill in the art will understand that, in general, the terms used herein, particularly in the appended claims (e.g., the subject matter of the appended claims), are generally intended as "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", etc.). Those of ordinary skill in the art will also understand that if a specific number of an introduced claim recitation object is intended, such intent will be explicitly stated in the claim, and in the absence of such a statement, no such intent exists. For example, to aid understanding, the appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitation objects. However, the use of such phrases should not be interpreted as limiting any claim containing such introduced claim recitation with the indefinite article "a or an" to an invention containing only one such recitation, even if the same claim contains the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should generally be interpreted as meaning "at least one" or "one or more"); the same applies to the case where the claim recitation is introduced with a definite article. In addition, even if a specific number of introduced claim recitations is explicitly stated, a person of ordinary skill in the art will recognize that such a statement should generally be interpreted as meaning at least the stated number (e.g., a statement of "two recitations" without other modifiers generally means at least two recitations, or two or more recitations). Furthermore, where phrases similar to “at least one of A, B, and C, etc.” are used, generally such constructions are intended to have the meaning of the phrase as understood by those of ordinary skill in the art (e.g., “a system having at least one of A, B, and C” would include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Where phrases similar to “at least one of A, B, or C, etc.” are used, generally such constructions are intended to have the meaning of the phrase as understood by those of ordinary skill in the art (e.g., “a system having at least one of A, B, or C” would include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.).Those skilled in the art will further understand that, whether in the specification, claims or drawings, almost any disjunctive word and / or phrase representing two or more interchangeable terms should be understood to include the possibility of one of the terms, any one of the terms, or both of the terms. For example, the phrase "A or B" should be understood to include the possibility of "A", "B", or "A and B".

[0185] Although different methods, devices, and systems have been used to describe and illustrate some exemplary techniques, it should be understood by those of ordinary skill in the art that various other modifications and equivalent substitutions may be made without departing from the claimed subject matter. In addition, many modifications may be made to adapt specific situations to the teachings of the claimed subject matter without departing from the central concept described herein. Therefore, it is intended that the claimed subject matter is not limited to the specific examples disclosed, and such claimed subject matter may also include all implementations and their equivalents that fall within the scope of the appended claims.

Claims

1. A video processing method, comprising: identifying a partition corresponding to a level in a hierarchical partition structure of a current picture according to a partition size threshold, wherein a boundary of the identified partition surrounds a plurality of pixel blocks of the current picture in a video sequence; Creating a shared candidate list of the plurality of pixel blocks, the shared candidate list comprising one or more prediction candidates determined based on neighboring coding units of the identified partition; as well as encoding one or more pixel blocks of the plurality of pixel blocks surrounded by the boundary of the identified partition by using one or more prediction candidates selected from the shared candidate list; Identifying the partition includes: traversing the hierarchical partition structure to identify the partitions that are greater than or equal to the partition size threshold, and A subpartition of the identified partition is smaller than the partition size threshold, or traversing the hierarchical partition structure to identify the partitions that are less than or equal to the partition size threshold, and The parent partition of the identified partition is larger than the partition size threshold.

2. The video processing method according to claim 1, characterized in that: Encoding the one or more pixel blocks includes encoding the first pixel block and the second pixel block in parallel by using the shared candidate list.

3. The video processing method according to claim 1, characterized in that: The identified partition is part of a coding tree unit and corresponds to a root of a subtree of the coding tree unit.

4. The video processing method according to claim 1, characterized in that: The identified partition is a part of a coding tree unit, and the plurality of pixel blocks surrounded by the boundary of the identified partition corresponds to leaf coding units of the coding tree unit.

5. The video processing method according to claim 1, characterized in that: The shared candidate list includes motion vectors used to encode a plurality of neighboring blocks of the identified partition. The video processing method according to claim 5 , wherein at least one of the motion vectors is applicable to a reconstructed reference sample in the current picture.

7. The video processing method according to claim 1, characterized in that: The shared candidate list includes one or more candidates derived according to the merge mode.

8. The video processing method according to claim 1, characterized in that: The shared candidate list includes one or more candidates derived from merge candidates of previously encoded coding units.

9. The video processing method according to claim 1, characterized in that: The hierarchical partition structure corresponds to a coding tree unit of the current picture.

10. An electronic device comprising: A decoder circuit is configured to perform operations including: Receiving data of a coding tree unit of a current picture in a video sequence; identifying a partition corresponding to a level in the hierarchical partition structure of the coding tree unit according to a partition size threshold, a boundary of the identified partition enclosing a plurality of coding units in the coding tree unit; Creating a shared candidate list for the plurality of coding units, the shared candidate list comprising one or more prediction candidates determined based on neighboring coding units of the identified partition; as well as decoding one or more coding units of the plurality of coding units surrounded by the boundary of the identified partition by using the one or more prediction candidates selected from the shared candidate list; The decoder is configured to perform the following operations to identify the partition: traversing the hierarchical partition structure to identify the partitions that are greater than or equal to the partition size threshold, and A subpartition of the identified partition is smaller than the partition size threshold, or traversing the hierarchical partition structure to identify the partitions that are less than or equal to the partition size threshold, and The parent partition of the identified partition is larger than the partition size threshold.

11. The electronic device according to claim 10, wherein: The decoding circuit is configured to encode a first coding unit and a second coding unit of the plurality of coding units in parallel by using the shared candidate list.

12. The electronic device according to claim 10, wherein: The identified partition corresponds to the root of the subtree of the coding tree unit.

13. The electronic device according to claim 10, wherein: The coding unit enclosed by the boundary of the identified partition corresponds to a leaf coding unit of the coding tree unit.

14. The electronic device according to claim 10, wherein: The shared candidate list includes motion vectors used to encode the neighboring coding units of the identified partition. 15 . The electronic device of claim 14 , wherein at least one of the motion vectors is applicable to a reconstructed reference sample in the current picture.

16. The electronic device according to claim 10, wherein: The shared candidate list includes one or more candidates derived according to the merge mode.

17. The electronic device according to claim 10, wherein: The shared candidate list includes one or more candidates derived from one or more merge candidates of previously encoded coding units.

18. An electronic device comprising: An encoder circuit configured to perform operations including: identifying a partition corresponding to a level in a hierarchical partition structure of a coding tree unit according to a partition size threshold, a boundary of the identified partition enclosing a plurality of coding units in the coding tree unit; Creating a shared candidate list for the plurality of coding units, the shared candidate list comprising one or more prediction candidates determined based on neighboring coding units of the identified partition; as well as encoding one or more coding units of the plurality of coding units surrounded by the boundary of the identified partition by using one or more prediction candidates selected from the shared candidate list; Wherein the encoder circuit is configured to identify the partition by traversing the hierarchical partition structure of the coding tree unit to identify the partition that is greater than or equal to the partition size threshold, and a child partition of the identified partition is smaller than the partition size threshold, or the encoder circuit is configured to identify the partition by traversing the hierarchical partition structure of the coding tree unit to identify the partition that is less than or equal to the partition size threshold, and a parent partition of the identified partition is larger than the partition size threshold.

Images