Entropy coding for partitioned syntax.

Abstract

Systems, methods, and apparatuses for video processing are described. The video processing may include video encoding, video decoding, or video transcoding. One example method of video processing includes performing a conversion between a block of video and a video bitstream according to rules. The rules specify that a selection of a context for coding a syntax element indicating whether a block is partitioned horizontally or vertically is based on the number of allowed vertical divisions and the number of allowed horizontal divisions. The number of allowed vertical divisions includes the number of allowed binary vertical divisions and the number of allowed ternary vertical divisions, and the number of allowed horizontal divisions includes the number of allowed binary horizontal divisions and the number of allowed ternary horizontal divisions.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS Books This application claims priority to and the benefit of International Patent Application No. PCT / CN2020 / 088546, filed on May 1, 2020. main Stretch Based on International Patent Application No. PCT / CN2021 / 091870 filed on May 6, 2021 . above The entire disclosure of this application is: three By lighting Here It is incorporated herein by reference.

[0002] TECHNICAL FIELD This disclosure relates to video and image coding technology. [Background technology]

[0003] Digital video accounts for the largest bandwidth usage on the Internet and other digital communications networks, and the bandwidth demands for digital video use are expected to continue to grow as the number of connected user devices capable of receiving and displaying video increases. Summary of the Invention

[0004] The disclosed techniques may be used by embodiments of a video or image encoder to encode or decode using context-based encoding and decoding.

[0005] In one exemplary aspect, a method for processing a video is disclosed. The method includes performing a conversion between a video block of a video and a coded representation of the video, the coded representation conforming to a format rule, the conversion is performed based on an AMVR (Adaptive Motion Vector Difference Resolution) tool, in which a motion vector or a motion vector difference or a motion vector predictor representation for the video block is represented in the coded representation using an adaptive resolution, and the format rule specifies that the adaptive resolution is represented in the coded representation by a context modeling that depends on the coded information of the video block or the neighboring block of the video block.

[0006] In another exemplary aspect, a method of processing another video is disclosed, the method includes performing a conversion between a video block of the video and a coded representation of the video, the coded representation conforming to a format rule, the conversion is performed based on an Adaptive Motion Vector Difference Resolution (AMVR) tool in which a representation of a motion vector or a motion vector differential or a motion vector predictor for the video block is represented in the coded representation using an adaptive resolution, the format rule specifies how to express the use of the adaptive resolution in the coded representation by a context modeling used to code a first bin and a second bin for an index of precision used by the AMVR tool.

[0007] In another exemplary aspect, a method of processing another video is disclosed, the method including performing a conversion between a video including one or more video pictures of a plurality of video blocks and a coded representation of the video, the coded representation conforming to a format rule for signaling information regarding Adaptive Motion Vector Difference Resolution (AMVR) coding of the one or more video blocks, the format rule specifying coding bins of an AMVR precision index of a first video block coded using a first coding mode and bins of an AMVR precision index of a second video block coded using a second coding mode using the same context.

[0008] In another exemplary aspect, another method of processing video is disclosed, the method including performing a conversion between video blocks of the video and a coded representation of the video, where the video blocks are divided into one or more vertical and / or one or more horizontal divisions, and the coded representation conforms to a format rule that specifies context-based coding of the division information of the video blocks.

[0009] In another exemplary aspect, a method of processing another video is disclosed that includes performing a conversion between video blocks of the video and a coded representation of the video, where the coded representation conforms to a format rule that specifies coding conditions used to determine whether to use context coding or bypass coding to indicate signs of transform coefficients.

[0010] In another exemplary aspect, a method of processing another video is disclosed, the method including performing a conversion between a video block of the video and a coded representation of the video, the coded representation conforming to a format rule, the format rule specifying that the operation is applied to a variable that specifies a number of remaining allowed context coded bins at the start of bypass coding of remaining syntax elements in a third or residual coefficient scan pass of a transform skip residual coding process.

[0011] In another exemplary aspect, the methods described above may be implemented by a video encoder device that includes a processor.

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

[0013] These and other aspects are further described herein. [Brief description of the drawings]

[0014] [Figure 1] 1 shows an example of an encoder block diagram. [Diagram 2] 67 examples of intra prediction modes are shown. [Figure 3A] Here is an example of a four-parameter affine model. [Figure 3B] Here is an example of a six-parameter affine model. [Figure 4] An example of affine MVF for each subblock is shown. [Diagram 5] 1 shows an example of an inherited affine motion predictor. [Figure 6] 13 shows an example of control point motion vector inheritance. [Figure 7] 13 shows examples of candidate positions for a constructed affine merge mode. [Figure 8] FIG. 13 is an illustration of motion vector usage for the proposed combined method. [Figure 9] An example of a sub-block MV VSB and pixel Δv(i,j) is shown (red arrow). [Figure 10] 4 illustrates a multi-type tree splitting mode. [Figure 11] 13 shows an example of signaling of split flags in a quadtree with nested multi-type tree coding tree structure. [Figure 12] FIG. 1 is a block diagram of an example video processing system. [Figure 13] 1 illustrates an example of a video processing device. [Figure 14] 1 is a flowchart illustrating an example of a video processing method. [Figure 15] 1 is a block diagram illustrating a video coding system according to some embodiments of the present disclosure. [Figure 16] FIG. 2 is a block diagram illustrating an encoder according to some embodiments of the present invention. [Figure 17] FIG. 2 is a block diagram illustrating a decoder according to some embodiments of the present invention. [Figure 18] 1 is a flow chart illustrating a video processing method in accordance with one or more embodiments of the present technology. [Figure 19] 11 is a flow chart illustrating another method of video processing in accordance with one or more embodiments of the present technology. [Figure 20] 11 is a flow chart illustrating yet another method of video processing in accordance with one or more embodiments of the present technology. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] This specification provides various techniques that can be used by a decoder of an image or video bitstream to improve the quality of the unpacked or decoded digital video or image. For simplicity, the term "video" is used herein to include both a series of pictures (conventionally called video) and individual images. Furthermore, a video encoder may implement these techniques during the encoding process to reconstruct decoded frames that are used for further encoding.

[0016] Section headings are used herein for ease of understanding and are not intended to limit embodiments disclosed in one section to only that section, and thus embodiments in one section may be combined with embodiments in other sections.

[0017] 1. Overview This specification relates to video coding technology. In particular, it relates to coding tools such as AMVR (Adaptive Motion Vector Resolution) and block division in image / video coding. It may be applied to existing video coding standards such as HEVC, or may be applied to finalize a standard (Versatile Video Coding). The present invention is also applicable to future video coding standards or video codecs.

[0018] 2. Initial Discussions Video coding standards have evolved primarily through the development of well-known ITU-T and ISO / IEC standards. ITU-T created H.261 and H.263, ISO / IEC created MPEG-1 and MPEG-4 Visual, and the two organizations jointly created H.262 / MPEG-2 Video, H.264 / MPEG-4 AVC (Advanced Video Coding), and H.265 / HEVC standards. Since H.262, video coding standards have been based on hybrid video coding structures where temporal prediction and transform coding are utilized. In 2015, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) to explore future video coding technologies beyond HEVC. Since then, many new methods have been adopted by JVET and incorporated into reference software called JEM (Joint Exploration Mode). In April 2018, the Joint Video Expert Team (JVET) was established between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG), and is working on formulating the VVC standard with the goal of reducing the bitrate by 50% compared to HEVC.

[0019] 2.1. Typical video codec coding flow Figure 1 shows an example of an encoder block diagram for VVC, including three in-loop filtering blocks: Deblocking Filter (DF), Sample Adaptive Offset (SAO) and ALF. Unlike DF, which uses predefined filters, SAO and ALF utilize the original samples of the current picture and reduce the mean square error between the original and reconstructed samples by adding an offset and applying a Finite Impulse Response (FIR) filter, respectively, with coded-side information signaling the offset and filter coefficients. The ALF is located at the last processing stage of each picture and can be considered as a tool that tries to capture and correct artifacts generated in the previous stage.

[0020] 2.2. Intra-mode coding with 67 intra-prediction modes To capture any edge orientation represented in natural video, the number of directional intra modes, as used in HEVC, is expanded from 33 to 65. The additional directional modes are indicated by the red dotted arrows in Figure 2, while the planar and DC modes remain the same. These denser directional intra prediction modes apply to all block sizes, and to both luma and chroma intra prediction.

[0021] The conventional angular intra prediction direction is defined from 45 degrees to -135 degrees in a clockwise direction as shown in Figure 2. In VTM, some conventional angular intra prediction modes are adaptively replaced with wide-angle intra prediction modes for non-square blocks. The replaced modes are 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, e.g., 67, and the intra mode coding remains unchanged.

[0022] In HEVC, all intra-coded blocks have a square shape, and the length of each of their sides is a power of 2. Thus, no division operations are required to generate an intra predictor using DC mode. In VVC, blocks may have rectangular shapes, which in the general case requires the use of division operations for each block. To avoid division operations for DC prediction, we calculate the average of non-square blocks using only the long sides.

[0023] 2.3. Inter Prediction For each inter-predicted CU, motion parameters consisting of a motion vector, a reference picture index, and a reference picture list usage index, as well as additional information required for the new coding features of VVC, are used for inter-predicted sample generation. The motion parameters may be signaled explicitly or implicitly. If a CU is coded in skip mode, it is associated with one PU and has no significant residual coefficients, coded motion vector differentials, or reference picture indexes. A merge mode is defined, which obtains motion parameters for the current CU, including spatial and temporal candidates, as well as additional schedules introduced in VVC, from neighboring CUs. The merge mode can be applied to any inter-predicted CU, not just for skip mode. An alternative to the merge mode is to explicitly transmit the motion parameters, where the motion vector, the reference picture index corresponding to each reference picture list and the reference picture list usage flag, as well as other necessary information, are explicitly signaled for each CU.

[0024] 2.4. IBC (Intra Block Copy) IBC (Intra Block Copy) is a tool adopted in the HEVC extension of SCC. It is known to significantly improve the coding efficiency of screen content material. Since IBC mode is implemented as a block-level coding mode, Block Matching (BM) is performed in the encoder to find the optimal block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to a reference block already reconstructed inside the current picture. Luma block vectors of IBC coded CUs are integer precision. Chroma block vectors are also rounded to integer precision. When combined with AMVR, IBC mode can switch between 1-pixel and 4-pixel motion vector precision. IBC coded CUs are treated as a third prediction mode other than intra or inter prediction modes. IBC mode is applicable for CUs with both width and height less than or equal to 64 luma samples.

[0025] On the encoder side, hash-based motion estimation is performed for IBC. The encoder performs an RD check for blocks with width or height less than or equal to 16 luma samples. For non-merge modes, first a block vector search is performed using a hash-based search. If the hash search does not return a valid candidate, a block matching-based local search is performed.

[0026] In hash-based search, the hash key matching (32-bit CRC) between the current block and the reference block is expanded to all allowed block sizes. The calculation of the hash key for every location in the current picture is based on 4×4 sub-blocks. If the size of the current block is larger, the hash key is determined to match that of the reference block if all the hash keys of all the 4×4 sub-blocks match the hash key of the corresponding reference location. If the hash keys of multiple reference blocks are found to match the hash key of the current block, calculate the block vector cost of each matched reference block and select the one with the minimum cost. In block matching search, the search range is set to cover both the previous CTU and the current CTU.

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

[0028] - IBC skip / merge mode: The merge candidate index is used to indicate which block vector in the list from neighboring candidate IBC coded blocks is used to predict the current block. The merge list consists of spatial candidates, HMVP candidates, and pairwise candidates.

[0029] -IBC AMVP mode: Block vector differentials are coded similarly to motion vector differentials. The block vector prediction method uses two candidates as predictors, one from the left neighbor and one from the top neighbor (if IBC coded). If any neighbor is not available, a default block vector is used as predictor. A flag is signaled to indicate the block vector predictor index.

[0030] 2.5. Affine motion compensation prediction In HEVC, only the translational motion model is applied for MCP (Motion Compensation Prediction). Meanwhile, in the real world, there are various kinds of motions, such as zoom in / out, rotation, perspective motion, and other irregular motions. In VVC, block-based affine transform motion compensation prediction is applied. As shown in Figure 3A to Figure 3B, the affine motion field of a block is described by the motion information of two control points (four parameters) or three control point motion vectors (six parameters).

