Entropy coding and decoding for motion precision syntax

Abstract

Systems, methods, and devices for video processing are described. Video processing may include video encoding, video decoding, or video transcoding. An example method of video processing includes performing a conversion between a block of video and a bitstream of video according to a rule. The conversion is based on an adaptive motion vector difference precision (AMVR) tool, and the rule specifies that a context is selected for a first bin within a bin string of a first syntax element specifying a precision that derives a motion vector difference associated with an AMVR shift based on use of a block's codec mode.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is filed in accordance with applicable patent laws and / or rules under the Paris Convention to timely claim priority and the benefit of International Patent Application No. PCT / CN2020 / 088546 filed on May 1, 2020. The entire disclosure of the above application is incorporated by reference as part of the disclosure of this application for all purposes prescribed by law. Technical Field

[0003] This document covers video and image encoding and decoding technologies. Background Art

[0004] Digital video accounts for the largest use of bandwidth on the Internet and other digital communications networks. Bandwidth demand for digital video usage is expected to continue to grow as the number of connected user devices capable of receiving and displaying video increases. Summary of the invention

[0005] The disclosed techniques may be used by video or image decoder or encoder embodiments to perform encoding or decoding using context-based encoding and decoding.

[0006] In one example aspect, a method of processing a video is disclosed. The method includes performing a conversion between a block of the video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the conversion is based on an adaptive motion vector difference precision (AMVR) tool, wherein a representation of a motion vector or a motion vector difference or a motion vector predictor of the video block is represented in the codec representation using adaptive precision; wherein the format rule specifies that the use of adaptive precision is represented in the codec representation by context modeling that depends on codec information of the video block or neighboring blocks of the video block.

[0007] In another example aspect, another method of processing a video is disclosed. The method includes performing a conversion between a video block of the video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the conversion is based on an adaptive motion vector difference precision (AMVR) tool, wherein a representation of a motion vector or a motion vector difference or a motion vector predictor of the video block is represented in the codec representation using adaptive precision; wherein the format rule specifies how to represent the use of adaptive precision in the codec representation through context modeling, such that the context is used to encode a first binary bit and a second binary bit for an index of the precision used by the AMVR tool.

[0008] In another example aspect, another method of processing video is disclosed. The method includes performing conversion between a video including one or more video pictures and a codec representation of the video, the one or more video pictures including a plurality of video blocks, wherein the codec represents a format rule, the format rule being used to signal information about adaptive motion vector difference precision (AMVR) codecs of the one or more video blocks; wherein the format rule specifies that the same context is used to encode and decode binary bits of an AMVR precision index of a first video block encoded using a first codec mode and binary bits of an AMVR precision index of a second video block encoded using a second codec mode.

[0009] In another example aspect, another method of processing a video is disclosed. The method includes performing conversion between a video block of the video and a codec representation of the video, wherein the video block is partitioned into one or more vertical partitions and / or one or more horizontal partitions, wherein the codec representation conforms to a format rule that specifies context-based encoding and decoding of partition information of the video block.

[0010] In another example aspect, another method of processing video is disclosed. The method includes performing conversion between a video block of the video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the format rule specifies a codec condition for deciding whether to use a context codec or a bypass codec to represent a sign of a transform coefficient.

[0011] In another example aspect, another method of processing video is disclosed. The method includes performing a conversion between a video block of the video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the format rule specifies that at the beginning of bypass codec of remaining syntax elements in a third or remaining coefficient scan pass of a transform skip residual codec process, an operation is applied to a variable specifying remaining allowed context codec bits.

[0012] In another example aspect, the above method may be implemented by a video encoder apparatus including a processor.

[0013] In yet another example aspect, the methods may be embodied in the form of processor-executable instructions and stored on a computer-readable program medium.

[0014] These and other aspects are described further in this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 An example of an encoder block diagram is shown.

[0016] Figure 2 Examples of 67 intra prediction modes are shown.

[0017] Figure 3A A 4-parameter affine model example is shown.

[0018] Figure 3B A 6-parameter affine model example is shown.

[0019] Figure 4 An example of the affine MVF for each sub-block is shown.

[0020] Figure 5 Example positions of inherited affine motion predictors are shown.

[0021] Figure 6 An example of control point motion vector inheritance is shown.

[0022] Figure 7 Example positions of candidate positions of the constructed affine merge pattern are shown.

[0023] Figure 8 is an illustration of the motion vector usage of the proposed combination method.

[0024] Fig. 9 Shows sub-block MV V SB and an example of pixel Δv(i,j).

[0025] Fig.10 An example of a multi-type tree partitioning pattern is shown.

[0026] Fig.11 An example of partitioning flag signaling in a quadtree with a nested multi-type tree codec tree structure is shown.

[0027] Fig.12 is a block diagram of an example video processing system.

[0028] Fig.13 An example of a video processing apparatus is shown.

[0029] Fig.14 is a flow chart of an example of a video processing method.

[0030] Fig.15 is a block diagram illustrating a video encoding and decoding system according to some embodiments of the present disclosure.

[0031] Fig.16 is a block diagram illustrating an encoder according to some embodiments of the present disclosure.

[0032] Fig.17 is a block diagram illustrating a decoder according to some embodiments of the present disclosure.

[0033] Fig.18 is a flowchart representation of a video processing method according to one or more embodiments of the present technology.

[0034] Fig.19 is a flowchart representation of another video processing method according to one or more embodiments of the present technology.

[0035] Fig. 20 is a flowchart representation of yet another video processing method according to one or more embodiments of the present technology. DETAILED DESCRIPTION

[0036] This document provides various techniques that can be used by decoders of image or video bitstreams to improve the quality of decompressed or decoded digital video or images. For brevity, the term "video" as used herein includes both sequences of pictures (traditionally referred to as video) and individual images. In addition, video encoders may also implement these techniques during the encoding process in order to reconstruct decoded frames for further encoding.

[0037] The section headings used in this document are for ease of understanding and do not limit the embodiments and techniques to the corresponding sections. Thus, embodiments from one section can be combined with embodiments from other sections.

[0038] 1. Overview

[0039] This document is about video codec technology. Specifically, it deals with AMVR (Adaptive Motion Vector Precision), block segmentation, and other codec tools in image / video codecs. It can be applied to existing video codec standards, such as HEVC, or to standards that are about to be completed (Versatile Video Codec). It can also be applied to future video codec standards or video codecs.

[0040] 2. Preliminary Discussion

[0041] Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T produced the H.261 and H.263 standards, ISO / IEC produced the MPEG-1 and MPEG-4 Visual standards, and the two organizations jointly produced the H.262 / MPEG-2 Video standard, the H.264 / MPEG-4 Advanced Video Codec (AVC) standard, and the H.265 / HEVC standard. Starting with H.262, video codec standards are based on a hybrid video codec structure that utilizes temporal prediction plus transform coding. In order to explore future video codec technologies beyond HEVC, the Joint Video Exploration Team (JVET) was jointly established by VCEG and MPEG in 2015. Since then, JVET has adopted many new methods and incorporated them into reference software called the Joint Exploration Model (JEM). In April 2018, the Joint Video Experts 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 reducing bitrate by 50% compared to HEVC.

[0042] 2.1. Encoding and decoding process of typical video codecs

[0043] Figure 1 An example of an encoder block diagram of VVC is shown, which contains three loop filter blocks: deblocking filter (DF), sample adaptive offset (SAO) and ALF. Unlike DF, which uses a predefined filter, SAO and ALF use the original samples of the current picture to reduce the mean square error between the original samples and the reconstructed samples by adding an offset and applying a finite impulse response (FIR) filter, respectively, where the auxiliary information of the codec signals the offset and filter coefficients. ALF is located at the last processing stage of each picture and can be seen as a tool that attempts to capture and repair artifacts created by previous stages.

[0044] 2.2. Intra-mode codec with 67 intra-prediction modes

[0045] To capture arbitrary edge orientations present in natural videos, the number of directional intra modes is extended from the 33 used by HEVC to 65. Additional directional modes are Figure 2 In the example above, the directional intra prediction modes are shown with dashed arrows, and the planar and DC modes remain unchanged. These more dense directional intra prediction modes are applicable to all block sizes and to both luma and chroma intra prediction.

[0046] like Figure 2As shown, the traditional angular intra prediction direction is defined as clockwise from 45 degrees to -135 degrees. In VTM2, for non-square blocks, several traditional angular intra prediction modes are adaptively replaced with wide-angle intra prediction modes. The replaced mode is signaled using the original method and remapped to the index of the wide-angle mode after parsing. The total number of intra prediction modes remains unchanged, i.e. 67, and the intra mode encoding and decoding remains unchanged.

[0047] In HEVC, each intra-coded block has a square shape and the length of each side is a power of 2. Therefore, no division operation is required to generate the intra predictor using the DC mode. In VVV, blocks can have a rectangular shape, which in general requires the use of a division operation for each block. To avoid the division operation for DC prediction, only the longer side is used to calculate the average for non-square blocks.

[0048] 2.3. Inter-frame prediction

[0049] For each inter-frame prediction CU, the motion parameters include motion vector, reference picture index and reference picture list usage index, as well as additional information required by the new coding features of VVC for inter-frame prediction sample generation. Motion parameters can be signaled in an explicit or implicit manner. When a CU is coded using skip mode, the CU is associated with one PU and has no significant residual coefficients, no coded motion vector increments or reference picture indexes. A Merge mode is specified, in which the motion parameters of the current CU are obtained from neighboring CUs, including spatial and temporal candidates, as well as additional scheduling introduced in VVC. Merge mode can be applied to any inter-frame prediction CU, not just skip mode. An alternative to Merge mode is explicit transmission of motion parameters, in which motion vectors, corresponding reference picture indexes for each reference picture list and reference picture list usage flags, as well as other required information, are explicitly signaled for each CU.

[0050] 2.4. Intra-block copy (IBC)

[0051] Intra-block copying (IBC) is a tool adopted in the HEVC extension on SCC. It is well known that it significantly improves the encoding and decoding efficiency of screen content materials. Since the IBC mode is implemented as a block-level codec mode, block matching (BM) is performed at the encoder to find the best block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to the reference block, which has been reconstructed within the current picture. The luminance block vector of the CU encoded and decoded by IBC is integer precision. The chrominance block vector is also rounded to integer precision. When combined with AMVR, the IBC mode is able to switch between 1-pixel and 4-pixel motion vector precision. The CU encoded and decoded by IBC is regarded as a third prediction mode in addition to the intra or inter prediction mode. The IBC mode is applicable to CUs with a width and height that are less than or equal to 64 luminance samples.

[0052] On the encoder side, hash-based motion estimation is performed for IBC. The encoder performs RD checks on blocks with a width or height no greater than 16 luma samples. For non-Merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return a valid candidate, a local search based on block matching is performed.

[0053] In hash-based search, the hash key match (32-bit CRC) between the current block and the reference block is extended to all allowed block sizes. The hash key calculation for each position in the current picture is based on a 4×4 sub-block. For a current block of larger size, a hash key is determined to match the hash key of a reference block when all hash keys of all 4×4 sub-blocks match the hash keys in the corresponding reference positions. If multiple reference blocks are found to match the hash key of the current block, the block vector cost of each matching reference is calculated and the one with the smallest cost is selected.

[0054] In the block matching search, the search range is set to cover both the previous and current CTUs.

[0055] At the CU level, the IBC mode is signaled with a flag, and can be signaled as IBC AMVP mode or IBC skip / merge mode as follows:

[0056] –IBC Skip / Merge mode: The Merge candidate index is used to indicate which block vectors from the list of neighboring candidate IBC codec blocks are used to predict the current block. The Merge list includes spatial, HMVP, and pairwise candidates.

[0057] – IBC AMVP mode: Block vector differences are encoded in the same way as motion vector differences. The block vector prediction method uses two candidates as predictors, one from the left neighbor and the other from the top neighbor (if IBC encoding). When one neighbor is not available, the default block vector will be used as predictor. A flag is signaled to indicate the block vector predictor index.

[0058] 2.5. Affine Motion Compensated Prediction

[0059] In HEVC, motion compensated prediction (MCP) only applies the translation motion model. However, in the real world, there may be a variety of motions, such as zooming in / out, rotation, perspective motion, and other irregular motions. In VVC, block-based affine transformation motion compensated prediction is applied. Figure 3A-3B As shown, the affine motion field of a block is described by the motion information of two control points (4 parameters) or three control point motion vectors (6 parameters).

[0060] Figure 6 An example of control point motion vector inheritance is shown.

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

[0062]

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

[0064]

[0065] Where (mv 0x ,mv 0y ) is the motion vector of the left top corner control point, (mv 1x ,mv 1y ) is the motion vector of the right top corner control point, and (mv 2x ,mv 2y ) is the motion vector of the left bottom corner control point.

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

[0067] Like translational motion inter prediction, there are two affine motion inter prediction modes: affine merge mode and affine AMVP mode.

[0068] 2.5.1. Affine Merge Prediction

[0069] AF_MERGE mode can be applied to CUs 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 spatially adjacent CUs. There can be up to five CPMVP candidates, and the signaling index is used 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:

[0070] --Inherited affine merge candidates inferred from the CPMV of neighboring CUs

[0071] --Use the translational MV of the adjacent CU to construct the affine Merge candidate CPMVP

[0072] --Zero MV

