Context Adaptive Coding and Decoding of Block Vectors

Abstract

A video processing method is described. The video processing method includes: performing a conversion between a video including video blocks and an encoded / decoded representation of the video; wherein the encoded / decoded representation conforms to format rules, and the format rules specify context adaptive encoding / decoding of a block vector predictor (BVP) index for encoding / decoding a first video block using a block vector (BV) prediction mode by sharing the same context and an index for inter-frame mode encoding / decoding of a second video block; wherein the BVP index points to an entry in a history-based motion vector predictor list, and the history-based motion vector predictor list is used to generate a block vector predictor for the first video block.

Description

[0001] Cross - reference to related applications

[0002] In accordance with the provisions of the applicable Patent Law and / or Paris Convention, this application timely claims the priority and benefits of International Patent Application No. PCT / CN2019 / 102411 filed on August 24, 2019. For all legal purposes, the entire disclosure of the above - mentioned application is incorporated herein by reference as part of the disclosure of this application. Technical field

[0003] This patent document relates to video encoding and decoding. Background art

[0004] Despite the progress in video compression, digital video still occupies the largest bandwidth in the Internet and other digital communication networks. With the increase in the number of connected user devices capable of receiving and displaying video, it is expected that the bandwidth demand for digital video will continue to grow. Summary of the invention

[0005] Devices, systems, and methods related to digital video processing, particularly devices, systems, and methods related to video and image encoding and decoding using block vector encoding and decoding.

[0006] In one exemplary aspect, a video processing method is disclosed. The method includes: for the conversion between a current video block of a current picture of a video and the encoded / decoded representation of the video, constructing a history - based motion vector predictor (HMVP) table according to rules, and performing the conversion using the HMVP table, wherein a block vector representing the displacement between the current video block and the region in the current picture used to predict the current video block is used to encode and decode the current video block in the encoded / decoded representation; wherein the rules specify that the construction uses the block vector information of previously processed video blocks in the HMVP table.

[0007] In another exemplary aspect, another video processing method is disclosed. The method includes: for the conversion between a current video block of a current picture of a video and the encoded / decoded representation of the video, determining a block vector predictor according to one or more entries in a history - based motion vector prediction (HMVP) table, the one or more entries corresponding to one or more block vector candidates from one or more previously processed blocks; and performing the conversion based on the determination, wherein a block vector representing the displacement between the current video block and the region in the current picture used to predict the current video block is used to encode and decode the current video block in the encoded / decoded representation.

[0008] In another example aspect, another video processing method is disclosed. The method includes: for the conversion between a current video block of a video and the codec representation of the video, determining whether to clip or use a block vector derived from a history-based motion vector prediction (HMVP) table when motion is detected, the history-based motion vector prediction (HMVP) table including one or more entries corresponding to motion information from one or more previously processed blocks; and performing the conversion based on the determination.

[0009] In another example aspect, another video processing method is disclosed. The method includes: for the conversion between a current video block of a current picture of a video and the codec representation of the video, making a first determination that a history-based motion vector predictor (HMVP) table of the current video block does not include any entries for predicting a block vector, the block vector representing the displacement between the current video block and the region in the current picture used to predict the current video block; making a second determination regarding using the block vector for the conversion of the current video block based on the first determination and a rule; and performing the conversion according to the first determination and the second determination.

[0010] In another example aspect, another video processing method is disclosed. The method includes: for the conversion between a current video block of a current picture of a video and the codec representation of the video, determining a block motion vector predictor for block vector prediction; generating a modified block motion vector predictor by modifying the block motion vector predictor; and using the modified block motion vector predictor to perform the conversion, wherein the block vector prediction predicts a block vector representing the displacement between the current video block and the region in the current picture used to predict the current video block.

[0011] In another example aspect, another video processing method is disclosed. The method includes: for the conversion between a current video block of a current picture of a video and the codec representation of the current video block, determining a block motion vector predictor for predicting a block vector according to a history-based motion vector prediction (HMVP) table, the history-based motion vector prediction (HMVP) table including motion vector information of previously processed video blocks; and using the block motion vector predictor to perform the conversion, wherein the block vector representing the displacement between the current video block and the region in the current picture used to predict the current video block is used to encode and decode the current video block in codec representation.

[0012] In another example aspect, another video processing method is disclosed. The method includes: performing a transformation between a video including video blocks and an encoded / decoded representation of the video; wherein the encoded / decoded representation conforms to format rules, wherein the format rules specify performing context adaptive coding of the block vector predictor (BVP) index of a first video block encoded / decoded using a block vector (BV) prediction mode by sharing the same context and an index for inter-frame mode coding of a second video block; wherein the BVP index points to an entry in a history-based motion vector predictor list that is used to generate a block vector predictor for the first video block.

[0013] In another example aspect, another video processing method is disclosed. The method includes: performing a transformation between a video including video blocks and an encoded / decoded representation of the video; wherein the encoded / decoded representation conforms to format rules, wherein the format rules specify performing context adaptive coding of the block vector predictor (BVP) index of a first video block encoded / decoded using a block vector (BV) prediction mode independent of the context used to code an index for inter-frame mode coding of a second video block; wherein the BVP index points to an entry in a history-based motion vector predictor list that is used to generate a block vector predictor for the first video block.

[0014] In another example aspect, another video processing method is disclosed. The method includes: performing a transformation between a current video block of a current picture of a video and an encoded / decoded representation of the video, wherein the current video block is encoded / decoded in the encoded / decoded representation using a block vector that represents a displacement between the current video block and a region in the current picture used to predict the current video block, wherein the transformation is performed using a history-based motion vector prediction (HMVP) table that contains one or more previously used block vectors; wherein the encoded / decoded representation includes a syntax element that represents an index to an entry in the HMVP table applied to the current video block, and wherein a maximum value of binarization of the index is determined according to rules.

[0015] In another example aspect, another video processing method is disclosed. The method includes: for a transformation between a current video region of a video and an encoded / decoded representation of the video, resetting a history-based motion vector prediction (HMVP) table that includes one or more previously used block vectors, wherein resetting includes setting an indication of available entries of the HMVP table to K, where K is a non-zero integer; and performing the transformation using the HMVP table.

[0016] In another example aspect, another video processing method is disclosed. The method includes: for the conversion between the current video block of a video and the codec representation of the video, applying a plurality of constant block vectors to a table to initialize the table, the table including motion vector information of previously processed video blocks; and performing the conversion using the table.

[0017] In another example aspect, another video processing method is disclosed. The method includes: performing a conversion between the current video block of the current picture of a video and the codec representation of the video according to a rule, where a block vector is used to encode and decode the current video block in the codec representation, the block vector representing a displacement between the current video block and a region in the current picture used to predict the current video block; wherein, the codec representation includes a syntax element that indicates an index to a history-based motion vector predictor (HMVP) list for the conversion, and wherein, the rule specifies that when the index indicated by the syntax element is not less than the number of entries in the HMVP list, default processing is used to determine the prediction of the block vector.

[0018] In yet another representative aspect, the above method is embodied in the form of processor-executable code and stored in a computer-readable program medium.

[0019] In yet another representative aspect, a device configured to or operable to perform the above method is disclosed. The device may include a processor programmed to implement the method.

[0020] In yet another representative aspect, a video decoder device may implement the method as described herein.

[0021] The above and other aspects and features of the disclosed technology are described in more detail in the drawings, the specification, and the claims. Description of the Drawings

[0022] Figure 1 An example position of a spatial Merge candidate is shown.

[0023] Figure 2 An example candidate pair considering redundancy check for a spatial Merge candidate is shown.

[0024] Figure 3 An illustration of motion vector scaling for a temporal Merge candidate.

[0025] Figure 4 An example of candidate positions C0 and C1 of a temporal Merge candidate is shown.

[0026] Figure 5 An example of an MMVD search point is shown.

[0027] Figure 6 An example illustration of a symmetric MVD mode.

[0028] Figure 7A and 7B shows an example of an affine motion model based on control points.

[0029] Figure 8 shows an example of the affine MVF for each sub-block.

[0030] Figure 9 shows the position of the inherited affine motion predictor.

[0031] Figure 10 shows an example of inheritance of control point motion vectors.

[0032] Figure 11 shows an example of the position for constructing candidate positions for the affine Merge mode.

[0033] Figure 12 is an illustration of the motion vector usage of the proposed combined method.

[0034] Figure 13A and 13B shows an example of SbTMVP processing in VVC.

[0035] Figure 14 is an illustration of the intra block copy codec mode.

[0036] Figure 15 is a block diagram of an example implementation of a hardware platform for video processing.

[0037] Figure 16 is a flowchart of an example method for video processing.

[0038] Figure 17 is a block diagram of a system in which video processing is implemented.

[0039] Figures 18A to 18F is a flowchart of an example method for video processing.

[0040] Figure 19A and 19B is a flowchart of an example method for video processing.

[0041] Figure 20 is a flowchart of an example method for video processing. Detailed Description

[0042] Embodiments of the disclosed technology can be applied to existing video coding standards (e.g., HEVC, H.265) and future standards to improve compression performance. Section headings are used in this document to improve the readability of the description and do not limit the discussion or embodiments (and / or implementations) to the corresponding section in any way.

[0043] 1. Overview

[0044] This document is related to video coding and decoding technology. Specifically, it relates to motion / block vector coding and decoding in video coding and decoding. It can be applied to existing video coding and decoding standards, such as HEVC, or standards to be finalized in the future, such as Versatile Video Coding and Audio Video Coding Standard version 3. It may also be applicable to future video coding and decoding standards or video codecs.

[0045] 2. Background

[0046] Video coding and decoding standards have mainly evolved through the development of well-known ITU-T and ISO / IEC standards. ITU-T produced H.261 and H.263, ISO / IEC produced MPEG-1 and MPEG-4 Video, and the two organizations jointly produced H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Coding (AVC) and H.265 / HEVC standards. Since H.262, video coding and decoding standards have been based on a hybrid video coding and decoding structure, which utilizes temporal prediction plus transform coding. To explore future video coding and decoding technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and applied them to a reference software called the Joint Exploration Model (JEM) [3][4]. In April 2018, the Joint Video Exploration Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) was established to work on the VVC standard with the goal of a 50% bitrate reduction compared to HEVC.

[0047] 2.1 Inter-Frame Prediction

[0048] For each inter-predicted CU, the motion parameters consisting of the motion vector, reference picture index, and reference picture list use index, as well as additional information required for the new decoded features of VVC for the samples to be used for inter-prediction. The motion parameters can be signaled in an explicit or implicit manner. When a CU is coded or decoded in skip mode, the CU is associated with a PU, and there are no significant residual coefficients, no coded motion vector difference, or reference picture index. The Merge mode is specified so that the motion parameters of the current CU can be obtained from neighboring CUs (including spatial and temporal candidates) and other schemes introduced in VVC. The Merge mode can be applied to any inter-predicted CU, not only to the skip mode. An alternative to the Merge mode is the explicit transmission of motion parameters, where the motion vector, the corresponding reference picture index for each reference picture list, the reference picture list use flag, and other required information are signaled explicitly for each CU.

[0049] In addition to the inter-frame coding and decoding functions in HEVC, VTM5 also includes many new and refined inter-prediction coding tools as follows:

[0050] – Extended Merge prediction

[0051] – Merge mode with MVD (MMVD)

[0052] – AMVP mode with symmetric MVD signaling

[0053] – Affine motion compensation prediction

[0054] – Sub-block based temporal motion vector prediction (SbTMVP)

[0055] – Adaptive motion vector resolution (AMVR)

[0056] – Motion field storage: 1 / 16 luma sample MV storage and 8x8 motion field compression

[0057] – Bi-directional prediction with CU-level weight (BCW)

[0058] – Bi-directional optical flow (BDOF)

[0059] – Decoder side motion vector refinement (DMVR)

[0060] – Triangular partitioning prediction

[0061] – Combined inter and intra prediction (CIIP)

[0062] Details of the inter-prediction methods specified in VVC are provided below.

[0063] 2.1.1 Extended Merge prediction

[0064] In VTM5, the Merge candidate list is constructed by sequentially including the following five types of candidates:

[0065] 1) Spatial MVPs from spatial neighboring CUs

[0066] 2) Temporal MVPs from collocated CUs

[0067] 3) History-based MVPs in the FIFO table

[0068] 4) Paired-average MVPs

[0069] 5) Zero MVs.

[0070] The size of the Merge list is signaled in the slice header, and in VTM5, the maximum allowed size of the Merge list is 6. For each CU code in Merge mode, the index of the best Merge candidate is encoded and decoded using Truncated Unary (TU). The first bin of the Merge index is encoded and decoded using context, while the other bins are encoded and decoded using bypass coding.

[0071] For each category of Merge candidates, a generation process is provided in this session.

[0072] 2.1.1.1 Spatial candidate derivation