[0031] FIG. 6 shows an example of control point motion vector inheritance.

[0032] For the four-parameter affine motion model, the motion vector for a sample position (x,y) within a block is derived as follows:

[0033]

number

[0034] For the six-parameter affine motion model, the motion vector for a sample position (x,y) within a block is derived as follows:

[0035]

number

[0036] Here, (mv 0x ,mv 0y ) is the motion vector of the upper left corner control point, (mv 1x ,mv 1y ) is the motion vector of the control point in the upper right corner, (mv 2x ,mv 2y ) is the motion vector of the bottom-left corner control point.

[0037] To simplify the motion compensation prediction, a block-based affine transformation prediction is applied. To derive the motion vectors for each 4×4 luma sub-block, the motion vectors of the center samples of each sub-block are calculated according to the above equation and rounded to 1 / 16 fractional precision, as shown in FIG. 4. Then, a motion compensation interpolation filter is applied to generate a prediction for each sub-block using the derived motion vectors. Also, the sub-block size of the chroma components is set to 4×4. The MV of a 4×4 chroma sub-block is calculated as the average of the MVs of the corresponding 4×4 luma sub-blocks.

[0038] Similar to translational motion inter prediction, there are two affine motion inter prediction modes: affine merge mode and affine AMVP mode.

[0039] 2.5.1. Affine Merge Prediction The AF_MERGE mode can be applied to CUs whose width and height are both 8 or more. In this mode, we generate a CPVM for the current CU based on the motion information of spatially neighboring CUs. There are up to 5 CPMVP candidates, and an index is signaled to indicate the one that should be used for the current CU. The following three types of CPVM candidates are used to form the affine merge candidate list: - Inherited affine merge candidates extrapolated from the CPMVs of nearby CUs - Constructed affine merge candidate CPMVP derived using translation MVs of nearby CUs -Zero MV

[0040] In VVC, there are up to two inherited affine candidates derived from the affine motion models of the neighboring blocks, one from the left neighboring CU and one from the top neighboring CU. The candidate blocks are shown in Figure 5. For the left predictor, the scan order is A0->A1, and for the top predictor, the scan order is B0->B1->B2. We select only the first inherited candidate from each side. No pruning check is performed between the two inherited candidates. Once a neighboring affine CU is identified, we use its control point motion vectors to derive CPMVP candidates in the affine merge list of the current CU. As shown in the figure, if the neighboring bottom-left block A is coded in affine mode, the motion vectors v of the top-left, top-right and bottom-left corners of the CU containing block A are used. 2 , v 3 , v 4 When coding with a four-parameter affine model, v 2 and v 3 Calculate the two CPMVs of the current unit by: If block A is coded using a 6-parameter affine model, v 2 , v 3 and v 4 Based on this, the three CPMVs of the current CU are calculated.

[0041] The constructed affine candidate means that we construct the candidate by combining the local translational motion information of each control point. We derive the motion of the control points from the identified spatial and temporal neighborhoods shown in Figure 7. CPMV k (k=1,2,3,4) represents the kth control point. CPMV 1 If so, then the B2->B3->A2 block is checked and the MV of the first available block is used. 2 In this case, the B1→B0 block is checked and CPMV 3 The A1 → A0 block is checked for CPMV if available. 4 TMVP is used as the

[0042] After arriving at the MVs of the four control points, we construct affine merge candidates based on their motion information. We do so in order using the following combinations of control point MVs: {CPMV 1 ,CPMV 2 ,CPMV 3},{CPMV 1 ,CPMV 2 ,CPMV 4},{CPMV 1 ,CPMV 3 ,CPMV 4},{CPMV 2 ,CPMV 3 ,CPMV 4},{CPMV 1 ,CPMV 2},{CPMV 1 ,CPMV 3}

[0043] A combination of three CPMVs constitutes a six-parameter affine merge candidate, and a combination of two CPMVs constitutes a four-parameter affine merge candidate. To avoid the motion scaling process, we discard the associated combination of control point MVs if the reference indices of the control points are different.

[0044] After checking the inherited and constructed affine merge candidates, if the list is not already full, insert a zero MV at the end of the list.

[0045] Affine AMVP Prediction Affine AMVP mode can be applied to CUs with both width and height equal to or greater than 16. A CU-level affine flag is signaled in the bitstream to indicate whether affine AMVP mode is used, and then another flag is signaled to indicate whether it is 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 is generated using the following four types of CPVM candidates in order: - Inherited affine AMVP candidates extrapolated from the CPUMV of neighboring CUs - Affine AMVP candidate CPMVP constructed using translational MVs of nearby CUs - Translational MV from nearby CU -Zero MV

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

[0047] The constructed AMVP candidates are derived from the defined spatial neighborhood shown in Figure 7. The same check order is used as done in the affine merge candidate construction. We also check the reference picture indexes of the neighboring blocks. The first block in the check order that is inter-coded and has the same reference picture as the current CU is used. If the current CU is coded in 4-parameter affine mode and mv 0 and mv 1 If both CPMVs are available, add them as one candidate in the affine AMVP list. If the current CU is coded in 6-parameter affine mode and all three CPMVs are available, add them as one candidate in the affine AMVP list. Otherwise, set the constructed AMVP candidate to unavailable.

[0048] After checking the inherited and constructed affine AMVP candidates, if there are still less than 2 affine AMVP list candidates, mv 0 , mv 1 , and mv 2 In the order, all control point MVs of the current CU are added as predicted translation MVs. Finally, if the affine AMVP list is not yet fully filled, we use zero MVs to fill it up.

[0049] 2.5.3. Affine Motion Information Storage In VVC, the CPUMV of an affine CU is stored in a separate buffer. The stored CPMV is used only to generate the inherited CPMVP in affine merge and affine AMVP modes for the recently coded CU. Sub-block MVs derived from the CPMV are used for motion compensation, merging of translational MVs / MV derivation of AMVP lists, and deblocking.

[0050] In order to avoid picture line buffer for additional CPUMV, inheritance of affine motion data from CU from upper CTU is treated differently from inheritance from normal neighboring CU. If a candidate CU for affine motion data inheritance is in upper CTU line, the bottom left and bottom right sub-block MVs in the line buffer are used to derive the affine MVP instead of CPMV. In this way, CPMV is stored only in the local buffer. If the candidate CU is 6-parameter affine coded, the affine model is degraded to a 4-parameter model. As shown in Figure 8, the bottom left and bottom right sub-block motion vectors of the CU along the upper bound of the CTU are used to affine inherit the CU in the lower bound CTU.

[0051] 2.5.4. Optical flow prediction improvement for affine modes Subblock-based affine motion compensation can save memory access bandwidth and reduce computational complexity compared to pixel-based motion compensation at the expense of prediction accuracy. To achieve finer granularity of motion compensation, Prediction Refinement with Optical Flow (PROF) is used to improve subblock-based affine motion compensation prediction without increasing memory access bandwidth for motion compensation. After performing subblock-based affine motion compensation in VVC, the luma prediction samples are refined by adding the difference derived by the optical flow equation. PROF is described as the following four steps:

[0052] Step 1) Perform sub-block based affine motion compensation to generate the sub-block prediction I(i,j). Step 2) At each sample location, we use a 3-tap filter [-1,0,1] to find the spatial gradient of the subblock prediction g x (i,j) and g y Calculate (i,j). The gradient calculation is exactly the same as the BDOF gradient calculation.

[0053]

number

[0054] shift1 is used to control the precision of the gradient. Sub-block (e.g., 4x4) predictions are expanded by one sample on each side for gradient calculation. To avoid additional memory bandwidth and additional interpolation calculations, these expanded samples on the expanded border are copied from the nearest integer pixel location in the reference picture.

[0055] Step 3) Calculate the luminance prediction improvement using the optical flow equation:

[0056]

number

[0057] Here, Δv(i,j) is the difference between the sample MV, denoted by v(i,j), calculated to 0 for sample position (i,j), and the sub-block MV of the sub-block to which sample (i,j) belongs, as shown in Figure 9. This Δv(i,j) is quantized in units of 1 / 32 luma sample precision.

[0058] Since the affine model parameters and sample positions relative to the subblock center do not change for each subblock, Δv(i,j) can be calculated for the first subblock and reused for other subblocks in the same CU. dx(i,j) and dy(i,j) are calculated as the affine model parameters from sample position (i,j) to the subblock (x SB ,y SB ), Δv(x,y) can be derived as follows:

[0059]

number

[0060] To maintain accuracy, we use subblocks (x SB ,y SB The center of ((W SB -1) / 2,(H SB -1) / 2), where W SB and H SB are the width and height of the sub-block, respectively.

[0061] For a four-parameter affine model,

[0062]

number

[0063] For a six-parameter affine model,

[0064]

number

[0065] Here, (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, and w, h are the width and height of the CU.

[0066] Step 4) Finally, we add the luma prediction improvement ΔI(i,j) to the sub-block prediction I(i,j). The final prediction I′ is generated according to the following equation:

[0067]

number

[0068] PROF is not applied in two cases for affine coded CUs: 1) all control points MV are the same, which indicates that the CU has only translational motion, and 2) the affine motion parameters are larger than the prescribed limit, since sub-block based affine MC degrades to CU based MC to avoid large memory access bandwidth requirements.

[0069] In order to reduce the coding complexity of affine motion estimation using PROF, a fast coding method is applied. In the following two situations, a) if this CU is not a root block and its parent block does not select affine mode as its best mode, PROF is not applied because the current CU is unlikely to select affine mode as its best mode; b) if the magnitudes of the four affine parameters (C, D, E, F) are all smaller 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 by PROF can be accelerated.

[0070] 2.6. Example Availability Process for Block Splits 6.4.1 Allowed Quad Division Processes The inputs to this process are: the coding block size in luma samples, cbSize; - the multitype tree depth mttDepth, - variable treeType that stipulates whether a single tree (SINGLE_TREE) or a dual tree is used to split the coding tree nodes, and if a dual tree is used, whether we are currently processing the luma (DUAL_TREE_LUMA) or chroma components (DUAL_TREE_CHROMA). - variable modeType that specifies whether intra (MODE_INTRA), IBC (MODE_IBC), inter coding modes can be used (MODE_TYPE_ALL), or only intra and IBC coding modes can be used (MODE_TYPE_INTRA), or only inter coding modes can be used (MODE_TYPE_INTER).

[0071] The output of this process is the variable allowSplitQt. The variable allowSplitQt is derived as follows: -allowSplitQt is set to FALSE if one or more of the following conditions are true: -treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA and cbSize is less than or equal to MinQtSizeY -treeType is equal to DUAL_TREE_CHROMA and cbSize is less than or equal to (MinQtSizeC*SubHeightC / SubWidthC). -mttDepth is not equal to 0 -treeType is equal to DUAL_TREE_CHROMA and (cbSize / SubWidthC) is less than or equal to 4 -treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA - Otherwise, allowSplitQt is set to TRUE.

[0072] 6.4.2 Permitted Binary Split Operations The inputs to this process are: - binary split mode btSplit, - the coding block width cbWidth in luma samples, - cbHeight, the height of the coding block in luma samples, the position (x0,y0) of the top left luminance sample of the considered coding block relative to the top left luminance sample of the picture, - the multitype tree depth mttDepth, - the maximum multitype tree depth, offset by maxMttDepth, - maximum binary tree size maxBtSize, -minimum quadtree size minQtSize, - Partition index partIdx, - variable treeType that stipulates whether a single tree (SINGLE_TREE) or a dual tree is used to split the coding tree nodes, and if a dual tree is used, whether we are currently processing the luma (DUAL_TREE_LUMA) or chroma components (DUAL_TREE_CHROMA). - variable modeType that specifies whether intra (MODE_INTRA), IBC (MODE_IBC), inter coding modes can be used (MODE_TYPE_ALL), or only intra and IBC coding modes can be used (MODE_TYPE_INTRA), or only inter coding modes can be used (MODE_TYPE_INTER).

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

[0074] Table 2-1 Specifications of parallelTtSplit and cbSize based on btSplit

[0075] [Table 1]