[0073] In VVC, 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. Figure 5 As shown in . For the left predictor, the scanning order is A0->A1, and for the upper predictor, the scanning order is B0->B1->B2. Only the first inherited candidate from each side is selected. No pruning check is performed between two inherited candidates. When an adjacent affine CU is identified, its control point motion vector is used to derive the CPMVP candidate in the affine Merge list of the current CU. As shown in the figure, if the adjacent left bottom block A is encoded and decoded in affine mode, the motion vectors v2, v3 and v4 of the left top corner, upper right corner and left bottom corner of the CU containing block A are obtained. When block A is encoded and decoded using a 4-parameter affine model, the two CPMVs of the current CU are calculated based on v2 and v3. In the case where block A is encoded and decoded using a 6-parameter affine model, the three CPMVs of the current CU are calculated based on v2, v3 and v4.

[0074] Constructing affine candidates means constructing candidates by combining the adjacent translation motion information of each control point. The motion information of the control point is obtained from Figure 7 The spatial and temporal neighbors shown are derived from the CPMV. k(k=1,2,3,4) indicates the kth control point. For CPMV1, check B2->B3->A2 blocks and use the MV of the first available block. For CPMV2, check B1->B0 blocks, and for CPMV3, check A1->A0 blocks. For TMVP (if available) use as CPMV4.

[0075] After obtaining the MVs of the four control points, construct the affine Merge candidate based on those motion information. The following combinations of control point MVs are used to construct in order:

[0076] {CPMV1,CPMV2,CPMV3},{CPMV1,CPMV2,CPMV4},{CPMV1,CPMV3,CPMV4},{CPMV2,CPMV3,CPMV4},{CPMV1,CPMV2},{CPMV1,CPMV3}

[0077] The combination of 3 CPMVs constructs a 6-parameter affine merge candidate, while the combination of 2 CPMVs constructs a 4-parameter affine merge candidate. To avoid motion scaling processing, if the reference index of the control point is different, the relevant combination of control point MVs is discarded.

[0078] After checking the inherited affine merge candidates and the constructed affine merge candidates, if the list is still incomplete, a zero MV is inserted at the end of the list.

[0079] 2.5.2. Affine AMVP Prediction

[0080] Affine AMVP mode is applicable to CUs with both width and height greater than or equal to 16. A CU-level affine flag is signaled in the bitstream to indicate whether to use affine AMVP mode, and then another flag is signaled to indicate whether to use 4-parameter affine or 6-parameter affine. 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:

[0081] --Inherited affine AMVP candidates inferred from the CPMV of neighboring CUs

[0082] --Use the translation MV of the adjacent CU to derive the constructed affine AMVP candidate CPMVP

[0083] --Translation MV from adjacent CU

[0084] --Zero MV

[0085] The order of checking inherited affine AMVP candidates is the same as that of checking 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.

[0086] The AMVP candidates are constructed from Figure 7 Derived from the specified spatial neighbors shown in . The same check order as in the affine Merge candidate construction is used. In addition, the reference picture index of the neighboring blocks is also checked. The first block in the check order is used, which is inter-coded and has the same reference picture as the current CU. There is only one current CU, when the current CU is encoded and decoded 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 encoded and decoded 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 will be set to unavailable.

[0087] If after checking the inherited affine AMVP candidates and the constructed AMVP candidates, the affine AMVP list candidate is still less than 2, then mv0, mv1, and mv2 will be added in sequence as translation MVs to predict all control point MVs of the current CU (if available). Finally, if the affine AMVP list is still not full, it is filled with zero MVs.

[0088] 2.5.3. Affine motion information storage

[0089] In VVC, the CPMV of an affine CU is stored in a separate buffer. The stored CPMV is only used to generate inherited CPMVP for the most recently encoded CU in affine Merge mode and affine AMVP mode. The sub-block MV derived from the CPMV is used for motion compensation, MV derivation of the Merge / AMVP list of the translation MV, and deblocking.

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

[0091] 2.5.4. Prediction Refinement with Optical Flow for Affine Mode

[0092] Compared with pixel-based motion compensation, sub-block-based affine motion compensation can save memory access bandwidth and reduce computational complexity, but at the expense of prediction accuracy loss. In order to obtain finer motion compensation granularity, prediction refinement with optical flow (PROF) is used to refine sub-block-based affine motion compensation prediction without increasing the memory access bandwidth for motion compensation. In VVC, after performing sub-block-based affine motion compensation, the brightness prediction samples are refined by adding the difference derived from the optical flow equation. PROF is described as the following four steps.

[0093] Step 1) Perform sub-block based affine motion compensation to generate sub-block prediction I(i,j).

[0094] Step 2) Use a 3-tap filter [-1, 0, 1] to calculate the spatial gradient g of the sub-block prediction at each sample point x (i,j) and g y (i,j). The gradient calculation is exactly the same as that in BDOF.

[0095] g x (i,j)=(I(i+1,j)>>shift1)-(I(i-1,j)>>shift1) (2-3)

[0096] g y (i,j)=(I(i,j+1)>>shift1)-(I(i,j-1)>>shift1) (2-4)

[0097] Shift1 is used to control the accuracy of the gradient. The sub-block (e.g. 4x4) prediction is extended by one pixel on each side for gradient calculation. To avoid extra memory bandwidth and extra interpolation calculations, those extended samples on the extended boundary are copied from the nearest integer pixel position in the reference picture.

[0098] Step 3) The brightness prediction refinement is calculated by the following optical flow equation.

[0099] ΔI(i,j)=g x (i,j)*Δv x (i,j)+g y (i,j)*Δv y (i,j) (2-5)

[0100] Wherein, Δv(i,j) is the difference between the sample point MV (expressed as Δv(i,j)) calculated for the sample point position (i,j) and the sub-block MV of the sub-block to which the sample point (i,j) belongs, as Fig. 9As shown in Figure 1, Δv(i,j) is quantized with 1 / 32 brightness sample accuracy as the unit.

[0101] Since the affine model parameters and the sample position relative to the sub-block center do not change between sub-blocks, Δv(i,j) can be calculated for the first sub-block and reused for other sub-blocks in the same CU. Assume that dx(i,j) and dy(i,j) are the distance from the sample position (i,j) to the sub-block (x SB ,y SB )’s center, Δv(x,y), can be derived from the following equations,

[0102]

[0103]

[0104] To maintain accuracy, the sub-block (x SB ,y SB ) is calculated as ((W SB -1) / 2,(H SB -1) / 2), where W SB and H SB are the width and height of the sub-block respectively.

[0105] For the 4-parameter affine model,

[0106]

[0107] For the 6-parameter affine model,

[0108]

[0109] Where (v 0x ,v 0y )、(v 1x ,v 1y )、(v 2x ,v 2y ) are the top left, top right and bottom left control point motion vectors, w and h are the width and height of the CU.

[0110] Step 4) Finally, the luma prediction refinement ΔI(i,j) is added to the sub-block prediction I(i,j). The final prediction I' is generated by the following equation.

[0111] I'(i,j)=I(i,j)+ΔI(i,j) (3-10)

[0112] PROF is not applicable to two cases of affine-encoded CUs: 1) all control point MVs are the same, which indicates that the CU has only translational motion; 2) the affine motion parameters are larger than the specified limit, because the sub-block-based affine MC is downgraded to CU-based MC to avoid large memory access bandwidth requirements.

[0113] A fast coding method is applied to reduce the coding complexity of affine motion estimation. PROF is not applied in the affine motion estimation stage in the following two cases: a) If the CU is not a root block and its parent block does not select the affine mode as its best mode, PROF is not applied because the current CU may select the affine mode because the best mode is low; b) If the magnitudes of the four affine parameters (C, D, E, F) are all less than a predefined threshold and the current picture is not a low-latency picture, PROF is not applied because the improvement introduced by PROF is small in this case. In this way, affine motion estimation with PROF can be accelerated.

[0114] 2.6. Example availability process of chunk splitting

[0115] 6.4.1 Allowable Four-Partition Process

[0116] The input to this process is:

[0117] – Codec block size cbSize in luma samples,

[0118] –Multi-type tree depth mttDepth,

[0119] – The variable treeType specifies whether to use a single tree (SINGLE_TREE) or a dual tree to split the codec tree nodes, and when using a dual tree, whether the current processing is the luma (DUAL_TREE_LUMA) or chroma component (DUAL_TREE_CHROMA),

[0120] – The variable modeType specifies whether intra (MODE_INTRA), IBC (MODE_IBC) and inter codec modes (MODE_TYPE_ALL) can be used, or whether only intra and IBC codec modes (MODE_TYPE_INTRA) can be used, or whether only inter codec mode (MODE_TYPE_INTER) can be used for a codec unit within a codec tree node.

[0121] The output of this process is the variable allowSplitQt.

[0122] The variable allowSplitQt is exported as follows:

[0123] – Set allowSplitQt equal to FALSE if one or more of the following conditions are true:

[0124] –treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA and cbSize is less than or equal to MinQtSizeY

[0125] –treeType is equal to DUAL_TREE_CHROMA and cbSize is less than or equal to (MinQtSizeC*SubHeightC / SubWidthC)

[0126] –mttDepth is not equal to 0

[0127] –treeType is equal to DUAL_TREE_CHROMA and (cbSize / SubWidthC) is less than or equal to 4

[0128] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0129] – Otherwise, allowSplitQt is set equal to TRUE.

[0130] 6.4.2 Allowing binary partitioning process

[0131] The input to this process is:

[0132] – Binary split mode btSplit,

[0133] – Codec block width cbWidth in luma samples,

[0134] – Codec block height cbHeight in luma samples,

[0135] – the position (x0, y0) of the top left luma sample of the considered codec block relative to the top left luma sample of the picture,

[0136] –Multi-type tree depth mttDepth,

[0137] – maximum multi-type tree depth with offset maxMttDepth,

[0138] – Maximum binary tree size maxBtSize,

[0139] – minimum quadtree size minQtSize,

[0140] – Split index partIdx,

[0141] – The variable treeType specifies whether to use a single tree (SINGLE_TREE) or a dual tree to split the codec tree nodes, and when using a dual tree, whether the current processing is the luma (DUAL_TREE_LUMA) or chroma component (DUAL_TREE_CHROMA),

[0142] – The variable modeType specifies whether intra (MODE_INTRA), IBC (MODE_IBC) and inter codec modes (MODE_TYPE_ALL) can be used, or whether only intra and IBC codec modes (MODE_TYPE_INTRA) can be used, or whether only inter codec mode (MODE_TYPE_INTER) can be used for a codec unit within a codec tree node.

[0143] The output of this process is the variable allowBtSplit.

[0144] Table 2-1. parallelTtSplit and cbSize specifications based on btSplit

[0145] btSplit==SPLIT_BT_VER btSplit == SPLIT_BT_HOR parallelTtSplit SPLIT_TT_VER SPLIT_TT_HOR cbSize cbWidth cbHeight

[0146] The variables parallelTtSplit and cbSize are derived as specified in Table 2-1.

[0147] The variable allowBtSplit is exported as follows:

[0148] – Set allowBtSplit equal to FALSE if one or more of the following conditions are true:

[0149] –cbSize is less than or equal to MinBtSizeY

[0150] –cbWidth is greater than maxBtSize

[0151] –cbHeight is greater than maxBtSize

[0152] –mttDepth is greater than or equal to maxMttDepth

[0153] –treeType is equal to DUAL_TREE_CHROMA and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0154] –treeType equals DUAL_TREE_CHROMA and (cbWidth / SubWidthC) equals 4 and btSplit equals SPLIT_BT_VER

[0155] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0156] –cbWidth*cbHeight is equal to 32 and modeType is equal to MODE_TYPE_INTER

[0157] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0158] –btSplit is equal to SPLIT_BT_VER

[0159] –y0+cbHeight is greater than pic_height_in_luma_samples

[0160] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0161] –btSplit is equal to SPLIT_BT_VER

[0162] –cbHeight is greater than 64

[0163] –x0+cbWidth is greater than pic_width_in_luma_samples

[0164] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0165] –btSplit is equal to SPLIT_BT_HOR

[0166] –cbWidth is greater than 64

[0167] –y0+cbHeight is greater than pic_height_in_luma_samples

[0168] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0169] –x0+cbWidth is greater than pic_width_in_luma_samples

[0170] –y0+cbHeight is greater than pic_height_in_luma_samples

[0171] –cbWidth is greater than minQtSize

[0172] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0173] –btSplit is equal to SPLIT_BT_HOR

[0174] –x0+cbWidth is greater than pic_width_in_luma_samples

[0175] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[0176] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE:

[0177] –mttDepth is greater than 0

[0178] –partIdx is equal to 1

[0179] –MttSplitMode[x0][y0][mttDepth-1] is equal to parallelTtSplit

[0180] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0181] –btSplit is equal to SPLIT_BT_VER

[0182] –cbWidth is less than or equal to 64

[0183] –cbHeight is greater than 64

[0184] – Otherwise, if all of the following are true, then set allowBtSplit equal to FALSE

[0185] –btSplit is equal to SPLIT_BT_HOR

[0186] –cbWidth is greater than 64

[0187] –cbHeight is less than or equal to 64

[0188] – Otherwise, allowBtSplit is set equal to TRUE.

[0189] 6.4.3 Allowing ternary partitioning process

[0190] The input to this process is:

[0191] – ternary split mode ttSplit,

[0192] – Codec block width cbWidth in luma samples,

[0193] – Codec block height cbHeight in luma samples,

[0194] – the position (x0, y0) of the top left luma sample of the considered codec block relative to the top left luma sample of the picture,

[0195] –Multi-type tree depth mttDepth

[0196] – maximum multi-type tree depth with offset maxMttDepth,