[0073] The derivation of spatial Merge candidates in VVC is the same as that in HEVC. Among the candidates located at the Figure 1 shown positions, at most four Merge candidates are selected. The derivation order is A0, B0, B1, A1, and B2. Only when any of the CUs at positions A0, B0, B1, A1 is unavailable (e.g., because it belongs to another slice or tile) or is intra-coded, position B2 is considered. After adding the candidate at position A1, a redundancy check is performed on the addition of the remaining candidates, which ensures that candidates with the same motion information are excluded from the list, thus improving the coding efficiency. To reduce the computational complexity, not all possible candidate pairs are considered in the mentioned redundancy check. Instead, only the pairs linked by the Figure 2 arrows are considered, and a candidate is added to the list only when the corresponding candidates used for the redundancy check do not have the same motion information.

[0074] Figure 1 shows an example position of spatial Merge candidates.

[0075] Figure 2 shows an example candidate pair considered for the redundancy check of spatial Merge candidates.

[0076] 2.1.1.2 Temporal candidate derivation

[0077] In this step, only one candidate is added to the list. Specifically, in the derivation of the temporal Merge candidate, the scaled motion vectors are derived based on the collocated CUs belonging to the collocated reference pictures. The reference picture list for deriving the collocated CUs is signaled explicitly in the slice header. The scaled motion vectors of the temporal Merge candidates (as shown by the dashed lines in Figure 3 ) are scaled from the motion vectors of the collocated CUs using the POC distances tb and td, where tb is defined as the POC difference between the reference picture of the current picture and the current picture, and td is defined as the POC difference between the reference picture of the collocated picture and the collocated picture. The reference picture index of the temporal Merge candidate is set to zero.

[0078] Figure 3 is the illustration of the motion vector scaling for the temporal Merge candidate.

[0079] As shown in Figure 4 , the position of the temporal candidate is selected between candidates C0 and C1. If the CU at position C0 is unavailable, intra-coded, or outside the current row of the CTU, position C0 is used. Otherwise, position C0 is used in the derivation of the temporal Merge candidate.

[0080] Figure 4 shows an example of the candidate positions of the temporal Merge candidates C0 and C1.

[0081] History-based Merge candidate derivation

[0082] After the spatial MVP and TMVP, the history-based MVP (HMVP) Merge candidates are added to the Merge list. In this method, the motion information of the previously coded blocks is stored in a table and used as the MVP for the current CU. During the encoding / decoding process, a table with multiple HMVP candidates is maintained. When a new CTU row is encountered, the table is reset (emptied). As long as there is a non-sub-block inter-coded CU, the associated motion information is added as a new HMVP candidate to the last entry of the table.

[0083] In VTM5, the HMVP table size S is set to 6, which means that up to 6 history-based MVP (HMVP) candidates can be added to the table. When a new motion candidate is inserted into the table, the constrained first-in-first-out (FIFO) rule is utilized, where a redundancy check is first applied to find if there is an identical HMVP in the table. If found, the identical HMVP is removed from the table, and then all the HMVP candidates are moved forward,

[0084] HMVP candidates can be used in the Merge candidate list construction process. Check several latest HMVP candidates in the list in sequence and insert them into the candidate list after the TMVP candidates. Apply redundancy check to the HMVP candidates against the spatial or temporal Merge candidates.

[0085] To reduce the number of redundancy check operations, the following simplifications are introduced:

[0086] 1) Set the number of HMPV candidates used for Merge list generation to (N <= 4)? M : (8 - N), where N represents the number of existing candidates in the Merge list and M represents the number of available HMVP candidates in the table.

[0087] 2) Once the total number of available Merge candidates reaches the maximum allowed Merge candidates minus 1, terminate the Merge candidate list construction process from the HMVP.

[0088] 2.1.1.3 Derivation of pairwise-averaged Merge candidates

[0089] Generate pairwise-averaged candidates by averaging predefined candidate pairs in the existing Merge candidate list, and define the predefined pairs as {(0, 1), (0, 2), (1, 2), (0, 3), (1, 3), (2, 3)}, where the numbers represent the Merge indices of the Merge candidate list. Calculate the average motion vector for each reference list separately. If both motion vectors are available in a list, average them even if the two motion vectors point to different reference pictures; if only one motion vector is available, use it directly; if no motion vector is available, invalidate the list.

[0090] When the Merge list is incomplete after adding pairwise-averaged Merge candidates, insert zero MVPs at the end until the maximum number of Merge candidates is reached.

[0091] 2.1.2 Merge mode with MVD (MMVD)

[0092] In addition to the Merge mode where the implicitly derived motion information is directly used for the prediction sample generation of the current CU, a Merge mode with motion vector difference (MMVD) is also introduced in VVC. The MMVD flag is signaled immediately after sending the skip flag and the Merge flag to specify whether the MMVD mode is used for the CU.

[0093] In MMVD, after a Merge candidate is selected, it is further refined by the MVD information signaled. The further information includes the Merge candidate flag, the index for specifying the motion amplitude, and the index for indicating the motion direction. In the MMVD mode, one of the first two candidates in the Merge list is selected as the MV basis. The Merge candidate flag is signaled to specify which one to use.

[0094] Figure 5 An example of an MMVD search point is shown.

[0095] The distance index specifies the motion amplitude information and indicates a predefined offset from the starting point. As Figure 5 shown, the offset is added to either the horizontal or vertical component of the starting MV. The relationship between the distance index and the predefined offset is specified in Table 1.

[0096] Table 1 - Relationship between distance index and predefined offset

[0097]

[0098] The direction index indicates the direction of the MVD relative to the starting point. The direction index can represent four directions, as shown in Table 3-8. Note that the meaning of the MVD sign may vary depending on the information of the starting MV. When the starting MV is a non-predicted MV or a bi-predicted MV and both lists point to the same side of the current picture (i.e., both reference POCs are greater than the POC of the current picture, or both are less than the POC of the current picture). POC of the current picture), the signs in Table 2 specify the signs of the MV offsets added to the starting MV. When the starting MV is a bi-predicted MV and the two MVs point to different sides of the current picture (i.e., one reference POC is greater than the POC of the current picture and the other reference POC is less than the POC of the current picture), the signs in Table 2 specify the signs of the MV offsets added to the list 0 MV component of the starting MV, while the sign of the list 1 MV has the opposite value.

[0099] Table 2 - Signs of MV offsets specified by the direction index

[0100]

[0101] 2.1.3 Symmetric MVD encoding and decoding

[0102] In VTM5, in addition to the regular MVD signaling for unidirectional prediction and bi-prediction modes, a symmetric MVD mode of bi-directional MVD signaling is applied. In the symmetric MVD mode, instead of signaling, the motion information including the reference picture indices for list 0 and list 1 and the MVD for list 1 is derived.

[0103] The decoding process of the symmetric MVD mode is as follows:

[0104] 1. At the slice level, the derivation of the variables BiDirPredFlag, RefIdxSymL0, and RefIdxSymL1 is as follows:

[0105] – If mvd_l1_zero_flag is 1, then BiDirPredFlag is set to be equal to 0.

[0106] – Otherwise, if the closest reference picture in list 0 and the closest reference picture in list 1 form a forward-backward reference picture pair or a backward-forward reference picture pair, then BiDirPredFlag is set to 1. Otherwise, BiDirPredFlag is set to 0.

[0107] 2. At the CU level, if the CU is bi-directionally predicted and BiDirPredFlag is equal to 1, then the symmetry mode flag indicating whether to use the symmetry mode is signaled explicitly.

[0108] When the symmetry mode flag is true, only mvp_l0_flag, mvp_l1_flag, and MVD0 are signaled explicitly. The reference indices of list 0 and list 1 are respectively set to be equal to the reference picture pair. MVD1 is set to be equal to (–MVD0). The final motion vector is shown in the following formula.

[0109]

[0110] Figure 6 It is an example illustration of the symmetric MVD mode.

[0111] In the encoder, the symmetric MVD motion estimation starts from the initial MV evaluation. The initial MV candidate group includes the MVs obtained from the uni-directional prediction search, the MVs obtained from the bi-directional prediction search, and the MVs in the AMVP list. The one with the lowest rate-distortion cost is selected as the initial MV for the symmetric MVD motion search.

[0112] 2.1.4 Affine Motion Compensation Prediction

[0113] In HEVC, only the translational motion model is applied to the motion compensation prediction (MCP). In the real world, there are many kinds of motions, such as zooming in / out, rotation, perspective motion, and other irregular motions. In VTM5, the block-based affine transform motion compensation prediction is applied. As Figures 7A - 7B shown, the affine motion field of the block is described by the motion information of two control points (4 parameters) or three control point motion vectors (6 parameters).

[0114] Figures 7A - 7BShows an affine motion model based on control points for a 4-parameter affine model ( Figure 7A ) and a 6-parameter affine model ( Figure 7B ).

[0115] For the 4-parameter affine motion model, the motion vector at the sample position (x, y) in the block is derived as:

[0116]

[0117] For the 6-parameter affine motion model, the motion vector at the sample position (x, y) in the block is derived as:

[0118]

[0119] where, (mv 0x , mv 0y ) is the motion vector of the upper left control point, (mv 1x , mv 1y ) is the motion vector of the upper right control point, and (mv 2x , mv 2y ) is the motion vector of the lower left control point - left corner control point.

[0120] To simplify motion compensation prediction, block-based affine transform prediction is applied. To derive the motion vector for each 4×4 luma sub-block, as Figure 8 shown, the motion vector of the center sample of each sub-block is calculated according to the above equations and rounded to 1 / 16 fractional precision. Then, a motion compensation interpolation filter is applied to generate a prediction for each sub-block with the derived motion vector. The sub-block size of the chrominance component is also set to 4×4. The MV of the 4×4 chrominance sub-block is calculated as the average of the MVs of four corresponding 4×4 luma sub-blocks.

[0121] Figure 8 Shows an example of the affine MVF for each sub-block.

[0122] Similar to what is done for translational motion inter prediction, there are also two affine motion inter prediction modes: affine Merge mode and affine AMVP mode.

[0123] 2.1.4.1 Affine Merge Prediction

[0124] The AF_MERGE mode can be applied to a CU whose width and height are both greater than or equal to 8. In this mode, the CPMV of the current CU is generated based on the motion information of the spatial neighboring CUs. There can be up to five CPMVP candidates, and an index is signaled to indicate which CPMVP candidate to use for the current CU. The following three types of CPVM candidates are used to form the affine Merge candidate list:

[0125] 1) Inherited affine Merge candidates inferred from the CPMV of neighboring CUs

[0126] 2) Constructed affine Merge candidate CPMVP derived using the translational MVs of neighboring CUs

[0127] 3) Zero MV

[0128] In VTM5, there are at most two inherited affine candidates, which are derived from the affine motion models of neighboring blocks, one from the left neighboring CU and one from the upper neighboring CU. The candidate blocks are shown in Figure 9 . For the left predictor, the scan order is A0 -> A1, and for the upper predictor, the scan order is B0 -> B1 -> B2. Only the first inherited candidate from both sides is selected. No pruning check is performed between the two inherited candidates. When a neighboring affine CU is identified, its control point motion vectors are used to derive the CPMVP candidates in the affine Merge list of the current CU. As shown in the figure, if block A in the neighboring lower left is encoded / decoded in affine mode, the motion vectors v2, v3, and v4 of the upper left corner, upper right corner, and lower left corner of the CU containing block A are obtained. When block A is encoded / decoded using a 4-parameter affine model, two CPMVs of the current CU are calculated based on v2 and v3. In the case where block A is encoded / decoded using a 6-parameter affine model, three CPMVs of the current CU are calculated based on v2, v3, and v4.

[0129] Figure 9 Shows the positions of the inherited affine motion predictors.

[0130] Figure 10 Shows an example of the inheritance of control point motion vectors.

[0131] Constructed affine candidates refer to constructing candidates by combining the neighboring translational motion information of each control point. The motion information of the control points is derived from the specified spatial and temporal neighbors shown in Figure 11 . CPMV k (k = 1, 2, 3, 4) represents the k-th control point. For CPMV1, blocks B2 -> B3 -> A2 are checked and the MV of the first available block is used. For CPMV2, blocks B1 -> B0 are checked, for CPMV3, blocks A1 -> A0 are checked. For TMVP (if available) is used as CPMV4.

[0132] After obtaining the MVs of the four control points, affine Merge candidates are constructed based on those motion information. The following combinations of control point MVs are used for sequential construction:

[0133] {CPMV1, CPMV2, CPMV3}, {CPMV1, CPMV2, CPMV4}, {CPMV1, CPMV3, CPMV4}, {CPMV2, CPMV3, CPMV4}, {CPMV1, CPMV2}, {CPMV1, CPMV3}。

[0134] Combinations of 3 CPMVs form 6-parameter affine Merge candidates, while combinations of 2 CPMVs form 4-parameter affine Merge candidates. To avoid motion scaling processing, if the reference indices of the control points are different, the relevant combinations of the control point MVs are discarded.