[0076] Derive the variables parallelTtSplit and cbSize as shown in Table 2-1. The variable allowBtSplit is derived as follows: allowBtSplit is set to FALSE if one or more of the following conditions are true: -cbSize is less than or equal to MinBtSizeY -cbWidth is greater than maxBtSize -cbHeight is greater than maxBtSize -mttDepth is greater than or equal to maxMttDepth -treeType is equal to DUAL_TREE_CHROMA and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16 -treeType is equal to DUAL_TREE_CHROMA, (cbWidth / SubWidthC) is equal to 4, and btSplit is equal to SPLIT_BT_VER. -treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA -cbWidth*cbHeight is equal to 32 and modeType is equal to MODE_TYPE_INTER Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -btSplit equals SPLIT_BT_VER -y0+cbHeight is greater than pic_height_in_luma_samples

[0077] Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -btSplit equals SPLIT_BT_VER -cbHeight is greater than 64 -x0+cbWidth is greater than pic_width_in_luma_samples Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -btSplit equals SPLIT_BT_HOR -cbWidth is greater than 64 -y0+cbHeight is greater than pic_height_in_luma_samples Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -x0+cbWidth is greater than pic_width_in_luma_samples -y0+cbHeight is greater than pic_height_in_luma_samples -cbWidth is larger than minQtSize

[0078] Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -btSplit equals SPLIT_BT_HOR -x0+cbWidth is greater than pic_width_in_luma_samples -y0+cbHeight is less than or equal to pic_height_in_luma_samples Otherwise, if all of the following conditions are true, then allowBtSplit is set equal to FALSE: -mttDepth is greater than 0 -partIdx=1 -MttSplitMode[x0][y0][mttDepth-1] is equaltoparallelTtSplit. Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -btSplit equals SPLIT_BT_VER -cbWidth is less than or equal to 64 -cbHeight is greater than 64 Otherwise, if all of the following conditions are met, allowBtSplit is set to FALSE: -btSplit equals SPLIT_BT_HOR -cbWidth is greater than 64 -cbHeight is 64 or less - Otherwise, allowBtSplit is set to TRUE.

[0079] 6.4.3 Permitted Ternary Splitting Operations The inputs to this process are: -Tternary split mode ttSplit, - the coding block width cbWidth in luma samples, - cbHeight, the height of the coding block in luma samples, the position (x0,y0) of the top left luminance sample of the considered coding block relative to the top left luminance sample of the picture, - Multitype tree depth mttDepth - the maximum multitype tree depth, offset by maxMttDepth, - maximum ternary tree size maxTtSize, - variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to split the coding tree nodes, and if a dual tree is used, whether the luma (DUAL_TREE_LUMA) or chroma component (DUAL_TREE_CHROMA) is currently being processed; - variable modeType that specifies whether intra (MODE_INTRA), IBC (MODE_IBC), inter coding modes can be used (MODE_TYPE_ALL), or only intra and IBC coding modes can be used (MODE_TYPE_INTRA), or only inter coding modes can be used (MODE_TYPE_INTER).

[0080] The output of this process is the variable allowTtSplit. Table 2-2 cbSize specifications according to ttSplit

[0081] [Table 2]

[0082] Derive the variable cbSize as shown in Table 2-2. The variable allowTtSplit is derived as follows: -allowTtSplit is set to FALSE if one or more of the following conditions are true: -cbSize is less than or equal to 2*MinTtSizeY -cbWidth is greater than Min(64,maxTtSize) -cbHeight is greater than Min(64,maxTtSize) -mttDepth is greater than or equal to maxMttDepth -x0+cbWidth is greater than pic_width_in_luma_samples -y0+cbHeight is greater than pic_height_in_luma_samples -treeType is equal to DUAL_TREE_CHROMA and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32 -treeType equals DUAL_TREE_CHROMA, (cbWidth / SubWidthC) equals 8, and ttSplit equals SPLIT_TT_VER -treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA -cbWidth*cbHeight equals 64 and modeType equals MODE_TYPE_INTER. - Otherwise, allowTtSplit is set to TRUE.

[0083] 6.4.4 Neighborhood Block Availability Derivation Process The inputs to this process are: - the luminance position (xCurr, yCurr) of the top-left sample of the current block relative to the top-left luminance sample of the current picture, - the luminance position (xNbY, yNbY) covered by the neighboring block relative to the top-left luminance sample of the current picture, a variable checkPredModeY that specifies whether availability depends on the prediction mode, - The variable cIdx that defines the color components of the current block.

[0084] The output of this process is the availability of neighboring blocks covering position (xNbY, yNbY), denoted as availableN. The availability of neighboring blocks, availableN, is derived as follows: - availableN is set to FALSE if one or more of the following conditions are true: -xNbY is less than 0. - yNbY is less than 0. -xNbY is greater than or equal to pic_width_in_luma_samples. - yNbY is greater than or equal to pic_height_in_luma_samples. -IsAvailable[cIdx][xNbY][yNbY] is equal to FALSE. - The neighboring block is in a different slice than the current block. - The neighboring block is contained in a different tile than the current block. -sp_entropy_coding_sync_enabled_flag is equal to 1 and (xNbY>CtbLog2SizeY) is greater than or equal to (xCurr>CtbLog2SizeY)+1. - Otherwise, availableN is set to TRUE. If all of the following conditions are true, availableN is set to FALSE: -checkPredModeY equals TRUE. -availableN is set to TRUE. - CuPredMode[0][xNbY][yNbY] is not equal to CuPredMode[0][xCurr][yCurr].

[0085] 2.7. AMVR (Adaptive Motion Vector Resolution) In HEVC, if use_integer_mv_flag is 0 in the slice header, the MVD (Motion Vector Difference) (the difference between the motion vector and the predicted motion vector of the CU) is signaled in units of 1 / 4 luma samples. In VVC, a CU-level AMVR (Adaptive Motion Vector Resolution) scheme is introduced. AMVR allows the MVD of a CU to be coded with different precision. Based on the mode of the current CU (normal AMVP mode or affine AVMP mode or IBC mode), the MVD of the current CU can be adaptively selected as follows: -Normal AMVP mode: 1 / 4 luminance sample, 1 / 2 luminance sample, 1 luminance sample or 4 luminance samples -Affine AMVP modes: 1 / 4 luma sample, 1 luma sample, or 1 / 16 luma sample -IBC mode: 1 luminance sample or 1 / 4 luminance sample

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

[0087] For a CU coded with normal AMVP inter mode (non-IBC, non-affine) with at least one non-zero MVD component, a first flag (e.g., amvr_flag) is signaled 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, a second flag (e.g., the first bin of amvr_precision_idx) is signaled to indicate whether 1 / 2 luma sample or other MVD precision (1 luma sample or 4 luma sample) is used for normal AMVP CU. For 1 / 2 luma sample, a 6-tap interpolation filter is used for the 1 / 2 luma sample position instead of the default 8-tap interpolation filter. Otherwise, a third flag (e.g., the second bin of amvr_precision_idx) is signaled to indicate whether 1 luma sample or 4 luma sample MVD precision is used for normal AMVP_CU.

[0088] For CUs coded in affine AMVP mode, the second flag is used to indicate whether MVD precision of 1 luma sample or 1 / 16 luma sample is used. For CUs coded in IBC mode, the first flag is not signaled and is inferred to be equal to 1.

[0089] In the current design of AMVR, amvr_flag equal to 0 specifies that the resolution of the motion vector difference is ¼ of a luma sample. amvr_flag equal to 1 specifies that the resolution of the motion vector difference is further specified by amvr_precision_idx.

[0090] amvr_precision_idx specifies that the resolution of the motion vector difference with AmvrShift is defined in Table 2-3. Example Syntax Table for AMVR 7.3.10.5 Coding unit syntax

[0091] [Table 3]

[0092] [Table 4]

[0093] [Table 5]

[0094] [Table 6]

[0095] Specifically, the bin strings and context for coding the amvr_flag and amvr_precision_idx bin strings are defined as follows:

[0096] [Table 7]

[0097] [Table 8]

[0098] [Table 9]

[0099] [Table 10]

[0100] 7.4.11.5 Coding unit syntax amvr_precision_idx[x0][y0] specifies the resolution of the motion vector difference with AmvrShift defined in Table 2-3. The array index x0,y0 specifies the position (x0,y0) of the top-left luma sample of the considered coding block relative to the top-left luma sample of the picture. If amvr_precision_idx[x0][y0] is not present, it is inferred to be equal to 0.

[0101] Table 2-3 AmvrShift specifications

[0102] [Table 11]

[0103] 9.3.3 Binarization

[0104] Table 126 - Syntax elements and associated binarization

[0105] [Table 12]

[0106] [Table 13]

[0107] 9.3.2.2 Context Variable Initialization Process

[0108] Table 51 - Association between ctxIdx and syntax elements of each initializationType in the initialization process

[0109] [Table 14]

[0110] Table 88-amvr_flag ctxIdx initValue and shiftIdx specifications

[0111] [Table 15]

[0112] Table 89 - amvr_precision_idx ctxIdx initValue and shiftIdx specifications

[0113] [Table 16]

[0114] 9.3.4.2 Derivation process of ctxTable, ctxIdx, bypassFlag 9.3.4.2.1 General

[0115] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0116] [Table 17]

[0117] 2.8. Split information In VVC, a quad tree with nested multi-type trees using binary and ternary split segmentation structures replaces the concept of multiple split unit types, for example, it eliminates the separation of CU, PU, ​​and TU concepts, except when necessary for CUs with sizes that are too large for the maximum transform length, and supports more flexibility for CU split shapes. In the coding tree structure, a CU can have either a square or a rectangle. First, a coding tree unit (CTU) is split by a quad tree structure. Then, the leaf nodes of the quad tree can be further split by a multi-type tree structure. As shown in FIG. 10, there are four split types in the multi-type tree structure: vertical binary split (SPLIT_BT_VER), horizontal binary split (SPLIT_BT_HOR), vertical ternary split (SPLIT_TT_VER), and horizontal ternary split (SPLIT_TT_HOR). The leaf nodes of the multi-type tree are called CUs (Coding Units), and this segmentation is used for prediction and transformation processing without further division, unless the CU is too large to reach the maximum transform length. This means that in most cases, CUs, PUs, and TUs have the same block size in a quad-tree with a nested multi-type tree coding block structure. The exception occurs when the maximum supported transform length is smaller than the width or height of the color components of the CU.

[0118] FIG. 11 shows the signaling mechanism of split information in a quadtree with nested multitype tree coding trees. A Coding Tree Unit (CTU) is treated as the root of a quadtree and is first split by one quadtree structure. Leaf nodes of each quadtree (if large enough and therefore allowed) are then further split by a multitype tree structure. In the multitype tree structure, a first flag (mtt_split_cu_flag) is signaled to indicate whether the node is further split, and if the node is further split, a second flag (mtt_split_cu_vertical_flag) is signaled to indicate the split direction, and then a third flag (mtt_split_cu_binary_flag) is signaled to indicate whether the split is a binary split or a ternary split. Based on the values ​​of mtt_split_cu_vertical_flag and mtt_split_cu_binary_flag, a multitype tree slit mode (MttSplitMode) of the CU is derived as shown in Table 2-4.

[0119] Table 2-4 Derivation of MttSplitMode Based on Multitype Tree Syntax Elements

[0120] [Table 18]

[0121] mtt_split_cu_vertical_flag=0 specifies that the coding unit is split horizontally. mtt_split_cu_vertical_flag=1 specifies that the coding unit is split vertically. If mtt_split_cu_vertical_flag is not present, the following is inferred: 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. Otherwise, the value of mtt_split_cu_vertical_flag is inferred to be equal to 1.

[0122] Example syntax table for mtt_split_cu_vertical_flag 9.3.2.2 Context Variable Initialization Process

[0123] Table 51 - Association between ctxIdx and syntax elements of each initializationType in the initialization process

[0124] [Table 19]

[0125] Table 61 - ctxInc initValue and shiftIdx specifications for mtt_split_cu_vertical_flag

[0126] [Table 20]

[0127] 9.3.4.2 Derivation process of ctxTable, ctxIdx, bypassFlag 9.3.4.2.1 General

[0128] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0129] [Table 21]