[0197] – Maximum ternary tree size maxTtSize,

[0198] – The variable treeType specifies whether to use a single tree (SINGLE_TREE) or a dual tree to split the codec tree nodes. When using a dual tree, whether the current processing is the luma (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA).

[0199] – The variable modeType specifies whether intra (MODE_INTRA), IBC (MODE_IBC) and inter codec modes (MODE_TYPE_ALL) can be used, or whether only intra and IBC codec modes (MODE_TYPE_INTRA) can be used, or whether only inter codec mode (MODE_TYPE_INTER) can be used for a codec unit within a codec tree node.

[0200] The output of this process is the variable allowTtSplit.

[0201] Table 2-2. cbSize specification based on ttSplit

[0202] ttSplit==SPLIT_TT_VER ttSplit==SPLIT_TT_HOR cbSize cbWidth cbHeight

[0203] The variable cbSize is derived as specified in Table 2-2.

[0204] The variable allowTtSplit is exported as follows:

[0205] – Set allowTtSplit equal to FALSE if one or more of the following conditions are true:

[0206] –cbSize is less than or equal to 2*MinTtSizeY

[0207] –cbWidth is greater than Min(64,maxTtSize)

[0208] –cbHeight is greater than Min(64,maxTtSize)

[0209] –mttDepth is greater than or equal to maxMttDepth

[0210] –x0+cbWidth is greater than pic_width_in_luma_samples

[0211] –y0+cbHeight is greater than pic_height_in_luma_samples

[0212] –treeType is equal to DUAL_TREE_CHROMA and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0213] –treeType equals DUAL_TREE_CHROMA and (cbWidth / SubWidthC) equals 8 and ttSplit equals SPLIT_TT_VER

[0214] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0215] –cbWidth*cbHeight is equal to 64 and modeType is equal to MODE_TYPE_INTER

[0216] — Otherwise, allowTtSplit is set equal to TRUE.

[0217] 6.4.4 Neighboring Block Availability Derivation Process

[0218] The input to this process is:

[0219] – The luminance position of the top left sample of the current block relative to the top left luminance sample of the current picture (xCurr, yCurr),

[0220] – The luminance position (xNbY, yNbY) covered by the neighboring block relative to the top left luminance sample of the current picture, – The variable checkPredModeY specifies whether the availability depends on the prediction mode,

[0221] – The variable cIdx specifies the color component of the current block.

[0222] The output of this process is the availability of neighboring blocks covering the position (xNbY, yNbY), denoted as availableN.

[0223] The neighboring block availability availableN is derived as follows:

[0224] – availableN is set equal to FALSE if one or more of the following conditions are true:

[0225] –xNbY is less than 0.

[0226] –yNbY is less than 0.

[0227] –xNbY is greater than or equal to pic_width_in_luma_samples.

[0228] –yNbY is greater than or equal to pic_height_in_luma_samples.

[0229] —IsAvailable[cIdx][xNbY][yNbY] is equal to FALSE.

[0230] – The neighboring block is contained in a different stripe than the current block.

[0231] – The neighboring block is contained in a different slice than the current block.

[0232] –sps_entropy_coding_sync_enabled_flag is equal to 1 and (xNbY>>CtbLog2SizeY) is greater than or equal to (xCurr>>CtbLog2SizeY)+1.

[0233] — Otherwise, availableN is set equal to TRUE.

[0234] availableN is set equal to FALSE when all of the following conditions are true:

[0235] —checkPredModeY is equal to TRUE.

[0236] —availableN is set equal to TRUE.

[0237] – CuPredMode[0][xNbY][yNbY] is not equal to CuPredMode[0][xCurr][yCurr].

[0238] 2.7. Adaptive Motion Vector Precision (AMVR)

[0239] In HEVC, when use_integer_mv_flag in the slice header is equal to 0, the motion vector difference (MVD) (between the CU's motion vector and the predicted motion vector) is signaled in units of quarter luma samples. In VVC, a CU-level adaptive motion vector precision (AMVR) scheme is introduced.

[0240] AMVR allows encoding and decoding of the CU's MVD with different precisions. Depending on the current CU mode (normal AMVP mode or affine AVMP or IBC mode), the current CU's MVD can be adaptively selected as follows:

[0241] – Normal AMVP mode: 1 / 4 luma sample, 1 / 2 luma sample, 1 luma sample or 4 luma samples.

[0242] – Affine AMVP mode: 1 / 4 luma sample, 1 luma sample, or 1 / 16 luma sample.

[0243] –IBC mode: 1 brightness sample or 1 / 4 brightness sample.

[0244] If the current CU has at least one non-zero MVD component, the CU-level MVD precision indication is conditionally signaled.If all MVD components (ie, both horizontal and vertical MVDs for reference list L0 and reference list L1) are zero, 1 / 4 luma sample MVD precision is inferred.

[0245] For a CU coded using normal AMVP inter-mode (non-IBC, non-affine) with at least one non-zero MVD component, the first flag (e.g. ) to indicate whether 1 / 4 luma sample MVD precision is used for the CU. If the first flag is 0, no further signaling is required and 1 / 4 luma sample MVD precision is used for the current CU. Otherwise, the second flag (e.g., The first binary bit of the ) is signaled to indicate that 1 / 2 luma samples or other MVD precision (1 luma sample or 4 luma samples) is used for normal AMVP CU. In the case of 1 / 2 luma samples, a 6-tap interpolation filter is used for the 1 / 2 luma sample position instead of the default 8-tap interpolation filter. Otherwise, the third flag (e.g., The second binary bit of the MVD precision bit is used to indicate whether 1 luma sample or 4 luma sample MVD precision is used for a normal AMVP CU.

[0246] For a CU encoded and decoded using the affine AMVP mode, the second flag is used to indicate whether to use 1 luma sample or 1 / 16 luma sample MVD precision.

[0247] For CUs encoded using IBC mode, the first flag is not signaled and is inferred to be equal to 1.

[0248] In the current design of AMVR, A value of 0 specifies that the precision of the motion vector difference is 1 / 4 luma sample. Equal to 1 specifies that the precision of the motion vector difference is further specified by amvr_precision_idx.

[0249] The precision of the motion vector interpolation specified for AmvrShift is defined in Table 2-3.

[0250] Example syntax table for AMVR

[0251] 7.3.10.5 Codec unit syntax

[0252]

[0253]

[0254]

[0255]

[0256] More specifically, the bit strings and contexts used to encode and decode the bit strings of amvr_flag and amvr_precision_idx are defined as follows:

[0257]

[0258]

[0259]

[0260]

[0261]

[0262] 7.4.11.5 Codec unit semantics

[0263] [x0][y0] specifies the precision of the motion vector difference for AmvrShift as defined in Table 2-3. Array index x0, y0 specifies the position (x0, y0) of the top left luma sample of the considered codec block relative to the top left luma sample of the picture.

[0264] When amvr_precision_idx[x0][y0] is not present, it is inferred to be equal to 0.

[0265] Table 2-3.AmvrShift specifications

[0266]

[0267] 9.3.3 Binarization process

[0268] Table 126 – Syntax elements and associated binarization

[0269]

[0270]

[0271]

[0272] 9.3.2.2 Context variable initialization process

[0273] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0274]

[0275] Table 88 – initValue and shiftIdx specifications for ctxIdx of amvr_flag

[0276]

[0277] Table 89 – initValue and shiftIdx specifications for ctxIdx of amvr_precision_idx

[0278]

[0279] 9.3.4.2 Export process of ctxTable, ctxIdx and bypassFlag

[0280] 9.3.4.2.1 Overview

[0281] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0282]

[0283] 2.8. Division Information

[0284] In VVC, a quadtree with nested multi-type trees using binary and ternary partition structures replaces the concept of multiple partition unit types. For example, it removes the separation of CU, PU, ​​and TU concepts, except for CUs whose size is too large for the maximum transform length, and supports greater flexibility in CU partition shapes. In the codec tree structure, a CU can have a square or rectangular shape. The codec tree unit (CTU) is first partitioned by a quadtree (also called a quadtree) structure. Then, the quadtree leaf nodes can be further partitioned by a multi-type tree structure. Fig.10 As shown, there are four types of partitions in the multi-type tree structure, vertical binary partition (SPLIT_BT_VER), horizontal binary partition (SPLIT_BT_HOR), vertical ternary partition (SPLIT_TT_VER), horizontal ternary partition (SPLIT_TT_HOR). The multi-type tree leaf node is called a codec unit (CU). Unless the CU is too large for the maximum transform length, this partition is used for prediction and transform processing without further partitioning. This means that in most cases, CU, PU, ​​and TU have the same block size in a quadtree with a nested multi-type tree codec block structure. An exception occurs when the maximum supported transform length is less than the width or height of the color component of the CU.

[0285] Fig.11 The signaling mechanism for split partition information in a quadtree with a nested multi-type tree codec tree structure is shown. The codec tree unit (CTU) is regarded as the root of the quadtree and is first split by the quadtree structure. Each quadtree leaf node (when large enough to allow it) is then further split by the multi-type tree structure. In the multi-type tree structure, the first flag (mtt_split_cu_flag) is signaled to indicate whether the node is further split; when a node is further split, the second flag (mtt_split_cu_vertical_flag) is signaled to indicate the split direction, and then the third flag (mtt_split_cu_binary_flag) is signaled to indicate whether the split is binary or ternary. Based on the values ​​of mtt_split_cu_vertical_flag and mtt_split_cu_binary_flag, the multi-type tree split mode (MttSplitMode) of the CU is derived, as shown in Table 2-4.

[0286] Table 2-4. MttSplitMode derivation based on multi-type tree syntax elements

[0287]

[0288] mtt_split_cu_vertical_flag is equal to 1 and specifies that the codec unit is split horizontally.

[0289] When mtt_split_cu_vertical_flag is not present, it is inferred as follows:

[0290] – If allowSplitBtHor is equal to TRUE or allowSplitTtHor is equal to TRUE, the value of mtt_split_cu_vertical_flag is inferred to be equal to 0.

[0291] – Otherwise, the value of mtt_split_cu_vertical_flag is inferred to be equal to 1.

[0292] Example syntax table for mtt_split_cu_vertical_flag

[0293] 9.3.2.2 Context variable initialization process

[0294] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0295]

[0296] Table 61 – initValue and shiftIdx specifications for ctxInc of mtt_split_cu_vertical_flag

[0297]

[0298] 9.3.4.2 Export process of ctxTable, ctxIdx and bypassFlag

[0299] 9.3.4.2.1 Overview

[0300] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0301]

[0302] 9.3.4.2.3 Derivation of ctxInc for the syntax element mtt_split_cu_vertical_flag

[0303] The inputs to this process are the luma position (x0, y0) which specifies the top left luma sample of the current luma block relative to the top left sample of the current picture, the dual-tree channel type chType, the width and height cbWidth and cbHeight of the current codec block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the codec tree semantics in clause 7.4.11.4.

[0304] The output of this process is ctxInc.

[0305] The position (xNbL, yNbL) is set equal to (x0-1, y0) and the derivation procedure for neighbor block availability specified in clause 6.4.4 is called with the position (xCurr, yCurr) set equal to (x0, y0) and the neighbor position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set equal to FALSE, and cIdx as input, and the output assigned to availableL.

[0306] Set position (xNbA, yNbA) equal to (x0, y0-1), invoke the derivation procedure for neighbor block availability specified in Clause 6.4.4 with position (xCurr, yCurr) set equal to (x0, y0), neighbor position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set equal to FALSE, and cIdx as input, and assign the output to availableA.

[0307] The allocation rules for ctxInc are as follows:

[0308] – If allowSplitBtVer+allowSplitBtHor is greater than allowSplitTtVer+allowSplitTtHor, then ctxInc is set equal to 4.

[0309] – Otherwise, if allowSplitBtVer+allowSplitBtHor is less than allowSplitTtVer+allowSplitTtHor, then ctxInc is set equal to 4.

[0310] – Otherwise, the following applies:

[0311] – The variables dA and dL are derived as follows

[0312] dA=cbWidth / (availableA?CbWidth[chType][xNbA][yNbA]:1) (1563)

[0313] dL=cbHeight / (availableL?CbHeight[chType][xNbL][yNbL]:1) (1564)

[0314] – ctxInc is set equal to 0 if any of the following conditions is true:

[0315] –dA is equal to dL,

[0316] –availableA is equal to FALSE,

[0317] –availableL is equal to FALSE.

[0318] – Otherwise, if dA is less than dL, ctxInc is set equal to 1.

[0319] Otherwise, ctxInc is set equal to 0.

[0320] 2.9. Coefficient Encoding and Decoding in Transform Skip Mode

[0321] In the current VVC draft, some modifications are proposed for coefficient coding in transform skip (TS) mode compared to non-TS coefficient coding to adapt the residual coding to the statistical and signaling characteristics of the transform skip level.

[0322] 7.3.10.11 Residual Codec Syntax

[0323]

[0324]

[0325]

[0326]

[0327]

[0328]

[0329]

[0330]

[0331]

[0332]

[0333]

[0334]

[0335] 2.9.1. Context Modeling and Context Index Offset Derivation for Sign Flag coeff_sign_flag

[0336] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0337]

[0338] Table 125 – initValue and shiftIdx specifications for ctxInc of coeff_sign_flag

[0339]

[0340] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0341]

[0342]

[0343] 9.3.4.2.10 Derivation of ctxInc for the syntax element coeff_sign_flag for transform skip mode

[0344] The inputs to this process are the color component index cIdx, the luma position (x0, y0) that specifies the top left sample of the current transform block relative to the top left sample of the current picture, and the current coefficient scan position (xC, yC).