[0135] Figure 11 Examples of positions for constructing candidate positions for the affine Merge mode are shown.

[0136] After checking the inherited affine Merge candidates and the constructed affine Merge candidates, if the list is still incomplete, zero MVs are inserted at the end of the list.

[0137] 2.1.4.2 Affine AMVP Prediction

[0138] The affine AMVP mode can be applied to CUs with both width and height greater than or equal to 16. An affine flag at the CU level is signaled in the bitstream to indicate whether the affine AMVP mode is used, and then another flag is signaled to indicate whether 4-parameter affine or 6-parameter affine is used. In this mode, the difference between the CPMV of the current CU and its predictor CPMVP is signaled in the bitstream. The affine AVMP candidate list size is 2, and it is generated by using the following four types of CPVM candidate orders:

[0139] 1) Inherited affine AMVP candidates inferred from the CPMVs of neighboring CUs

[0140] 2) Constructed affine AMVP candidate CPMVP derived using the translational MVs of neighboring CUs

[0141] 3) Translational MVs from neighboring CUs

[0142] 4) Zero MVs

[0143] The checking order of the inherited affine AMVP candidates is the same as that of the inherited affine Merge candidates. The only difference is that for AVMP candidates, only affine CUs with the same reference picture as in the current block are considered. When inserting the inherited affine motion predictor into the candidate list, no pruning process is applied.

[0144] The constructed AMVP candidates are from Figure 11Derived from the specified spatial neighbors shown in [Fig.]. The same check order as in affine Merge candidate construction is used. Additionally, the reference picture indices of neighboring blocks are also checked. The first block in the check order that has been inter-coded and has the same reference picture as the current CU is used. There is only one current CU. When the current CU is coded using the 4-parameter affine mode and both mv0 and mv1 are available, they are added to the affine AMVP list as a candidate. When the current CU is coded using the 6-parameter affine mode and all three CPMVs are available, they are added to the affine AMVP list as a candidate. Otherwise, the constructed AMVP candidate is set to unavailable.

[0145] If, after checking the inherited affine AMVP candidates and the constructed AMVP candidates, the affine AMVP list candidates are still less than 2, then mv0, mv1, and mv2 are added in sequence as translational MVs to predict all control point MVs of the current CU (if available). Finally, if the affine AMVP list is still not full, zero MVs are used to fill it.

[0146] 2.1.4.3 Affine Motion Information Storage

[0147] In VTM5, the CPMVs of affine CUs are stored in a separate buffer. The stored CPMVs are only used to generate inherited CPMVPs for the most recently coded CU in affine Merge mode and affine AMVP mode. The sub-block MVs derived from the CPMVs are used for motion compensation, MV derivation for the Merge / AMVP list of translational MVs, and deblocking.

[0148] To avoid the picture line buffer for additional CPMVs, the inheritance of affine motion data from the CU above the CTU is treated differently from the inheritance from regular neighboring CUs. If the candidate CU for affine motion data inheritance is above the CTU row, the lower-left and lower-right sub-block MVs in the line buffer are used instead of the CPMVs for affine MVP derivation. In this way, the CPMVs are only stored in the local buffer. If the candidate CU is 6-parameter affine coded, the affine model is degraded to a 4-parameter model. As Figure 12 shown, along the top CTU boundary, the lower-left and lower-right sub-block motion vectors of the CU are used for affine inheritance of the CU in the bottom CTU.

[0149] Figure 12 is an illustration of the motion vector usage of the proposed combined method.

[0150] 2.1.5 Sub-Block Based Temporal Motion Vector Prediction (SbTMVP)

[0151] VTM supports the sub - block - based temporal motion vector prediction (SbTMVP) method. Similar to the temporal motion vector prediction (TMVP) in HEVC, SbTMVP uses the motion field in the collocated picture to improve the motion vector prediction and the Merge mode of the CUs in the current picture. The same collocated pictures used by TMVP are used for SbTVMP. SbTMVP differs from TMVP in the following two main aspects:

[0152] 1. TMVP predicts the motion at the CU level, while SbTMVP predicts the motion at the sub - CU level;

[0153] 2. Given that TMVP obtains the temporal motion vector from the collocated block in the collocated picture (the collocated block is the bottom - right or center block relative to the current CU), while SbTMVP applies a motion offset before obtaining the temporal motion information from the collocated picture, where the motion offset is obtained from the motion vector of one of the spatial neighbors of the current CU.

[0154] In Figure 13A and 13B the SbTVMP process is shown. SbTMVP predicts the motion vector of the sub - CUs within the current CU in two steps. In the first step, the spatial neighbor A1 in Figures 13A - 13B is checked. If A1 has a motion vector that uses the collocated picture as its reference picture, then that motion vector is selected as the motion offset to be applied. If no such motion is identified, the motion offset is set to (0, 0).

[0155] In the second step, as shown in Figure 13B the motion offset identified in step 1 (i.e., adding it to the coordinates of the current block) is applied to obtain the sub - CU level motion information (motion vector and reference index) from the collocated picture. Figure 13B The example in assumes that the motion offset is set to the motion of block A1. Then, for each sub - CU, the motion information of its corresponding block (the smallest motion grid covering the central sample points) in the collocated picture is used to derive the motion information of the sub - CU. After identifying the motion information of the collocated sub - CU, in a manner similar to the TMVP process in HEVC, it is converted into the motion vector and reference index of the current sub - CU, where temporal motion scaling is applied to align the reference picture of the temporal motion vector to the reference picture of the current CU.

[0156] The sub - CU motion field is derived by applying the motion offset from the spatial neighbor and scaling the motion information from the corresponding collocated sub - CU

[0157] Figure 13A and 13B show examples of the SbTMVP process in VVC.

[0158] In VTM5, a sub-block based Merge list containing a combination of both SbTVMP candidates and affine Merge candidates is used for signaling of the sub-block based Merge mode. The SbTVMP mode is enabled / disabled by a Sequence Parameter Set (SPS) flag. If the SbTMVP mode is enabled, the SbTMVP predictor is added as the first entry of the sub-block based Merge candidate list, and then the affine Merge candidates are added. The size of the sub-block based Merge list is signaled in the SPS, and the maximum allowed size of the sub-block based Merge list is 5 in VTM5.

[0159] The sub-CU size used in SbTMVP is fixed to 8x8, and like the affine Merge mode, the SbTMVP mode is only applicable to CUs with width and height both greater than or equal to 8.

[0160] The encoding / decoding logic for additional SbTMVP Merge candidates is the same as that for other Merge candidates, i.e., for each CU in a P or B slice, an additional RD check is performed to decide whether to use the SbTMVP candidate.

[0161] 2.1.6 Adaptive Motion Vector Resolution (AMVR)

[0162] In HEVC, when the use_integer_mv_flag in the slice header is equal to 0, the Motion Vector Difference (MVD) (between the motion vector of a CU and the predicted motion vector) is signaled in quarter luminance samples. In VVC, a CU-level Adaptive Motion Vector Resolution (AMVR) scheme is introduced. AMVR allows encoding / decoding of the MVD of a CU with different precisions. Depending on the mode of the current CU (regular AMVP mode or affine AVMP mode), the MVD of the current CU can be adaptively selected as follows:

[0163] – Regular AMVP mode: quarter luminance samples, integer luminance samples, or four luminance samples.

[0164] – Affine AMVP mode: quarter luminance samples, integer luminance samples, or 1 / 16 luminance samples.

[0165] If the current CU has at least one non-zero MVD component, the CU-level MVD resolution indication is signaled conditionally. If all MVD components (i.e., the horizontal and vertical MVDs of reference list L0 and reference list L1) are zero, a quarter luminance sample MVD resolution is inferred.

[0166] For a CU with at least one non-zero MVD component, a first flag is signaled to indicate whether quarter-luma sample MVD precision is used for the CU. If the first flag is 0, no further signaling is required and quarter-luma sample MVD precision is used for the current CU. Otherwise, a second flag is signaled to indicate whether integer-luma sample or quarter-luma sample MVD precision is used for a regular AMVP CU. The same second flag is used to indicate whether integer-luma sample or 1 / 16-luma sample MVD precision is used for an affine AMVP CU. To ensure that the reconstructed MV has the expected precision (quarter-luma sample, integer-luma sample, or quarter-luma sample), the motion vector predictor of the CU is rounded to the same precision as the MVD before adding the MVD. The motion vector predictor is rounded towards zero (i.e., a negative motion vector predictor is rounded to positive infinity and a positive motion vector predictor is rounded to negative infinity).

[0167] The codec uses RD checking to determine the motion vector resolution of the current CU. To avoid always performing three CU-level RD checks for each MVD resolution, in VTM5, the RD check for MVD precision other than quarter-luma sample is only conditionally invoked. For the regular AVMP mode, the RD costs for quarter-luma sample MVD precision and integer-luma sample MV precision are first calculated. Then, the RD cost of integer-luma sample MVD precision is compared with the RD cost of quarter-luma sample MVD precision to determine whether it is necessary to further check the RD cost of quarter-luma sample MVD precision. When the RD cost of quarter-luma sample MVD precision is much smaller than the RD cost of integer-luma sample MVD precision, the RD check for quarter-luma sample MVD precision is skipped. For the affine AMVP mode, if the affine inter prediction mode is not selected after checking the rate-distortion costs of the affine Merge / skip mode, Merge / skip mode, quarter-luma sample MVD precision regular AMVP mode, and quarter-luma sample MVD precision affine AMVP mode, then the 1 / 16-luma sample MV precision and 1-pixel MV precision affine inter prediction modes are not checked. In addition, the affine parameters obtained in the quarter-luma sample MV precision affine inter prediction mode are used as the starting search points for the 1 / 16-luma sample and quarter-luma sample MV precision affine inter prediction modes.

[0168] 2.1.7 Motion Field Storage

[0169] In VTM5, the highest precision of explicitly signaled motion vectors is quarter-luma sample. In some inter prediction modes such as the affine mode, motion vectors are derived with 1 / 16-luma sample precision and motion compensation prediction is performed with 1 / 16-sample precision. In terms of internal motion field storage, all motion vectors are stored with 1 / 16-luma sample precision.

[0170] For the temporal motion vector prediction (TMVP) and the advanced TMVP (ATVMP), the motion field storage in the time domain is performed at an 8x8 granularity for motion field compression, compared to the 16x16 granularity in HEVC.

[0171] 2.2 Intra Block Copy

[0172] In the High Efficiency Video Coding (HEVC) Screen Content Coding (SCC) extension and the current Versatile Video Coding (VVC) Test Model (VTM-6.0), Intra Block Copy (IBC) (also known as current picture reference) is adopted. IBC extends the concept of motion compensation from inter-frame coding to intra-frame coding. As Figure 14 shown, when IBC is applied, the current block is predicted from a reference block in the same picture. The samples in the reference block must have been reconstructed before encoding or decoding the current block. Although IBC is not efficient for most sequences captured by cameras, it shows significant coding gain for screen content. The reason is that there are many repetitive patterns in screen content pictures, such as icons and text characters. IBC can effectively eliminate the redundancy between these repetitive patterns. In HEVC-SCC, if an inter coding unit (CU) selects the current picture as its reference picture, it can apply IBC. In this case, the motion vector (MV) is renamed as the block vector (BV), and the BV always has integer pixel accuracy. To be compatible with the main profile of HEVC, the current picture is marked as a "long-term" reference picture in the decoded picture buffer (DPB). It should be noted that, similarly, in multi-view / 3D video coding standards, the inter-view reference pictures are also marked as "long-term" reference pictures.

[0173] After the BV finds its reference block, the prediction can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixels from the original signal. Then, transformation and quantization can be applied as in other coding modes.

[0174] Figure 14 is an illustration of the Intra Block Copy coding mode.

[0175] However, when the reference block is outside the picture, or overlaps with the current block, or is outside the reconstructed area, or is outside the valid area restricted by certain constraints, some or all of the pixel values are not defined. Basically, there are two solutions to this problem. One is to prohibit such a situation, for example, in terms of bitstream consistency. The other is to apply padding to those undefined pixel values. The following subsections describe the solutions in detail.

[0176] 2.3 IBC in HEVC Screen Content Coding Extension

[0177] In the screen content coding and decoding extension of HEVC, when a block uses the current picture as a reference, it shall be ensured that the entire reference block is within the available reconstruction area, as shown in the following text in the specification:

[0178] The derivation of variables offsetX and offsetY is as follows:

[0179] offsetX = (ChromaArrayType == 0)? 0 : (mvCLX[0] & 0x7? 2 : 0)

[0180] (8 - 104)

[0181] offsetY = (ChromaArrayType == 0)? 0 : (mvCLX[1] & 0x7? 2 : 0)

[0182] (8 - 105)