[0130] 9.3.4.2.3 Derivation Process of ctxIncfor of Syntax Element mtt_split_cu_vertical_flag The inputs to this process are 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 and the width and height of the current coding block in luma samples, cbWidth, cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTVer, allowSplitTHor, allowSplitTHor, and allowSplit, derived in the coding tree semantics in Section 7.4.11.4.

[0131] The output of this operation is ctxInc. The position (xNbL, yNbL) is set equal to (x0-1, y0) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs the position (xCurr, yCurr) set equal to (x0, y0), the neighboring position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableL. The position (xNbA, yNbA) is set equal to (x0, y0-1) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs position (xCurr, yCurr) set equal to (x0, y0), neighboring position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableA.

[0132] The allocation of ctxInc is specified as follows: -If allowSplitBtVer+allowSplitBtHor is greater than allowSplitTVer+allowSplitTTHor, ctxInc is set to 4. - Otherwise, if allowSplitBtVer+allowSplitBtHor is less than allowSplitTVer+allowSplitTTHor, then ctxInc is set equal to 4. - Otherwise the following applies: The variables dA and dL are derived as follows: dA=cbWidth / (availableA?CbWidth[chType][xNbA][yNbA]:1) (1563) dL=cbHeight / (availableL?CbHeight[chType][xNbL][yNbL]:1) (1564) - ctxInc is set equal to 0 if any of the following conditions are true: -dA is equal to dL, -availableA is FALSE -availableL is FALSE - Otherwise, if dA is less than dL, then ctxInc is set equal to 1. Otherwise, ctxInc is set equal to 0.

[0133] 2.9. Coefficient Coding in Transform Skip Mode In the current VVC draft, some modifications are proposed for coefficient coding in Transform Skip (TS) mode compared to non-TS coefficient coding in order to adapt the residual coding to the statistics and signal characteristics of the transform skip level.

[0134] 7.3.10.11 Residual Coding Syntax

[0135] [Table 22]

[0136] [Table 23]

[0137] [Table 24]

[0138] [Table 25]

[0139] [Table 26]

[0140] [Table 27]

[0141] [Table 28]

[0142] [Table 29]

[0143] 2.9.1. Context modeling of sign flag coeff_sign_flag and context index offset derivation

[0144] Table 51 - Association between ctxIdx and syntax elements of each initializationType in the initialization process

[0145] [Table 30]

[0146] Table 125 - ctxInc initValue and shiftIdx specifications for coeff_sign_flag

[0147] [Table 31]

[0148] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0149] [Table 32]

[0150] 9.3.4.2.10 Derivation Process of ctxInc for Syntax Element coeff_sign_flag for Transform Skip Mode The inputs to this process are the color component index cIdx, the luma position (x0,y0) that defines 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). The output of this process is the variable ctxInc. The variables leftSign and aboveSign are derived as follows: leftSign=(xC==0)?0:CoeffSignLevel[xC-1][yC] (1595) aboveSign=(yC==0)?0:CoeffSignLevel[xC][yC-1] (1596) The variable ctxInc is derived as follows. If -leftSign is equal to 0 and aboveSign is equal to 0 or leftSign is equal to -aboveSign, the following applies: ctxInc=(BdpcmFlag[x0][y0][cIdx]==0?0:3) (1597) - Else, if leftSign is greater than or equal to 0 and aboveSign is greater than or equal to 0, then the following applies: ctxInc=(BdpcmFlag[x0][y0][cIdx]?1:4) (1598) - Otherwise the following applies: ctxInc=(BdpcmFlag[x0][y0][cIdx]?2:5) (1599)

[0151] 3. Technical Problems Solved by the Disclosed Technical Solutions and Embodiments The current design of the context derivation process for AMVR fine index and split CU vertical flag has the following problems. 1. The context modeling of syntax elements that specify splitting a block horizontally or vertically (e.g., mtt_split_cu_vertical_flag) depends on the relationship between "allowSplitBtVer+allowSplitBtHor" and "allowSplitTVer+allowSplitTHor". However, note that there is a greater correlation between split information and allowing BT / TT vertical than there is with allowing BT / TT horizontal. 2. In current VVC, the first bin of the AMVR precision index (e.g., amvr_precision_idx) is context coded with one context, without considering whether the block is coded in IBC mode, affine mode, or normal inter mode (non-IBC, non-affine). Coding the AMVR precision index may not be very efficient. Also, the second bin of amvr_precision_idx, which is coded for a block with normal inter mode, uses a separate context from the context used for the first bin of amvr_precision_idx. Multiple contexts used to code a syntax element may not be optimal if the syntax element is coded infrequently. 3. Although coefficient coding can realize the coding advantages in coding screen content, coefficient coding and TS mode may still have some shortcomings. a. It is unclear in this case whether to use bypass coding or context coding for the sign flag. i. The number of remaining allowed context-coded bins (denoted by RemCcbs) is equal to 0. ii. The current block is coded in TS mode. iii.slice_ts_residual_coding_disabled_flag is false.

[0152] 4. List of technical solutions and embodiments The following items should be considered as examples to illustrate the general concepts. These items should not be interpreted in a narrow sense. Moreover, these items can be combined in any way.

[0153] In this disclosure, the term AMVR refers to a coding tool that uses adaptive motion vector differential resolution for MV (Motion Vector) / MVD (MV Difference) coding or MVP (MV Predictor). The present invention is not limited to the AMVR and block partitioning techniques described in VVC.

[0154] amvr_precision_idx represents a syntax element that specifies the index (or index) of the differential resolution of the allowed motion vectors. In one example, it may be amvr_precision_idx defined in the VVC text. Note that amvr_precision_idx may be binarized to a string of bins, which may contain one or more bins.

[0155] mtt_split_cu_vertical_flag represents a syntax element that specifies whether to split a coding block vertically. In one example, it may be mtt_split_cu_vertical_flag defined in the VVC text.

[0156] Deriving the context of amvr_precision_idx 1. The context modeling (e.g., how to select the context) for the first bin (bin index equal to 0) of a Syntax Element (SE) indicating the use of AMVR and / or other bins of the bin string (e.g., amvr_precision_idx and / or amvr_flag) may depend on the coded information (e.g., coded mode) of the current block and / or neighboring blocks. a. In one example, the coded information may comprise at least one of IBC, affine AMVR, and normal inter (e.g., non-IBC, non-affine) modes, bi-prediction and / or uni-prediction, block dimensions of the current block and / or block dimensions of neighboring blocks, and may utilize different contexts for coding a bin (e.g., the first bin) based on the coded information. i. Alternatively, one bin (eg, the first bin) of an IBC coded block is coded with a single context, denoted by CtxM. ii. Alternatively, one bin (eg, the first bin) of the SE for the affine coded block is coded with a single context, represented by CtxN. iii. Alternatively or additionally, one bin (e.g., the first bin) of the SE for a regular inter (e.g., non-affine and non-IBC) coded block is coded with a single context represented by CtxP. iv. Alternatively, at least one of the three contexts CtxM, CtxN, and CtxP is different from the other two contexts. v. Alternatively, the three contexts CtxM, CtxN, and CtxP are different from each other. vi. For example, one bin (e.g., the first bin) of an SE is coded in a single context, denoted by CtxBi, in the case of a bi-predictive block, and in the case of a uni-predictive coded block, denoted by CtxUni. 1) In one example, CtxBi is different from CtxUni.

[0157] b. In one example, two or more contexts may be utilized to code the first bin and / or other bins of a bin string of an SE. i. In one example, X contexts may be utilized for the first bin, where X>1. 1) In one example, X=3. a) Alternatively or additionally, the choice of context depends on the coded information (eg the mode as mentioned above). 2) In one example, X=2. a) Alternatively or additionally, the choice of context may depend on the coded information (e.g., the mode mentioned above) and one context for IBC coding blocks and another context for other blocks (e.g., affine or regular inter coding). b) Alternatively, the choice of context depends on the coded information (e.g., the modes mentioned above), one context for IBC and affine AMVR coded blocks and one context for other blocks (e.g., regular inter-coding). c. In one example, based on the coded information (e.g., coding mode), different models for the first bin (bin index equal to 0) and / or other bins of the bin string of the SE may be initialized with different initialization values. d. In one example, based on the coded information (e.g., coding mode), different models of the first bin (bin index equal to 0) and / or other bins of the bin string of the SE may be initialized with the same initialization value.

[0158] 2. Instead of using different contexts for the first and second bins of the amvr_precision_idx bin string, it is proposed that the context used for coding the second bin may be the same as one or more of the contexts used for coding the first bin of the bin string. Alternatively, the second bin of the string of bins is coded only for regular inter (eg, non-affine and non-IBC) coding blocks. b. Alternatively, the second bin of the bin string is coded with a single context, represented by CtxQ. c. Alternatively, the same context may be used to code the first bin of amvr_precision_idx for an IBC coded block and the second bin of amvr_precision_idx for a regular inter-coded block. d. Alternatively, the same context may be used to code the first bin of amvr_precision_idx for an affine coded block and the second bin of amvr_precision_idx for a regular inter coded block. e. Alternatively, the same context may be used to code the first bin of amvr_precision_idx for a normal inter-coded block and the second bin of amvr_precision_idx for a normal inter-coded block.

[0159] 3. The same context may be used to code the first bin of amvr_precision_idx for an IBC coded block (denoted as CtxM) and the second bin of amvr_precision_idx for a normal inter coded block (denoted as CtxQ), such that CtxM=CtxQ. In one example, the X1 (eg, X1=3) context may be used to code amvr_precision_idx. b. Alternatively, for non-IBC coded blocks, a different context may be used to code the first bin of the amvr_precision_idx bin string.

[0160] 4. The same context may be used for coding the first bin of amvr_precision_idx for IBC coded blocks, the first bin of amvr_precision_idx for affine coded blocks, and the first bin of amvr_precision_idx for normal inter coding, such that CtxM=CtxN=CtxP. In one example, the X2 (eg, X2=2) context may be utilized to code amvr_precision_idx. b. Alternatively or additionally, for non-IBC and non-affine coded blocks, a different context for coding the first bin of the amvr_precision_idx bin string may be utilized.

[0161] 5. The same context may be used for coding the first bin of amvr_precision_idx for IBC coded blocks and the first bin of amvr_precision_idx for normal inter coded blocks, such that CtxM=CtxP. In one example, the X3 (eg, X3=3) context may be utilized to code amvr_precision_idx. b. Alternatively, for non-IBC and non-normal inter-coded blocks (e.g., coded with affine AMVR), a different context for coding the first bin of the amvr_precision_idx bin string may be utilized. c. Alternatively or additionally, a different context for coding the second bin of the amvr_precision_idx bin string may be utilized.

[0162] 6. The same context may be used for coding the first bin of amvr_precision_idx for IBC coded blocks and the first bin of amvr_precision_idx for affine coded blocks, such that CtxM=CtxN. 7. For IBC coded, affine coded and normal coded blocks, the same context may be used to code all bins of amvr_precision_idx. In one example, a single context may be utilized to code amvr_precision_idx.

[0163] 8. Multiple contexts may be used to code the first bin of amvr_precision_idx for IBC coded blocks, affine coded blocks, and regular inter coded blocks, and a single context may be used to code a second bin different from the one used to code the first bin. In one example, an X4 (eg, X4=4) context may be utilized to code amvr_precision_idx. b. For example, CtxM != CtxQ != CtxN != CtxP.

[0164] 9. It is proposed that at least one context used for coding amvr_precision_idx may be the same as the context used for coding amvr_flag. a. The same context as for coding the AMVR flag (e.g., amvr_flag) of an affine coded block may be used for the first bin of amvr_precision_idx for an IBC coded block, or / and the first bin of amvr_precision_idx for an affine coded block, or / and the first bin of amvr_precision_idx for a normal inter coded block, or / and the second bin of amvr_precision_idx for a normal inter coded block. b. The same context as for coding the AMVR flag (e.g., amvr_flag) of a non-affine coded block may be used for the first bin of amvr_precision_idx for an IBC coded block, or / and the first bin of amvr_precision_idx for an affine coded block, or / and the first bin of amvr_precision_idx for a normal inter coded block, or / and the second bin of amvr_precision_idx for a normal inter coded block. The context modeling of the first bin of c.amvr_precision_idx depends on whether affine mode is applied for the block. i. Alternatively or additionally, one context is used to code the first bin of an affine coded block, and the other context is used for non-affine coded blocks (e.g., including regular inter coded blocks and IBC coded blocks). ii. Alternatively or further, a first context is used for coding the first bin of an affine coded block, and a second context is used for non-affine coded blocks (e.g., including normal inter-coded blocks and IBC coded blocks). The first context is the same as the context used for coding the amvr_flag of the affine coded block, and the second context is the same as the context used for coding the amvr_flag of the non-affine coded block.