[0345] The output of this process is the variable ctxInc.

[0346] The variables leftSign and aboveSign are derived as follows:

[0347] leftSign=(xC==0)? 0:CoeffSignLevel[xC-1][yC] (1595)

[0348] aboveSign=(yC==0)? 0:CoeffSignLevel[xC][yC-1] (1596)

[0349] The variable ctxInc is exported as follows:

[0350] – If leftSign equals 0 and aboveSign equals 0, or if leftSign equals -aboveSign, then the following applies:

[0351] ctxInc=(BdpcmFlag[x0][y0][cIdx]==0?0:3) (1597)

[0352] – Otherwise, if leftSign is greater than or equal to 0 and aboveSign is greater than or equal to 0, then the following applies:

[0353] ctxInc=(BdpcmFlag[x0][y0][cIdx]?1:4) (1598)

[0354] – Otherwise, the following applies:

[0355] ctxInc=(BdpcmFlag[x0][y0][cIdx]?2:5) (1599)

[0356] 3. Technical problems solved by the disclosed technical solutions and embodiments

[0357] The current design of the derivation process of AMVR precision index and split CU vertical flag context has the following issues:

[0358] 1. Syntax elements that specify that blocks are divided horizontally or vertically (e.g. ) depends on the relationship between "allowSplitBtVer+allowSplitBtHor" and "allowSplitTtVer+allowSplitTtHor". However, it is noted that the correlation between the split information and allowing BT / TT vertical is higher than that between allowing BT / TT horizontal.

[0359] 2. In the current VVC, AMVR precision index (e.g. ) uses one context for context encoding and decoding regardless of whether the block uses IBC mode, affine mode, or normal inter mode (non-IBC, non-affine). Encoding and decoding the AMVR precision index may be inefficient. In addition, for the second bin of amvr_precision_idx to be encoded for a block with normal inter mode, it uses a separate context from the context used for the first bin of amvr_precision_idx. When the encoding and decoding frequency of the syntax element is low, multiple contexts for encoding and decoding the syntax element may not be optimal.

[0360] 3. Although coefficient coding can achieve coding advantages over screen content coding, coefficient coding and TS mode may still have some defects.

[0361] a. For this case, it is unclear whether to use bypass codec or context codec for the symbol flag:

[0362] i. The number of remaining allowed context codec bins (denoted by RemCcbs) is equal to 0.

[0363] ii. The current block is encoded and decoded using TS mode.

[0364] iii.slice_ts_residual_coding_disabled_flag is false.

[0365] 4. Technical solutions and implementation examples

[0366] The following items should be considered as examples to explain the general concept. These items should not be interpreted narrowly. In addition, these items can be combined in any way.

[0367] In this disclosure, the term AMVR refers to a codec tool for adaptive motion vector difference accuracy for motion vector (MV) / MV difference (MVD) codec or MV predictor (MVP). It is not limited to the AMVR and block partitioning techniques described in VVC.

[0368] The term amvr_precision_idx refers to a syntax element that specifies an index (or indicator) of the allowable motion vector difference precision. In one example, it may be amvr_precision_idx defined in the VVC profile. Note that amvr_precision_idx may be binarized into a binary bit string that may contain one or more binary bits.

[0369] The term mtt_split_cu_vertical_flag refers to a syntax element that specifies whether a codec block is split vertically. In one example, it may be mtt_split_cu_vertical_flag defined in the VVC profile. amvr_ Contextual export of precision_idx

[0370] 1. The context modeling (e.g., how to select the context) of the first (where the bin index is equal to 0) and / or other bins of the binary bit string of the syntax element (SE) used to indicate the use of AMVR (e.g., amvr_precision_idx and / or amvr_flag) may depend on the codec information (e.g., codec mode) of the current block and / or neighboring blocks.

[0371] a. In one example, the codec information may include at least one of: IBC, affine AMVR and normal inter-frame (e.g., non-IBC, non-affine) modes, bidirectional prediction and / or unidirectional prediction, block dimensions of the current block and / or block dimensions of the neighboring blocks, and different contexts may be used to encode and decode a binary bit (e.g., a first binary bit) according to the codec information.

[0372] i. Alternatively, or in addition, one binary bit (eg, the first binary bit) of the SE of the IBC codec block is encoded and decoded with a single context represented by CtxM.

[0373] ii. Alternatively, or in addition, one bin (eg, the first bin) of the SE of the affine coded block is encoded and decoded with a single context represented by CtxN.

[0374] iii. Alternatively, or in addition, one bin (eg, the first bin) of the SE of a normal inter (eg, non-affine and non-IBC) coded block is coded with a single context represented by CtxP.

[0375] iv. Alternatively, in addition, at least one of the three contexts CtxM, CtxN and CtxP is different from the other two.

[0376] v. Alternatively, in addition, each of the three contexts CtxM, CtxN and CtxP is different from the other contexts.

[0377] vi. For example, for a bidirectionally predicted block, one binary bit (e.g., the first binary bit) of SE is encoded and decoded using a single context represented by CtxBi, while for a uni-predicted coded block, one binary bit (e.g., the first binary bit) of SE is encoded and decoded using a single context represented by CtxUni.

[0378] 1) In one example, CtxBi is different from CtxUni.

[0379] b. In one example, more than one context may be used to encode and decode the first bin and / or other bins of the bin string of the SE.

[0380] i. In one example, X contexts are available for the first bin, where X>1.

[0381] 1) In one example, X=3.

[0382] a) Alternatively, or in addition, the context selection depends on codec information (eg, the mode described above).

[0383] 2) In one example, X=2.

[0384] a) Alternatively, or in addition, the context selection depends on codec information (eg, the above-mentioned mode), and one context is used for IBC-coded blocks and another one for other blocks (eg, affine or normal inter-coded).

[0385] b) Alternatively, or in addition, the context selection depends on the codec information (eg the mode described above), and one context is used for IBC and affine AMVR coded blocks and another one for other blocks (eg coded with normal inter).

[0386] c. In one example, different models of the first (where the bin index is equal to 0) and / or other bins of the bin string of the SE depending on the codec information (eg, codec mode) may be initialized with different initialization values.

[0387] d. In one example, different models of the first (where the bin index is equal to 0) and / or other bins of the bin string of the SE depending on the codec information (eg, codec mode) may be initialized with the same initialization value.

[0388] 2. Instead of using different contexts for the first and second bins of the bin string of amvr_precision_idx, it is proposed that the context used to encode the second bin may be the same as one or more contexts used to encode the first bin of the bin string.

[0389] a. Alternatively, the second bin of the bin string is coded only for normal inter (eg, non-affine and non-IBC) coded blocks.

[0390] b. Alternatively, the second bin of the bin string is encoded or decoded using a single context represented by CtxQ.

[0391] c. Alternatively, or in addition, the same context can be used for IBC codec blocks The first binary bit of the normal inter-frame codec block The second binary bit is encoded and decoded.

[0392] d. Alternatively, or in addition, the same context can be used for affine codec blocks The first binary bit of the normal inter-frame codec block The second binary bit is encoded and decoded.

[0393] e. Alternatively, or in addition, the same context can be used for normal inter-frame coded blocks The first binary bit of the normal inter-frame codec block The second binary bit is encoded and decoded.

[0394] 3. The same context can be used for the IBC codec block (represented by CtxM) The first binary bit and the normal inter-frame codec block (represented by CtxQ) The second binary bit is encoded and decoded, for example, CtxM=CtxQ.

[0395] a. In one example, X1 (e.g., X1=3) context can be used for encoding and decoding

[0396] b. Alternatively, or in addition, a different context for encoding and decoding the first bin of the bin string of amvr_precision_idx of a non-IBC codec block may be utilized.

[0397] 4. The same context can be used for IBC codec blocks The first binary bit of the affine codec block The first binary bit of the normal inter-frame codec block The first binary bit is encoded and decoded, for example, CtxM=CtxN=CtxP.

[0398] a. In one example, X2 (eg, X2=2) context can be used for encoding and decoding

[0399] b. Alternatively, or in addition, different contexts for encoding and decoding the first bin of the bin string of amvr_precision_idx for non-IBC and non-affine codec blocks may be utilized.

[0400] 5. The same context can be used for IBC codec blocks The first binary bit of the normal inter-frame codec block The first binary bit is encoded and decoded, for example, CtxM=CtxP.

[0401] a. In one example, X3 (eg, X3=3) context can be used for encoding and decoding

[0402] b. Alternatively, or in addition, a different context for encoding and decoding the first bin of the amvr_precision_idx bin string for non-IBC and non-normal inter-coded blocks (eg, coded with affine AMVR) may be utilized.

[0403] c. Alternatively, or in addition, a different context for encoding and decoding the second bin of the bin string of amvr_precision_idx may be utilized.

[0404] 6. The same context can be used for IBC codec blocks The first binary bit and the affine codec block The first binary bit is encoded and decoded, for example, CtxM=CtxN.

[0405] 7. The same context can be used for IBC codec blocks, affine codec blocks and normal inter-frame codec blocks All binary bits are encoded and decoded.

[0406] a. In one example, a single context can be used for encoding and decoding

[0407] 8. Multiple contexts can be used for IBC codec blocks, affine codec blocks and normal inter-frame codec blocks A first bin is encoded and decoded, and a single context is available for encoding and decoding the second bin, which is different from those used to encode and decode the first bin.

[0408] a. In one example, X4 (eg, X4=4) context can be used for encoding and decoding

[0409]

[0410] b. For example, CtxM!=CtxQ!=CtxN!=CtxP.

[0411] 9. It is recommended that at least one context used for encoding and decoding amvr_precision_idx may be the same as the context used for encoding and decoding amvr_flag.

[0412] a. AMVR flag for affine codec blocks (e.g. ) can be used for the IBC codec block The first binary bit of, or / and the affine codec block The first binary bit of, or / and the first binary bit of the normal inter-frame codec block The first binary digit and / or the second binary digit of

[0413] b. AMVR flag for non-affine codec blocks (e.g. ) can be used for the IBC codec block The first binary bit of, or / and the affine codec block The first binary bit of, or / and the first binary bit of the normal inter-frame codec block The first binary digit and / or the second binary digit of

[0414] c. The context modeling of the first binary bit of depends on whether an affine mode is applied to the block.

[0415] i. Alternatively, or in addition, one context is used to encode the first bin of an affine codec block, and another context is used for non-affine codec blocks (eg, including normal inter and IBC codec blocks).

[0416] ii. Alternatively, in addition, the first context is used to encode and decode the first binary bit of the affine codec block, and the second context is used for non-affine codec blocks (e.g., including normal inter-frame and IBC codec blocks). The first context is the same as the context of amvr_flag used to encode and decode the affine codec block; and the second context is the same as the context of amvr_flag used to encode and decode the non-affine codec block.

[0417] Context export of mtt_split_cu_vertical_flag

[0418] Assume that variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, and allowSplitTtHor represent whether the current codec tree node allows vertical BT splitting, horizontal BT splitting, vertical TT splitting, and horizontal TT splitting, respectively. And the values ​​of allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, and allowSplitTtHor can be equal to 0 or 1, which is derived in Section 2.6. Use curW, curH, leftW, leftH, aboveW, and aboveH to represent the width of the current block, the height of the current block, the width of the left adjacent block, the height of the left adjacent block, the width of the upper adjacent block, and the height of the upper adjacent block, respectively. Assume that "numV" is a value equal to the sum of allowSplitBtVer and allowSplitTtVer, and "numH" is a value equal to the sum of allowSplitBtHor and allowSplitTtHor.

[0419] 10. Indicates block partition information (e.g. )'s context modeling may depend on the number of allowed vertical partitions (eg, for BT and TT) and allowed horizontal partitions (eg, for BT and TT).

[0420] a. In one example, if there are more cases where vertical partitions are allowed than horizontal partitions (eg, numV>numH), the first set of contexts is used.

[0421] b. In one example, if there are fewer cases allowing vertical partitioning compared to horizontal partitioning (e.g., numV < numH), the second set of contexts is used.

[0422] c. In one example, if there are the same number of cases allowing vertical partitioning compared to horizontal partitioning (e.g., numV = numH), the third set of contexts is used.

[0423] d. Alternatively, in addition, none of the contexts in the first / second / third set are the same.

[0424] e. Alternatively, further, at least one context in the first / second / third set is the same as the context included in another set.

[0425] f. Alternatively, in addition, the number of contexts for each of the three sets can depend on the set index.

[0426] i. In one example, only one context is included in the first and / or second set.

[0427] ii. In one example, multiple contexts are included in the third set.

[0428] 1) Alternatively, in addition, selecting a context from the third set can further depend on the availability of the upper and left adjacent blocks, and / or the block dimensions of the current block and the adjacent blocks.

[0429] g. Examples are given in Embodiment #4 of Section 5.4.

[0430] h. Examples are given in Embodiment #5 of Section 5.5.

[0431] 11. The SE indicating whether to vertically partition a block (e.g., ) is encoded and decoded with N contexts, which may depend on whether BT / TT partitioning is allowed, and / or the width / height of the current block, and / or the width / height of the adjacent blocks.

[0432] i. In one example, which context is used to encode and decode the SE may depend on numV and numH.

[0433] i. For example, it depends on whether numV is greater than numH.

[0434] ii. For example, it depends on whether numV is less than numH.

[0435] iii. For example, it depends on whether numV is equal to numH.

[0436] j. In one example, the binary bit string of SE can be context-coded and decoded using N contexts depending on whether BT / TT partitioning is allowed.