[0183] This is a requirement for bitstream conformance, that is, when the reference picture is the current picture, the luminance motion vector mvLX shall follow the following restrictions:

[0184] - When the derivation process of z-scan order block availability specified in Section 6.4.1 takes (xCuee, yCurr) set to (xCb, yCb) and the neighboring luminance position (xNbY, yNbY) set to be equal to (xPb + (mvLX[0] >> 2) - offsetX, yPb + (mvLX[1] >> 2) - offsetY) as inputs, the output shall be TRUE.

[0185] - When the derivation process of z-scan order block availability specified in Section 6.4.1 takes (xCuee, yCurr) set to (xCb, yCb) and the neighboring luminance position (xNbY, yNbY) set to be equal to (xPb + (mvLX[0] >> 2) + nPbW - 1 + offsetX, yPb + (mvLX[1] >> 2) + nPbH - 1 + offsetY) as inputs, the output shall be TRUE

[0186] - One or both of the following conditions shall be true:

[0187] - The value of (mvLX[0] >> 2) + nPbW + xB1 + offsetX is less than or equal to 0.

[0188] - The value of (mvLX[1] >> 2) + nPbH + yB1 + offsetY is less than or equal to 0.

[0189] - The following condition shall be true:

[0190] (xPb+(mvLX[0]>>2)+nPbSw-1+offsetX) / CtbSizeY-xCurr / CtbSizeY <= yCurr / CtbSizeY-(yPb+(mvLX[1]>>2)+nPbSh-1+offsetY) / CtbSizeY (8-106)

[0191] Therefore, there will be no situation where the reference block overlaps with the current block or the reference block is outside the picture. There is no need to fill the reference or prediction block.

[0192] 2.4. IBC in the VVC Test Model

[0193] In the current VVC test model (i.e., the VTM-4.0 design), the entire reference block should overlap with the current coding tree unit (CTU) and not overlap with the current block. Therefore, there is no need to fill the reference or prediction block. The IBC flag is coded as the prediction mode of the current CU. Therefore, there are a total of three prediction modes for each CU: MODE_INTRA, MODE_INTER, and MODE_IBC.

[0194] 2.4.1. IBC Merge Mode

[0195] In the IBC Merge mode, an index pointing to an entry in the IBC Merge candidate list is parsed from the bitstream. The construction of the IBC Merge list can be summarized sequentially according to the following steps:

[0196] · Step 1: Derive spatial candidates

[0197] · Step 2: Insert HMVP candidates

[0198] · Step 3: Insert paired average candidates

[0199] In the derivation of spatial Merge candidates, up to four Merge candidates are selected among the candidates located at the positions depicted in the appendix Figure 1 The derivation order is A1, B1, B0, A0, and B2. Only when any prediction unit (PU) at positions A1, B1, B0, A0 is unavailable (e.g., because it belongs to another strip or tile) or is not coded in the IBC mode, is position B2 considered. After adding the candidate at position A1, a redundancy check is performed on the insertion of the remaining candidates, which ensures that candidates with the same motion information are excluded from the list, improving the coding efficiency. To reduce the computational complexity, not all possible candidate pairs are considered in the mentioned redundancy check. Instead, only the pairs connected by arrows depicted in the appendix Figure 2 are considered, and a candidate is added to the list only when the corresponding candidates used for the redundancy check have different motion information.

[0200] After inserting the spatial candidate, if the IBC Merge list size is still smaller than the maximum IBC Merge list size, IBC candidates from the HMVP table can be inserted. A redundancy check is performed when inserting HMVP candidates.

[0201] Finally, the paired average candidate is inserted into the IBC Merge list.

[0202] When the reference block identified by the Merge candidate is outside the picture, or overlaps with the current block, or outside the reconstruction region, or outside the valid region restricted by certain constraints, the Merge candidate is called an invalid Merge candidate.

[0203] Note that invalid Merge candidates can be inserted into the IBC Merge list.

[0204] 2.4.2 IBC AMVP Mode

[0205] In the IBC AMVP mode, the AMVP index pointing to an entry in the IBC AMVP list is parsed from the bitstream. The construction of the IBC AMVP list can be summarized in the following steps sequentially:

[0206] · Step 1: Derive spatial candidates

[0207] ο Check A0, A1 until an available candidate is found.

[0208] ο Check B0, B1, B2 until an available candidate is found.

[0209] · Step 2: Insert HMVP candidates

[0210] · Step 3: Insert zero candidates

[0211] After inserting the spatial candidates, if the IBC AMVP list size is still smaller than the maximum IBC AMVP list size, IBC candidates from the HMVP table can be inserted.

[0212] Finally, the zero candidates are inserted into the IBC AMVP list.

[0213] 3. Examples of Technical Problems Solved by the Embodiments and Techniques Described in this Document

[0214] 1) For IBC block vector prediction, using HMVP may be simpler than Merge and AMVP.

[0215] 2) The HMVP design for only block vectors can be simplified and optimized.

[0216] 4. List of Embodiments and Techniques

[0217] The term "IBC" should not be interpreted narrowly. Any technique that uses motion vectors pointing to the same picture that covers the current block can be considered "IBC". Additionally, it should not be limited to unidirectional prediction.

[0218] The detailed inventions below should be considered as examples to explain the general concepts. These inventions should not be interpreted narrowly. Additionally, these inventions can be combined in any way.

[0219] Define the function clip3(min, max, x) as clip3(min,max,x) = x < min? min : (x > max? max : x). Hereinafter, ctbSize represents the width and / or height of the CTU / CTB, and (xCb, yCb) represents the upper left corner of the block relative to the upper left corner of the picture.

[0220] The block vector can be abbreviated as "BV".

[0221] 1. The HMVP table can contain multiple (e.g., N, where N >= 0 and N is an integer) block vector predictors.

[0222] a. In one example, each entry in the HMVP may contain only a pair of integers, such as BVx and BVy.

[0223] b. In one example, each entry in the HMVP can represent the block vector with integer precision.

[0224] c. For example, N = 1, 2, 3, 4, 5, 6, or 8.

[0225] d. In one example, N can be signaled or derived based on other decoding information (such as how many HMVP candidates are allowed for the inter - frame mode).

[0226] e. In one example, there can be multiple HMVP tables, and at least one specific HMVP table includes only BVs (no MV references to reference pictures other than the current picture in the table).

[0227] i. In one example, multiple HMVP tables operate independently.

[0228] 2. One or more entries in the HMVP table can be used to predict the BV of the current block.

[0229] a. In one example, for the block vector (BVx and BVy) and block vector prediction (BVPx and BVPy) in the HMVP, (BVx - BVPx, BVy - BVPy) can be signaled in the bitstream.

[0230] b. In one example, the indices of the block vector predictions (BVPx and BVPy) in the HMVP table can be signaled.

[0231] 3. The CABAC context for the HMVP index used to encode and decode BVP can be shared with the Merge index used for inter - frame mode encoding and decoding.

[0232] a. In one example, the context used to encode and decode the HMVP index for BVP can use the first K (e.g., K = 1 to 8) contexts to encode and decode the Merge index.

[0233] b. In one example, the context used to encode and decode the HMVP index for BVP can use the last K (e.g., K = 1 to 8) contexts to encode and decode the Merge index.

[0234] c. Alternatively, the context used to encode and decode the HMVP index for BVP can be independent of the context used to encode and decode the Merge index.

[0235] 4. The motion vector / block vector derived from HMVP prediction can be clipped.

[0236] a. In one example, the motion vector derived from HMVP prediction, i.e., the motion vector difference plus the HMVP prediction, can be clipped to the allowed motion vector range, e.g., [-32768, 32767].

[0237] 5. When the HMVP table does not contain any entries, it may not be allowed to use block vector prediction.

[0238] a. In one example, the signaling of the HMVP index can be skipped.

[0239] b. Alternatively, in addition, the block vector can be directly signaled in the bitstream.

[0240] c. Alternatively, in addition, a default block vector can be used to predict the block vector.

[0241] i. In one example, (0, 0) can be used to predict the block vector.

[0242] ii. In one example, (-M, 0) can be used to predict the block vector, where M is a positive integer. For example, M can be equal to the width of the current block.

[0243] iii. In one example, (0, -N) can be used to predict the block vector, where N is a positive integer. For example, N can be equal to the height of the current block.

[0244] iv. Whether to use the default BV to predict the BV of the current block may depend on the number of entries in the HMVP table.

[0245] 1) For example, when the number of entries in the HMVP table is less than K, the default BV is used to predict the BV of the current block, e.g., K = 1 or 2.

[0246] 6. The HMVP table can be initialized using multiple constant block vectors (also called default BV).

[0247] a. In one example, (-M * idx, 0) can be set as the initial value of the entry in HMVP whose index is equal to idx, where M is an integer value.

[0248] b. In one example, (M * idx, 0) can be set as the initial value of the entry in HMVP whose index is equal to idx, where M is an integer value.

[0249] c. In one example, (0, -N * idx) can be set as the initial value of the entry in HMVP whose index is equal to idx, where N is an integer value.

[0250] d. In one example, the above M and / or N can be predefined or adaptively changed from one video unit to another video unit.

[0251] i. In one example, M and / or N can depend on the codec information.

[0252] e. In one example, the default BV can be defined as (0, -16), (0, -12), (0, -8), (0, -4), (-16, 0), (-12, 0), (-8, 0), (-4, 0).

[0253] f. In one example, for a certain index, one of the above methods can be used to initialize the entry.

[0254] g. In one example, the HMVP table can be initialized before encoding or decoding a sequence / picture / strip / slice group / slice / tile / sub - picture / CTU row / CTU.

[0255] 7. When the decoded HMVP index is not less than the length of the HMVP list, i.e., the number of available MVs in the list, default processing can be invoked.

[0256] a. In one example, when the decoded index is not less than the length of the HMVP list, the block vector prediction can be set to (0, 0).

[0257] b. In one example, when the decoded index is not less than the length of the HMVP list, the block vector prediction can be set to (-M, 0), where M is a positive integer. For example, M can be equal to the width of the current block.

[0258] c. In one example, when the decoded index is not less than the length of the HMVP list, the block vector prediction can be set to (0, -N), where N is a positive integer. For example, M can be equal to the height of the current block.

[0259] d. In one example, when the decoded index is not less than the length of the HMVP list, the block vector prediction can be set to (M, 0), where M is a positive integer. For example, M can be equal to the width of the current block.

[0260] e. In one example, for instance when the decoded index is not less than the length of the HMVP list, a default prediction mode can be used (e.g., the entire block can be predicted using an intermediate gray value).

[0261] 8. The binarized maximum value of the HMVP index in the bitstream may depend on the number of block vectors that have been considered as HMVP entries.

[0262] a. In one example, the number of block vectors that have been considered as HMVP entries can be set to be equal to the number of times the HMVP table has been updated before decoding / encoding the current block.

[0263] b. In one example, the binarization method, e.g., truncated unary / truncated binary, can depend on the number of block vectors that have been considered as HMVP entries.

[0264] c. Alternatively, the maximum value for the binarization of the HMVP index in the bitstream can depend on the number of available entries in the HMVP table.

[0265] i. Alternatively, the maximum value for the binarization of the HMVP index in the bitstream can be a fixed number (e.g., the HMVP table size), independent of the number of available entries in the HMVP table.

[0266] d. In one example, this number can be a counter (denoted by Cnt) for counting the block vectors that have been considered as HMVP entries.

[0267] i. In one example, after decoding an IBC-coded block, Cnt can be incremented by K (e.g., 1 or 0).

[0268] 1) In one example, when sending a block vector, Cnt will be incremented by 1.

[0269] 2) In one example, when a block encoded or decoded in IBC AMVP mode is detected, Cnt can be incremented by 1.

[0270] 3) In one example, when a non-zero block vector difference is detected, Cnt can be incremented by 1.

[0271] 4) In one example, if Cnt is equal to the HMVP table size / the maximum number of HMVP candidates allowed in the table, Cnt can be incremented by 0.

[0272] ii. In one example, when the HMVP does not contain any entries, the counter is reset to 0.

[0273] iii. In one example, the counter can be reset before encoding or decoding a new video unit.

[0274] 1) In one example, the new video unit is a new CTU row.

[0275] 2) In one example, the new video unit is a sub-region of a new strip / slice / tile / sub-picture / VPDU / CTU / picture.

[0276] e. In one example, the maximum value for binarization of the HMVP index can be min(counter, LEN), where counter is the quantity described above and LEN represents the maximum size of the HMVP table.

[0277] 9. Before predicting the block vector, the block vector prediction (predictor) can be modified.

[0278] a. In one example, the block vector can be modified to a valid block vector of the current block.

[0279] b. In one example, an invalid block vector can not be used as a block vector prediction.

[0280] c. In one example, when the reference region is a CTU / CTB, the block vector can be modified to be within the current CTU / CTB.