[0165] Context derivation of mtt_split_cu_vertical_flag Variables allowSplitBtVer, allowSplitBtHor, allowSplitT t Ver,allowSplitT t Ver,allowSplitT t Let Hor indicate whether vertical BT splitting, horizontal BT splitting, vertical TT splitting, and horizontal TT splitting are allowed for the current coding tree node, respectively. t Ver,allowSplitT t The value of Hor may be equal to 0 or 1, which are derived in Section 2.6. Let curW, curH, leftW, leftH, aboveW, and aboveH denote the width of the current block, the height of the current block, the width of the left neighbor block, the height of the left neighbor block, the width of the top neighbor block, and the height of the top neighbor block, respectively. Let "numV" be a value equal to the sum of allowSplitBtVer and allowSplitTtVer, and "numH" be the value equal to the sum of allowSplitBtHor and allowSplitTtHor. t The value is equal to the sum of Hor.

[0166] 10. Context modeling for SE (e.g., mtt_split_cu_vertical_flag) indicating block splitting information may depend on the number allowing vertical splitting (e.g., BT and TT) and the number allowing horizontal splitting (e.g., BT and TT). a. In one example, when vertical splitting is often allowed compared to horizontal splitting (e.g., numV>numH), a first set of contexts is used. b. In one example, when vertical splitting is allowed less often than horizontal splitting (e.g., numV<numH), a second set of contexts is used. c. In one example, when the cases where vertical splitting is allowed are the same as compared to horizontal splitting (e.g., numV=numH), a third set of contexts is used. d. Alternatively, furthermore, the contexts in the first / second / third sets are not all the same. e. Alternatively, furthermore, at least one of the contexts in the first / second / third sets is the same as the context included in another set. f. Alternatively, furthermore, the number of contexts in each of the three sets may depend on the set index. i. In one example, only one context is included in the first and / or second sets. ii. In one example, a plurality of contexts are included in the third set. 1) Alternatively, the selection of contexts from the third set may further depend on the availability of blocks in the upper and left neighborhoods, and / or the block dimensions of the current block and the block dimensions of the neighboring blocks. g. One example is shown in Embodiment #4 of Chapter 5.4. h. One example is shown in Embodiment #5 of Chapter 5.5.

[0167] 11. An SE indicating whether to split a block vertically (e.g., mtt_split_cu_vertical_flag) is coded in N contexts, which may depend on whether BT / TT splitting is allowed or / and the width / height of the current block or / and the width / height of neighboring blocks. i. In one example, which context is used to code the SE may depend on numV and numH. i. For example, it depends on whether numV is greater than numH. ii. For example, it depends on whether numV is less than numH. iii. For example, whether numV is equal to numH depends on the average.

[0168] j. In one example, the bin string of the SE may be context coded with N contexts based on whether BT / TT splitting is allowed. i. In one example, an SE is coded in the context represented by CtxA if numV is greater than numH. ii. In one example, SE is coded in the context represented by CtxB if numV is less than numH. iii. In one example, SE is coded in the context represented by CtxC if numV is equal to numH. iv. In one example, CtxA is equal to CtxB and CtxB is equal to CtxC (e.g., CtxA=CtxB=CtxC), e.g., CtxA=CtxB=CtxC=0. v. In one example, CtxA != CtxB != CtxC, e.g., CtxA=0, CtxB=1, CtxC=2.

[0169] k. In one example, the string of bins of the SE may be context coded with N contexts based on the width / height of the current block and / or the width / height of neighboring blocks. i. In one example, a neighboring block may refer to an upper neighboring block or / and a left neighboring block. ii. In one example, the SE is coded with N contexts, which may depend on a function of the width or height of the current block and / or the width or height of neighboring blocks. Let dA=curW / aboveW and dL=curH / leftH. 1) In one example, SE is coded in the context represented by CtxD if either the left neighboring block or the above neighboring block is unavailable or if dA is equal to dL. 2) In one example, SE is coded in the context represented by CtxE if dA is less than dL. 3) In one example, SE is coded in the context represented by CtxF if dA is greater than dL.

[0170] l. In one example, the string of bins in the SE may be context coded with N contexts based on whether BT / TT splitting is allowed and / or the width / height of the current block and / or the width / height of neighboring blocks. i. In one example, an SE is coded in the context represented by CtxA if numV is greater than numH. ii. In one example, SE is coded in the context represented by CtxB if numV is less than numH. iii. In one example, SE is coded in the context indicated by CtxC if numV is equal to numH (either the left neighbor or the above neighbor is unavailable or dA is equal to dL). iv. In one example, SE is coded in the context represented by CtxE if numV is equal to numH and dA is less than dL. v. In one example, SE is coded in the context represented by CtxF if numV is equal to numH and dA is greater than dL. In one example, N=5, CtxA!=CtxB!=CtxC!=CtxE!=CtxF.

[0171] m. In one example, the string of bins of the SE may be context coded with N contexts based on whether the current block is on a picture boundary. In one example, the string of bins in the SE may be context coded with N contexts based on whether the dual tree and / or the local dual tree is applied. o. In one example, the string of bins of an SE may be context coded with N contexts based on the color components of the samples it is split into. p. In one example, the string of bins in the SE may be context coded with N contexts based on the width / height of the current block. i. In one example, the context augmentation measure may be set as a function of the width or height of the block.

[0172] 12. The split CU vertical flag (eg, mtt_split_cu_vertical_flag) may be coded in a single context.

[0173] Method for using bypass coding or context coding for coefficient sign flag

[0174] 13. Whether to use context coding or bypass coding for the sign of the transform coefficient levels (e.g., syntax element coeff_sign_flag) depends on the number of remaining allowed context coded bins (e.g., RemCcbs) and / or the type of transform used for the current block (e.g., DCT2, DST7, or transform skip). In one example, in the process of transform skip residual coding, if RemCcbs is greater than T1 (eg, T1=0), context coding may be used for coeff_sign_flag. i. Also, in the transform skip residual coding procedure, if RemCcbs is equal to T1 (eg, T1=0), bypass coding may be used for coeff_sign_flag. b. In one example, in the process of transform skip residual coding, if RemCcbs is equal to or greater than T2 (eg, T2=3), context coding may be used for coeff_sign_flag. i. Also, in the process of transform skip residual coding, if RemCcbs is less than T2 (eg, T2=3), bypass coding may be used for coeff_sign_flag.

[0175] 14. At the start of bypass coding for the remaining syntax elements (e.g., syntax elements abs_remainder and coeff_sign_flag) in the third / remainder coefficient scanning pass of the transform skip residual coding process, one operation may be applied to a variable that specifies the number of remaining allowed context coded bins (e.g., RemCcbs). c. In one example, this action may set RemCcbs equal to a value (eg, 0). d. In some embodiments, the action may be to set RemCcbs equal to a value based on at least one variable or syntax element other than RemCcbs. i. In one example, this action may set RemCcbs equal to RemCcbs minus one.

[0176] 15. One example is shown in embodiment #7 in section 5.7. 16. One example is shown in embodiment #8 in section 5.8.

[0177] 17. Whether a transform coefficient level (e.g., coeff_sign_flag) is coded in bypass mode or in context coding mode may depend on the number of remaining allowed context coded bins (e.g., RemCcbs). e. If the number of remaining allowed context coded bins (eg, RemCcbs) is less than N, it is suggested to code the sign of the transform coefficient levels (eg, coeff_sign_flag) in bypass mode. f. In one example, the sign flag is coded in bypass mode if RemCcbs<=N. i. Alternatively, in one example, if RemCcbs>N, the sign flag is coded in context mode. g. In one example, if RemCcbs is equal to N, the sign flag is coded in bypass mode. i. Alternatively, in one example, if RemCcbs>N, the sign flag is coded in bypass mode. ii. In one example, N may be set equal to 4. 1) Alternatively, in one example, N may be set equal to 0. iii. In one example, RemCcbs may be modified to X, where X is equal to N, before decoding the absolute values ​​of the remaining transform coefficient levels.

[0178] h. In one example, if RemCcbs is less than N, the sign flag is coded in bypass mode. i. Alternatively, in one example, if RemCcbs>=N, the sign flag is coded in context mode. ii. In one example, N may be set equal to 3. iii. In one example, RemCcbs may be modified to X, where X is less than N, before decoding the absolute values ​​of the remaining transform coefficient levels. i. In one example, N is an integer and may be based on the following: i. Indications signalled in SPS / VPS / PPS / Picture Header / Slice Header / Tile Group Header / LCU Row / Group of LCU / LCU / CU ii. Block dimensions of the current block and / or its neighboring blocks iii. The block shape of the current block and / or its neighboring blocks iv. Display color format (e.g. 4:2:0, 4:4:4) v. Whether a separate or dual coding tree structure is used vi. Slice type and / or picture type vii. Number of color components

[0179] j. The coding context (eg, coeff_sign_flag) used to code a transform coefficient level may depend on the number of remaining allowed context-coded bins (eg, RemCcbs). k. The above examples may apply to transform blocks and / or transform skip blocks, with or without BDPCM coded blocks.

[0180] General

[0181] 18. Whether and / or how to apply the above disclosed methods may be signaled at the sequence level / picture level / slice level / tile group level, for example in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / tile group header. 19. Whether and / or how to apply the above disclosed methods may depend on the coded information, such as color format, single / dual tree split, etc.

[0182] 5. Embodiments Below are some example embodiments for some of the inventive aspects summarized in Section 4 above, which are applicable to the VVC specification. Bold Italics In the above, the most relevant parts that have been added or modified are underlined, and some of the parts that have been deleted are indicated using [[]].

[0183] 5.1. First embodiment 9.3.2.2 Context Variable Initialization Process

[0184] Table 51 - Association between ctxIdx and syntax elements of each initializationType in the initialization process

[0185] [Table 33]

[0186] Table 89 - amvr_precision_idx ctxIdx initValue and shiftIdx specifications

[0187] [Table 34]

[0188] 9.3.4.2 Derivation process of ctxTable, ctxIdx, bypassFlag 9.3.4.2.1 General

[0189] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0190] [Table 35]

[0191] [ka]

[0192] [Table 36]

[0193] In the above example, X!=Y, X!=Z, Y!=Z. Alternatively, the following also applies: 1) In one example, W is equal to X. 2) Alternatively, W is equal to Y. 3) Alternatively, W is equal to Z.

[0194] 5.2. Embodiment 2 9.3.2.2 Context Variable Initialization Process

[0195] Table 51 - Association between ctxIdx and syntax elements of each initializationType in the initialization process

[0196] [Table 37]

[0197] Table 89 - amvr_precision_idx ctxIdx initValue and shiftIdx specifications

[0198] [Table 38]

[0199] 9.3.4.2 Derivation process of ctxTable, ctxIdx, bypassFlag 9.3.4.2.1 General

[0200] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0201] [Table 39]

[0202] [ka]

[0203] 5.3. Third embodiment 9.3.2.2 Context Variable Initialization Process

[0204] Table 51 - Association between ctxIdx and syntax elements of each initializationType in the initialization process

[0205] [Table 40]

[0206] Table 89 - amvr_precision_idx ctxIdx initValue and shiftIdx specifications

[0207] [Table 41]

[0208] 9.3.4.2 Derivation process of ctxTable, ctxIdx, bypassFlag 9.3.4.2.1 General

[0209] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0210] [Table 42]

[0211] 5.4. Embodiment 4 The working draft may be amended as follows: 9.3.4.2.3 Derivation Process of ctxIncfor of Syntax Element mtt_split_cu_vertical_flag The inputs to this process are 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 and the width and height of the current coding block in luma samples, cbWidth, cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTVer, allowSplitTHor, allowSplitTHor, and allowSplit, derived in the coding tree semantics in Section 7.4.11.4.