[0437] i. In one example, when numV is greater than numH, the SE is encoded and decoded using the context represented by CtxA.

[0438] ii. In one example, when numV is less than numH, SE is encoded and decoded using the context represented by CtxB.

[0439] iii. In one example, when numV is equal to numH, SE is encoded and decoded using the context represented by CtxC.

[0440] iv. In one example, CtxA is equal to CtxB, and CtxB is equal to CtxC (eg, CtxA=CtxB=CtxC), eg, CtxA=CtxB=CtxC=0.

[0441] v. In one example, CtxA!=CtxB!=CtxC, for example, CtxA=0, CtxB=1, CtxC=2.

[0442] k. In one example, the binary bit string of SE can be context-encoded and decoded using N contexts according to the width / height of the current block, or / and the width / height of the adjacent block.

[0443] i. In one example, the neighboring block may refer to an upper neighboring block, or / and a left neighboring block.

[0444] ii. In one example, SE is encoded and decoded with N contexts, which may depend on the width or height of the current block and / or the function of the width or height of the neighboring blocks. Denote dA=curW / aboveW and dL=curH / leftH.

[0445] 1) In one example, when the left neighboring block or the top neighboring block is not available or dA is equal to dL, SE is encoded and decoded using the context represented by CtxD.

[0446] 2) In one example, when dA is less than dL, SE is encoded and decoded using the context represented by CtxE.

[0447] 3) In one example, when dA is greater than dL, SE is encoded and decoded using the context represented by CtxF.

[0448] 1. In one example, depending on whether BT / TT partitioning is allowed, or / and the width / height of the current block, or / and the width / height of the adjacent block, the binary bit string of SE can be context encoded and decoded with N contexts.

[0449] i. In one example, when numV is greater than numH, the SE is encoded and decoded using the context represented by CtxA.

[0450] ii. In one example, when numV is less than numH, SE is encoded and decoded using the context represented by CtxB.

[0451] iii. In one example, when numV is equal to numH and (the left neighboring block or the upper neighboring block is not available, or dA is equal to dL), SE is encoded and decoded using the context represented by CtxC.

[0452] iv. In one example, when numV is equal to numH and dA is less than dL, SE is encoded and decoded using the context represented by CtxE.

[0453] v. In one example, when numV is equal to numH and dA is greater than dL, SE is encoded and decoded using the context represented by CtxF.

[0454] In one example, N=5, CtxA!=CtxB!=CtxC!=CtxE!=CtxF.

[0455] m. In one example, the binary bit string of SE can be context-encoded and decoded using N contexts depending on whether the current block is at a picture boundary.

[0456] n. In one example, the binary bit string of SE can be context-coded and decoded using N contexts depending on whether dual tree and / or partial dual tree is applied.

[0457] o. In one example, the binary bit string of SE can be context-encoded and decoded using N contexts according to the color component(s) of the sample to be segmented.

[0458] p. In one example, the binary bit string of SE can be context-encoded and decoded using N contexts according to the width / height of the current block.

[0459] i. In one example, the context increase can be set as a function of the block width or height.

[0460] 12. Split CU vertical flags (e.g. ) can be encoded and decoded with a single context.

[0461] How to use bypass coding or context coding for coefficient sign flags

[0462] 13. For symbols at the transform coefficient level (e.g., syntax elements ) Whether context coding or bypass coding is used depends on the number of remaining allowed context coding bits (e.g., RemCcbs) and / or the type of transform used for the current block (e.g., DCT2, DST7, or transform skip).

[0463] a. In one example, in the process of transform skipping residual coding, when RemCcbs is greater than T1 (e.g., T1=0), context coding can be used for

[0464] i. In addition, in the process of transform skipping residual codec, when RemCcbs is equal to T1 (for example, T1 = 0), bypass codec can be used for

[0465] b. In one example, in the process of transform skipping residual coding, when RemCcbs is greater than or equal to T2 (for example, T2=3), context coding can be used for

[0466] i. In addition, in the process of transform skipping residual codec, when RemCcbs is less than T2 (such as T2 = 3), bypass codec can be used for

[0467] 14. At the start of bypass decoding of the remaining syntax elements (e.g., syntax elements abs_remainder and coeff_sign_flag) in the third / remaining coefficient scan pass of the transform skip residual coding process, an operation may be applied to a variable specifying the number of remaining allowed context coding bins (e.g., RemCcbs).

[0468] c. In one example, the operation may set RemCcbs equal to a certain value (eg, 0).

[0469] d. In one example, the operation may set RemCcbs equal to a value that depends on at least one variable or syntax element other than RemCcbs.

[0470] i. In one example, this operation may set RemCcbs equal to RemCcbs minus one.

[0471] 15. An example is given in Example #7 in Section 5.7.

[0472] 16. An example is given in Example #8 in Section 5.8.

[0473] 17. Transform coefficient levels (e.g. ) Whether to encode and decode using bypass mode or context coding mode may depend on the number of remaining allowed context coding bins (e.g., RemCcbs).

[0474] e. It is recommended to use bypass mode for the sign of the transform coefficient level (e.g. ) for encoding and decoding.

[0475] f. In one example, when RemCcbs<=N, the bypass mode is used to encode and decode the symbol flag.

[0476] i. Alternatively, in one example, when RemCcbs>N, the symbol flag is encoded and decoded using the context mode.

[0477] g. In one example, when RemCcbs is equal to N, the symbol flag is encoded and decoded using bypass mode.

[0478] i. Alternatively, in one example, when RemCcbs>N, the symbol flags are encoded and decoded using bypass mode.

[0479] ii. In one example, N may be set equal to 4.

[0480] 1) Alternatively, in one example, N can be set equal to 0.

[0481] iii. In one example, RemCcbs may be modified to X before decoding the residual absolute value of the transform coefficient level, where X is equal to N.

[0482] h. In one example, when RemCcbs is less than N, the symbol flag is encoded and decoded using bypass mode.

[0483] i. Alternatively, in one example, when RemCcbs>=N, the symbol flag is encoded and decoded using the context mode.

[0484] ii. In one example, N may be set equal to 3.

[0485] iii. In one example, RemCcbs may be modified to X before decoding the residual absolute values ​​of the transform coefficient levels, where X is less than N.

[0486] i. In one example, N is an integer and may be based on,

[0487] i. Indication of signaling notification in SPS / VPS / PPS / picture header / slice header / slice group header / LCU row / LCU group / LCU / CU

[0488] ii. Block dimensions of the current block and / or its neighboring blocks

[0489] iii. Block shape of the current block and / or its neighboring blocks

[0490] iv. Indication of color format (e.g. 4:2:0, 4:4:4)

[0491] v. Whether to use a separate codec tree structure or a dual codec tree structure

[0492] vi. Strip type and / or picture type

[0493] vii. Number of color components

[0494] j. Codec context for encoding and decoding transform coefficient levels (e.g., ) may depend on the number of remaining allowed context codec bins (e.g., RemCcbs).

[0495] k. The above examples may be applied to transform blocks and / or transform skip blocks including or not including BDPCM codec blocks.

[0496] Overview

[0497] 18. Whether to apply the method disclosed above and / or how to apply the method disclosed above can be signaled at the sequence level / picture level / slice level / slice group level, for example in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / slice group header.

[0498] 19. Whether to apply the above disclosed method and / or how to apply the above disclosed method may depend on codec information, such as color format, single / double tree partitioning.

[0499] 5. Examples

[0500] The following are some example embodiments of some aspects of the invention summarized in Section 4 above, which may be applied to the VVC specification. Most of the relevant parts that have been added or modified are referred to in The text is underlined and some deleted parts are indicated by [[ ]].

[0501] 5.1. Example 1

[0502] 9.3.2.2 Context variable initialization process

[0503] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0504]

[0505] Table 89 – initValue and shiftIdx specifications for ctxIdx of amvr_precision_idx

[0506]

[0507] 9.3.4.2 Export process of ctxTable, ctxIdx and bypassFlag

[0508] 9.3.4.2.1 Overview

[0509] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0510]

[0511]

[0512] Alternatively, the following applies:

[0513]

[0514] In the above example, X!=Y, X!=Z, Y!=Z.

[0515] Alternatively, or in addition, the following apply:

[0516] 1) In one example, W is equal to X.

[0517] 2) Or, W equals Y.

[0518] 3) Or, W equals Z.

[0519] 5.2. Example 2

[0520] 9.3.2.2 Context variable initialization process

[0521] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0522]

[0523] Table 89 – initValue and shiftIdx specifications for ctxIdx of amvr_precision_idx

[0524]

[0525] 9.3.4.2 Export process of ctxTable, ctxIdx and bypassFlag

[0526] 9.3.4.2.1 Overview

[0527] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0528]

[0529]

[0530] 5.3. Example 3

[0531] 9.3.2.2 Context variable initialization process

[0532] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0533]

[0534] Table 89 – initValue and shiftIdx specifications for ctxIdx of amvr_precision_idx

[0535]

[0536] 9.3.4.2 Export process of ctxTable, ctxIdx and bypassFlag

[0537] 9.3.4.2.1 Overview

[0538] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0539]

[0540] 5.4. Example 4

[0541] The working draft can be changed as follows.

[0542] 9.3.4.2.3 Derivation of ctxInc for the syntax element mtt_split_cu_vertical_flag

[0543] The inputs to this process are the luma position (x0, y0) which specifies the top left luma sample of the current luma block relative to the top left sample of the current picture, the dual-tree channel type chType, the width and height cbWidth and cbHeight of the current codec block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the codec tree semantics in clause 7.4.11.4.

[0544] The output of this process is ctxInc.

[0545] The position (xNbL, yNbL) is set equal to (x0-1, y0) and the derivation procedure for neighbor block availability specified in clause 6.4.4 is called with the position (xCurr, yCurr) set equal to (x0, y0) and the neighbor position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set equal to FALSE, and cIdx as input, and the output assigned to availableL.

[0546] Set position (xNbA, yNbA) equal to (x0, y0-1), invoke the derivation procedure for neighbor block availability specified in Clause 6.4.4 with position (xCurr, yCurr) set equal to (x0, y0), neighbor position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set equal to FALSE, and cIdx as input, and assign the output to availableA.

[0547] The allocation rules for ctxInc are as follows:

[0548] –if allowSplitBtVer+[[allowSplitBtHor]] Greater than [[allowSplitTtVer]] Then ctxInc is set equal to 4.

[0549] – Otherwise, if allowSplitBtVer+[[allowSplitBtHor]] Less than [[allowSplitTtVer]] Then ctxInc is set equal to [[4]]

[0550] – Otherwise, the following applies:

[0551] – The variables dA and dL are derived as follows

[0552] dA=cbWidth / (availableA?CbWidth[chType][xNbA][yNbA]:1) (1563)

[0553] dL=cbHeight / (availableL?CbHeight[chType][xNbL][yNbL]:1) (1564)

[0554] – ctxInc is set equal to 0 if any of the following conditions is true:

[0555] –dA is equal to dL,

[0556] –availableA is equal to FALSE,

[0557] –availableL is equal to FALSE.

[0558] – Otherwise, if dA is less than dL, ctxInc is set equal to 1.

[0559] – Otherwise, set ctxInc equal to [[0]]

[0560] 5.5. Example 5

[0561] The working draft can be changed as follows.

[0562] 9.3.4.2.3 Derivation of ctxInc for the syntax element mtt_split_cu_vertical_flag

[0563] The inputs to this process are the luma position (x0, y0) which specifies the top left luma sample of the current luma block relative to the top left sample of the current picture, the dual-tree channel type chType, the width and height cbWidth and cbHeight of the current codec block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the codec tree semantics in clause 7.4.11.4.

[0564] The output of this process is ctxInc.

[0565] The position (xNbL, yNbL) is set equal to (x0-1, y0) and the derivation procedure for neighbor block availability specified in clause 6.4.4 is called with the position (xCurr, yCurr) set equal to (x0, y0) and the neighbor position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set equal to FALSE, and cIdx as input, and the output assigned to availableL.

[0566] Set position (xNbA, yNbA) equal to (x0, y0-1), invoke the derivation procedure for neighbor block availability specified in Clause 6.4.4 with position (xCurr, yCurr) set equal to (x0, y0), neighbor position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set equal to FALSE, and cIdx as input, and assign the output to availableA.

[0567] The allocation rules for ctxInc are as follows:

[0568] –if allowSplitBtVer+[[allowSplitBtHor]] Greater than [[allowSplitTtVer]] Then ctxInc is set equal to [[4]]

[0569] – Otherwise, if allowSplitBtVer+[[allowSplitBtHor]] Less than [[allowSplitTtVer]] Then ctxInc is set equal to [[4]]

[0570] – Otherwise, the following applies:

[0571] – The variables dA and dL are derived as follows

[0572] dA=cbWidth / (availableA?CbWidth[chType][xNbA][yNbA]:1) (1563)

[0573] dL=cbHeight / (availableL?CbHeight[chType][xNbL][yNbL]:1) (1564)

[0574] – If any of the following conditions is true, ctxInc is set equal to [[0]]

[0575] –dA is equal to dL,

[0576] –availableA is equal to FALSE,

[0577] –availableL is equal to FALSE.

[0578] – Otherwise, if dA is less than dL, set ctxInc equal to [[1]]

[0579] – Otherwise, set ctxInc equal to [[0]]

[0580]

[0581] 5.6. Example 6

[0582] The working draft can be changed as follows.

[0583] 9.3.2.2 Context variable initialization process