[0281] i. In one example, for a block (xCb, yCb) and a block vector prediction (BVPx, BVPy), a modified block vector prediction (BVPMx, BVPMy) can be generated, where BVPMx = clip3(xCb / ctbSize*ctbSize, xCb / ctbSize*ctbSize+ctbSize, xCb+BVPx) – xCb and BVPMy = clip3(yCb / ctbSize*ctbSize, yCb / ctbSize*ctbSize+ctbSize, yCb+BVPy) – yCb.

[0282] d. In one example, BVt = f(BV1, BV2, …, BVn) can be used as a BV prediction, where BV1, BV2, …, BVn are entries in the HMVP table, f is a function such as average(), max(), min(), middle(), etc., and n is an integer greater than 0.

[0283] 10. Block vector prediction (predictors) in the HMVP table can be used to represent the block vector of the current block.

[0284] a. In one example, an index can be signaled in the bitstream to indicate which block vector prediction (predictor) in the HMVP is used as the block vector of the current block.

[0285] i. In one example, one index must correspond to one and only one entry in the HMVP table.

[0286] 1) In one example, the maximum index is equal to N - 1, where N is the number of available entries in the HMVP table.

[0287] 2) In one example, if the index is greater than N - 1, where N is the number of available entries in the HMVP table, then the BV prediction is set to a default BV, such as those defined in bullet 4.

[0288] 3) In one example, the decoded index k can correspond to the (M - 1 - k)-th entry in the HMVP table.

[0289] a. Alternatively, the decoded index k can correspond to the k-th entry in the HMVP table.

[0290] b. In one example, when using HMVP to predict the block vector, a constant block vector difference can be applied.

[0291] i. In one example, the block vector difference of (0, 0) can always be applied to the HMVP entry.

[0292] c. In one example, an indication of whether there is a non-zero block vector difference can be signaled for the CU / PU / block.

[0293] i. Alternatively, in addition, the block vector difference can be signaled only if the block vector difference indication indicates the presence of a non-zero block vector difference.

[0294] d. In one example, which block vector prediction from the HMVP table can be used can depend on an indication of whether there is a non-zero block vector difference that can be signaled for the CU / PU / block.

[0295] 11. Whether and how to apply the proposed method may depend on codec information, such as block dimensions.

[0296] 12. Whether to apply the proposed method and how to apply the proposed method can be signaled from the encoder to the decoder, such as at the sequence level (e.g., SPS or sequence header), picture level (e.g., picture header or PPS), slice level (e.g., slice header), slice group level, tile level, CTU row level, CTU level, etc.

[0297] HMVP is typically used for intra / IBC or other codec methods

[0298] 13. When resetting the HMVP table (e.g., before decoding a new slice / tile / block / sub-picture / CTU row / CTU), a counter associated with the HMVP table indicating the number of available entries (HMVP candidates available in the table) can be reset to K, where K is not equal to 0.

[0299] a. In one example, K depends on the number of default HMVP candidates to be added to the HMVP table (e.g., equal to) during the reset.

[0300] b. In one example, K depends on the maximum number of HMVP candidates in the HMVP table (e.g., equal to).

[0301] 5 Embodiments

[0302] 5.1 Embodiment 1

[0303] This embodiment indicates how to design the syntax for using HMVP in BV coding and decoding. It is based on the latest VVC draft, i.e., JVET-O2001-vE. Changes are highlighted in bold and italic. Deleted text is flagged with double brackets (e.g., [[a]] indicates the deletion of the character "a").

[0304]

[0305] bvp_idx uses truncated Rice (TR) binarization, where

[0306] 8.6.2.1 Overview

[0307] The input to this process is:

[0308] – The luminance position (xCb, yCb) of the top-left sample of the current luminance coding block relative to the top-left luminance sample of the current picture,

[0309] – The variable cbWidth, which is used to specify the width of the current coding block in luminance samples,

[0310] – The variable cbHeight, which is used to specify the height of the current coding block in luminance samples.

[0311] The output of this process is:

[0312] – The luminance block vector in integer sample precision bvL of [[1 / 16 fraction]].

[0313] The derivation of the luminance block vector mvL is as follows:

[0314] – Call the derivation process of IBC luminance block vector prediction specified in Section 8.6.2.2 with the luminance position (xCb, yCb), variables cbWidth and cbHeight as inputs, and output the luminance block vector bvL.

[0315]

[0316] – When general_merge_flag[xCb][yCb] is equal to 0, the following conditions apply:

[0317] 1. The derivation of variable bvd is as follows:

[0318] bvd[0] = MvdL0[xCb][yCb][0] (8 - 900)

[0319] bvd[1] = MvdL0[xCb][yCb][1] (8 - 901)

[0320] 2. Call the motion vector rounding process specified in Section 8.5.2.14 with mvX set to be equal to bvL, rightShift set to be equal to AmvrShift, leftShift set to be equal to AmvrShift as inputs, and the rounded bvL as the output.

[0321] 3. The luminance block vector bvL is modified as follows:

[0322] u[0] = (bvL[0] + bvd[0] + 2 18 ) % 2 18 (8 - 902)

[0323] bvL[0] = (u[0] >= 2 17 )? (u[0] - 2 18 ): u[0] (8 - 903)

[0324] u[1] = (bvL[1] + bvd[1] + 2 18 ) % 2 18 (8 - 904)

[0325] bvL[1] = (u[1] >= 2 17 )? (u[1] - 2 18): u[1] (8 - 905)

[0326] Note 1 – The resulting values of bvL[0] and bvL[1] specified above will always be in the range of -2 17 to 2 17 -1 (including -2 17 and 2 17 -1).

[0327] When IsInSmr[xCb][yCb] is equal to false, the update process of the history-based block vector predictor list specified in Section 8.8.6.6 will be called using the luminance block vector bvL.

[0328] 8.6.2.6 Update Process of the History-Based Block Vector Predictor Candidate List

[0329] The input to this process is:

[0330] – The luminance block vector bvL in [[1 / 16 fraction]] integer sample precision.

[0331] The candidate list HmvpIbcCandList is modified through the following ordered steps:

[0332] 1. Set the variable sameCandExist to false and the variable removeIdx to 0.

[0333] 2. When NumHmvpIbcCand is greater than 0, for each index hMvpIdx with hMvpIdx = 0..NumHmvpIbcCand - 1, the following steps will be applied until identicalCandExist is equal to true:

[0334] – When hMvpCand is equal to HmvpIbcCandList[hMvpIdx], set identicalCandExist to true and removeIdx to hMvpIdx.

[0335] 3. The candidate list HmvpIbcCandList is updated as follows:

[0336] – If identicalCandExist is equal to true or NumHmvpIbcCand is equal to [[5]] then the following conditions apply:

[0337] – For each index i where i = (removeIdx + 1)..(NumHmvpIbcCand - 1), set HmvpIbcCandList[i - 1] to be equal to HmvpIbcCandList[i].

[0338] – Set HmvpIbcCandList[NumHmvpIbcCand - 1] to be equal to bvL.

[0339] – Otherwise identicalCandExist is equal to false and NumHmvpIbcCand is less than [[5]] ), the following conditions apply:

[0340] – Set HmvpIbcCandList[NumHmvpIbcCand++] to be equal to bvL.

[0341] 5.2 Example 2

[0342] This example is based on the AVS3 draft, document number N2686. Changes are marked in bold. 7.1.2.2

[0344] 7.1.6

[0346]

[0347]

[0348] 7.2.2 Semantic Description of Video Sequence

[0349] 7.2.2.1 Semantic Description of Video Sequence

[0350]

[0351] 4-bit unsigned integer.

[0352] The value of NumOfHmvpCandIbc is equal to the value of num_of_hbvp_cand, and the value range is from 0 to 15. A value of 0 for NumOfHmvpCandIbc means that block vector prediction based on historical information should not be used.

[0353] 7.2.6 Coding and Decoding Unit

[0354] Block Vector Prediction Index bvp_idx

[0355] Index value of block vector prediction.

[0356] The value of bvpidx is equal to the value of bvp_idx, and the value of bvpidx is less than the value of num_of_hbvp_cands.

[0357] 8.3.4 Inverse Binarization Method

[0358] 8.3.4.1 Overview

[0359]

[0360] 9.4 Maximum Coding / Decoding Unit Decoding

[0361] Sequential decoding of the maximum decoding unit is performed according to the raster scan order within the strip, and the decoding process is as follows:

[0362] If the current maximum coding / decoding unit is the first maximum coding / decoding unit of the current row in the strip, the value of the candidate number CntHmvp in the historical motion information table is initialized to 0, and the value of the candidate number CntHmvpIbc in the historical block vector information table is initialized to 0.

[0363] 9.5.6 Intra Prediction Mode

[0364] 9.5.6.1 Overview

[0365] When the intra prediction type of the coding / decoding unit is the conventional intra prediction mode, pressing the xxx key can export the luminance prediction mode and chrominance prediction mode of the current coding / decoding unit; when the intra prediction type of the coding / decoding unit is block copy intra prediction, the block vector of the current coding / decoding unit is exported according to 9.5.6.3.

[0366] 9.5.6.3 Block Copy Intra Prediction Mode

[0367] The block vector prediction derivation process of the block copy intra prediction mode is as follows: According to the historical block vector prediction table HmvpCandidateListIbc and the block vector prediction index bvpidx, the historical block vector prediction value MvEPredBv is derived according to the following steps:

[0368] a) If the block vector prediction index bvpidx is less than CntHmvpIbc, the block vector prediction MvEPredBv of the current prediction unit is equal to HmvpCandidateListIbc[bvpidx].

[0369] b) Otherwise, the block vector prediction MvEPredBv of the current prediction unit is a zero vector.

[0370]

[0371] The block vector difference derivation process of the block copy intra prediction mode is as follows:

[0372]

[0373] Alternatively, the following conditions may apply:

[0374]

[0375] The block vector derivation of the block copy intra prediction mode is processed as follows:

[0376]

[0377] bvE is the block vector of the current prediction unit, and BvE is equal to bvE.

[0378] 9.16 Determine the differences and similarities of block vector information

[0379] Two block vectors are different if they meet the following conditions. Otherwise, the two block vectors are the same:

[0380] The L0 motion vectors are not equal.

[0381] 9.18 Update the historical block vector prediction information table

[0382] After the decoding of the current prediction unit is completed, if the current prediction unit is a block copy prediction unit, when NumOfHmvpCand is greater than 0, update the historical block vector prediction information table HmvpCandidateListIbc according to the block vector information of the current prediction block; otherwise, the operations defined in this section will not be performed.

[0383] a) Initialize hmvpIbcIdx to 0.

[0384] a) If CntHmvpIbc is equal to 0, then HmvpCandidateListIbc[CntHmvpIbc] is equal to the block vector information of the current prediction unit, and CntHmvpIbc is incremented by 1.

[0385] b) Otherwise, judge whether the block vector of the current prediction block is the same as HmvpCandidateListIbc[hmvpIdxIbc] according to the method defined in 9.16:

[0386] 1) If the block vector information is the same, perform step d); otherwise, hmvpIdxIbc is incremented by 1.

[0387] 2) If hmvpIdxIbc is less than CntHmvpIbc, go to step c); otherwise, go to step d).

[0388] c) If hmvpIdxIbc is less than CntHmvpIbc, then:

[0389] 1) i ranges from hmvpIdxIbc to CntHmvpIbc - 1,

[0390] · Set HmvpCandidateListIbc[i] equal to HmvpCandidateListIbc[i + 1];

[0391] 2) Set HmvpCandidateListIbc[CntHmvpIbc - 1] equal to the block vector information of the current prediction unit. Otherwise, if hmvpIdxIbc is equal to CntHmvpIbc and CntHmvpIbc is equal to NumOfHmvpCandIbc, then:

[0392] 1) i ranges from 0 to CntHmvpIbc - 1, set HmvpCandidateListIbc[i] equal to HmvpCandidateListIbc[i + 1];

[0393] 2) Set HmvpCandidateListIbc[CntHmvpIbc - 1] equal to the block vector information of the current prediction unit.

[0394] Otherwise, if hmvpIdxIbc is equal to CntHmvpIbc and CntHmvpIbc is less than NumOfHmvpCandIbc, then set HmvpCandidateListIbc[CntHmvpIbc] equal to the block vector information of the current prediction unit and increment CntHmvpIbc by 1.

[0395] ctxIdxStart and ctxIdxInc corresponding to the syntax elements in Table 53

[0396]

[0397] Figure 15 is a block diagram of video processing device 1500. Device 1500 can be used to implement one or more methods described herein. Device 1500 can be implemented in a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. Device 1500 may include one or more processors 1502, one or more memories 1504, and video processing hardware 1506. Processor 1502 can be configured to implement one or more methods described in this document. Memory 1504 can be used to store data and code for implementing the methods and techniques described herein. Video processing hardware 1506 can be used to implement some of the techniques described herein in hardware circuits. In some embodiments, hardware 1506 may be at least partially located in processor 1502, such as a graphics coprocessor.