[0212] The output of this operation is ctxInc. The position (xNbL, yNbL) is set equal to (x0-1, y0) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs the position (xCurr, yCurr) set equal to (x0, y0), the neighboring position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableL. The position (xNbA, yNbA) is set equal to (x0, y0-1) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs position (xCurr, yCurr) set equal to (x0, y0), neighboring position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableA.

[0213] [ka]

[0214] 5.5. Embodiment 5 The working draft may be amended as follows: 9.3.4.2.3 Derivation Process of ctxIncfor of Syntax Element mtt_split_cu_vertical_flag The inputs to this process are 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 and the width and height of the current coding block in luma samples, cbWidth, cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTVer, allowSplitTHor, allowSplitTHor, and allowSplit, derived in the coding tree semantics in Section 7.4.11.4. The output of this operation is ctxInc. The position (xNbL, yNbL) is set equal to (x0-1, y0) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs the position (xCurr, yCurr) set equal to (x0, y0), the neighboring position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableL. The position (xNbA, yNbA) is set equal to (x0, y0-1) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs position (xCurr, yCurr) set equal to (x0, y0), neighboring position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableA.

[0215] [ka]

[0216] 5.6. Embodiment 6 The working draft may be amended as follows: 9.3.2.2 Context Variable Initialization Process

[0217] Table 51 - Association of ctxIdx and syntax elements for each initializatioType in the initialization process

[0218] [Table 43]

[0219] Table 61 - ctxInc initValue and shiftIdx specifications for mtt_split_cu_vertical_flag

[0220] [Table 44]

[0221] 9.3.4.2 Derivation process of ctxTable, ctxIdx, bypassFlag 9.3.4.2.1 General

[0222] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0223] [Table 45]

[0224] [[9.3.4.2.3 Derivation process of ctxIncfor of syntax element mtt_split_cu_vertical_flag The inputs to this process are 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 and the width and height of the current coding block in luma samples, cbWidth, cbHeight, and the variables allowSplitBtVer, allowSplitBtHor, allowSplitTVer, allowSplitTHor, allowSplitTHor, and allowSplit, derived in the coding tree semantics in Section 7.4.11.4. The output of this operation is ctxInc. The position (xNbL, yNbL) is set equal to (x0-1, y0) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs the position (xCurr, yCurr) set equal to (x0, y0), the neighboring position (xNbY, yNbY) set equal to (xNbL, yNbL), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableL. The position (xNbA, yNbA) is set equal to (x0, y0-1) and the neighboring block availability derivation process specified in Section 6.4.4 is performed with inputs position (xCurr, yCurr) set equal to (x0, y0), neighboring position (xNbY, yNbY) set equal to (xNbA, yNbA), checkPredModeY set to FALSE, and cIdx, and the output is assigned to availableA.

[0225] The allocation of ctxInc is specified as follows: -If allowSplitBtVer+allowSplitBtHor is greater than allowSplitTVer+allowSplitTTHor, ctxInc is set to 4. - Otherwise, if allowSplitBtVer+allowSplitBtHor is less than allowSplitTVer+allowSplitTTHor, then ctxInc is set equal to 4. - Otherwise the following applies: The variables dA and dL are derived as follows: dA=cbWidth / (availableA?CbWidth[chType][xNbA][yNbA]:1) (1563) dL=cbHeight / (availableL?CbHeight[chType][xNbL][yNbL]:1) (1564) - ctxInc is set equal to 0 if any of the following conditions are true: -dA is equal to dL, -availableA is FALSE, -availableL is FALSE. - Otherwise, if dA is less than dL, then ctxInc is set equal to 1. Otherwise, ctxInc is set equal to 0.

[0226] 5.7. Seventh embodiment The working draft may be amended as follows: 7.3.10.11 Residual Coding Syntax

[0227] [Table 46]

[0228] [Table 47]

[0229] [Table 48]

[0230] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0231] [Table 49]

[0232] 5.8. Embodiment 8 The working draft may be amended as follows: 7.3.10.11 Residual Coding Syntax

[0233] [Table 50]

[0234] [Table 51]

[0235] [Table 52]

[0236] Table 131 - Allocation of ctxInc to syntax elements with context-coded bins

[0237] [Table 53]

[0238] FIG. 12 is a block diagram illustrating an example video processing system 1200 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of 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 Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

[0239] System 1200 may include a coding component 1204 that may implement various coding or encoding methods described herein. Coding component 1204 may reduce the average bit rate of the video from input 1202 to the output of coding component 1204, generating a coded representation of the video. Thus, this coding technique may be referred to as a video compression or video transcoding technique. The output of coding component 1204 may be stored or transmitted via a connected communication, as represented by component 1206. The bitstream (or coded) representation of the video received at input 1202, stored or communicated, may be used by component 1208 to generate pixel values ​​or displayable video that are transmitted to display interface 1210. The process of generating a user-viewable video from the bitstream representation may be referred to as video decompression. Additionally, although certain video processing operations are referred to as "coding" operations or tools, it will be understood that the coding tools or operations are performed by an encoder and corresponding decoding tools or operations that reverse the results of the coding, performed by a decoder.

[0240] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Buses (USBs) or High Definition Multimedia Interfaces (HDMIs), or display ports, etc. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), PCI, IDE interfaces, etc. The techniques described herein may be implemented in various electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of digital data processing and / or video display.

[0241] FIG. 13 is a block diagram of a video processing device 3600. The device 3600 may be used to implement one or more of the methods described herein. The device 3600 may be implemented in a smartphone, tablet, computer, Internet of Things (IoT) receiver, etc. The device 3600 may include one or more processors 3602, one or more memories 3604, and video processing hardware 3606. The one or more processors 3602 may be configured to implement one or more methods described herein. The one or more memories 3604 may be used to store data and codes used to implement the methods and techniques described herein. The video processing hardware 3606 may be used to implement the techniques described herein in a hardware circuit.

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

[0243] 15, video coding system 100 may include source device 110 and destination device 120. Source device 110 generates coded video data and may also be referred to as a video coding device. Destination device 120 may decode the encoded video data generated by source device 110 and may also be referred to as a video decoding device.

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

[0245] 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 for generating 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 and generates a bitstream. The bitstream may include a sequence of bits that form a coded representation of the video data. The bitstream may include a coded picture and associated data. A coded picture is a coded representation of a picture. The associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. The I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. The coded video data may be transmitted directly to the destination device 120 via the I / O interface 116 over the network 130a. The coded video data may be stored on a recording medium / server 130b for access by the destination device 120.

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

[0247] 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.

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

[0249] FIG. 16 is a block diagram illustrating an example of a video encoder 200, which may be the video encoder 114 in the system 100 shown in FIG.

[0250] Video encoder 200 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 16, video encoder 200 comprises multiple functional components. Techniques described in this disclosure may be shared among various components of video encoder 200. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.

[0251] The functional components of the video encoder 200 may include a splitting unit 201, a prediction unit 202, a residual generation unit 207, a transformation unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transformation unit 211, a reconstruction unit 212, a buffer 213, and an entropy coding unit 214, and the prediction unit 202 includes a mode selection unit 203, a motion estimation unit 204, a motion compensation unit 205, and an intra prediction unit 206.

[0252] In other examples, video encoder 200 may include more, fewer, or different functional components. In one example, prediction unit 202 may include an Intra Block Copy (IBC) unit. The IBC unit may perform prediction in an IBC mode in which at least one reference picture is the picture in which the current video block is located.

[0253] Furthermore, some components, such as the motion estimator 204 and the motion compensator 205, may be highly integrated, but are depicted separately in the example of FIG. 16 for purposes of illustration.

[0254] The divider 201 may divide a picture into one or more video blocks. The video encoder 200 and the video decoder 300 may support a variety of video block sizes.

[0255] The mode selection unit 203 may, for example, select one of intra or inter coding modes based on the error result, and provide the resulting intra or inter coded block to the residual generation unit 207 for generating residual block data, and to the reconstruction unit 212 for reconstructing the coded 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 that performs prediction based on an inter prediction signal and an intra prediction signal. The mode selection unit 203 may select a resolution of the motion vector for the block (e.g., sub-pixel or integer pixel precision) in the case of inter prediction.

[0256] To perform inter prediction on the current video block, motion estimation unit 204 may generate motion information for the current video block by comparing the current video block to one or more reference frames from buffer 213. Motion compensation unit 205 may determine a prediction video block for the current video block based on the motion information and decoded samples of pictures from buffer 213 other than the picture associated with the current video block.

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

[0258] In some examples, the motion estimation unit 204 may perform unidirectional prediction on the current video block, and the motion estimation unit 204 may search for a reference picture in list 0 or list 1 for a reference video block for the current video block. The motion estimation unit 204 may then generate a reference index indicating a reference picture in list 0 or list 1, the reference picture including the reference video block 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 for the current video block. The motion compensation unit 205 may generate a prediction video block for the current block based on the reference video block indicated by the motion information of the current video block.

[0259] In another example, motion estimation unit 204 may bidirectionally predict the current video block, and motion estimation unit 204 may search for reference pictures from list 0 for a reference video block for the current video block, and may also search for reference pictures in list 1 for another reference video block for the current video block. Motion estimation unit 204 may then generate reference indices indicating reference pictures in lists 0 and 1 that contain the reference video blocks, and motion vectors indicating spatial displacements between the reference video blocks and the current video block. Motion estimation unit 204 may output the reference index and the motion vector for the current video block as motion information for the current video block. Motion compensation unit 205 may generate a predicted video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[0260] In some examples, the motion estimation unit 204 may output a full set of motion information for the decoding process of the decoder.

[0261] In some examples, the motion estimator 204 may not output a full set of motion information for the current picture. Rather, the motion estimator 204 may signal the motion information of the current video block by reference to motion information of another video block. For example, the motion estimator 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of a neighboring video block.

[0262] In one example, motion estimator 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.

[0263] In another example, 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 a difference between the motion vector of the current video block and the motion vector of the indicated video block. 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.

[0264] As mentioned above, video encoder 200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by video encoder 200 include Advanced Motion Vector Prediction (AMVP) and merge mode signaling.

[0265] The intra predictor 206 may perform intra prediction on the current video block. When the intra predictor 206 performs intra prediction on the current video block, the intra predictor 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.

[0266] Residual generator 207 may generate residual data for the current video block by subtracting (e.g., as indicated by a minus sign) the predicted video block of the current video block from the current video block. The residual data for the current video block may include residual video blocks that correspond to different sample components of the samples in the current video block.

[0267] In other examples, for example in skip mode, there may be no residual data for the current video block, and residual generator 207 may not perform the subtraction operation.

[0268] Transform processor 208 may generate one or more transform coefficient image blocks for the current video block by applying one or more transforms to a residual video block associated with the current video block.

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

[0270] The inverse quantization unit 210 and the inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient image block to reconstruct a residual video block from the transform coefficient image block. The reconstruction unit 212 may add the reconstructed residual video block to samples corresponding to 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.

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

[0272] The entropy encoder 214 may receive data from other functional components of the video encoder 200. If the entropy encoder 214 receives data, the entropy encoder 214 may perform one or more entropy encoding operations to generate entropy coded data, and output a bitstream that includes the entropy coded data.

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

[0274] The video decoder 300 may be configured to perform any or all of the techniques of this disclosure. In the example of FIG. 17, the video decoder 300 comprises multiple functional components. The techniques described in this disclosure may be shared among various components of the video decoder 300. In some examples, a processor may be configured to perform any or all of the techniques described in this disclosure.

[0275] In the example of Figure 17, the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, and a reconstruction unit 306, as well as a buffer 307. The video decoder 300 may, in some examples, perform a decoding path that is generally the reverse of the encoding path described with respect to the video encoder 200 (Figure 16).

[0276] The entropy decoder 301 retrieves an encoded bitstream. The encoded bitstream may include entropy coded video data (e.g., coded blocks of video data). The entropy decoder 301 decodes the entropy coded video data, and from 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 by performing, for example, AMVP and merge mode.