[0584] Table 51 - Association between ctxIdx and syntax elements for each initialization type during initialization

[0585]

[0586] Table 61 – initValue and shiftIdx specifications for ctxInc of mtt_split_cu_vertical_flag

[0587]

[0588] 9.3.4.2 Export process of ctxTable, ctxIdx and bypassFlag

[0589] 9.3.4.2.1 Overview

[0590] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0591]

[0592] [[9.3.4.2.3 Derivation of ctxInc of the syntax element mtt_split_cu_vertical_flag

[0593] The inputs to this process are the luma position (x0, y0) which specifies the top left luma sample of the current luma block relative to the top left sample of the current picture, the dual-tree channel type chType, the width and height cbWidth and cbHeight of the current codec block in luma samples, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt derived in the codec tree semantics in clause 7.4.11.4.

[0594] The output of this process is ctxInc.

[0595] The position (xNbL, yNbL) is set equal to (x0-1, y0) and the derivation procedure for neighbor block availability specified in clause 6.4.4 is called with the position (xCurr, yCurr) set equal to (x0, y0) and the neighbor position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set equal to FALSE, and cIdx as input, and the output assigned to availableL.

[0596] Set position (xNbA, yNbA) equal to (x0, y0-1), invoke the derivation procedure for neighbor block availability specified in Clause 6.4.4 with position (xCurr, yCurr) set equal to (x0, y0), neighbor position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set equal to FALSE, and cIdx as input, and assign the output to availableA.

[0597] The allocation rules for ctxInc are as follows:

[0598] – If allowSplitBtVer+allowSplitBtHor is greater than allowSplitTtVer+allowSplitTtHor, then ctxInc is set equal to 4.

[0599] – Otherwise, if allowSplitBtVer+allowSplitBtHor is less than allowSplitTtVer+allowSplitTtHor, then ctxInc is set equal to 4.

[0600] – Otherwise, the following applies:

[0601] – The variables dA and dL are derived as follows

[0602] dA=cbWidth / (availableA?CbWidth[chType][xNbA][yNbA]:1) (1563)

[0603] dL=cbHeight / (availableL?CbHeight[chType][xNbL][yNbL]:1) (1564)

[0604] – ctxInc is set equal to 0 if any of the following conditions is true:

[0605] –dA is equal to dL,

[0606] –availableA is equal to FALSE,

[0607] –availableL is equal to FALSE.

[0608] – Otherwise, if dA is less than dL, ctxInc is set equal to 1.

[0609] Otherwise, set ctxInc equal to 0. ]]

[0610] 5.7. Example 7

[0611] The working draft can be changed as follows.

[0612] 7.3.10.11 Residual Codec Syntax

[0613]

[0614]

[0615]

[0616]

[0617]

[0618] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0619]

[0620] 5.8. Example 8

[0621] The working draft can be changed as follows. 7.3.10.11 Residual Codec Syntax

[0622]

[0623]

[0624]

[0625]

[0626] Table 131 – Assignment of ctxInc to syntax elements with context codec bins

[0627]

[0628]

[0629] Fig.121 is a block diagram of an example video processing system 1200 that may implement various techniques disclosed herein. Various implementations may include some or all of the components in system 1200. System 1200 may include an input 1202 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 encoded format. Input 1202 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 networks (PONs), etc.) and wireless interfaces (such as Wi-Fi or cellular interfaces).

[0630] System 1200 may include a codec component 1204 that can implement various codecs or encoding methods described in this document. Codec component 1204 can reduce the average bit rate of the video from input 1202 to the output of codec component 1204 to generate a codec representation of the video. Therefore, codec technology is sometimes referred to as video compression or video transcoding technology. The output of codec component 1204 can be stored or sent via the connected communication, as represented by component 1206. The bitstream (or codec) representation of the storage or communication of the video received at input 1202 can be used by component 1208 to generate pixel values ​​or displayable video sent to display interface 1210. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it should be understood that codec tools or operations are used at the encoder, and corresponding decoding tools or operations of the results of the inverse codec will be performed by the decoder.

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

[0632] Fig.133600. The apparatus 3600 may be used to implement one or more of the methods described herein. The apparatus 3600 may be implemented in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The apparatus 3600 may include one or more processors 3602, one or more memories 3604, and video processing hardware 3606. The processor(s) 3602 may be configured to implement one or more of the methods described in this document. The memory(s) 3604 may be used to store data and code that is used to implement the methods and techniques described herein. The video processing hardware 3606 may be used to implement some of the techniques described in this document in hardware circuits.

[0633] Fig.15 is a block diagram illustrating an example video coding system 100 that may utilize the techniques of this disclosure.

[0634] like Fig.15 As shown, the video codec system 100 may include a source device 110 and a destination device 120. The source device 110 generates encoded video data, which may be referred to as a video encoding device. The destination device 120 may decode the encoded video data generated by the source device 110, which may be referred to as a video decoding device.

[0635] Source device 110 may include a video source 112 , a video encoder 114 , and an input / output (I / O) interface 116 .

[0636] The video source 112 may include a source such as a video capture device, an interface for receiving video data from a video content provider, and / or a computer graphics system that generates video data, or a combination of these sources. The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bit stream. The bit stream may include a sequence of bits that form a codec representation of the video data. The bit stream may include a codec picture and associated data. The codec picture is a codec representation of the picture. The associated data may include a sequence parameter set, a picture parameter set, and other syntax elements. The I / O interface 116 includes a modulator / demodulator (modem) and / or a transmitter. The encoded video data may be directly sent to the destination device 120 via the I / O interface 116 through the network 130a. The encoded video data may also be stored on a storage medium / server 130b for access by the destination device 120.

[0637] Destination device 120 may include an I / O interface 126 , a video decoder 124 , and a display device 122 .

[0638] The I / O interface 126 may include a receiver and / or a modem. The I / O interface 126 may obtain the encoded video data from the source device 110 or the storage medium / server 130b. The video decoder 124 may decode the encoded video data. The display device 122 may display the decoded video data to a user. The display device 122 may be integrated with the destination device 120, or may be external to the destination device 120 configured to interface with an external display device.

[0639] The video encoder 114 and the video decoder 124 may operate according to a video compression standard, such as the High Efficiency Video Codec (HEVC) standard, the Versatile Video Codec (VVC) standard, and other current and / or other standards.

[0640] Fig.16 is a block diagram showing an example of a video encoder 200, which may be Fig.15 The video encoder 114 in the system 100 is shown in FIG.

[0641] Video encoder 200 may be configured to perform any or all of the techniques of this disclosure. Fig.16 In the example of , video encoder 200 includes multiple functional components. The techniques described in this disclosure can be shared between various components of video encoder 200. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0642] The functional components of the video encoder 200 may include a segmentation unit 201, a prediction unit 202 (which may include a mode selection unit 203, a motion estimation unit 204, a motion compensation unit 205 and an intra-frame prediction unit 206), a residual generation unit 207, a transform unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transform unit 211, a reconstruction unit 212, a buffer 213 and an entropy coding unit 214.

[0643] In other examples, the video encoder 200 may include more, fewer, or different functional components. In one example, the prediction unit 202 may include an intra-block copy (IBC) unit. The IBC unit may perform prediction in an IBC mode, where at least one reference picture is a picture where the current video block is located.

[0644] Furthermore, some components such as the motion estimation unit 204 and the motion compensation unit 205 may be highly integrated, but are not shown for the purpose of explanation. Fig.16 In the example, they are shown separately.

[0645] The partitioning unit 201 may partition a picture into one or more video blocks. The video encoder 200 and the video decoder 300 may support various video block sizes.

[0646] The mode selection unit 203 may select one of the intra or inter codec modes, for example, based on the error result, and provide the resulting intra or inter codec block to the residual generation unit 207 to generate residual block data and to the reconstruction unit 212 to reconstruct the codec block for use as a reference picture. In some examples, the mode selection unit 203 may select a combination of intra and inter prediction (CIIP) mode, where the prediction is based on an inter prediction signal and an intra prediction signal. The mode selection unit 203 may also select the precision of the motion vector (e.g., sub-pixel or integer pixel precision) for the block in the case of inter prediction.

[0647] To perform inter-frame prediction on the current video block, the motion estimation unit 204 may generate motion information of the current video block by comparing the current video block with one or more reference frames from the buffer 213. The motion compensation unit 205 may determine a predicted video block for the current video block based on the motion information and decoded samples of a picture from the buffer 213 (rather than a picture associated with the current video block).

[0648] Motion estimation unit 204 and motion compensation unit 205 may perform different operations for the current video block, for example, performing different operations depending on whether the current video block is in an I slice, a P slice, or a B slice.

[0649] In some examples, the motion estimation unit 204 may perform unidirectional prediction of the current video block, and the motion estimation unit 204 may search for a reference video block of the current video block in the reference picture of list 0 or list 1. The motion estimation unit 204 may then generate a reference index indicating a reference video block in the reference picture of list 0 or list 1 and a motion vector indicating a spatial displacement between the current video block and the reference video block. The motion estimation unit 204 may output the reference index, the prediction direction indicator, and the motion vector as motion information of the current video block. The motion compensation unit 205 may generate a predicted video block of the current block based on the reference video block indicated by the motion information of the current video block.

[0650] In other examples, the motion estimation unit 204 may perform bidirectional prediction of the current video block, and the motion estimation unit 204 may search for a reference video block of the current video block in the reference picture of list 0 and may also search for another reference video block of the current video block in the reference picture of list 1. The motion estimation unit 204 may then generate a reference index indicating a reference video block in the reference picture of list 0 or list 1 and a motion vector indicating a spatial displacement between the reference video block and the current video block. The motion estimation unit 204 may output the reference index and the motion vector of the current video block as motion information of the current video block. The motion compensation unit 205 may generate a predicted video block of the current video block based on the reference video block indicated by the motion information of the current video block.

[0651] In some examples, motion estimation unit 204 may output the entire set of motion information for use in a decoding process by a decoder.

[0652] In some examples, motion estimation unit 204 may not output a full set of motion information for the current video. Instead, motion estimation unit 204 may signal the motion information of the current video block with reference to the motion information of another video block. For example, motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of the neighboring video block.

[0653] In one example, motion estimation unit 204 may indicate in a syntax structure associated with the current video block a value that indicates to video decoder 300 that the current video block has the same motion information as another video block.

[0654] In another example, the motion estimation unit 204 may identify another video block and a motion vector difference (MVD) in a syntax structure associated with the current video block. The motion vector difference indicates the difference between the motion vector of the current video block and the motion vector of the indicated video block. The video decoder 300 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0655] As discussed above, the video encoder 200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by the video encoder 200 include advanced motion vector prediction (AMVP) and merge mode signaling.

[0656] The intra prediction unit 206 may perform intra prediction on the current video block. When the intra prediction unit 206 performs intra prediction on the current video block, the intra prediction unit 206 may generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block may include a predicted video block and various syntax elements.

[0657] The residual generation unit 207 can generate residual data for the current video block by subtracting (e.g., indicated by a minus sign) the predicted video block(s) of the current video block from the current video block. The residual data for the current video block may include residual video blocks corresponding to different sample components of samples in the current video block.

[0658] In other examples, such as in skip mode, there may be no residual data for the current video block, and the residual generation unit 207 may not perform a subtraction operation.

[0659] Transform processing unit 208 may generate one or more transform coefficient video blocks for the current video block by applying one or more transforms to the residual video block associated with the current video block.

[0660] After transform processing unit 208 generates a transform coefficient video block associated with the current video block, quantization unit 209 may quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values ​​associated with the current video block.

[0661] The inverse quantization unit 210 and the inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient video block to reconstruct the residual video block from the transform coefficient video block. The reconstruction unit 212 may add the reconstructed residual video block to the corresponding samples from one or more prediction video blocks generated by the prediction unit 202 to generate a reconstructed video block associated with the current block for storage in the buffer 213.

[0662] After the reconstruction unit 212 reconstructs the video block, a loop filtering operation may be performed to reduce video blocking artifacts in the video block.

[0663] The entropy coding unit 214 may receive data from other functional components of the video encoder 200. When the entropy coding unit 214 receives data, the entropy coding unit 214 may perform one or more entropy coding operations to generate entropy-coded data and output a bitstream including the entropy-coded data.

[0664] Fig.17 is a block diagram showing an example of a video decoder 300, which may be Fig.15 The video decoder 114 in the system 100 is shown in FIG.

[0665] Video decoder 300 may be configured to perform any or all of the techniques of this disclosure. Fig.17 In the example of , video decoder 300 includes multiple functional components. The techniques described in this disclosure can be shared between various components of video decoder 300. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0666] exist Fig.17 In the example of , the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306 and a buffer 307. In some examples, the video decoder 300 can be performed with respect to the video encoder 200 ( Fig.16 ) is a decoding process that is the overall inverse of the encoding process described.

[0667] The entropy decoding unit 301 may retrieve a coded bitstream. The coded bitstream may include entropy coded video data (e.g., a coded block of video data). The entropy decoding unit 301 may decode the entropy coded video, and based on the entropy decoded video data, the motion compensation unit 302 may determine motion information including motion vectors, motion vector precision, reference picture list index, and other motion information. The motion compensation unit 302 may determine such information, for example, by performing AMVP and merge modes.

[0668] The motion compensation unit 302 may generate a motion compensated block, possibly interpolated based on an interpolation filter. An identifier of the interpolation filter to be used with sub-pixel precision may be included in the syntax element.