[0398] Figure 17 is a block diagram showing an example video processing system 1700 in which various techniques disclosed herein may be implemented. Various implementations may include some or all components of system 1700. System 1700 may include an input 1702 for receiving video content. The video content may be received in a raw or uncompressed format (e.g., 8- or 10-bit multi-component pixel values), or may be received in a compressed or codec format. Input 1702 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), etc., and wireless interfaces such as Wi-Fi or cellular interfaces.

[0399] System 1700 may include a codec component 1704, which may implement various encoding or decoding methods described herein. The codec component 1704 may reduce the average bit rate of the video from the input 1702 to the output of the codec component 1704 to produce a codec representation of the video. Thus, codec techniques are sometimes referred to as video compression or video transcoding techniques. The output of the codec component 1704 may be stored or transmitted through a connection represented by component 1706. Component 1708 may use the stored or communicated bitstream (or codec) representation of the video received at input 1702 to generate pixel values or a displayable video to be sent to the display interface 1710. The process of generating a user-visible video from the bitstream representation is sometimes referred to as video decompression. Additionally, although some video processing operations are referred to as "codec" operations or tools, it should be understood that encoding tools or operations are used at the encoder, and the corresponding decoding tools or operations to reverse the encoding results will be performed by the decoder.

[0400] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), or DisplayPort, etc. Examples of storage interfaces include SATA (Serial Advanced Technology Attachment), PCI, IDE interfaces, etc. The techniques described herein may be implemented in various electronic devices, such as mobile phones, laptop computers, smartphones, or other devices capable of performing digital data processing and / or video display.

[0401] Some embodiments of the disclosed technology include making a decision or determination to enable a video processing tool or mode. In one example, when a video processing tool or mode is enabled, the codec will use or implement the tool or mode in the processing of video blocks, but not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, when a video processing tool or mode is enabled based on a decision or determination, the conversion from video blocks to a bitstream representation of the video will use the video processing tool or mode. In another example, when a video processing tool or mode is enabled, the decoder will process the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, the conversion from the bitstream representation of the video to video blocks will be performed using the video processing tool or mode enabled based on the decision or determination.

[0402] Some embodiments of the disclosed technology include making a decision or determination to disable a video processing tool or mode. In one example, when a video processing tool or mode is disabled, the codec will not use the tool or mode in the conversion of video blocks to a bitstream representation of the video. In another example, when a video processing tool or mode is disabled, the decoder will process the bitstream knowing that the bitstream has not been modified using the video processing tool or mode enabled based on the decision or determination.

[0403] As used herein, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from a pixel representation of a video to a corresponding bitstream representation, and vice versa. For example, the bitstream representation of a current video block may correspond to a juxtaposed position in the bitstream defined by the syntax or bits propagated at different positions. For example, a macroblock may be encoded and decoded based on a transformed and encoded error residual, and bits in headers and other fields in the bitstream may also be used to encode and decode the macroblock.

[0404] In some embodiments, the following solutions may be implemented as preferred solutions.

[0405] The following clause-based format may be used to describe various technologies and embodiments. The first set of clauses describes certain features and aspects of the disclosed technology in previous sections.

[0406] The following clauses may be implemented in conjunction with other technologies described in the items listed in the previous section (e.g., item 1).

[0407] 1. A method of video processing (e.g., Figure 16The method shown in (1600) includes: for the conversion between the video region of a video and the codec representation of the video region, determining (1602) whether the table stores any block vector candidates; and based on determining that the table stores at least some block vector candidates, using (1604) multiple candidate block vectors to perform the conversion.

[0408] 2. The method according to clause 1 further includes: based on determining that the table stores zero block vector candidates, performing the conversion by omitting the use of block vector prediction in the conversion.

[0409] 3. The method according to clauses 1 - 2 further includes: based on the codec mode used for the conversion of the video region, selectively updating the converted table.

[0410] 4. The method according to any one of clauses 1 - 3, wherein each candidate block vector includes a pair of integers respectively representing the block vector in the x - direction and the block vector in the y - direction.

[0411] 5. The method according to any one of clauses 1 - 4, wherein the table is configured to store up to N block vectors, where N is an integer pre - specified or signaled in the codec representation.

[0412] The following clauses can be implemented together with other techniques described in the items (e.g., item 2) listed in the previous section.

[0413] 6. The method according to clause 1, wherein performing the conversion includes determining a predicted block vector according to the candidate block vectors in the table.

[0414] 7. The method according to clause 6, wherein the codec representation signals the difference between the block vector predictor and the block vector.

[0415] 8. The method according to clause 6, wherein the codec representation signals an index to the entry in the table corresponding to the block vector predictor.

[0416] The following clauses can be implemented together with other techniques described in the items (e.g., item 3) listed in the previous section.

[0417] 9. The method according to clause 2, wherein the value of the block vector of the video region is signaled in the codec representation.

[0418] 10. The method according to clause 1 further includes: based on determining that the table contains zero block vector candidates, performing the conversion by performing block vector prediction in the conversion using a default block vector.

[0419] 11. The method according to clause 10, wherein the default block vector is (0, 0).

[0420] 12. The method according to clause 10, wherein the default block vector is (-M, 0), where M is the width of the video region.

[0421] The following clauses can be implemented together with other techniques described in the items (e.g., item 4) listed in the previous section.

[0422] 13. A method for video processing, comprising: for the conversion between the video region of a video and the coded representation of the video region, initializing a table by adding a plurality of constant block vectors to the table; and performing the conversion using certain block vectors.

[0423] 14. The method according to clause 13, wherein the value of the constant block vector with index idx is (-M * idx, 0), where M is a positive integer.

[0424] 15. The method according to clause 13, wherein the value of the constant block vector with index idx is (M * idx, 0), where M is a positive integer.

[0425] 16. The method according to clause 13, wherein the value of the constant block vector with index idx is (0, -N * idx), where N is a positive integer.

[0426] The following clauses can be implemented together with other techniques described in the items (e.g., item 5) listed in the previous section.

[0427] 17. A method for video processing, comprising: for the conversion between the video region of a video and the coded representation of the video, determining that the index idx to the table storing N block vector candidates is idx ≥ N; and based on the determination, performing the conversion by using default block vector prediction processing.

[0428] 18. The method according to clause 17, wherein the default block vector prediction processing sets the block vector predictor to the value (0, 0).

[0429] 19. The method according to clause 17, wherein the default block vector prediction processing sets the block vector predictor to the value (-M, 0), where M is a positive integer.

[0430] 20. The method according to clause 17, wherein the default block vector prediction processing sets the block vector predictor to the value (0, N), where N is a positive integer

[0431] The following clauses can be implemented together with other techniques described in the items (e.g., item 6) listed in the previous section.

[0432] 21. A method for video processing, comprising: using a table of block vector values indicating previously used block vectors to perform a conversion between an encoded / decoded representation of a video region of a video and pixel values of the video region; wherein the encoded / decoded representation includes a syntax element representing an index in the table that is considered for the conversion of the video region, and wherein a maximum value of the binarization of the index for the syntax element is a function of a plurality of block vectors previously considered for addition to the table or a plurality of entries.

[0433] 22. The method according to clause 21, wherein the number of block vectors previously considered for addition to the table is equal to the number of times the table is updated by adding or deleting entries during video conversion.

[0434] 23. The method according to clause 21, wherein the maximum value of the binarization is a function of the number of available entries.

[0435] 24. The method according to clause 23, wherein the number of available entries is a counter that changes in steps of K, where K is an integer.

[0436] The following clauses can be implemented together with other techniques described in the items (e.g., item 7) listed in the previous section.

[0437] 25. A method for video processing, comprising: for the conversion between a video region of a video and an encoded / decoded representation of the video region, determining a block motion vector predictor; and generating a modified block motion vector predictor by modifying the block motion vector predictor; performing the conversion using the modified block motion vector predictor.

[0438] 26. The method according to clause 25, wherein the modified block motion vector predictor is generated by modifying the block vector predictor to a valid value.

[0439] 27. The method according to clause 25, wherein the modified block motion vector predictor is generated by modifying the block vector predictor to fall within an encoded / decoded tree unit of the video region.

[0440] The following clauses can be implemented together with other techniques described in the items (e.g., item 8) listed in the previous section.

[0441] 28. A method for video processing, comprising: for the conversion between a video region of a video and an encoded / decoded representation of the video region, selecting a block motion vector predictor from a table of previously used block motion vectors; and performing the conversion using the block motion vector predictor, wherein the block motion vector predictor is signaled in the encoded / decoded representation using an index.

[0442] 29. The method according to clause 28, wherein the index exactly corresponds to one entry in the table.

[0443] 30. A method according to any one of clauses 28 - 29, wherein using the block motion vector predictor includes using the block vector predictor by applying a constant difference.

[0444] 31. The method according to clause 30, wherein the codec representation signals a non - zero constant difference value.

[0445] The following clauses can be implemented together with other techniques described in the items (e.g., item 11) listed in the previous section.

[0446] 32. A method for video processing, comprising: for the conversion between a video region of a video and the codec representation of the video region, resetting a table at the start of the conversion; setting an indication of the available entries of the table to K, where K is an integer; and performing the conversion using the table after the reset.

[0447] 33. The method according to clause 32, wherein K is not equal to zero.

[0448] 34. The method according to any one of clauses 32 - 33, wherein K is based on a plurality of default candidates added to the table during the reset.

[0449] 35. The method according to any one of the above clauses, wherein the video region is a codec unit of the video.

[0450] 36. The method according to any one of the above clauses, wherein the video region is a codec tree unit of the video.

[0451] 37. The method according to any one of clauses 1 to 36, wherein the conversion includes encoding the video into a codec representation.

[0452] 38. The method according to any one of clauses 1 to 36, wherein the conversion includes decoding the codec representation to generate pixel values of the video.

[0453] 39. A video decoding device, comprising a processor configured to implement one or more of the methods described in clauses 1 to 38.

[0454] 40. A video codec device, comprising a processor configured to implement one or more of the methods described in clauses 1 to 38.

[0455] 41. A computer program product having computer code stored thereon, which when executed by a processor causes the processor to implement the method according to any one of clauses 1 to 38.

[0456] 42. The method, device or system described in this document.

[0457] The second set of clauses describes certain features and aspects of the technology disclosed in the previous section, e.g., items 1, 2, 4, 5, and 9 - 12.

[0458] 1. A video processing method (e.g., Figure 18A method 1810 as shown), comprising: for the conversion between a current video block of a current picture of a video and a codec representation of the video, constructing (1812) a history - based motion vector predictor (HMVP) table according to rules, and performing (1814) the conversion using the HMVP table, wherein a block vector representing a displacement between the current video block and a region in the current picture used to predict the current video block is used to codec - encode the current video block; wherein the rules specify that the construction uses block vector information of previously processed video blocks in the HMVP table.

[0459] 2. The method according to clause 1, wherein the rules specify that each entry of the HMVP table contains only a pair of integers BVx and BVy, which respectively represent block vectors in the x - direction and y - direction.

[0460] 3. The method according to clause 1, wherein the rules specify that each entry of the HMVP table represents a block vector with integer precision.

[0461] 4. The method according to clause 1, wherein the rules specify that the HMVP table includes N block vector candidates, where N is 1, 2, 3, 4, 5, 6, or 8.

[0462] 5. The method according to clause 4, wherein the rules specify that N is an integer signaled in the codec representation or derived based on decoding information.

[0463] 6. The method according to clause 1, further comprising: maintaining an additional history - based motion vector predictor (HMVP) table, wherein at least one of the HMVP table or the additional HMVP table includes only block vectors and does not include motion vectors referring to reference pictures other than the current picture.

[0464] 7. A video processing method (e.g., Figure 18B method 1820 as shown), comprising: for the conversion between a current video block of a current picture of a video and a codec representation of the video, determining (1822) a block vector predictor according to one or more entries in a history - based motion vector prediction (HMVP) table, the one or more entries corresponding to one or more block vector candidates from one or more previously processed blocks; and performing (1824) the conversion based on the determination, wherein a block vector representing a displacement between the current video block and a region in the current picture used to predict the current video block is used to codec - encode the current video block.

[0465] 8. A method according to clause 7, wherein the coded representation comprises: (BVx - BVPx, BVy - BVPy), where BVx and BVy respectively represent block vectors in the x-direction and y-direction, and BVPx and BVPy respectively represent block vector predictions in the x-direction and y-direction.

[0466] 9. A method according to clause 7, wherein the coded representation comprises an index to an entry in the HMVP table corresponding to a block vector predictor.

[0467] 10. A video processing method (e.g., Figure 18C the method 1830 as shown), comprising: for the conversion between a current video block of a video and the coded representation of the video, determining (1832) whether to clip a block vector derived using a history-based motion vector prediction (HMVP) table or a motion when it is bright, the history-based motion vector prediction (HMVP) table including one or more entries corresponding to motion information from one or more previously processed blocks; and performing (1834) the conversion based on the determination.

[0468] 11. A method according to clause 10, wherein the motion vector is clipped to an allowable motion vector range.

[0469] 12. A method according to clause 11, wherein the allowable motion vector range is [-32768, 32767].

[0470] 13. A video processing method (e.g., Figure 18D the method 1840 as shown), comprising: for the conversion between a current video block of a current picture of a video and the coded representation of the video, making (1842) a first determination that a history-based motion vector predictor (HMVP) table of the current video block does not include any entries for predicting a block vector, the block vector representing a displacement between the current video block and a region in the current picture used to predict the current video block; making (1844) a second determination regarding using the block vector for the conversion of the current video block based on the first determination and a rule; and performing (1846) the conversion according to the first determination and the second determination.

[0471] 14. A method according to clause 13, wherein the rule specifies omitting the prediction of the block vector.

[0472] 15. A method according to clause 14, wherein the coded representation does not include an index to the HMVP table.

[0473] 16. A method according to clause 13, wherein the rule specifies directly signaling the block vector in the coded representation.

[0474] 17. A method according to clause 13, wherein the rule specifies using a default block vector to predict the block vector.

[0475] 18. A method according to clause 17, wherein the default block vector has a value corresponding to (0, 0), (-M, 0) or (0, -N), where M is a positive integer and N is a positive integer.

[0476] 19. A method according to clause 17, wherein the rule specifies the use of the default block vector based on the number of entries in the HMVP table.

[0477] 20. A video processing method (e.g., Figure 18E the method 1850 shown), comprising: for the conversion between a current video block of a current picture of a video and an encoded / decoded representation of the video, determining (1852) a block motion vector predictor for block vector prediction; generating (1854) a modified block motion vector predictor by modifying the block motion vector predictor; and using the modified block motion vector predictor to perform (1856) the conversion, wherein the block vector prediction predicts a block vector representing the displacement between the current video block and the region in the current picture used to predict the current video block.

[0478] 21. A method according to clause 20, wherein the modified block motion vector predictor is generated by modifying the block vector predictor to a valid value.

[0479] 22. A method according to clause 21, wherein in the case where the generated block motion vector predictor has an invalid value, the generated block motion vector predictor is not used for block vector prediction.

[0480] 23. A method according to clause 20, wherein the modified block motion vector predictor is generated by modifying the block vector predictor to fall within the encoded / decoded tree unit of the current video block.

[0481] 24. A method according to clause 23, wherein a modified block vector predictor (BVPMx, BVPMy) is generated such that BVPMx = clip3(xCb / ctbSize*ctbSize, xCb / ctbSize*ctbSize + ctbSize, xCb + BVPx) - xCb, and BVPMy = clip3(yCb / ctbSize*ctbSize, yCb / ctbSize*ctbSize + ctbSize, yCb + BVPy) – yCb, where xCb and yCb respectively represent the sample positions of the current video block in the x and y directions, BVPx and BVPy represent the block vector predictors in the x and y directions respectively, clip3(min, max, x) is defined as clip3(min, max, x) = x < min? min : (x > max? max : x), and ctbSize represents the width and / or height of the encoded / decoded tree unit or encoded / decoded tree block of the video.

[0482] 25. The method according to clause 20, wherein BVt = f(BV1, BV2, …, BVn) is used as a block vector prediction, where BV1, BV2, …, BVn are entries in a history-based motion vector prediction (HMVP) table, f is a function, and n is an integer greater than 0.

[0483] 26. A video processing method (e.g., Figure 18F the method 1860 shown), comprising: for the conversion between a current video block of a current picture of a video and an encoded / decoded representation of the current video block, determining (1862) a block motion vector predictor for predicting a block vector according to a history-based motion vector prediction (HMVP) table, the history-based motion vector prediction (HMVP) table including motion vector information of previously processed video blocks; and using the block motion vector predictor to perform (1864) the conversion, wherein a block vector representing a displacement between the current video block and a region in the current picture for predicting the current video block is used to encode / decode the current video block in the encoded / decoded representation.

[0484] 27. The method according to clause 26, wherein the encoded / decoded representation includes an index indicating the block motion vector predictor.

[0485] 28. The method according to clause 27, wherein the index exactly corresponds to one entry in the HMVP table.

[0486] 29. The method according to clause 27, wherein the index has a maximum value equal to N - 1, where N is an integer indicating the number of available entries in the HMVP table.

[0487] 30. The method according to clause 29, further comprising determining to use a default block vector for the conversion in case the index is greater than N - 1.

[0488] 31. The method according to clause 26, wherein a constant block vector difference is applied to the entries in the HMVP table.

[0489] 32. The method according to clause 26, wherein the encoded / decoded representation includes an indication indicating whether there is a non-zero block vector difference.

[0490] 33. The method according to clause 26, wherein the encoded / decoded representation includes a non-zero block vector difference.

[0491] 34. The method according to clause 32, wherein determining the block motion vector depends on the indication indicating whether there is a non-zero block vector difference.

[0492] 35. The method according to any one of clauses 1 to 34, wherein the method is further performed depending on the encoding / decoding information of the video.

[0493] 36. A method according to any one of clauses 1 to 35, wherein the conversion is performed according to information signaled at the sequence level, picture level, slice group level, slice level, coding tree unit row level, coding tree unit level.

[0494] 37. A method according to any one of clauses 1 to 36, wherein performing the conversion includes generating a coded representation from a current video block.

[0495] 38. A method according to any one of clauses 1 to 36, wherein performing the conversion includes generating a current video block from a coded representation.

[0496] 39. An apparatus in a video system, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to implement a method according to any one of clauses 1 to 38.

[0497] 40. A computer program product stored on a non-transitory computer-readable medium, the computer program product comprising program code for performing a method according to any one of clauses 1 to 38.

[0498] The third group of clauses describes certain features and aspects of the techniques disclosed in the previous section, e.g., items 3, 8, and 13.

[0499] 1. A video processing method (e.g., method 1910 as shown in Figure 19A ) includes: performing (1912) a conversion between a video including video blocks and a coded representation of the video; wherein the coded representation conforms to format rules, and the format rules specify context-adaptive coding of a block vector predictor (BVP) index for a first video block coded using a block vector (BV) prediction mode by sharing the same context and an index for inter-frame mode coding for a second video block; wherein the BVP index points to an entry in a history-based motion vector predictor list that is used to generate a block vector predictor for the first video block.

[0500] 2. The method according to clause 1, wherein the format rules further specify that the context-adaptive coding decodes the Merge index using the first K contexts.

[0501] 3. The method according to clause 1, wherein the format rules further specify that the context-adaptive coding decodes the Merge index using the last K contexts.

[0502] 4. A video processing method (e.g., Figure 19AThe method shown in (1910) includes: performing (1912) a conversion between a video including video blocks and an encoded / decoded representation of the video; wherein, the encoded / decoded representation conforms to format rules, and wherein the format rules specify: performing context-adaptive encoding / decoding of the block vector predictor (BVP) index of a first video block encoded using a block vector (BV) prediction mode independently of the context for encoding / decoding the index used for encoding / decoding the inter-prediction mode used in a second video block; wherein the BVP index points to an entry in a history-based motion vector predictor list that is used to generate a block vector predictor for the first video block.

[0503] 5. A method of video processing (e.g., Figure 19A the method shown in (1910) includes: performing (1912) a conversion between a current video block of a current picture of a video and an encoded / decoded representation of the video, wherein the current video block is encoded / decoded in the encoded / decoded representation using a block vector that represents the displacement between the current video block and a region in the current picture used to predict the current video block, and wherein the conversion is performed using a history-based motion vector prediction (HMVP) table that contains one or more previously used block vectors; wherein the encoded / decoded representation includes a syntax element that represents an index to an entry in the HMVP table applied to the current video block, and wherein the maximum value of the binarization of the index is determined according to a rule.

[0504] 6. The method according to clause 5, wherein the rule specifies determining the maximum value of the binarization of the index as: i) a function of the number of block vectors previously considered for addition to the HMVP table, ii) the number of available entries in the HMVP table, or iii) a fixed number.