[0277] The motion compensation unit 302 may generate motion compensated blocks, possibly performing the interpolation based on an interpolation filter. The syntax element may include an identifier for the interpolation filter to be used with sub-pixel accuracy.

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

[0279] The motion compensation unit 302 may use the syntax information to determine the size of the blocks used to encode the frames and / or slices of the encoded video sequence, partitioning information describing how each macroblock of a picture of the encoded video sequence is partitioned, a mode indicating how each partition is encoded, one or more reference frames (and reference frame lists) for each inter-encoded block, and any of the other information to decode the encoded video sequence.

[0280] The intra prediction unit 303 may form a prediction block from spatially neighboring blocks, for example using an intra prediction mode received in the bitstream. The inverse quantization unit 303 inverse quantizes (e.g., dequantizes) the 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.

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

[0282] Next, preferred solutions are listed in some embodiments.

[0283] The following solutions represent exemplary implementations of the techniques discussed in the previous section (eg, item 1).

[0284] 1. A video processing method (e.g., method 1400 shown in FIG. 14) includes performing a conversion between a video block of a video and a coded representation of the video, where the coded representation complies with a format rule, the conversion being based on an AMVR (Adaptive Motion Vector difference Resolution) tool in which a representation of a motion vector or a motion vector differential or a motion vector predictor for the video block is represented in the coded representation using an adaptive resolution, and the format rule specifies the representation of the use of adaptive resolution in the coded representation by context modeling that depends on coded information of the video block or blocks neighboring the video block.

[0285] 2. The method according to solution 1, wherein the coded information uses an intra-block copy mode.

[0286] 3. The method according to solution 1, wherein the coded information includes the use of affine AMVR mode or non-affine and non-intra block copy modes, bi-predictive or uni-predictive modes.

[0287] 4. The method according to any of solutions 1 to 3, wherein the coded information includes dimensions of the video block.

[0288] The following solutions represent exemplary implementations of the techniques discussed in the previous section (eg, item 2).

[0289] 5. A method of video processing includes performing a conversion between a video block of a video and a coded representation of the video, wherein the coded representation complies with a format rule, and the conversion is performed based on an Adaptive Motion Vector difference Resolution (AMVR) tool in which a representation of a motion vector or a motion vector differential or a motion vector predictor for the video block is represented in the coded representation using adaptive resolution, and the format rule specifies how to express the use of adaptive resolution in the coded representation by context modeling used to code a first bin and a second bin for an index of precision used by the AMVR tool.

[0290] 6. The method according to solution 5, wherein the formatting rules stipulate to use a first bin and a second bin is coded using the same context.

[0291] 7. The method of Solution 5, wherein the format rules specify that the second bin is coded in the coded representation if, and only if, a non-affine and non-intra block copy mode is used to represent the video block in the coded representation.

[0292] The following solutions represent exemplary implementations of the techniques discussed in the previous sections (eg, items 3 through 8).

[0293] 8. A method of video processing includes performing a conversion between a video including one or more video pictures including a plurality of video blocks and a coded representation of the video, the coded representation conforming to a format rule for signaling information relating to Adaptive Motion Vector difference Resolution (AMVR) coding of the one or more video blocks, the format rule specifying coding a bin of an AMVR precision index of a first video block coded using a first coding mode and a bin of an AMVR precision index of a second video block coded using a second coding mode using the same context.

[0294] 9. The method of solution 8, wherein the first coding mode corresponds to an intra block copy mode, the second coding mode corresponds to inter coding, the bins of the first video block are first bins of an AMVR precision index, and the bins of the second video block are second bins of a corresponding AMVR precision index.

[0295] 10. The method of solution 8, wherein the first coding mode corresponds to an intra block copy mode, the second coding mode corresponds to inter coding, the bin of the first video block is a first bin of an AMVR precision index, and the bin of the second video block is a first bin of a corresponding AMVR precision index.

[0296] 11. The method of solution 8, wherein the first coding mode corresponds to an intra block copy mode, the second coding mode corresponds to inter coding, the bin of the first video block is a first bin of an AMVR precision index, and the bin of the second video block is a first bin of a corresponding AMVR precision index.

[0297] 12. The method of solution 8, wherein the first coding mode corresponds to an intra block copy mode, the second coding mode corresponds to affine coding, the bins of the first video block are first bins of an AMVR precision index, and the bins of the second video block are first bins of a corresponding AMVR precision index.

[0298] 13. The method of solution 8, wherein the format rules further specify that the same context is used for coding all bins of the first video block, the second video block, and the third video block having intra block copy mode, affine mode, and inter coding mode.

[0299] 14. The method of solution 8, wherein the format rules further specify using different contexts for coding the first bins of the first video block, the second video block, and the third video block, and the same context for coding the second bins of the first video block, the second video block, and the third video block, having intra block copy mode, affine mode, and inter coding mode.

[0300] The following solutions represent exemplary implementations of the techniques discussed in the previous section (eg, item 9).

[0301] 15. The method according to any of Solutions 1 to 14, wherein the formatting rules further specify that at least one context used for coding the precision value is the same as the context used for coding the flag indicating the applicability of the AMVR tool.

[0302] The following solutions represent exemplary implementations of the techniques discussed in the previous sections (eg, items 10 and 11).

[0303] 16. A method of video processing includes performing a conversion between video blocks of a video and a coded representation of the video, where the video blocks are partitioned into one or more vertical and / or one or more horizontal partitions, and the coded representation complies with format rules that specify context-based coding of the partition information of the video blocks.

[0304] 17. The method of solution 16, wherein the formatting rules specify that context modeling of syntax elements indicating partition information depends on the number of vertical partitions allowed for a video block and / or the number of horizontal partitions allowed for the video block.

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

[0306] 19. The method according to any of solutions 17 to 18, wherein the formatting rules specify the use of N contexts for coding the syntax element, where N is based on a dimension of the video block or a dimension of a neighboring video block.

[0307] The following solutions represent exemplary implementations of the techniques discussed in the previous section (eg, item 12).

[0308] 20. The method according to any of solutions 16 to 19, wherein the format rules specify that a single context is used for coding a flag indicating the applicability of vertical partitioning to a video block.

[0309] The following solutions represent exemplary implementations of the techniques discussed in the previous sections (eg, items 13, 17).

[0310] 21. A method of video processing includes performing a conversion between a video block of a video and a coded representation of the video, the coded representation conforming to a format rule, the format rule specifying coding conditions used to determine whether to use context coding or bypass coding to represent signs of transform coefficients.

[0311] 22. The method according to solution 21, wherein the coding condition corresponds to the number of remaining allowed context-coded bins.

[0312] 23. The method according to solution 21, wherein the coding conditions correspond to the type of transformation used to convert between the video block and the coded representation.

[0313] The following solutions represent exemplary implementations of the techniques discussed in the previous section (eg, item 14).

[0314] 24. A method of video processing includes performing a conversion between a video block of a video and a coded representation of the video, the coded representation conforming to a format rule, the format rule specifying that an operation is applied to a variable that specifies a number of remaining allowed context coded bins at the start of bypass coding of remaining syntax elements in a third or residual coefficient scan pass of a transform skip residual coding process.

[0315] 25. The method according to any one of solutions 1 to 24, wherein the conversion comprises encoding the video into a coded representation.

[0316] 26. A method according to any one of solutions 1 to 24, wherein the conversion includes decoding the coded representation to generate pixel values ​​of the image.

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

[0318] 28. A video encoding device comprising a processor configured to implement a method according to one or more of solutions 1 to 26.

[0319] 29. A computer program product having computer code stored thereon, the code causing the processor to implement a method according to any one of solutions 1 to 26 when executed by the processor.

[0320] 30. Any method, apparatus or system described herein.

[0321] 18 is a flow chart illustrating a video processing method 1800 in accordance with 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 rules. The conversion is based on an Adaptive Motion Vector Difference Resolution (AMVR) tool, where the rules specify deriving a selection of a context for a first bin in a string of bins of a first syntax element that specifies a resolution of a motion vector difference associated with an AMVR shift based on a coding mode usage of the block.

[0322] In some embodiments, the block is a coding unit. In some embodiments, a coding mode of the block is one of an affine inter mode, an intra block copy mode, or a normal inter mode. In some embodiments, multiple contexts corresponding to different coding modes may be applied to the first bin. In some embodiments, the multiple contexts include three contexts. In some embodiments, each coding mode corresponds to a single context.

[0323] In some embodiments, when coding the block using an IBC mode, a first context for the first bin is assigned to a first value, and when not coding the block using an IBC mode, at least one context different from the first context is applicable to the first bin for at least one inter coding mode. In some embodiments, a second context for the first bin is assigned to a second value if the block is coded using an affine inter mode, and a third context for the first bin is assigned to a third value if the block is coded using a normal inter mode, which is a non-affine inter mode. The second value and the third value are different values.

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

[0325] In some embodiments, when coding the block using an IBC mode or an affine inter mode, the string of bins consists of a first bin. When coding the block using a normal inter mode, which is a non-affine inter mode, the string of bins further comprises a second bin. In some embodiments, at least one of the contexts applied to the first bin is the same as at least one context selected for a second syntax element that specifies whether the resolution of the motion vector differential is a quarter of a luma sample or is defined by the first syntax element. In some embodiments, when coding the block using an IBC mode, the context for the first syntax element that specifies the resolution of the motion vector differential is the same as the context selected for the second syntax element that specifies whether the resolution of the motion vector differential is a quarter of a luma sample or is defined by the first syntax element. In some embodiments, if the block is not coded using IBC or affine mode, the context for the first syntax element that specifies the resolution of the motion vector differential is the same as the context selected for the second syntax element that specifies whether the resolution of the motion vector differential is ¼ of a luma sample or is defined by the first syntax element. In some embodiments, the context for the first bin in the string of bins is assigned a value of CtxM, and the context for the second bin with the string of bins is assigned a value of CtxQ, where CtxM=CtxQ. In some embodiments, a different context is selected for the second bin compared to the first bin.

[0326] In some embodiments, the first context for the first bin when the block is coded in IBC mode, the second context for the first bin when the block is coded using affine mode, and the third context for the first bin when the block is coded neither using IBC mode nor affine mode are the same. In some embodiments, the first context for the first bin when the block is coded in IBC mode, and the second context for the first bin when the block is coded neither using IBC mode nor affine mode are the same. In some embodiments, the third context for the first bin when the block is coded 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 coded in IBC mode, and the second context for the first bin when the block is coded in affine mode are the same. In some embodiments, the context for all bins in the string of bins when the block is coded in IBC mode, the context for all bins in the string of bins when the block is coded using affine mode, and the context for all bins in the string of bins when the block is coded using neither IBC mode nor affine mode are the same.

[0327] In an embodiment of the present invention, the AMVR tool is a coding tool that adaptively adjusts the resolution of motion vector differentials on a block-by-block basis.

[0328] 19 is a flow diagram illustrating a video processing method 1900 according to one or more embodiments of the present invention. The method 1900 includes, at operation 1910, performing a conversion between a current block of video and a bitstream of video according to a rule. The rule specifies that a context for coding a syntax element that specifies whether to split a block horizontally or vertically is selected based on a number of allowed vertical splits and a number of allowed horizontal splits. The number of allowed vertical splits includes a number of allowed binary vertical splits and a number of allowed ternary vertical splits, and the number of allowed horizontal splits includes a number of allowed binary horizontal splits and a number of allowed ternary horizontal splits.

[0329] In some embodiments, the block is a coding unit. In some embodiments, the content is selected by comparing the number of allowed vertical divisions to the number of allowed horizontal divisions. In some embodiments, the context is selected from the first set of contexts if the number of allowed vertical divisions is greater than the number of allowed horizontal divisions. In some embodiments, the context is selected from the second set of contexts if the number of allowed vertical divisions is less than the number of allowed horizontal divisions. In some embodiments, the first set of contexts and the second set of contexts each include a single context. In some embodiments, the value of the single context in the first set of contexts is 4. In some embodiments, the value of the single context in the second set of contexts is 3.

[0330] In some embodiments, a context is selected from the third set of contexts if the number of allowed vertical splits is equal to the number of allowed horizontal splits. In some embodiments, the third set of contexts includes a plurality of contexts. In some embodiments, the third set of contexts 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.