[0669] The motion compensation unit 302 may calculate interpolated values ​​of a sub-integer number of pixels of the reference block using an interpolation filter used by the video encoder 200 during encoding of the video block. The motion compensation unit 302 may determine the interpolation filter used by the video encoder 200 based on received syntax information and use the interpolation filter to generate a prediction block.

[0670] The motion compensation unit 302 can use some syntax information to determine: the size of the blocks used to encode (multiple) frames and / or (multiple) slices of the coded video sequence, the partitioning information describing how each macroblock of the pictures of the coded video sequence is partitioned, the mode indicating how to encode each partition, one or more reference frames (and reference frame lists) for each inter-frame codec block, and other information for decoding the coded video sequence.

[0671] The intra prediction unit 303 may form a prediction block from spatially neighboring blocks using, for example, an intra prediction mode received in the bitstream. The inverse quantization unit 303 inversely quantizes (e.g., dequantizes) quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 301. The inverse transform unit 303 applies an inverse transform.

[0672] The reconstruction unit 306 may sum the residual block with the corresponding prediction block generated by the motion compensation unit 202 or the intra prediction unit 303 to form a decoded block. As desired, a deblocking filter may also be applied to filter the decoded block to remove blocking artifacts. The decoded video block is then stored in a buffer 307, which provides reference blocks for subsequent motion compensation / intra prediction and also produces decoded video for presentation on a display device.

[0673] A list of some preferred solutions for some embodiments is provided next.

[0674] The following solution shows an example implementation of the technique discussed in the previous section (eg, item 1).

[0675] 1. A video processing method (eg, Fig.14 The method 1400 shown comprises: performing a conversion between a block of a video of a video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the conversion is based on an adaptive motion vector difference precision (AMVR) tool, wherein a representation of a motion vector or a motion vector difference or a motion vector predictor of the video block is represented in the codec representation using adaptive precision; wherein the format rule specifies that the use of adaptive precision is represented in the codec representation by context modeling that depends on codec information of the video block or neighboring blocks of the video block.

[0676] 2. The method of solution 1, wherein the coding information includes using an intra block copy mode.

[0677] 3. The method as described in solution 1, wherein the codec information includes the use of affine AMVR mode or non-affine and non-intra block copy mode, bi-directional prediction or uni-prediction mode.

[0678] 4. A method as described in any of solutions 1-3, wherein the codec information includes the dimension of the video block.

[0679] The following solution shows an example implementation of the technique discussed in the previous section (eg, item 2).

[0680] 5. A video processing method, comprising: performing a conversion between a video block of a video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the conversion is based on an adaptive motion vector difference precision (AMVR) tool, wherein a representation of a motion vector or a motion vector difference or a motion vector predictor of the video block is represented in the codec representation using adaptive precision; wherein the format rule specifies how to represent the use of adaptive precision in the codec representation through context modeling, so that the context is used to encode and decode a first binary bit and a second binary bit for an index of the precision used by the AMVR tool.

[0681] 6. A method as described in solution 5, wherein the format rule stipulates that the first binary bit and the second binary bit are encoded and decoded using the same context.

[0682] 7. A method as described in solution 5, wherein the format rule specifies that the second binary bit is encoded and decoded in the codec representation if and only if non-affine and non-intra block copy modes are used to represent the video block in the codec representation.

[0683] The following solutions show example embodiments of the techniques discussed in the previous section (eg, items 3 to 8).

[0684] 8. A video processing method, comprising: performing conversion between a video including one or more video pictures and a codec representation of the video, the one or more video pictures including multiple video blocks, wherein the codec representation has a format rule, and the format rule is used to signal information about adaptive motion vector difference precision (AMVR) encoding and decoding of the one or more video blocks; wherein the format rule specifies that the same context is used to encode and decode binary bits of an AMVR precision index of a first video block encoded and decoded using a first codec mode and binary bits of an AMVR precision index of a second video block encoded and decoded using a second codec mode.

[0685] 9. A method as described in Solution 8, wherein the first codec mode corresponds to an intra-block copy mode, and the second codec mode corresponds to an inter-frame codec, and wherein the binary bits of the first video block are the first binary bits of the AMVR precision index, and the binary bits of the second video block are the second binary bits of the corresponding AMVR precision index.

[0686] 10. A method as described in Solution 8, wherein the first codec mode corresponds to an intra-block copy mode, and the second codec mode corresponds to an inter-frame codec, and wherein the binary bits of the first video block are the first binary bits of the AMVR precision index, and the binary bits of the second video block are the first binary bits of the corresponding AMVR precision index.

[0687] 11. A method as described in Solution 8, wherein the first codec mode corresponds to an intra-block copy mode, and the second codec mode corresponds to an inter-frame codec, and wherein the binary bits of the first video block are the first binary bits of the AMVR precision index, and the binary bits of the second video block are the first binary bits of the corresponding AMVR precision index.

[0688] 12. A method as described in Solution 8, wherein the first codec mode corresponds to an intra block copy mode, and the second codec mode corresponds to an affine codec, and wherein the binary bits of the first video block are the first binary bits of an AMVR precision index, and the binary bits of the second video block are the first binary bits of the corresponding AMVR precision index.

[0689] 13. The method of solution 8, wherein the format rule further specifies that the same context is used to encode and decode all binary bits of the first video block, the second video block, and the third video block having an intra block copy mode, an affine mode, and an inter coding mode.

[0690] 14. A method as described in solution 8, wherein the format rule further stipulates that different contexts are used to encode and decode the first binary bits of the first video block, the second video block and the third video block with intra-frame block copy mode, affine mode and inter-frame coding and decoding, and the same context is used to encode and decode the second binary bits of the first video block, the second video block and the third video block.

[0691] The following solution shows an example implementation of the technique discussed in the previous section (eg, item 9).

[0692] 15. A method as described in any of solutions 1-14, wherein the format rule further stipulates that at least one context for encoding and decoding the precision value is the same as the context for encoding and decoding the flag indicating the applicability of the AMVR tool.

[0693] The following solutions show example embodiments of the techniques discussed in the previous section (eg, items 10-11).

[0694] 16. A video processing method, comprising: performing conversion between a video block of a video and a codec representation of the video, wherein the video block is divided into one or more vertical partitions and / or one or more horizontal partitions, wherein the codec representation conforms to a format rule that specifies context-based encoding and decoding of partition information of the video block.

[0695] 17. The method of solution 16, wherein the format rule specifies that context modeling of the syntax element for indicating partition information depends on the number of allowed vertical partitions of the video block and / or the number of allowed horizontal partitions of the video.

[0696] 18. The method of solution 17, wherein the format rule depends on whether the number of allowed vertical partitions of the video block is greater than the number of allowed horizontal partitions of the video block.

[0697] 19. A method as described in any of solutions 17-18, wherein the format rules specify the use of N contexts to encode and decode syntax elements, where N is based on the dimension of the video block or the dimension of neighboring video blocks.

[0698] The following solution shows an example implementation of the techniques discussed in the previous section (eg, items 10-12).

[0699] 20. The method of any of solutions 16-19, wherein the format rules specify the use of a single context to encode and decode a flag indicating the applicability of vertical partitioning for a video block.

[0700] The following solutions show example embodiments of the techniques discussed in the previous section (eg, items 10-13, 17).

[0701] 21. A video processing method, comprising: performing conversion between a video block of a video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the format rule specifies a codec condition for deciding whether to use a context codec or a bypass codec to represent a sign of a transform coefficient.

[0702] 22. The method of solution 21, wherein the codec condition corresponds to the number of remaining allowed context codec bins.

[0703] 23. The method of solution 21, wherein the codec condition corresponds to a transform for conversion between video blocks and codec representations.

[0704] The following solution shows an example implementation of the techniques discussed in the previous section (eg, items 10-14).

[0705] 24. A method of video processing, comprising: performing conversion between a video block of a video and a codec representation of the video, wherein the codec representation conforms to a format rule, wherein the format rule specifies that at the beginning of bypass coding of remaining syntax elements in a third or remaining coefficient scan pass of a transform skip residual coding process, an operation is applied to a variable specifying remaining allowed context coding binary bits.

[0706] 25. A method as described in any of solutions 1 to 24, wherein converting includes encoding the video into a codec representation.

[0707] 26. A method as described in any of solutions 1 to 24, wherein converting includes decoding the codec representation to generate pixel values ​​of the video.

[0708] 27. A video decoding device, comprising a processor configured to implement the method described in one or more of solutions 1 to 26.

[0709] 28. A video encoding device, comprising a processor configured to implement the method described in one or more of solutions 1 to 26.

[0710] 29. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method described in any one of solutions 1 to 26.

[0711] 30. A method, apparatus or system as described in this document.

[0712] Fig.18 1 is a flowchart representation of a video processing method 1800 according to one or more embodiments of the present technology. The method 1800 includes, at operation 1810, performing a conversion between a block of video and a bitstream of video according to a rule. The conversion is based on an adaptive motion vector difference precision (AMVR) tool, and the rule specifies selecting a context for a first bit within a bit string of a first syntax element, the first syntax element specifying the precision of a motion vector difference value associated with an AMVR shift is derived based on the use of a codec mode of the block.

[0713] In some embodiments, the block is a codec unit. In some embodiments, the codec mode of the block is one of an affine inter mode, an intra block copy mode, or a normal inter mode that is a non-affine inter mode. In some embodiments, a plurality of contexts corresponding to different codec modes are applicable to the first binary bit. In some embodiments, the plurality of contexts comprises three contexts. In some embodiments, each codec mode corresponds to a single context.

[0714] In some embodiments, when the block is encoded and decoded using the IBC mode, a first context of the first binary bit is assigned a first value, and when the block is not encoded and decoded using the IBC mode, at least one context different from the first context is applicable to the first binary bit for at least one inter coding mode. In some embodiments, when the block is encoded and decoded using the affine inter mode, a second context of the first binary bit is assigned a second value, and when the block is encoded and decoded using the normal inter mode that is a non-affine inter mode, a third context of the first binary bit is assigned a third value. The second value and the third value are different from each other.

[0715] In some embodiments, the context for the second bin of the bin string is the same as one or more contexts for the first bin. In some embodiments, the second bin of the bin string is encoded with a single context value. In some embodiments, the same context is selected for the first bin of the bin string of the first block encoded using IBC mode and the second bin of the bin string of the second block encoded using normal inter mode which is a non-affine inter mode.

[0716] In some embodiments, when the block is encoded or decoded using the IBC mode or the affine inter mode, the binary bit string consists of the first binary bit. When the block is encoded or decoded using the normal inter mode which is a non-affine inter mode, the binary bit string also includes a second binary bit. In some embodiments, at least one of the multiple contexts applicable to the first binary bit is the same as at least one context selected for the second syntax element, and the second syntax element specifies whether the precision of the motion vector difference is 1 / 4 luma sample or is specified by the first syntax element. In some embodiments, when the block is encoded or decoded using the IBC mode, the context of the first syntax element for specifying the precision of the motion vector difference is the same as the context selected for the second syntax element, and the second syntax element specifies whether the precision of the motion vector difference is 1 / 4 luma sample or is specified by the first syntax element. In some embodiments, when the block is not encoded or decoded using the IBC mode or the affine mode, the context of the first syntax element for specifying the precision of the motion vector difference is the same as the context selected for the second syntax element, and the second syntax element specifies whether the precision of the motion vector difference is 1 / 4 luma sample or is specified by the first syntax element. In some embodiments, the context of a first bin within a bin string is assigned a value of CtxM and the context of a second bin with a bin string is assigned a value of CtxQ, where CtxM = CtxQ. In some embodiments, a different context is selected for the second bin than for the first bin.

[0717] In some embodiments, a first context for a first bin when the block is encoded in IBC mode, a second context for the first bin when the block is encoded using affine mode, and a third context for the first bin when the block is encoded using neither IBC mode nor affine mode are the same. In some embodiments, the first context for the first bin when the block is encoded in IBC mode and the second context for the first bin when the block is encoded using neither IBC mode nor affine mode are the same. In some embodiments, the third context for the first bin when the block is encoded using affine mode is different from the first context and the second context. In some embodiments, the first context for the first bin when the block is encoded in IBC mode and the second context for the first bin when the block is encoded using affine mode are the same. In some embodiments, the context for all bins in a bin string when the block is encoded in IBC mode, the context for all bins in a bin string when the block is encoded using affine mode, and the context for all bins in a bin string when the block is encoded using neither IBC mode nor affine mode are the same.

[0718] In some embodiments, the AMVR tool is a codec tool in which the precision of motion vector differences is adaptively adjusted on a block-by-block basis.

[0719] Fig.19 1 is a flowchart representation of a video processing method 1900 according to one or more embodiments of the present technology. The method 1900 includes, at operation 1910, performing a conversion between a current block of a video and a bitstream of the video according to a rule. The rule specifies that the selection of a context for encoding a syntax element that specifies whether a block is horizontally partitioned or vertically partitioned is based on a number of allowed vertical partitions and a number of allowed horizontal partitions. The number of allowed vertical partitions includes a number of allowed binary vertical partitions and a number of allowed ternary vertical partitions, and the number of allowed horizontal partitions includes a number of allowed binary horizontal partitions and a number of allowed ternary horizontal partitions.

[0720] In some embodiments, the block is a codec unit. In some embodiments, the context is selected by comparing the number of allowed vertical partitions and the number of allowed horizontal partitions. In some embodiments, when the number of allowed vertical partitions is greater than the number of allowed horizontal partitions, the context is selected from the first context set. In some embodiments, when the number of allowed vertical partitions is less than the number of allowed horizontal partitions, the context is selected from the second context set. In some embodiments, each of the first context set and the second context set includes a single context. In some embodiments, the value of the single context in the first context set is 4. In some embodiments, the value of the single context in the second context set is 3.

[0721] In some embodiments, the context is selected from a third context set when the number of vertical partitions allowed is the same as the number of horizontal partitions allowed. In some embodiments, the third context set includes a plurality of contexts. In some embodiments, the third context set includes a third context having a value of 0, a fourth context having a value of 1, and a fifth context having a value of 2.

[0722] In some embodiments, selecting the context from the third context set is further based on (1) the availability of a first neighboring block located above the current block and a second neighboring block located to the left of the current block, (2) the dimension of the current block, and / or (3) the dimension of the neighboring block. In some embodiments, the context is assigned as the value of CtxD in the following cases: (1) the first neighboring block located above the current block or the second neighboring block located to the left of the current block is not available, or (2) dA is equal to dL, where dA represents the width of the current block divided by the width of the first neighboring block located above the current block, and where dL represents the height of the current block divided by the height of the second neighboring block located to the left of the current block. In some embodiments, when dA is less than dL, the context is assigned as the value of CtxE, where dA represents the width of the current block divided by the width of the first neighboring block located above the current block, and where dL represents the height of the current block divided by the height of the second neighboring block located to the left of the current block. In some embodiments, when dA is greater than dL, the context is assigned as the value of CtxF, where dA represents the width of the current block divided by the width of the first neighboring block located above the current block, and where dL represents the height of the current block divided by the height of the second neighboring block located to the left of the current block.

[0723] In some embodiments, the contexts in the first context set, the second context set, and the third context set are different from each other.

[0724] Fig. 202 is a flowchart representation of a video processing method 2000 according to one or more embodiments of the present technology. The method 2000 includes, at operation 2010, performing a conversion between a current block of video and a bitstream of the video according to a rule. The rule specifies that for a syntax element specifying a sign of a transform coefficient level, whether to use context coding or bypass coding is based on the number of remaining allowed context coding bits or the transform type for the current block.

[0725] In some embodiments, when the number of remaining allowed context coding bits is greater than or equal to a threshold, context coding is used for syntax elements in the transform skipping residual coding process for the current block. In some embodiments, when the number of remaining allowed context coding bits is less than a threshold, bypass coding is used for syntax elements in the transform skipping residual coding process for the current block. In some embodiments, the threshold is 0 or 3.

[0726] In some embodiments, bypass codec is used for syntax elements when the number of remaining allowed context codec bits is less than or equal to N. In some embodiments, context codec is used for syntax elements when the number of remaining allowed context codec bits is greater than or equal to N. In some embodiments, the number of remaining allowed context codec bits is modified to be less than or equal to N before processing the remaining absolute values ​​of the transform coefficient levels in the conversion. In some embodiments, N is 0, 3, or 4. In some embodiments, N is an integer based on a feature of the current block. In some embodiments, the feature of the current block includes an indication in a sequence parameter set, a video parameter set, a picture parameter set, a picture header, a slice header, a slice group header, a large codec unit row, a large codec unit group, a large codec unit, or a codec unit. In some embodiments, the feature of the current block includes a dimension or shape of the current block or a neighboring block of the current block. In some embodiments, the feature of the current block includes an indication of a color format of the video. In some embodiments, the feature of the current block includes an indication of whether a separate codec tree structure or a dual codec tree structure is used for conversion. In some embodiments, the feature of the current block includes a slice type or a picture type. In some embodiments, the feature of the current block includes the number of color components of the video.

[0727] In some embodiments, context coding of syntax elements is based on the number of remaining allowed context coding bits. In some embodiments, a variable specifying the number of remaining allowed context coding bits is modified at the beginning of bypass coding of remaining syntax elements in a third or remaining coefficient scan pass of a transform skip residual coding process. In some embodiments, the variable is set to a fixed value of 0. In some embodiments, the variable is decremented by 1. In some embodiments, the current block includes a transform block or a transform skip block, and the transform block or transform skip block includes or does not include a block-based delta pulse coding modulation codec block.

[0728] In some embodiments, whether or how to apply the method is indicated by a sequence level, a picture level, a slice level, or a slice group level. In some embodiments, the indication is included in a sequence header, a picture header, a sequence parameter set, a video parameter set, a decoder parameter set, decoding capability information, a picture parameter set, an adaptation parameter set, a slice header, or a slice group header. In some embodiments, whether or how to apply the method is based on the codec information of the video.

[0729] In some embodiments, the conversion includes encoding the video into a bitstream. In some embodiments, the conversion includes decoding the video from the bitstream.

[0730] In this document, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, during the conversion from a pixel representation of a video to a corresponding bitstream representation, a video compression algorithm may be applied, and vice versa. As defined by the syntax, the bitstream representation of the current video block may correspond to bits that are co-located or scattered at different positions within the bitstream, for example. For example, a macroblock may be encoded based on the error residual values ​​of the transform and the codec and also using bits in the header and other fields in the bitstream. In addition, during the conversion, the decoder may parse the bitstream based on this determination, knowing that some fields may or may not be present, as described in the above solution. Similarly, the encoder may determine whether to include or not include certain syntax fields, and generate the codec representation accordingly by including or excluding the syntax fields from the codec representation.

[0731] The disclosure and other schemes, examples, embodiments, modules and functional operations described in this document may be implemented in digital electronic circuits or in computer software, firmware or hardware, containing the structures disclosed in this document and the equivalents of their structures, or a combination of one or more of them. The disclosed and other embodiments may be implemented as one or more computer program products encoded on a computer-readable medium, such as one or more computer program instruction modules, for execution by a data processing device or for controlling the operation of a data processing device. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composite that affects a machine-readable propagable signal, or a combination of one or more thereof. The term "data processing device" encompasses all devices, equipment and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, for example, 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 propagation signal is an artificially generated signal, for example, a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[0732] A computer program (also referred to as a program, software, software application, script or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including stand-alone programs or modules, components, subroutines or other units 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 stores other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., files storing one or more modules, subroutines or code portions). A computer program can be deployed to execute on one computer or on multiple computers, which are located at one site or distributed across multiple sites and interconnected by a communication network.

[0733] The processes and logic flows described in this document may 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 logic flows may also be performed by special purpose logic circuits (e.g., field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs)), and the apparatus may be implemented as special purpose logic circuits (e.g., FPGAs or ASICs).