[0505] 7. The method according to clause 6, wherein the number of block vectors previously considered for addition to the HMVP table is equal to the number of times the HMVP table is updated by adding or deleting entries during video conversion.

[0506] 8. The method according to clause 6, wherein the binarization of the index depends on the number of block vectors previously considered for addition to the HMVP table.

[0507] 9. The method according to clause 6, wherein the number of block vectors previously considered for addition to the HMVP table corresponds to a counter value Cnt, which is obtained by counting the number of times a block vector has been considered for addition to the HMVP table.

[0508] 10. The method according to clause 9, wherein after decoding an IBC (inter-block copy) encoded block of the video, the counter value changes by K, where K is an integer.

[0509] 11. The method according to clause 9, wherein when the HMVP table does not contain any entries, the counter value is reset to 0.

[0510] 12. The method according to clause 9, wherein the counter value is reset before encoding / decoding a new video unit.

[0511] 13. The method according to clause 6, wherein the maximum value of the binarization of the index is min(counter, LEN), where the counter corresponds to the counter value Cnt, which is obtained by counting the number of times a block vector has been considered for addition to the HMVP table, and LEN represents the maximum size of the HMVP table.

[0512] 14. A method for video processing (e.g., Figure 19B the method 1920 shown in), comprising: for the conversion between the current video region of a video and the encoded / decoded representation of the video, resetting (1922) a history-based motion vector prediction (HMVP) table, the history-based motion vector prediction (HMVP) table including one or more previously used block vectors, wherein resetting includes setting the indication of the available entries of the HMVP table to K, where K is a non-zero integer; and performing (1924) the conversion using the HMVP table.

[0513] 15. The method according to clause 14, wherein K is based on the default number of candidates added to the table during resetting.

[0514] 16. The method according to clause 14, wherein K is based on the maximum number of candidates in the HMVP table.

[0515] 17. The method according to any one of clauses 1 to 16, wherein performing the conversion includes generating an encoded / decoded representation from the video.

[0516] 18. The method according to any one of clauses 1 to 16, wherein performing the conversion includes generating a video from the encoded / decoded representation.

[0517] 19. A video processing apparatus, comprising a processor configured to implement any one or more of the methods described in clauses 1 to 18.

[0518] 20. A computer-readable medium storing program code, which when executed causes a processor to perform any one or more of the methods described in clauses 1 to 18.

[0519] The fourth group of clauses describes certain features and aspects of the techniques disclosed in the previous sections, e.g., items 6 and 7.