[0331] In some embodiments, the selection of a context from the third set of contexts 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 dimensions of the current block, and / or (3) the dimensions of the neighboring blocks. In some embodiments, the context is assigned a value of CtxD if (1) either 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) if 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 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, the context is assigned a value of CtxE if dA is less than 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 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, the context is assigned a value of CtxF if dA is greater than 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 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.

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

[0333] 20 is a flow diagram illustrating a video processing method 2000 in accordance with one or more embodiments of the present invention. The method 2000 includes, at operation 2010, performing a conversion between a current block of video and a bitstream of video according to a rule. The rule specifies that whether to use context coding or bypass coding for a syntax element that specifies a sign of a transform coefficient level is based on the number of remaining allowed context coded bins or the type of transform used for the current block.

[0334] In some embodiments, if the number of remaining allowed context coded bins is greater than or equal to a threshold, context coding is used for the syntax element in the transform skip residual coding process for the current block. In some embodiments, if the number of remaining allowed context coded bins is less than a threshold, bypass coding is used for the syntax element in the transform skip residual coding process for the current block. In some embodiments, the threshold is 0 or 3.

[0335] In some embodiments, bypass coding is used for the syntax element if the number of remaining allowed context coded bins is less than or equal to N. In some embodiments, context coding is used for the syntax element if the number of remaining allowed context coded bins is greater than or equal to N. In some embodiments, the number of remaining allowed context coded bins is modified to be less than or equal to N before processing the remaining absolute values ​​of the transform coefficient levels in the transform. In some embodiments, N is 0, 3, or 4. In some embodiments, N is an integer based on characteristics of the current block. In some embodiments, the characteristics of the current block include a sequence parameter set, a picture parameter set, a picture parameter set, a picture header, a slice header, a tile group header, a row of a large coding unit, a group of a large coding unit, a large coding unit, or an indication in a coding unit. In some embodiments, the characteristics of the current block include a size or shape of the current block or a block in a neighborhood of the current block. In some embodiments, the characteristics of the current block include an indication of a color format of the picture. In some embodiments, the characteristics of the current block include an indication of whether a separate or dual coding tree structure is used for the transform. In some embodiments, the characteristics of the current block include a slice type or a picture type. In some embodiments, the characteristics of the current block include the number of color components in the image.

[0336] In some embodiments, the context coding of the syntax element is based on the number of remaining allowed context coded bins. In some embodiments, a variable defining the number of remaining allowed context coded bins is modified at the start of bypass coding of the remaining syntax elements in the third or remaining coefficient scan path of the 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 comprises a transform block or a transform skip block with or without a block-based differential pulse code modulation coded block.

[0337] In some embodiments, whether to apply the method is indicated at a sequence level, a picture level, a slice level or a tile 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, a decoding capability information, a picture parameter set, an adaptation parameter set, a slice header or a tile group header. In some embodiments, whether or how to apply the method is based on coded information of the video.

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

[0339] In this specification, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to bits spread to the same or different locations in the bitstream, for example, as specified by the syntax. For example, one macroblock may be coded in terms of transformed and coded error residual values ​​and using bits in the header and other fields in the bitstream. Furthermore, during conversion, the decoder may parse the bitstream with the knowledge that some fields may or may not be present based on the determination, as described in the above solution. Similarly, the encoder may determine whether a particular syntax field should or should not be included in the coded representation and generate the coded representation accordingly by including or excluding the syntax field in the coded representation.

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

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

[0342] The processing and logic flows described herein 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 processing and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC).

[0343] Processors suitable for executing computer programs include, for example, both general purpose and special purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer may include one or more mass storage devices, such as magnetic, magneto-optical, or optical disks, for storing data, or may be operatively coupled to receive data from or transfer data to these mass storage devices. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, EPROMs, EEPROMs, flash storage devices, magnetic disks, such as internal hard disks or removable disks, magneto-optical disks, and semiconductor storage devices such as CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0344] Although this patent specification includes many features, these should not be construed as limiting the scope of any subject matter or the scope of the claims, but rather as descriptions of features that may be specific to particular embodiments of a particular technology. Certain features described in this patent document in the context of separate embodiments may be implemented in combination in one example. Conversely, various features described in the context of one example may be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in a particular combination and initially claimed as such, one or more features from a claimed combination may, in some cases, be extracted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0345] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring that such operations be performed in the particular order or sequential order shown, or that all of the operations shown be performed, to achieve desired results, nor should the separation of various system components in the embodiments described in this patent specification be understood as requiring such separation in all embodiments.

[0346] Only certain implementations and examples have been described; other embodiments, extensions and variations are possible based on the content described and illustrated in this patent document.

Claims

1. 1. A method of image processing, comprising: performing a conversion between a current block of a video and a bitstream of said video according to a rule; having The rules specify that a selection of a context augmentation means (ctxInc) for coding a syntax element specifying whether the current block is to be split horizontally or vertically is based on a number of allowed vertical splits and a number of allowed horizontal splits; the number of allowed vertical splits is equal to the sum of the value of a variable of allowed binary vertical splits (allowSplitBtVer) and the value of a variable of allowed ternary vertical splits (allowSplitTtVer); the number of allowed horizontal splits is equal to the sum of the value of a variable of allowed binary horizontal splits (allowSplitBtHor) and the value of a variable of allowed ternary horizontal splits (allowSplitTtHor); the context augmentation means are selected from a first set of context augmentation means if the number of allowed vertical divisions is greater than the number of allowed horizontal divisions, and a second set of context augmentation means if the number of allowed vertical divisions is less than the number of allowed horizontal divisions; each of the first set of context augmentation means and the second set of context augmentation means includes a single context augmentation means; the single context augmentation means in the first set of context augmentation means has a value of 4; The method of claim 1, wherein the single context augmentation means in the second set of context augmentation means has a value of three.

2. The method of claim 1 , wherein the current block is a coding unit.

3. 3. The method of claim 1, wherein the context augmentation means is selected by comparing the number of allowed vertical splits with the number of allowed horizontal splits.

4. 4. The method according to claim 1, wherein the context augmentation means is selected from a third set of context augmentation means if the number of allowed vertical divisions is equal to the number of allowed horizontal divisions.

5. The third set of context augmentation means includes a plurality of context augmentation means, The method of claim 4 , wherein the context augmentation means in the first set of context augmentation means, the second set of context augmentation means, and the third set of context augmentation means are different from each other.

6. The method described in claim 5, wherein the set of third context augmentation means includes a third context augmentation means having a value of 0, a fourth context augmentation means having a value of 1, and a fifth context augmentation means having a value of 2.

7. 6. The method of claim 5, wherein the selection of the context augmentation means from the third set of context augmentation means is further based on: (1) 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) a size of the current block; and / or (3) a size of the first neighboring block and / or a size of the second neighboring block.

8. The context augmentation means is assigned a value of a third context augmentation means if at least one of the following is satisfied: (1) the first neighboring block located above the current block is not available; (2) the second neighboring block located to the left of the current block is not available; (3) dA is equal to dL, dA denotes the width of the current block divided by the width of the first neighboring block if the first neighboring block is available, and denotes the width of the current block if the first neighboring block is not available; 8. The method of claim 7, wherein dL indicates the height of the current block divided by the height of the second neighboring block if the second neighboring block is available, and indicates the height of the current block if the second neighboring block is not available.

9. the context augmentation means is assigned a value of a fourth context augmentation means if condition (a) is not satisfied and condition (b) is satisfied; The condition (a) includes satisfying at least one of the following: (1) the first neighboring block located above the current block is not available; (2) the second neighboring block located to the left of the current block is not available; (3) dA is equal to dL, dA denotes the width of the current block divided by the width of the first neighboring block if the first neighboring block is available, and denotes the width of the current block if the first neighboring block is not available; dL denotes the height of the current block divided by the height of the second neighboring block if the second neighboring block is available, and denotes the height of the current block if the second neighboring block is not available; The method of claim 7 , wherein the condition (b) includes dA being less than dL.

10. the context augmentation means is assigned a value of a fifth context augmentation means if condition (a) and condition (b) are not all satisfied; The condition (a) includes satisfying at least one of the following: (1) the first neighboring block located above the current block is not available; (2) the second neighboring block located to the left of the current block is not available; (3) dA is equal to dL, dA denotes the width of the current block divided by the width of the first neighboring block if the first neighboring block is available, and denotes the width of the current block if the first neighboring block is not available; dL denotes the height of the current block divided by the height of the second neighboring block if the second neighboring block is available, and denotes the height of the current block if the second neighboring block is not available; The method of claim 7 , wherein the condition (b) includes dA being less than dL.

11. The method of claim 1 , wherein the conversion comprises encoding the video into the bitstream.

12. The method of claim 1 , wherein the converting comprises decoding the video from the bitstream.

13. 1. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions, the instructions, when executed by the processor, causing the processor to: performing a conversion between a current block of a video and a bitstream of said video according to a rule; Let them do so, The rules specify that a selection of a context augmentation means (ctxInc) for coding a syntax element specifying whether the current block is to be split horizontally or vertically is based on a number of allowed vertical splits and a number of allowed horizontal splits; the number of allowed vertical splits is equal to the sum of the value of a variable of allowed binary vertical splits (allowSplitBtVer) and the value of a variable of allowed ternary vertical splits (allowSplitTtVer); the number of allowed horizontal splits is equal to the sum of the value of a variable of allowed binary horizontal splits (allowSplitBtHor) and the value of a variable of allowed ternary horizontal splits (allowSplitTtHor); the context augmentation means are selected from a first set of context augmentation means if the number of allowed vertical divisions is greater than the number of allowed horizontal divisions, and a second set of context augmentation means if the number of allowed vertical divisions is less than the number of allowed horizontal divisions; each of the first set of context augmentation means and the second set of context augmentation means includes a single context augmentation means; the single context augmentation means in the first set of context augmentation means has a value of 4; The single context augmentation means in the second set of context augmentation means has a value of three.

14. The processor: performing a conversion between a current block of a video and a bitstream of said video according to a rule; Let them do so, The rules specify that a selection of a context augmentation means (ctxInc) for coding a syntax element specifying whether the current block is to be split horizontally or vertically is based on a number of allowed vertical splits and a number of allowed horizontal splits; the number of allowed vertical splits is equal to the sum of the value of a variable of allowed binary vertical splits (allowSplitBtVer) and the value of a variable of allowed ternary vertical splits (allowSplitTtVer); the number of allowed horizontal splits is equal to the sum of the value of a variable of allowed binary horizontal splits (allowSplitBtHor) and the value of a variable of allowed ternary horizontal splits (allowSplitTtHor); the context augmentation means are selected from a first set of context augmentation means if the number of allowed vertical divisions is greater than the number of allowed horizontal divisions, and a second set of context augmentation means if the number of allowed vertical divisions is less than the number of allowed horizontal divisions; each of the first set of context augmentation means and the second set of context augmentation means includes a single context augmentation means; the single context augmentation means in the first set of context augmentation means has a value of 4; the single context augmentation means in the second set of context augmentation means has a value of three.

15. 1. A method for storing a video bitstream, comprising: generating the bitstream for the video according to a rule; storing the bitstream on a non-transitory computer readable recording medium; having The rules provide that the selection of a context augmentation means (ctxInc) for coding a syntax element specifying whether the current block is split horizontally or vertically is based on the number of allowed vertical splits and the number of allowed horizontal splits; the number of allowed vertical splits is equal to the sum of the value of a variable of allowed binary vertical splits (allowSplitBtVer) and the value of a variable of allowed ternary vertical splits (allowSplitTtVer); the number of allowed horizontal splits is equal to the sum of the value of a variable of allowed binary horizontal splits (allowSplitBtHor) and the value of a variable of allowed ternary horizontal splits (allowSplitTtHor); the context augmentation means are selected from a first set of context augmentation means if the number of allowed vertical divisions is greater than the number of allowed horizontal divisions, and a second set of context augmentation means if the number of allowed vertical divisions is less than the number of allowed horizontal divisions; each of the first set of context augmentation means and the second set of context augmentation means includes a single context augmentation means; the single context augmentation means in the first set of context augmentation means has a value of 4; The method of claim 1, wherein the single context augmentation means in the second set of context augmentation means has a value of three.

Images