[0734] Processors suitable for the execution of computer programs include, for example, both general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the 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 for performing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (such as magnetic, magneto-optical disks or optical disks) for storing data, or be operably coupled to receive data from a mass storage device (such as magnetic, magneto-optical disks or optical disks) or transfer data to a mass storage device (such as magnetic, magneto-optical disks or optical disks), or both. However, a computer does not have to have such devices. Computer-readable media suitable for storing computer program instructions and data contain all forms of non-volatile memory, media and memory devices, including, for example, semiconductor memory devices (such as EPROM, EEPROM and flash memory devices); disks (such as internal hard disks or removable disks); magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by special-purpose logic circuits, or incorporated in special-purpose logic circuits.

[0735] Although this patent document contains many details, these details should not be interpreted as limitations on any subject matter or the scope of protection that can be claimed, but as descriptions of features of specific embodiments specified in specific technologies. In this patent document, certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments, respectively, or in various suitable sub-combinations. In addition, although features may be described as working in certain combinations and even initially required in the same manner as described above, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0736] Similarly, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in the sequential order shown, or that all illustrated operations be performed, in order to achieve the desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0737] Only a few implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and illustrated in this patent document.

Claims

1. A video processing method, comprising: performing conversion between blocks of video and a bitstream of said video according to rules, wherein the conversion is based on an adaptive motion vector difference precision (AMVR) tool, and wherein the rule specifies selecting a context for a first binary bit within a binary bit string of a first syntax element, wherein the first syntax element specifies deriving a precision of a motion vector difference value associated with an AMVR shift based on use of a coding mode for the block.

2. The method according to claim 1, wherein: The blocks are codec units.

3. The method according to claim 1 or 2, wherein: The coding mode of the block is one of an affine inter mode, an intra block copy mode, or a normal inter mode which is a non-affine inter mode.

4. The method according to any one of claims 1 to 3, wherein: A plurality of contexts corresponding to different coding modes are applicable to the first binary bit.

5. The method according to claim 4, wherein: The plurality of contexts includes three contexts.

6. The method according to claim 4, wherein: Each codec mode corresponds to a single context.

7. The method according to any one of claims 1 to 6, wherein: A first context for the first binary bit is assigned a first value when the block is encoded or decoded using an IBC mode, and wherein, when the block is not encoded or decoded using the IBC mode, at least one context different from the first context is applicable to the first binary bit for at least one inter-frame coding mode.

8. The method according to claims 1 to 7, wherein: When the block is encoded and decoded using an affine inter mode, a second context of the first binary bit is assigned a second value, and when the block is encoded and decoded using a normal inter mode which is a non-affine inter mode, a third context of the first binary bit is assigned a third value, wherein the second value and the third value are different from each other.

9. The method according to any one of claims 1 to 8, wherein: The context for a second bin of the bin string is the same as one or more contexts for the first bin.

10. The method according to any one of claims 1 to 9, wherein: The second bin of the bin string is encoded with a single context value.

11. The method according to claim 10, wherein: The same context is selected for a first bin of the bin string of a first block decoded using the IBC mode and for a second bin of the bin string of a second block decoded using the normal inter mode which is a non-affine inter mode.

12. The method according to any one of claims 1 to 11, wherein: The binary bit string consists of the first binary bit when the block is encoded or decoded using the IBC mode or the affine inter mode, and wherein, the binary bit string further comprises a second binary bit when the block is encoded or decoded using the normal inter mode which is a non-affine inter mode.

13. The method according to any one of claims 4 to 9, wherein: At least one of the multiple contexts applicable to the first bin is the same as at least one context selected for a second syntax element, the second syntax element specifying whether the precision of the motion vector difference value is 1 / 4 luma sample or is specified by the first syntax element.

14. The method according to claim 13, wherein: When the block is encoded and decoded using the IBC mode, the context of the first syntax element for specifying the precision of the motion vector difference is the same as the context selected for the second syntax element, and the second syntax element specifies whether the precision of the motion vector difference is 1 / 4 luma sample or is specified by the first syntax element.

15. The method according to claim 13, wherein: When the block is not encoded or decoded using IBC mode or affine mode, the context of the first syntax element that specifies the precision of the motion vector difference is the same as the context selected for the second syntax element, and the second syntax element specifies whether the precision of the motion vector difference is 1 / 4 luma sample or is specified by the first syntax element.

16. The method according to claim 14 or 15, wherein: The context of the first bin within the bin string is assigned a value of CtxM, and the context of the second bin within the bin string is assigned a value of CtxQ, and wherein CtxM=CtxQ.

17. The method according to claim 16, wherein: A different context is selected for the second bin compared to the first bin.

18. The method according to claim 4, wherein: A first context for the first binary bit when the block is encoded and decoded in IBC mode, a second context for the first binary bit when the block is encoded and decoded using affine mode, and a third context for the first binary bit when the block is encoded and decoded using neither the IBC mode nor the affine mode are the same.

19. The method according to claim 4, wherein: A first context for the first bin when the block is encoded and decoded in IBC mode and a second context for the first bin when the block is encoded and decoded using neither the IBC mode nor the affine mode are the same.

20. The method according to claim 19, wherein: In case the block is encoded and decoded using the affine mode, a third context for the first bin is different from the first context and the second context.

21. The method according to claim 4, wherein: A first context for the first bin when the block is encoded in IBC mode and a second context for the first bin when the block is encoded using affine mode are the same.

22. The method according to claim 4, wherein: The context for all bins in the binary bit string when the block is encoded and decoded in IBC mode, the context for all bins in the binary bit string when the block is encoded and decoded using affine mode, and the context for all bins in the binary bit string when the block is encoded and decoded using neither the IBC mode nor the affine mode are the same.

23. The method according to any one of claims 1 to 22, wherein: The AMVR tool is a codec tool in which the precision of motion vector differences is adaptively adjusted on a block-by-block basis.

24. The method according to any one of claims 1 to 23, wherein: The converting includes encoding the video into the bitstream.

25. The method according to any one of claims 1 to 23, wherein: The converting includes decoding the video from the bitstream.

26. A method for storing a bit stream of a video, comprising: generating a bitstream of the video from blocks of the video according to a rule, wherein said generating comprises using an adaptive motion vector difference precision AMVR tool, wherein a motion vector difference is represented in said bitstream using a precision of said motion vector difference value, and Therein, the rule specifies selection of a context for a first bin within a bin string of a first syntax element specifying a precision of the motion vector difference value associated with an AMVR shift, based on usage of a coding mode for the block.

27. A video decoding apparatus comprising a processor configured to implement the method of one or more of claims 1 to 26.

28. A video encoding apparatus comprising a processor configured to implement the method of one or more of claims 1 to 26.

29. 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 claims 1 to 26.

30. A non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein: The method comprises: generating a bitstream of the video from blocks of the video according to a rule, and storing the bitstream in a non-transitory computer-readable recording medium, wherein said generating comprises using an adaptive motion vector difference precision AMVR tool, wherein a motion vector difference is represented in said bitstream using a precision of said motion vector difference value, and Therein, the rule specifies selection of a context for a first bin within a bin string of a first syntax element specifying a precision of the motion vector difference value associated with an AMVR shift, based on usage of a coding mode for the block.

31. A method, apparatus or system as described in this document.

Images