[0520] 1. A method for video processing (e.g., Figure 20The method shown in (2000) includes: for the conversion between the current video block of a video and the codec representation of the video, applying a plurality of constant block vectors to a table to initialize the table, the table including motion vector information of previously processed video blocks; and performing the conversion using the table.

[0521] 2. The method according to clause 1, wherein the table is a history-based motion vector predictor (HMVP) table.

[0522] 3. The method according to clause 1, wherein the value of the constant block vector with index idx is (-M * idx, 0), where M is a positive integer.

[0523] 4. The method according to clause 1, wherein the value of the constant block vector with index idx is (M * idx, 0), where M is a positive integer.

[0524] 5. The method according to clause 1, wherein the value of the constant block vector with index idx is (0, -N * idx), where N is a positive integer.

[0525] 6. The method according to any one of clauses 3 - 5, wherein M and / or N are predefined or adaptively changed between video units of the video.

[0526] 7. The method according to any one of clauses 3 - 5, wherein M and / or N depend on the codec information of the video.

[0527] 8. The method according to clause 1, wherein the plurality of constant block vectors are (0, -16), (0, -12), (0, -8), (0, -4), (-16, 0), (-12, 0), (-8, 0), (-4, 0).

[0528] 9. The method according to clause 1, further including: initializing an entry of the table to a constant block vector for a certain index.

[0529] 10. The method according to clause 1, wherein the initialization of the table is performed before encoding or decoding a sequence, picture, slice, slice group, slice, tile, sub-picture, codec tree unit row, codec tree unit.

[0530] 11. A method for video processing (e.g., Figure 19AThe method shown in (1910) includes: performing (1912) a conversion between a current video block of a current picture of a video and an encoded / decoded representation of the video according to a rule, where the current video block is encoded / decoded in the encoded / decoded representation using a block vector that represents a displacement between the current video block and a region in the current picture used to predict the current video block; wherein the encoded / decoded representation includes a syntax element that indicates an index to a history-based motion vector predictor (HMVP) list for the conversion, and wherein the rule specifies that when the index indicated by the syntax element is not less than the number of entries in the HMVP list, default processing is used to determine the prediction of the block vector.

[0531] 12. The method according to clause 11, wherein when the index indicated by the syntax element is not less than the number of entries in the HMVP list, the rule specifies that the prediction of the block vector is determined to be (0, 0).

[0532] 13. The method according to clause 11, wherein when the index indicated by the syntax element is not less than the number of entries in the HMVP list, the rule specifies that the prediction of the block vector is determined to be (-M, 0), where M is a positive integer indicating the width of the current block.

[0533] 14. The method according to clause 11, wherein when the index indicated by the syntax element is not less than the number of entries in the HMVP list, the rule specifies that the prediction of the block vector is determined to be (M, 0), where M is a positive integer indicating the width of the current block.

[0534] 15. The method according to clause 11, wherein when the index indicated by the syntax element is not less than the number of entries in the HMVP list, the rule specifies that the prediction of the block vector is determined to be (0, -N), where N is a positive integer indicating the height of the current block.

[0535] 16. The method according to clause 11, wherein the default processing uses a default prediction mode.

[0536] 17. The method according to any one of clauses 1 to 16, wherein performing the conversion includes generating an encoded / decoded representation from the current video block.

[0537] 18. The method according to any one of clauses 1 to 16, wherein performing the conversion includes generating the current video block from the encoded / decoded representation.

[0538] 19. A video processing apparatus includes a processor configured to implement the method according to any one or more of clauses 1 to 18.

[0539] 20. A computer-readable medium storing program code that, when executed, causes a processor to implement the method according to any one or more of clauses 1 to 18.

[0540] The disclosed and other solutions, examples, embodiments, modules, and functional operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in combinations of one or more of them. The disclosed embodiments and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing apparatus” includes all apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus can also include code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information for transmission to an appropriate receiver apparatus.

[0541] A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including a compiled or interpreted language, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to be executed on one or more computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0542] The processes and logical flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0543] For example, a processor suitable for executing a computer program includes general and special-purpose microprocessors, and any one or more of any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor that executes instructions and one or more storage devices that store instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, such as, magnetic disks, magneto-optical disks, or optical disks, or is operatively coupled to one or more mass storage devices to receive data therefrom or transfer data thereto, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable hard disks; magneto-optical disks; and CD ROM and DVD ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0544] Although this patent document contains many details, it should not be construed as limiting any subject matter or the scope of any claims, but rather as a description of features of certain embodiments of certain technologies. Certain features described in the context of separate embodiments of this patent document may also be implemented in combination in a single embodiment. Conversely, the various functions described in the context of a single embodiment may also be implemented separately in multiple embodiments, or in any suitable sub-combination. Additionally, although the above features may be described as acting in certain combinations, and even initially claimed as such, in some cases, one or more features from a claimed combination may be removed from the combination, and the claimed combination may be directed to a sub-combination or a variant of a sub-combination.

[0545] Similarly, although the operations are depicted in the drawings in a certain order, this should not be construed to mean that such operations must be performed in the order shown or any order for that matter to achieve the desired results, or that all illustrated operations must be performed. Additionally, the separation of various system components in the embodiments of this patent document should not be construed to mean that such separation is required in all embodiments.

[0546] Only some implementations and examples have been described, and other implementations, enhancements, and variations can be made based on what is described and illustrated in this patent document.

Claims

1. A video processing method, comprising: Determining a prediction mode applied to a current video block for conversion between the current video block of a video and a bitstream of the video; Maintaining a history-based motion vector prediction value (HMVP) table for the prediction mode; and Performing the conversion based on the prediction mode; Among them, In the prediction mode, determining a block vector prediction value of the current video block based on the HMVP table, and obtaining prediction samples of the current video block based on the block vector prediction value; Wherein the HMVP table includes one or more block vector prediction value candidates derived from previously processed video blocks; and Wherein the HMVP table is reset before processing a coding tree unit (CTU) row; Wherein the block vector prediction value of the current video block is further determined based on the size of the current video block, and a block vector for obtaining prediction samples of the current video block is derived based on the block vector prediction value and a difference between the block vector of the current video block and the block vector prediction value; and Wherein one or more syntax elements indicating the difference are included in the bitstream; Wherein when the HMVP table is reset, a counter associated with the HMVP table is reset to a predetermined integer not equal to 0, and the counter represents the number of available candidates in the HMVP table; 2. The method according to claim 1, wherein, A syntax element indicating that the prediction mode is enabled is included at the sequence level or picture level of the bitstream; 3. The method according to claim 1, wherein How the prediction mode is applied depends on the size of the current video block; 4. The method according to claim 1, wherein Before obtaining prediction samples of the current video block, a clipping operation is applied to the block vector; 5. The method according to claim 4, wherein, The block vector is clipped to a range of [-32768, 32767]; 6. The method according to claim 1, wherein An index for deriving the block vector prediction value in a first HVMP table is included in the bitstream; 7. The method according to claim 6, wherein Based on a fixed number, determining a maximum value at which the index in the bitstream is binary-coded; 8. The method according to claim 6, wherein Based on the number of block vectors previously considered for addition to the HMVP table, or based on the number of available candidates in the HMVP table, determining a maximum value at which the index in the bitstream is binary-coded; 9. The method according to claim 8, wherein, The number of block vectors previously considered for addition to the HMVP table is equal to the number of times the HMVP table is updated by adding or deleting entries during the conversion of the video; or Wherein the number of block vectors previously considered for addition to the HMVP table corresponds to a counter value obtained by counting the number of times block vectors considered for addition to the HMVP table; 10. The method according to claim 1, wherein, Obtaining an HMVP index to derive the block vector prediction value; and Wherein when the HMVP index is not less than the number of available candidates in the HMVP table, a default process is invoked; 11. According to the method described in any one of claims 1-10, wherein The conversion includes encoding the current video block into the bitstream; 12. The method according to any one of claims 1-10, wherein, The conversion includes decoding the current video block from the bitstream; 13. The method according to claim 1, further comprising: Performing a conversion between a video including video blocks and a bitstream of the video; Wherein the bitstream complies with format rules; Among them, the format rule specifies to perform context - adaptive coding and decoding of the block - vector prediction value BVP index of the first video block encoded and decoded using the block - vector BV prediction mode by sharing the same context, and the index for inter - frame mode coding and decoding of the second video block; Among them, the BVP index points to an entry in the history - based motion - vector prediction value table, and the history - based motion - vector prediction value table is used to generate a block - vector prediction value for the first video block.

14. The method according to claim 13, wherein the format rule further specifies that the context - adaptive coding and decoding uses the first K contexts to code and decode the Merge index.

15. The method according to claim 13, wherein the format rule further specifies that the context - adaptive coding and decoding uses the last K contexts to code and decode the Merge index.

16. The method according to claim 1, further comprising: Performing a conversion between a video including video blocks and a bit - stream of the video; Among them, the bit - stream conforms to the format rule, Among them, the format rule specifies: independent of the context for coding and decoding the index for inter - frame mode coding and decoding used in the second video block, perform context - adaptive coding and decoding of the block - vector prediction value BVP index of the first video block encoded and decoded using the block - vector BV prediction mode; Among them, the BVP index points to an entry in the history - based motion - vector prediction value table, and the history - based motion - vector prediction value table is used to generate a block - vector predictor for the first video block.

17. The method according to claim 1, further comprising: Performing a conversion between the current video block of the current picture of the video and the bit - stream of the video, Among them, the current video block is coded and decoded in the bit - stream using a block - vector, and the block - vector represents the displacement between the current video block and the region in the current picture used to predict the current video block, Among them, the conversion is performed using a history - based motion - vector prediction HMVP table, and the history - based motion - vector prediction HMVP table contains one or more previously used block - vectors; Among them, the bit - stream includes a syntax element, and the syntax element represents an index of an entry in the HMVP table applied to the current video block, Among them, the maximum value of the binarization of the index is determined according to a rule.

18. The method according to claim 17, wherein The rule specifies to determine the maximum value of the binarization of the index as: i) a function of the number of block - vectors previously considered for addition to the HMVP table, ii) the number of available entries in the HMVP table, or iii) a fixed number.

19. The method according to claim 18, wherein the number of block - vectors previously considered for addition to the HMVP table is equal to the number of times the HMVP table is updated by adding or deleting entries during the video conversion.

20. The method according to claim 18, wherein the binarization of the index depends on the number of block - vectors previously considered for addition to the HMVP table.

21. The method according to claim 18, wherein the number of block vectors previously considered for addition to the HMVP table corresponds to a counter value Cnt, which is obtained by counting the number of times the block vector has been considered for addition to the HMVP table.

22. The method according to claim 21, wherein after decoding an inter-block copy (IBC) coded block of a frame of the video, the counter value is changed by K, where K is an integer.

23. The method according to claim 21, wherein when the HMVP table does not contain any entries, the counter value is reset to 0.

24. The method according to claim 21, wherein the counter value is reset before coding or decoding a new video unit.

25. The method according to claim 18, wherein the maximum value of the binarization of the index is min(counter, LEN), where the counter corresponds to the counter value Cnt obtained by counting the number of times a block vector has been considered for addition to the HMVP table, and LEN represents the maximum size of the HMVP table.

26. The method according to claim 1, further comprising: For a conversion between a current video region of a video and a bitstream of the video, resetting a history-based motion vector prediction (HMVP) table that includes one or more previously used block vectors, wherein the resetting includes setting an indication of available entries of the HMVP table to K, where K is a non-zero integer; and performing the conversion using the HMVP table.

27. The method according to claim 26, wherein K is based on a default number of candidates added to the table during the reset.

28. The method according to claim 26, wherein K is based on a maximum number of candidates in the HMVP table.

29. The method according to any one of claims 13 to 28, wherein performing the conversion includes generating the bitstream from the video.

30. The method according to any one of claims 13 to 28, wherein performing the conversion includes generating the video from the bitstream.

31. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to: For a conversion between a current video block of a video and a bitstream of the video, determine a prediction mode applied to the current video block, Maintain a history-based motion vector prediction (HMVP) table for the prediction mode, and Perform the conversion based on the prediction mode, Among them, In the prediction mode, determine a block vector prediction value of the current video block based on the HMVP table and obtain prediction samples of the current video block based on the block vector prediction value, Wherein the HMVP table contains one or more block vector prediction value candidates derived from previously processed video blocks, and Wherein the HMVP table is reset before processing a coding or decoding tree unit (CTU) row; wherein, the block vector prediction value of the current video block is further determined based on the size of the current video block, the block vector for obtaining the predicted samples of the current video block is derived based on the block vector prediction value and the difference between the block vector of the current video block and the block vector prediction value, and wherein, one or more syntax elements indicating the difference are included in the bitstream; when the HMVP table is reset, the counter associated with the HMVP table is reset to a predetermined integer not equal to 0, and the counter represents the number of available candidates in the HMVP table.

32. The device according to claim 31, wherein, The syntax element indicating that the prediction mode is enabled is included at the sequence level or picture level of the bitstream.

33. A non-transitory computer-readable storage medium storing instructions that cause a processor to: For the conversion between a current video block of a video and the bitstream of the video, determine that a prediction mode is applied to the current video block, Maintain a history-based motion vector prediction value (HMVP) table for the prediction mode, and Perform the conversion based on the prediction mode, Among them, In the prediction mode, determine the block vector prediction value of the current video block based on the HMVP table, and obtain the predicted samples of the current video block based on the block vector prediction value, wherein, the HMVP table contains one or more block vector prediction value candidates derived from previously processed video blocks, and wherein, the HMVP table is reset before processing a coding tree unit (CTU) row; wherein, the block vector prediction value of the current video block is further determined based on the size of the current video block, the block vector for obtaining the predicted samples of the current video block is derived based on the block vector prediction value and the difference between the block vector of the current video block and the block vector prediction value, and wherein, one or more syntax elements indicating the difference are included in the bitstream; when the HMVP table is reset, the counter associated with the HMVP table is reset to a predetermined integer not equal to 0, and the counter represents the number of available candidates in the HMVP table.

34. A method for storing a bitstream of a video, comprising: Determine that a prediction mode is applied to a current video block, Maintain a history-based motion vector prediction value (HMVP) table for the prediction mode, Generate the bitstream based on the prediction mode, and Store the bitstream in a non-transitory computer-readable storage medium, wherein, in the prediction mode, determine the block vector prediction value of the current video block based on the HMVP table, and obtain the predicted samples of the current video block based on the block vector prediction value, wherein, the HMVP table contains one or more block vector prediction value candidates derived from previously processed video blocks, and wherein, the HMVP table is reset before processing a coding tree unit (CTU) row; Among them, the block vector prediction value of the current video block is further determined based on the size of the current video block, and the block vector for obtaining the predicted samples of the current video block is derived based on the block vector prediction value and the difference between the block vector of the current video block and the block vector prediction value, and Among them, one or more syntax elements indicating the difference are included in the bitstream; When the HMVP table is reset, the counter associated with the HMVP table is reset to a predetermined integer not equal to 0, and the counter represents the number of available candidates in the HMVP table.

Images