Method and apparatus for processing video data, medium, and method of storing a bitstream

Abstract

Methods and apparatus for video processing are described. An example method includes determining whether a video block satisfies a condition for conversion between video blocks and a bitstream of video, wherein the video block is encoded and decoded in the bitstream using an intra-block copy mode, and performing the conversion based on that determination. Here, because the video block satisfies the condition, a portion of the intra-block copy buffer is reset during the conversion.

Description

[0001] Cross-references to related applications

[0002] This application is based on International Patent Application No. PCT / CN2021 / 081469, filed on March 18, 2021, which claims priority and interest in International Patent Application No. PCT / CN2020 / 079858, filed on March 18, 2020. All of the aforementioned patent applications are incorporated herein by reference in their entirety. Technical Field

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

[0004] Digital video accounts for the largest share of bandwidth usage on the internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video is expected to continue to grow. Summary of the Invention

[0005] This document discloses techniques that can be used by video encoders and decoders to process the codec representation of video using control information useful for decoding the codec representation.

[0006] In one example aspect, a video processing method is disclosed. The method includes: determining that a video block satisfies a condition for a conversion between a video block and a codec representation of the video, wherein the video block is encoded and decoded in the codec representation using an intra-block copy mode; and performing the conversion based on the determination. During the conversion, a portion of the intra-block copy buffer is reset because the video block satisfies the condition.

[0007] In another example, a different video processing method is disclosed. This method includes performing a conversion between one or more video blocks and a codec representation of the video. The one or more video blocks are encoded and decoded using a palette of representative samples. The palette is predicted and encoded / decoded in the codec representation using palette prediction values, and the palette prediction values ​​are updated before processing each of the one or more video blocks.

[0008] In yet another example, a video encoder apparatus is disclosed. The video encoder includes a processor configured to implement the methods described above.

[0009] In yet another example, a video decoder apparatus is disclosed. The video decoder includes a processor configured to implement the methods described above.

[0010] In yet another example, a computer-readable medium storing code is disclosed. When executed by a processor, this code causes the processor to perform the methods described above.

[0011] In yet another example, a method for generating a bitstream according to the above approach is described. The bitstream can then be stored on a computer-readable medium.

[0012] These and other features will be described in this document. Attached Figure Description

[0013] Figure 1 This is a block diagram of an example video processing system.

[0014] Figure 2 This is a block diagram of a video processing device.

[0015] Figure 3 This is a flowchart of an example method for video processing.

[0016] Figure 4 This is a block diagram illustrating a video encoding / decoding system according to some embodiments of the present disclosure.

[0017] Figure 5 This is a block diagram illustrating an encoder according to some embodiments of the present disclosure.

[0018] Figure 6 This is a block diagram illustrating a decoder according to some embodiments of the present disclosure.

[0019] Figure 7 An example illustration of the current image reference is shown.

[0020] Figure 8 An example of a dynamic reference region as shown in JVET-M0407 is presented.

[0021] Figure 9 An example of a block encoded and decoded in palette mode is shown.

[0022] Figure 10 An example of a sub-block-based index graph scan of a color palette is shown, with a horizontal scan on the left and a vertical scan on the right.

[0023] Figure 11 This is a flowchart of an example method for video processing.

[0024] Figure 12 This is a flowchart of an example method for video processing. Detailed Implementation

[0025] Chapter headings are used in this document for ease of understanding, and the applicability of the technologies and embodiments disclosed in each chapter is not limited to that chapter alone. Furthermore, the use of H.266 technical terminology in some descriptions is merely for ease of understanding and not to limit the scope of the disclosed technologies. Therefore, the technologies described herein are also applicable to other video codec protocols and designs.

[0026] 1. Preliminary Discussion

[0027] This patent document relates to video encoding and decoding technology. Specifically, it relates to intra-frame block copying in video encoding and decoding. It can be applied to standards under development, such as multi-function video codecs. It can also be applied to future video encoding and decoding standards or video codecs.

[0028] 2. Introduction to Video Encoding and Decoding

[0029] Video codec standards have primarily evolved through the development of well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, while ISO / IEC developed MPEG-1 and MPEG-4 Visual. The two organizations jointly developed the H.262 / MPEG-2 video, H.264 / MPEG-4 Advanced Video Coding (AVC), and H.265 / HEVC standards. Since H.262, video codec standards have been based on a hybrid video codec architecture, employing temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and incorporated them into reference software called the Joint Exploration Model (JEM). In April 2018, the Joint Video Experts Group (JVET) was established between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) to work on the VVC standard, which aims to reduce the bit rate by 50% compared to HEVC.

[0030] The latest version of the VVC draft, namely Multi-Functional Video Codec (Draft 8), can be found at:

[0031] phenix.int-evry.fr / jvet / doc_end_user / documents / 17_Brussels / wg11 / JVET-

[0032] Q2001-v15.zip.

[0033] The latest reference software for VVC (called VTM) can be found at:

[0034] vcgit.hhi.fraunhofer.de / jvet / VVCSoftware_VTM / tags / VTM-8.0.

[0035] 2.1. Inter-frame prediction in HEVC / H.265

[0036] Each inter-frame prediction unit (PU) has motion parameters for one or two lists of reference images. The motion parameters include motion vectors and reference image indices. The use of one of the two reference image lists can also be signaled using `inter_pred_idc`. The motion vectors can be explicitly encoded as deltas relative to the predicted values.

[0037] When encoding and decoding a CU in skip mode, a PU is associated with the CU and there are no significant residual coefficients, no encoded motion vector increments, or reference picture indices. A Merge mode is specified, thereby obtaining the motion parameters of the current PU from neighboring PUs, including spatial and temporal candidates. The Merge mode can be applied to any inter-frame prediction PU, not just skip mode. An alternative to the Merge mode is the explicit transmission of motion parameters, where the motion vector (more precisely, the motion vector difference (MVD) compared to the predicted motion vector value), the corresponding reference picture index for each reference picture list, and the reference picture list are explicitly signaled per PU. Such a mode is referred to in this disclosure as Advanced Motion Vector Prediction (AMVP).

[0038] A PU is generated from a sample block when the signaling indicates that one of two lists of reference images will be used. This is called "one-way prediction". One-way prediction applies to both P-strips and B-strips.

[0039] When signaling indicates that two reference image lists should be used, a PU is generated from two sample blocks. This is called "bidirectional prediction". Bidirectional prediction is only applicable to B-strips.

[0040] The following section provides details about the inter-frame prediction modes specified in HEVC. The description will begin with the Merge mode.

[0041] 2.2. Current image reference

[0042] The current picture referencing (CPR), or once called intra block copy (IBC), has been adopted in the HEVC Screen Content Coding extension (HEVC-SCC)[1] and the current VVC test model (VTM-3.0)[2]. IBC extends the concept of motion compensation from inter-frame coding and decoding to intra-frame coding and decoding. Figure 7 As demonstrated, when CPR is applied, the current block is predicted using a reference block in the same image. Samples in the reference block must be reconstructed before the current block can be encoded or decoded. While CPR is inefficient for most camera-captured sequences, it demonstrates significant encoding / decoding gains for screen content. This is because screen content images contain many repeating patterns, such as icons and text characters. CPR effectively removes redundancy between these repeating patterns. In HEVC-SCC, CPR can be applied if the inter-frame encoding / decoding unit (CU) selects the current image as its reference image. In this case, the MV is renamed to a block vector (BV), and the BV always has integer pixel precision. For compatibility with the main profile HEVC, the current image is marked as the "long-term" reference image in the Decoded Picture Buffer (DPB). It should be noted that, similarly, in multi-view / 3D video codec standards, inter-view reference images are also marked as "long-term" reference images.

[0043] After the BV finds its reference block, predictions can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixel from the original signaling. Transformation and quantization can then be applied as in other encoding / decoding modes.

[0044] However, some or all pixel values ​​may be undefined when the reference block is outside the image, overlaps with the current block, is outside the reconstructed region, or is outside a valid region subject to certain constraints. Essentially, there are two solutions to this problem. One is to disallow this situation, for example, in bitstream consistency. The other is to apply padding to those undefined pixel values. The following subsections describe the solutions in detail.

[0045] 2.3. CPR in HEVC Screen Content Codec Extensions

[0046] In HEVC's screen content encoding and decoding extensions, when a block uses the current image as a reference, it should ensure that the entire reference block is within the available reconstruction area, as indicated by the following specification text:

[0047] The variables offsetX and offsetY are derived as follows:

[0048] offsetX=(ChromaArrayType==0)? 0:(mvCLX[0]&0x7?2:0) (8-104)

[0049] offsetY=(ChromaArrayType==0)? 0:(mvCLX[1]&0x7?2:0) (8-105)

[0050] The requirement for bitstream consistency is that, when the reference image is the current image, the luminance motion vector mvLX should adhere to the following constraints:

[0051] – When the derivation of the z-scan sequence block availability as specified in Clause 6.4.1 is invoked with (xCurr, yCurr) set to equal (xCb, yCb) and the neighboring luminance position (xNbY, yNbY) set to equal (xPb+(mvLX[0]>>2)–offsetX, yPb+(mvLX[1]>>2)–offsetY) as input, the output should be TRUE.

[0052] – When the derivation of the z-scan sequence block availability as specified in Clause 6.4.1 is invoked with (xCurr, yCurr) set to equal (xCb, yCb) and the neighboring luminance positions (xNbY, yNbY) set to equal (xPb+(mvLX[0]>>2)+nPbW–1+offsetX, yPb+(mvLX[1]>>2)+nPbH–1+offsetY) as input, the output should be TRUE.

[0053] One or both of the following conditions should be true:

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

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

[0056] The following conditions should be true:

[0057] (xPb+(mvLX[0]>>2)+nPbSw–1+offsetX) / CtbSizeY–xCb / CtbSizeY<=yCb / CtbSizeY–(yPb+(mvLX[1]>>2)+nPbSh–1+offsetY) / CtbSizeY(8-106)

[0058] Therefore, there will be no situation where the reference block overlaps with the current block or the reference block is outside the image. No need to fill reference or prediction blocks.

[0059] 2.4. CPR / IBC in the VVC test model

[0060] In the current VVC test model (i.e., the VTM-3.0 design), the entire reference block should have a current coding tree unit (CTU) and not overlap with the current block. Therefore, there is no need to fill the reference or prediction block.

[0061] When dual-tree is enabled, the segmentation structure from luma CTU to chroma CTU can be different. Therefore, for a 4:2:0 color format, a chroma block (e.g., CU) can correspond to a co-occurring luma region that has been divided into multiple luma CUs.

[0062] A chroma block can only be encoded and decoded in CPR mode if the following conditions are true:

[0063] 1) Each luminance CU within a co-occurring luminance block should be encoded and decoded in CPR mode.

[0064] 2) Each of the BVs in the luminance 4×4 block is first converted to the BV of the chrominance block, and the BV of the chrominance block is the valid BV.

[0065] If either of the two conditions is false, the chroma block should not be encoded or decoded in CPR mode.

[0066] Note that the definition of "valid BV" has the following constraints:

[0067] 1) All sample points within the reference block identified by BV should be within a limited search range (e.g., within the same CTU in the current VVC design).

[0068] 2) All samples within the reference block identified by BV have been reconstructed.

[0069] 2.5. CPR / IBC in JVET-L0297 / JVET-M0407 / JVET-M0408

[0070] In VTM3.0, the reference area for CPR / IBC is limited to the current CTU, which can be up to 128×128. JVET-L0297 / JVET-M0407 / JVET-M0408 present methods to dynamically change the reference area to reuse memory to store reference samples for CPR / IBC, allowing the CPR / IBC block to have more reference candidates, while the reference buffer for CPR / IBC can be maintained or reduced from one CTU.

[0071] Figure 8 One method is shown where the blocks are 64×64, and the CTU contains four 64×64 blocks. When encoding and decoding the 64×64 blocks, the previous three 64×64 blocks can be used as a reference. By doing so, the decoder only needs to store four 64×64 blocks to support CPR / IBC. This method is used in VTM 4.0.

[0072] Assume the current brightness CU is positioned (x, y) relative to the top-left corner of the image, and the block vector is (BVx, BVy). In the current design, whether BV is valid can be determined by the fact that the brightness position ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) has not yet been reconstructed and ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) is not equal to (x>>6<<6, y>>6<<6).

[0073] 2.6. Virtual IBC Buffer Proposed in JVET-O1170

[0074] A virtual buffer concept is introduced to help describe the reference region of the IBC prediction mode. For a CTU size of ctbSize, wIbcBuf = 128 * 128 / ctbSize, and a virtual IBC buffer IbcBuf is defined, with a width of wIbcBuf and a height of ctbSize. Therefore,

[0075] –For a CTU, the size is 128x128, and the size of an ibcBuf is also 128x128.

[0076] – For CTU, the size is 64x64, and for ibcBuf, the size is 256x64.

[0077] – For CTU, the size is 32x32, and for ibcBuf, the size is 512x32.

[0078] Note that the VPDU width and height are min(ctbSize, 64). This represents W. v =min(ctbSize,64).

[0079] The virtual IBC buffer ibcBuf is maintained as follows.

[0080] 1) At the beginning of decoding each CTU line, refresh the entire ibcBuf with the value (-1).

[0081] 2) At the beginning of decoding the VPDU(xVPDU, yVPDU) relative to the top left corner of the image, set ibcBuf[x][y] = -1, where x = xVPDU%wIbcBuf, ..., xVPDU%wIbcBuf + W v –1;y=yVPDU%ctbSize,…,yVPDU%ctbSize+W v -1.

[0082] 3) After decoding the CU containing (x, y) coordinates relative to the top-left corner of the image, set...

[0083] ibcBuf[x%wIbcBuf][y%ctbSize]=recSample[x][y]

[0084] Therefore, bitstream constraints can be simply described as...

[0085] The requirement for bitstream consistency is that, for bv, ibcBuf[(x+bv[0])%wIbcBuf][(y+bv[1])%ctbSize] should not be equal to -1.

[0086] Utilizing the concept of the IBC reference buffer, it also simplifies the decoding process by avoiding reference frame inter-interpolation and motion compensation processes (including sub-block processes).

[0087] 2.7.VPDU

[0088] Virtual Pipeline Data Units (VPDUs) are defined as non-overlapping units in an image. In a hardware decoder, consecutive VPDUs are processed simultaneously by multiple pipeline stages. In most pipeline stages, the VPDU size is roughly proportional to the buffer size, so keeping the VPDU size small is important. In most hardware decoders, the VPDU size can be set to the maximum transform block (TB) size. However, in VVC, ternary tree (TT) and binary tree (BT) partitioning can lead to an increase in VPDU size.

[0089] To maintain the VPDU size at 64x64 luminance samples, the following standard segmentation constraints (with syntax signaling modifications) are applied in VTM5:

[0090] -TT partitioning is not allowed for CUs with width or height, or width and height equal to 128.

[0091] – For a 128xN CU with N≤64 (i.e., width equal to 128 and height less than 128), horizontal BT is not allowed.

[0092] – For Nx128 CUs with N≤64 (i.e., height equal to 128 and width less than 128), vertical BTs are not allowed.

[0093] In VVC, it is generally agreed that the width and height of the VPDU in a luminance sample point are min(64, CtbSizeY). Therefore, for CTB / CTU sizes of 64x64, 128x128, or 256x256, the VPDU size is 64x64. For CTB / CTU sizes of 32x32, the VPDU size is 32x32.

[0094] 2.8. Buffer management and block vector encoding / decoding for intra-frame block copying in IDF P1809118901H and P1907355701H

[0095] Those IDFs describe various IBC buffers and their corresponding management.

[0096] 2.9. Current text regarding IBC in JVET-Q2001-vE

[0097] 8.6.2 Decoding process of the codec unit in IBC prediction mode

[0098] 8.6.2.1 General Decoding Process of Codec Units in IBC Prediction Mode

[0099] The input to this process is:

[0100] – Luminance position (xCb, yCb), specifies the top-left luminance sample of the current codec block relative to the top-left luminance sample of the current image.

[0101] – The variable cbWidth specifies the width of the current codec block in the luminance sample.

[0102] – The variable cbHeight specifies the height of the current codec block in the luminance sample.

[0103] The variable `treeType` specifies whether to use a single tree or a dual tree, and if a dual tree is used, it specifies whether the current tree corresponds to the luminance component or the chrominance component.

[0104] The output of this process is a reconstructed image modified before loop filtering.

[0105] Invoke the derivation process of the quantization parameters as specified in Clause 8.7.1, with the luminance position (xCb, yCb), the width cbWidth of the current codec block in the luminance sample, the height cbHeight of the current codec block in the luminance sample, and the variable treeType as input.

[0106] The variable IsGt4by4 is derived as follows:

[0107] IsGt4by4 = ( cbWidth * cbHeight ) > 16 (1111)

[0108] The decoding process of the codec unit in IBC prediction mode consists of the following ordered steps:

[0109] 1. The block vector components of the current encoding / decoding unit are derived as follows:

[0110] – Call the derivation procedure for the block vector components as specified in Clause 8.6.2.1, with the luma codec block position (xCb, yCb), luma codec block width cbWidth, and luma codec block height cbHeight as inputs, and the luma block vector bvL as output.

[0111] – When treeType equals SINGLE_TREE, invoke the derivation procedure for the chroma block vector as specified in Clause 8.6.2.5, with the luma block vector bvL as input and the chroma block vector bvC as output.

[0112] 2. The prediction samples of the current encoding / decoding unit are derived as follows:

[0113] – Invoke the decoding procedure for the IBC block as specified in Clause 8.6.3.1, wherein the luma codec block position (xCb, yCb), luma codec block width cbWidth and luma codec block height cbHeight, luma block vector bvL, and variable cIdx set to 0 are taken as inputs, and the (cbWidth)x(cbHeight) array predSamples is used as the predicted luma samples. L The IBC prediction samples (predSamples) are used as the output.

[0114] – When treeType equals SINGLE_TREE, the prediction samples of the current encoder / decoder unit are derived as follows:

[0115] – Invoke the decoding procedure for the IBC block as specified in Clause 8.6.3.1, wherein the luma codec block position (xCb, yCb), luma codec block width cbWidth and luma codec block height cbHeight, chroma block vector bvC, and variable cIdx set to 1 are taken as input, and the array predSamples of predicted chroma samples (cbWidth / SubWidthC)x(cbHeight / SubHeightC) as chroma components Cb is taken as input. Cb The IBC prediction samples (predSamples) are used as the output.

[0116] – Invoke the decoding procedure for the IBC block as specified in Clause 8.6.3.1, wherein the luma codec block position (xCb, yCb), luma codec block width cbWidth and luma codec block height cbHeight, chroma block vector bvC, and variable cIdx set to 2 are taken as input, and the array predSamples of predicted chroma samples as chroma components Cr is taken as input. Cr The IBC prediction samples (predSamples) are used as the output.

[0117] 3. The residual samples of the current encoding / decoding unit are derived as follows:

[0118] – Invoke the decoding process of the residual signal of the codec block encoded and decoded in inter-frame prediction mode as specified in Clause 8.5.8, wherein the inputs are the position (xTb0, yTb0) set to be equal to the luma position (xCb, yCb), the width nTbW set to be equal to the luma codec block width cbWidth, the height nTbH set to be equal to the luma codec block height cbHeight, and the variable cIdx set to be equal to 0, and the array resSamples L As output.

[0119] – When treeType equals SINGLE_TREE, the decoding process for the residual signal of the codec block encoded and decoded in inter-frame prediction mode as specified in Clause 8.5.8 is invoked, wherein the inputs are the position (xTb0, yTb0) set to equal the chroma position (xCb / SubWidthC, yCb / SubHeightC), the width nTbW set to equal the width cbWidth / SubWidthC of the chroma codec block, the height nTbH set to equal the height cbHeight / SubHeightC of the chroma codec block, and the variable cIdx set to equal 1, and the array resSamples is used.Cb As output.

[0120] – When treeType equals SINGLE_TREE, the decoding process for the residual signal of the codec block encoded and decoded in inter-frame prediction mode as specified in Clause 8.5.8 is invoked, wherein the inputs are the position (xTb0, yTb0) set to equal the chroma position (xCb / SubWidthC, yCb / SubHeightC), the width nTbW set to equal the width cbWidth / SubWidthC of the chroma codec block, the height nTbH set to equal the height cbHeight / SubHeightC of the chroma codec block, and the variable cIdx set to equal 2, and the array resSamples is used. Cr As output.

[0121] 4. The reconstructed samples of the current encoding / decoding unit are derived as follows:

[0122] – Invoke the image reconstruction process for the color components as specified in Clause 8.7.5, where the block position (xCurr, yCurr) is set to (xCb, yCb), the block width nCurrSw is set to cbWidth, the block height nCurrSh is set to cbHeight, the variable cIdx is set to 0, and the variable predSamples is set to... L The (cbWidth) x (cbHeight) array predSamples, and set to equal resSamples L The (cbWidth) x (cbHeight) array resSamples is used as input.

[0123] The output is a reconstructed image modified before loop filtering.

[0124] – When treeType equals SINGLE_TREE, the image reconstruction process for the color components as specified in Clause 8.7.5 is invoked, where the block position (xCurr, yCurr) is set to (xCb / SubWidthC, yCb / SubHeightC), the block width nCurrSw is set to cbWidth / SubWidthC, the block height nCurrSh is set to cbHeight / SubHeightC, the variable cIdx is set to 1, and the variable predSamples is set to... Cb The array predSamples is (cbWidth / SubWidthC)x(cbHeight / SubHeightC), and is set to be equal to resSamples. CbThe (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array resSamples is used as input, and the output is the reconstructed image modified before loop filtering.

[0125] – When treeType equals SINGLE_TREE, the image reconstruction procedure for the color components as specified in Clause 8.7.5 is invoked, where the block position (xCurr, yCurr) is set to (xCb / SubWidthC, yCb / SubHeightC), the block width nCurrSw is set to cbWidth / SubWidthC, the block height nCurrSh is set to cbHeight / SubHeightC, the variable cIdx is set to 2, and the value of predSamples is set to... Cr The array predSamples is (cbWidth / SubWidthC)x(cbHeight / SubHeightC), and is set to be equal to resSamples. Cr The (cbWidth / SubWidthC)x(cbHeight / SubHeightC) array resSamples is used as input, and the output is the reconstructed image modified before loop filtering.

[0126] 8.6.3 Derivation of the block vector components of the IBC block

[0127] 8.6.3.1 General

[0128] The input to this process is:

[0129] – The brightness position (xCb, yCb) of the current luminance block relative to the top-left luminance sample of the current image.

[0130] – The variable cbWidth specifies the width of the current codec block in the luminance sample.

[0131] – The variable cbHeight specifies the height of the current codec block in the luminance sample.

[0132] The output of this process is:

[0133] Luminance block vector bvL with a precision of -1 / 16 fractional sample points.

[0134] The luminance block vector mvL is derived as follows:

[0135] – Call the derivation procedure for IBC lumen block vector prediction as specified in Clause 8.6.2.2, where

[0136] The input consists of the luminance position (xCb, yCb), variables cbWidth and cbHeight, and the output is the luminance block vector bvL.

[0137] – When general_merge_flag[xCb][yCb] equals 0, the following applies:

[0138] 1. The variable bvd is derived as follows:

[0139] bvd[ 0 ] = MvdL0[ xCb ][ yCb ][ 0 ] (1112)

[0140] bvd[ 1 ] = MvdL0[ xCb ][ yCb ][ 1 ] (1113)2. Call the rounding procedure of the motion vector as specified in Clause 8.5.2.14, with mvX set to equal bvL, rightShift set to equal AmvrShift, and leftShift set to equal AmvrShift as inputs, and the rounded bvL as output.

[0141] 3. The luma block vector bvL is modified as follows:

[0142] u[0]=(bvL[0]+bvd[0]+2 18 )%2 18 (1114)

[0143] bvL[0]=(u[0]>=2 17 )? (u[0]-2 18 ):u[0] (1115)

[0144] u[1]=(bvL[1]+bvd[1]+2 18 )%2 18 (1116)

[0145] bvL[1]=(u[1]>=2 17 )? (u[1]-2 18 ):u[1] (1117)

[0146] Note 1 – The result values ​​of bvL[0] and bvL[1] as specified above will always be in the range of -2. 17 to 2 17 The range of -1 (including -2) 17 and 2 17 -1) inside.

[0147] When IsGt4by4 equals TRUE, the update procedure for the list of historical block vector predictions, as specified in Clause 8.6.2.6, is invoked using the luma block vector bvL.

[0148] Bitstream consistency requires that the luminance block vector bvL must comply with the following constraints:

[0149] –CtbSizeY is greater than or equal to ((yCb+(bvL[1]>>4))&(CtbSizeY-1))+cbHeight.

[0150] – For x=xCb..xCb+cbWidth-1 and y=yCb..yCb+cbHeight-1, IbcVirBuf[0][(x+(bvL[0]>>4))&(IbcBufWidthY-1)][(y+(bvL[1]>>4))&(CtbSizeY-1)] should not be equal to -1.

[0151] 8.6.3.2 Derivation of IBC Luminance Block Vector Prediction

[0152] This procedure is invoked only when CuPredMode[0][xCb][yCb] equals MODE_IBC, where (xCb, yCb) specifies the top-left sample of the current luminance codec block relative to the top-left luminance sample of the current image.

[0153] The input to this process is:

[0154] – The brightness position (xCb, yCb) of the current luminance block relative to the top-left luminance sample of the current image.

[0155] – The variable cbWidth specifies the width of the current codec block in the luminance sample.

[0156] – The variable cbHeight specifies the height of the current codec block in the luminance sample.

[0157] The output of this process is:

[0158] Luminance block vector bvL with a precision of -1 / 16 fractional sample points.

[0159] The luminance block vector bvL is derived through the following ordered steps:

[0160] 1. When IsGt4by4 equals TRUE, invoke the derivation procedure for spatial block vector candidates from neighboring codec units as specified in Clause 8.6.2.3, with the luma codec block position (xCb, yCb), luma codec block width cbWidth, and height cbHeight as inputs, and the outputs being availability flags availableFlagA1, availableFlagB1, and block vectors bvA1 and bvB1.

[0161] 2. When IsGt4by4 equals TRUE, the block vector candidate list bvCandList is constructed as follows:

[0162]

[0163] 3. The variable numCurrCand is derived as follows:

[0164] –IsGt4by4 is TRUE, and numCurrCand is set to the number of Merge candidates in bvCandList.

[0165] Otherwise (IsGt4by4 equals FALSE), numCurrCand is set to 0.

[0166] 4. When numCurrCand is less than MaxNumIbcMergeCand and NumHmvpIbcCand is greater than 0, invoke the IBC history-based block vector candidate derivation procedure as specified in Clause 8.6.2.4, with bvCandList and numCurrCand as inputs and modified bvCandList and numCurrCand as outputs.

[0167] 5. When numCurrCand is less than maxnumibmergecand, the following applies until numCurrCand equals MaxNumIbcMergeCand:

[0168] –bvCandList[numCurrCand][0] is set to equal to 0.

[0169] –bvCandList[numCurrCand][1] is set to equal to 0.

[0170] –numCurrCand increases by 1.

[0171] 6. The variable bvIdx is derived as follows:

[0172] bvIdx=general_merge_flag[xCb][yCb]? merge_idx[xCb][yCb]:

[0173] mvp_l0_flag[xCb][yCb](1119)7. Perform the following assignment:

[0174] bvL[ 0 ] = bvCandList[ mvIdx ][ 0 ] (1120)

[0175] bvL[ 1 ] = bvCandList[ mvIdx ][ 1 ] (1121)8.6.3.3 Derivation of IBC Spatial Block Vector Candidates

[0176] The input to this process is:

[0177] – The brightness position (xCb, yCb) of the current luminance block relative to the top-left luminance sample of the current image.

[0178] – The variable cbWidth specifies the width of the current codec block in the luminance sample.

[0179] – The variable cbHeight specifies the height of the current codec block in the luminance sample.

[0180] The output of this process is as follows:

[0181] –Availability flags for neighboring codec units, availableFlagA1 and availableFlagB1,

[0182] – For the derivation of availableFlagA1 and mvA1, the block vectors bvA1 and bvB1 with 1 / 16 fractional sample precision of adjacent codec units, the following applies:

[0183] – The luminance position (xNbA1, yNbA1) within the adjacent luminance code block is set to equal to (xCb-1, yCb+cbHeight-1).

[0184] – Invoke the derivation procedure for the availability of neighboring blocks as specified in Clause 6.4.4, with the current luminance position (xCurr, yCurr) set to equal to (xCb, yCb), the neighboring luminance position (xNbA1, yNbA1), checkPredModeY set to equal to TRUE, and cIdx set to equal to 0 as inputs, and the output is assigned to the block availability flag availableA1.

[0185] – The variables availableFlagA1 and bvA1 are derived as follows:

[0186] – If availableA1 equals FALSE, then availableFlagA1 is set to 0, and both components of bvA1 are set to 0.

[0187] Otherwise, availableFlagA1 is set to 1 and the following assignment is made:

[0188] bvA1=MvL0[xNbA1][yNbA1] (1122)

[0189] The following applies to the derivation of availableFlagB1 and bvB1:

[0190] – The luminance position (xNbB1, yNbB1) within the adjacent luminance codec block is set to equal to (xCb+cbWidth-1, yCb-1).

[0191] – Invoke the derivation procedure for the availability of neighboring blocks as specified in Clause 6.4.4, with the current luminance position (xCurr, yCurr) set to equal to (xCb, yCb), the neighboring luminance position (xNbB1, yNbB1), checkPredModeY set to equal to TRUE, and cIdx set to equal to 0 as inputs, and the output is assigned to the block availability flag availableB1.

[0192] – The variables availableFlagB1 and bvB1 are derived as follows:

[0193] – If one or more of the following conditions are true, availableFlagB1 is set to 0, and both components of bvB1 are set to 0:

[0194] –availableB1 equals FALSE.

[0195] –availableA1 equals TRUE, and the luminance position (xNbA1, yNbA1) and

[0196] (xNbB1, yNbB1) have the same block vector.

[0197] Otherwise, availableFlagB1 is set to 1 and assigned the following value:

[0198] bvB1 = MvL0[xNbB1][yNbB1] (1123) 8.6.3.4 Derivation of IBC based on history block vector candidates

[0199] The input to this process is:

[0200] –Block vector candidate list bvCandList

[0201] – The number of available block vector candidates in the list, numCurrCand.

[0202] The output of this process is:

[0203] – Modified block vector candidate list bvCandList,

[0204] – The number of modifications numCurrCand for the motion vector candidates in the list.

[0205] Both variables isPrunedA1 and isPrunedB1 are set to FALSE.

[0206] For each candidate in HmvpIbcCandList[hMvpIdx] (where index hMvpIdx = 1..NumHmvpIbcCand), repeat the following ordered steps until numCurrCand equals MaxNumIbcMergeCand:

[0207] 1. The variable sameMotion is derived as follows:

[0208] – If for any block vector candidate N (where N is A1 or B1), all of the following conditions are true, then sameMotion and isPrunedN are set to TRUE:

[0209] –IsGt4by4 equals TRUE.

[0210] –hMvpIdx equals 1.

[0211] – Candidate HmvpIbcCandList[NumHmvpIbcCand-hMvpIdx] is equal to candidate block vector N.

[0212] –isPrunedN equals FALSE.

[0213] Otherwise, sameMotion is set to equal FALSE.

[0214] 2. When sameMotion equals FALSE, candidate HmvpIbcCandList[NumHmvpIbcCand-hMvpIdx] is added to the block vector candidate list, as follows:

[0215] bvCandList[numCurrCand++] =

[0216] HmvpIbcCandList[NumHmvpIbcCand-hMvpIdx](1124) 8.6.3.5 Derivation of the chroma block vector

[0217] The input to this process is:

[0218] Luminance block vector bvL with a precision of -1 / 16 fractional sample points.

[0219] The output of this process is a chromaticity block vector bvC with a precision of 1 / 32 fractional sample points.

[0220] Derive the chroma block vector from the corresponding luminance block vector.

[0221] The chroma block vector bvC is derived as follows:

[0222] bvC[0]=((bvL[0]>>(3+SubWidthC))*32 (1125)

[0223] bvC[1]=((bvL[1]>>(3+SubHeightC))*32 (1126)8.6.3.6 Update process of candidate list of block vector prediction values ​​based on history

[0224] The input to this process is:

[0225] Luminance block vector bvL with a precision of -1 / 16 fractional sample points.

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

[0227] 1. The variable identicalCandExist is set to FALSE, and the variable removeIdx is set to 0.

[0228] 2. When NumHmvpIbcCand is greater than 0, for each index (where hMvpIdx = 0..NumHmvpIbcCand-1), the following steps apply until identicalCandExist equals TRUE:

[0229] When bvL equals HmvpIbcCandList[hMvpIdx], identicalCandExist is set to TRUE, and removeIdx is set to hMvpIdx.

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

[0231] – If identicalCandExist equals TRUE or NumHmvpIbcCand equals 5, then the following applies:

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

[0233] –HmvpIbcCandList[NumHmvpIbcCand-1] is set to equal bvL.

[0234] – Otherwise (identicalCandExist equals FALSE, and NumHmvpIbcCand is less than 5), the following applies:

[0235] –HmvpIbcCandList[NumHmvpIbcCand++] is set to equal bvL.

[0236] 8.6.4 Decoding process of IBC blocks

[0237] 8.6.4.1 General

[0238] This procedure is invoked when decoding a codec unit that is encoded and decoded in IBC prediction mode.

[0239] The input to this process is:

[0240] – Luminance position (xCb, yCb), specifies the top-left luminance sample of the current codec block relative to the top-left luminance sample of the current image.

[0241] – The variable cbWidth specifies the width of the current codec block in the luminance sample.

[0242] – The variable cbHeight specifies the height of the current codec block in the luminance sample.

[0243] –Block vector bv,

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

[0245] The output of this process is:

[0246] – An array of predicted sample points, predSamples.

[0247] When cIdx equals 0, for x = xCb..xCb + cbWidth-1 and y = yCb..yCb + cbHeight-1, the following applies:

[0248] xVb=(x+(bv[0]>>4))&(IbcBufWidthY-1) (1127)

[0249] yVb=(y+(bv[1]>>4))&(CtbSizeY-1) (1128)

[0250] predSamples[x][y]=ibcVirBuf[0][xVb][yVb] (1129)

[0251] When cIdx is not equal to 0, for x = xCb / subWidthC..xCb / subWidthC + cbWidth / subWidthC-1 and y = yCb / subHeightC..yCb / subHeightC + cbHeight / subHeightC-1, the following applies:

[0252] xVb=(x+(bv[0]>>5))&(IbcBufWidthC-1) (1130)

[0253] yVb=(y+(bv[1]>>5))&((CtbSizeY / subHeightC)-1) (1131)

[0254] predSamples[x][y]=ibcVirBuf[cIdx][xVb][yVb] (1132)

[0255] When cIdx equals 0, for x = 0..cbWidth-1 and y = 0..cbHeight-1, the following assignment is made:

[0256] MvL0[xCb+x][yCb+y]=bv (1133)

[0257] MvL1[xCb+x][yCb+y]=0 (1134)

[0258] RefIdxL0[xCb+x][yCb+y]=-1 (1135)

[0259] RefIdxL1[xCb+x][yCb+y]=-1 (1136)

[0260] PredFlagL0[xCb+x][yCb+y]=0 (1137)

[0261] PredFlagL1[xCb+x][yCb+y]=0 (1138)

[0262] BcwIdx[xCb+x][yCb+y]=0 (1139)

[0263] 2.10. Palette Mode

[0264] In VVC, palette mode is used for screen content encoding and decoding in all chroma formats supported by the 4:4:4 profile (i.e., 4:4:4, 4:2:0, 4:2:2, and monochrome). When palette mode is enabled, a flag indicating whether palette mode is used is sent at the CU level if the CU size is less than or equal to 64x64. The codec unit (CU) for palette encoding and decoding is considered as a prediction mode other than intra-prediction, inter-prediction, and intra-block copy (IBC) modes.

[0265] If a palette mode is used, sample values ​​in the CU are represented by a representative set of color values. This set is called the palette. For sample values ​​close to palette colors, signaling is used to notify the palette index. Samples outside the palette can also be specified by signaling an escape symbol. For samples encoded and decoded using escape symbols within the CU, their component values ​​are signaled directly using (possibly) quantized component values. This is in... Figure 9 As shown in the image.

[0266] For palette encoding / decoding, palette prediction values ​​are maintained. For non-wavefront cases, prediction values ​​are initialized to 0 at the beginning of each stripe, and for wavefront cases, they are initialized to 0 at the beginning of each CTU line. For each entry in the palette prediction values, a reuse flag is signaled to indicate whether it is part of the current palette in the CU. The reuse flag is transmitted using zero run-length encoding / decoding. Subsequently, the number of new palette entries and the component values ​​of the new palette entries are signaled. After encoding the palette encoding / decoding CU, the palette prediction values ​​are updated using the current palette, and entries from previous palette prediction values ​​that are not reused in the current palette are appended to the end of the new palette prediction values ​​until the maximum allowed size is reached. An escape flag is signaled for each CU to indicate whether an escape symbol exists in the current CU. If an escape symbol exists, the palette table is incremented by 1, and the last index is designated as the escape symbol.

[0267] Similar to coefficient groups (CGs) used in transform coefficient encoding and decoding, the CU encoded and decoded in palette mode is divided into multiple line-based coefficient groups, each consisting of m samples (i.e., m = 16). The escape mode's indexed run, palette index value, and quantized color are sequentially encoded / parsed for each CG. As with HEVC, horizontal or vertical traversal scans can be applied to scan the samples, such as... Figure 10 As shown.

[0268] The encoding order of the palette run-length encoding / decoding in each segment is as follows: For each sample location, the signaling notifies one context codec bit `run_copy_flag = 0` to indicate whether the pixel has the same pattern as the previous sample location; that is, whether both the previously scanned sample and the current sample have run-length type `COPY_ABOVE`, or whether both the previously scanned sample and the current sample have run-length type `INDEX` and the same index value. Otherwise, the signaling notifies `run_copy_flag = 1`. If the current sample and the previous sample have different patterns, the signaling notifies one context codec bit `copy_above_palette_indices_flag` to indicate the run-length type of the current sample, i.e., `INDEX` or `COPY_ABOVE`. Here, if the sample is in the first row (horizontal traversal scan) or the first column (vertical traversal scan), the decoder does not need to resolve the run-length type because the default is `INDEX` mode. Similarly, if the previously resolved run-length type is `COPY_ABOVE`, the decoder does not need to resolve the run-length type. After palette run encoding and decoding of samples in one encoding / decoding pass, the index values ​​(for INDEX mode) and quantized escaped colors are grouped and encoded / decoded using CABAC bypass encoding / decoding in another encoding / decoding pass. This separation of context encoding / decoding bits and bypass encoding / decoding bits can improve throughput within each line CG.

[0269] For stripes with dual luma / chroma trees, the palette is applied separately to the luma (Y component) and chroma (Cb and Cr components), where luma palette entries contain only Y values ​​and chroma palette entries contain both Cb and Cr values. For single-tree stripes, the palette is applied jointly to the Y, Cb, and Cr components, meaning each entry in the palette contains Y, Cb, and Cr values, unless when encoding / decoding the CU using a local dual-tree, in which case luma and chroma encoding / decoding are handled separately. In this case, if the corresponding luma or chroma block is encoded / decoded using a palette mode, its palette is applied in a similar manner to the dual-tree case (this is relevant to non-4:4:4 encoding / decoding).

[0270] For stripes encoded with dual-trees, the maximum palette prediction size is 63, and the maximum palette table size used to encode the current CU is 31. For stripes encoded with dual-trees, the maximum prediction size and palette table size are halved for each of the luma and chroma palettes; that is, the maximum prediction size is 31, and the maximum table size is 15. For deblocking, palette-encoded blocks on the block boundary side are not deblocked.

[0271] 2.10.1 Palette Mode for Non-4:4:4 Content

[0272] Similar to the palette mode in HEVC SCC, VVC's palette mode is supported for all chroma formats. For non-4:4:4 content, the following customizations apply:

[0273] 1. When signaling the escape value for a given sample location, if the sample location only has a luminance component and no chrominance component due to chrominance subsampling, then only the luminance escape value is signaled. This is the same as in HEVC SCC.

[0274] 2. For local double-tree blocks, the palette pattern is applied to the block in the same way as the palette pattern applied to single-tree blocks, with two exceptions:

[0275] a. The palette prediction update process is slightly modified as follows. Since the local dual-tree block only contains the luma (or chroma) component, the prediction update process uses the luma (or chroma) component value notified by the signaling and fills in the "missing" chroma (or luma) component by setting it to the default value (1 << (component bit depth - 1)).

[0276] b. The maximum palette prediction size is kept at 63 (because stripes are encoded and decoded using a single tree), but the maximum palette table size for the luma / chroma block is kept at 15 (because the block is encoded and decoded using a separate palette).

[0277] For monochrome palette mode, the number of color components in the palette codec block is set to 1 instead of 3.

[0278] 2.11. Current text regarding palette encoding / decoding modes in JVET-Q2001-vE

[0279] 2.11.1 Syntax for Palette Encoding / Decoding Mode

[0280]

[0281]

[0282]

[0283]

[0284] 2.11.2 Palette Encoding / Decoding Mode Semantics

[0285] In the following semantics, array indices x0 and y0 specify the position (x0, y0) of the considered codec block relative to the top-left luminance sample of the image. When treeType equals SINGLE_TREE or DUAL_TREE_LUMA, array indices xC and yC specify the position (xC, yC) of the sample relative to the top-left luminance sample of the image; and when treeType equals DUAL_TREE_CHROMA, array indices xC and yC specify the position (xC, yC) of the sample relative to the top-left chrominance sample of the image. The array index startComp specifies the first color component of the current palette table. startComp equals 0 indicates the Y component; startComp equals 1 indicates the Cb component; startComp equals 2 indicates the Cr component. numComps specifies the number of color components in the current palette table.

[0286] The predicted value palette consists of palette entries from previous encoding / decoding units used to predict entries in the current palette.

[0287] PredictorPaletteSize[startComp] specifies the size of the palette, representing the predicted value of the first color component startComp in the current palette table. PredictorPaletteSize[startComp] is derived as specified in Clause 8.4.5.3.

[0288] A value of 1 in `PalettePredictorEntryReuseFlags[i]` indicates that the i-th entry in the predicted value palette is reused in the current palette. A value of 0 in `PalettePredictorEntryReuseFlags[i]` indicates that the i-th entry in the predicted value palette is not an entry in the current palette. All elements of the array `PalettePredictorEntryReuseFlags[i]` are initialized to 0.

[0289] The palette_predictor_run is used to determine the number of zeros preceding non-zero entries in the array PalettePredictorEntryReuseFlags.

[0290] The requirement for bitstream consistency is that the value of `palette_predictor_run` should be within the range of 0 to `(PredictorPaletteSize[startComp] - predictorEntryIdx)` (inclusive), where `predictorEntryIdx` corresponds to the current position in the array `PalettePredictorEntryReuseFlags`. The variable `NumPredictedPaletteEntries` specifies the number of entries reused from the predicted value palette in the current palette. The value of `NumPredictedPaletteEntries` should be within the range of 0 to `maxNumPaletteEntries` (inclusive).

[0291] num_signalled_palette_entries specifies the number of entries in the current palette that are explicitly signaled by startComp for the first color component of the current palette table.

[0292] When num_signalled_palette_entries does not exist, it is inferred to be equal to 0.

[0293] The variable CurrentPaletteSize[startComp] specifies the size of the current palette for the first color component startComp of the current palette table, and is deduced as follows:

[0294] CurrentPaletteSize[startComp]=NumPredictedPaletteEntries+

[0295] num_signalled_palette_entries(180)

[0296] The value of CurrentPaletteSize[startComp] should be in the range of 0 to maxNumPaletteEntries (inclusive).

[0297] new_palette_entries[cIdx][i] specifies the value of the i-th signaling palette entry for color component cIdx.

[0298] The variable PredictorPaletteEntries[cIdx][i] specifies the i-th element in the color palette whose predicted value is cIdx.

[0299] The variable CurrentPaletteEntries[cIdx][i] specifies the i-th element in the current palette for color component cIdx, and is deduced as follows:

[0300]

[0301] A palette_escape_val_present_flag value of 1 indicates that the current codec unit contains at least one escaped codec sample. A palette_escape_val_present_flag value of 0 indicates that there are no escaped codec samples in the current codec unit. When it does not exist, the value of palette_escape_val_present_flag is inferred to be 1.

[0302] The variable MaxPaletteIndex specifies the maximum possible value of the palette index for the current codec unit. The value of MaxPaletteIndex is set to equal CurrentPaletteSize[startComp]-1+palette_escape_val_present_flag.

[0303] palette_idx_idc is an indicator of the index of the palette table CurrentPaletteEntries. For the first index in the block, the value of palette_idx_idc should be in the range of 0 to MaxPaletteIndex (inclusive), and for the remaining indices in the block, the value of palette_idx_idc should be in the range of 0 to (MaxPaletteIndex-1) (inclusive).

[0304] When palette_idx_idc does not exist, it is inferred to be equal to 0.

[0305] A palette_transpose_flag value of 1 specifies that a vertical traversal scan is applied to scan the indices of the samples in the current codec unit. A palette_transpose_flag value of 0 specifies that a horizontal traversal scan is applied to scan the indices of the samples in the current codec unit. When it does not exist, the value of palette_transpose_flag is inferred to be 0.

[0306] The array TraverseScanOrder specifies the scan order array for the palette encoding and decoding. If palette_transpose_flag is equal to 0, TraverseScanOrder is assigned the horizontal scan order HorTravScanOrder, and if palette_transpose_flag is equal to 1, TraverseScanOrder is assigned the vertical scan order VerTravScanOrder.

[0307] `run_copy_flag` equal to 1 specifies that if `copy_above_palette_indices_flag` equals 0, the palette run type is the same as the run type at the previous scan position, and the palette run index is the same as the index at the previous scan position. Otherwise, `run_copy_flag` equal to 0 specifies that the palette run type is different from the run type at the previous scan position.

[0308] `copy_above_palette_indices_flag` equal to 1 specifies that if a horizontal traversal scan is used, the palette index is equal to the palette index at the same position in the previous row; or if a vertical traversal scan is used, the palette index is equal to the palette index at the same position in the left column. `copy_above_palette_indices_flag` equal to 0 specifies that the palette index of the sample is either encoded / decoded or inferred in the bitstream.

[0309] The variable CopyAboveIndicesFlag[xC][yC] equal to 1 specifies that the palette index is copied from the palette index in the previous row (horizontal scan) or the left column (vertical scan). CopyAboveIndicesFlag[xC][yC] equal to 0 specifies that the palette index is explicitly encoded or decoded in the bitstream or inferred.

[0310] The variable PaletteIndexMap[xC][yC] specifies the palette index, which is the index of the array represented by CurrentPaletteEntries. The value of PaletteIndexMap[xC][yC] should be in the range of 0 to MaxPaletteIndex (inclusive).

[0311] The variable adjustedRefPaletteIndex is derived as follows:

[0312]

[0313]

[0314] When CopyAboveIndicesFlag[xC][yC] equals 0, the variable CurrPaletteIndex is deduced as follows:

[0315] if(CurrPaletteIndex>=adjustedRefPaletteIndex)

[0316] CurrPaletteIndex++(183)

[0317] Palette_escape_val specifies the escape codec sample value for the quantization of a component.

[0318] The variable PaletteEscapeVal[cIdx][xC][yC] specifies the escape value of the sample, whose PaletteIndexMap[xC][yC] is equal to MaxPaletteIndex, and palette_escape_val_present_flag is equal to 1. The array index cIdx specifies the color component.

[0319] The requirement for bitstream consistency is that, for cIdx equal to 0, PaletteEscapeVal[cIdx][xC][yC] should be in the range of 0 to (1<<(BitDepth+1))-1 (inclusive), and for cIdx not equal to 0, PaletteEscapeVal[cIdx][xC][yC] should be in the range of 0 to (1<<(BitDepth+1))-1 (inclusive).

[0320] 2.11.3 Decoding process of palette mode

[0321] The input to this process is:

[0322] – Position (xCbComp, yCbComp): Specifies the top-left sample of the current codec block relative to the top-left sample of the current image.

[0323] The `treeType` variable specifies whether to use a single-tree or dual-tree configuration. If a dual-tree configuration is used, it specifies whether the current tree corresponds to the luminance or chrominance component.

[0324] – The variable cIdx specifies the color components of the current block.

[0325] – Two variables, nCbW and nCbH, specify the width and height of the current codec block, respectively.

[0326] The output of this process is an array recSamples[x][y] (where x = 0..nCbW-1, y = 0..nCbH-1), which specifies the reconstructed sample values ​​of the block.

[0327] Based on the value of treeType, the variables startComp, numComps, and maxNumPalettePredictorSize are deduced as follows:

[0328] –If treeType equals SINGLE_TREE:

[0329] startComp = 0 (430)

[0330] numComps = ChromaArrayType = = 0? 1 : 3 (431)

[0331] maxNumPalettePredictorSize = 63 (432)

[0332] Otherwise, treeType equals DUAL_TREE_LUMA:

[0333] startComp = 0 (433)

[0334] numComps = 1 (434)

[0335] maxNumPalettePredictorSize = 31 (435)

[0336] Otherwise, treeType equals DUAL_TREE_CHROMA:

[0337] startComp = 1 (436)

[0338] numComps = 2 (437)

[0339] maxNumPalettePredictorSize = 31 (438)

[0340] Based on the value of cIdx, the variables nSubWidth and nSubHeight are derived as follows:

[0341] – If cIdx is greater than 0 and startComp is equal to 0, then nSubWidth is set to SubWidthC and nSubHeight is set to SubHeightC.

[0342] Otherwise, nSubWidth is set to 1, and nSubHeight is set to 1.

[0343] The (nCbW x nCbH) block of the reconstructed sample array recSamples at position (xCbComp, yCbComp) is represented by recSamples[x][y] (x = 0..nCbW-1, and y = 0..nCbH-1), and the value of recSamples[x][y] is derived as follows for each x in the range from 0 to nCbW-1 (inclusive) and for each y in the range from 0 to nCbH-1 (inclusive):

[0344] – The variables xL, yL, xCbL, and yCbL are derived as follows:

[0345] xL = x * nSubWidth (439)

[0346] yL = y * nSubHeight (440)

[0347] xCbL = xCbComp * nSubWidth (441)

[0348] yCbL = yCbComp * nSubHeight (442)

[0349] – The variable bIsEscapeSample is derived as follows:

[0350] – If PaletteIndexMap[xCbL+xL][yCbL+yL] equals MaxPaletteIndex and palette_escape_val_present_flag equals 1, then bIsEscapeSample is set to equal 1.

[0351] Otherwise, bIsEscapeSample is set to 0.

[0352] –If bIsEscapeSample equals 0, then the following applies:

[0353] recSamples[x][y]=

[0354] CurrentPaletteEntries[cIdx][PaletteIndexMap[xCbL+xL][yCbL+yL]](443)

[0355] Otherwise (bIsEscapeSample equals 1), the following ordered steps apply:

[0356] 1. The quantization parameter qP is derived as follows:

[0357] –If cIdx equals 0

[0358] qP = Max(QpPrimeTsMin, Qp′Y) (444)

[0359] Otherwise, if cIdx equals 1,

[0360] qP = Max(QpPrimeTsMin, Qp′Cb) (445)

[0361] Otherwise (cIdx equals 2),

[0362] qP = Max(QpPrimeTsMin, Qp′Cr) (446)

[0363] 2. The list levelScale[] is specified as levelScale[k] = {40, 45, 51, 57, 64, 72}, where k = 0..5.

[0364] 3. The following applies:

[0365] tmpVal=(PaletteEscapeVal[cIdx][xCbL+xL][yCbL+yL]*

[0366] levelScale[ qP%6 ] ) << ( qP / 6 ) + 32 ) >> 6 (447) recSamples[x][y]=Clip3(0,(1< <BitDepth)-1,tmpVal) (448)

[0367] The variable localDualTree is deduced as follows:

[0368] localDualTree=treeType! =SINGLE_TREE&&

[0369] (slice_type!=I||(slice_type==I&&

[0370] qtbtt_dual_tree_intra_flag = = 0 ) ) ? 1 : 0 (449)

[0371] When localDualTree equals 1, the following applies:

[0372] – If treeType equals DUAL_TREE_LUMA, then for i = 0..num_signalled_palette_entries[startComp] - 1, the following applies:

[0373] CurrentPaletteEntries[1][NumPredictedPaletteEntries+i]=

[0374] 1 << ( BitDepth - 1 ) (450)

[0375] CurrentPaletteEntries[2][NumPredictedPaletteEntries+i]=

[0376] 1 << ( BitDepth - 1 ) (451)

[0377] – Otherwise (if treeType equals DUAL_TREE_CHROMA), then for i = 0..num_signalled_palette_entries[startComp] - 1, the following applies:

[0378] CurrentPaletteEntries[0][NumPredictedPaletteEntries+i]=

[0379] 1 << ( BitDepth - 1 ) (452)

[0380] – The variables CurrentPaletteSize[0], startComp, numComps, and maxNumPalettePredictorSize are derived as follows:

[0381] CurrentPaletteSize[ 0 ] = CurrentPaletteSize[ startComp ] (453)

[0382] startComp = 0 (454)

[0383] numComps = 3 (455)

[0384] maxNumPalettePredictorSize = 63 (456)

[0385] When one of the following conditions is true:

[0386] –cIdx equals 0, and numComps equals 1;

[0387] –cIdx equals 2;

[0388] The value PredictorPaletteSize[startComp] and the array PredictorPaletteEntries are deduced or modified as follows:

[0389]

[0390]

[0391] The following applies when qtbtt_dual_tree_intra_flag equals 0 or slice_type is not equal to I:

[0392] PredictorPaletteSize[ 1 ] = newPredictorPaletteSize (458)

[0393] The requirement for bitstream consistency is that the value of PredictorPaletteSize[startComp] should be within the range of 0 to maxNumPalettePredictorSize (inclusive).

[0394] 3. Examples of problems solved by various embodiments

[0395] There are some issues with the current design of the IBC virtual buffer.

[0396] 1) When the current CU is greater than one VPDU, that is, when the current CU includes multiple VPDUs, only one VPDU in the IBC virtual buffer is reset.

[0397] 2) The palette mode can be further improved.

[0398] 4. List of embodiments and technologies

[0399] The width and height of the VPDU are represented by vSize, for example, VSize = min(64, ctbSizeY), where ctbSizeY is the width / height of the luminance CTB / CTU.

[0400] IBC buffer related

[0401] 1. When the block (CU / CB) size is larger than the VPDU size, all corresponding VPDUs in the IBC buffer can be reset.

[0402] a. In one example, the corresponding VPDU is defined as the VPDU that overlaps with the CU mapped to the IBC buffer.

[0403] b. In one example, all corresponding VPDUs are reset to -1.

[0404] c. In one example, the width of the region within the IBC buffer is deduced as max(VSize, block width) instead of VSize, where the region is the one that needs to be reset.

[0405] d. In one example, the height of the region within the IBC buffer is derived as max(VSize, block height) instead of VSize, where the region is the one that needs to be reset.

[0406] Palette mode related

[0407] 2. The predicted values ​​in the prediction palette can be updated before encoding / decoding a new block.

[0408] a. In one example, the palette prediction value can be updated using information encoded and decoded in a previous palette codec block.

[0409] b. In one example, the palette prediction can be updated using a palette prediction previously used with the same entry.

[0410] c. In one example, the difference between the palette prediction and its updated value can be indicated in the bitstream.

[0411] 5. Example of an implementation plan

[0412] 5.1. Example #1

[0413] use Bold underline The tagging change is based on JVET-Q2001-vD.

[0414] 7.4.11.5 Semantics of Encoding / Decoding Units

[0415] When ResetIbcBuf equals 1, the following applies:

[0416] – For x = 0..IbcBufWidthY-1 and y = 0..CtbSizeY-1, perform the following assignment:

[0417] IbcVirBuf[0][x][y]=-1 (178)

[0418] – The variable ResetIbcBuf is set to equal to 0.

[0419] When x0%VSize equals 0 and y0%VSize equals 0, for and Perform the following assignment:

[0420] IbcVirBuf[0][(x+(IbcBufWidthY>>1))%IbcBufWidthY][y%CtbSizeY] = -1(179)

[0421] Figure 1 This is a block diagram illustrating an example video processing system 1900 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 1900. System 1900 may include an input 1902 for receiving video content. The video content may be received in a raw or uncompressed format, such as 8 or 10-bit multi-component pixel values, or it may be in a compressed or encoded format. Input 1902 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.

[0422] System 1900 may include a codec component 1904 capable of implementing the various codec or encoding methods described in this document. Codec component 1904 can reduce the average bit rate of the video from input 1902 to the output of codec component 1904 to produce a codec representation of the video. Codec techniques are therefore sometimes referred to as video compression or video transcoding techniques. The output of codec component 1904 may be stored or transmitted via a communication connection, as represented by component 1906. The bitstream (or codec) representation of the video received at input 1902, whether stored or communicated, can be used by component 1908 to generate pixel values ​​or transmit as displayable video to display interface 1910. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. Furthermore, although some video processing operations are referred to as “codec” operations or tools, it will be understood that codec tools or operations are used at the encoder, and the corresponding decoding tools or operations that inversely represent the codec results will be performed by the decoder.

[0423] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), or DisplayPort. Examples of storage interfaces include SATA (Serial Advanced Technology Accessory), PCI, IDE, etc. The technologies described in this document can be found in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.

[0424] Figure 2 This is a block diagram of a video processing apparatus 3600. Apparatus 3600 can be used to implement one or more methods described herein. Apparatus 3600 can be embodied in smartphones, tablets, computers, Internet of Things (IoT) receivers, etc. Apparatus 3600 may include one or more processors 3602, one or more memories 3604, and video processing hardware 3606. The processors (multiple) 3602 can be configured to implement one or more methods described in this document. The memories (multiple) 3604 can be used to store data and code for implementing the methods and techniques described herein. The video processing hardware 3606 can be used to implement some of the techniques described in this document in a hardware circuit system.

[0425] Figure 4 This is a block diagram illustrating an example video codec system 100 that can utilize the techniques disclosed herein.

[0426] like Figure 4 As shown, the video encoding / decoding system 100 may include a source device 110 and a target device 120. The source device 110 generates encoded video data, and this source device 110 may be referred to as a video encoding device. The target device 120 can decode the encoded video data generated by the source device 110, and this target device 120 may be referred to as a video decoding device.

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

[0428] Video source 112 may include sources such as video capture devices, interfaces for receiving video data from video content providers, and / or computer graphics systems for generating video data, or combinations of these sources. Video data may include one or more pictures. Video encoder 114 encodes the video data from video source 112 to generate a bitstream. The bitstream may include a sequence of bits forming a codec representation of the video data. The bitstream may include codec pictures and related data. A codec picture is a codec representation of a picture. Related data may include sequence parameter sets, picture parameter sets, and other syntax structures. I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. Encoded video data may be transmitted directly to target device 120 via network 130a through I / O interface 116. Encoded video data may also be stored on storage medium / server 130b for access by target device 120.

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

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

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

[0432] Figure 5 This is a block diagram illustrating an example of a video encoder 200, which may be... Figure 4 The video encoder 114 in the system 100 shown.

[0433] The video encoder 200 can be configured to perform any or all of the techniques disclosed herein. Figure 5 In the example, the video encoder 200 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of the video encoder 200. In some examples, the processor can be configured to perform any or all of the techniques described in this disclosure.

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

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

[0436] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, can be highly integrated, but for illustrative purposes, in Figure 5 The example is shown separately.

[0437] The segmentation unit 201 can segment an image into one or more video blocks. The video encoder 200 and the video decoder 300 can support various video block sizes.

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

[0439] To perform inter-frame prediction on the current video block, motion estimation unit 204 can generate motion information for the current video block by comparing one or more reference frames from buffer 213 with the current video block. Motion compensation unit 205 can determine the predicted video block for the current video block based on the motion information and decoded samples of images from buffer 213 other than the image associated with the current video block.

[0440] The motion estimation unit 204 and the motion compensation unit 205 can perform different operations on the current video block, for example, depending on whether the current video block is in an I-band, P-band, or B-band.

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

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

[0443] In some examples, the motion estimation unit 204 can output a complete set of motion information for use in the decoder's decoding process.

[0444] In some examples, the motion estimation unit 204 may not output the complete set of motion information for the current video. Instead, the motion estimation unit 204 may refer to motion information signaling from another video block to inform the motion information of the current video block. For example, the motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.

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

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

[0447] As discussed above, the video encoder 200 can predictively signal motion vectors. Two examples of predictive signaling notification techniques that can be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and Merge Pattern Signaling Notification.

[0448] Intra-prediction unit 206 can perform intra-prediction on the current video block. When intra-prediction unit 206 performs intra-prediction on the current video block, it can generate prediction data for the current video block based on decoded samples from other video blocks in the same frame. The prediction data for the current video block can include the predicted video block and various syntax elements.

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

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

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

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

[0453] Inverse quantization unit 210 and inverse transform unit 211 can apply inverse quantization and inverse transform to the transform coefficient video block, respectively, to reconstruct the residual video block from the transform coefficient video block. Reconstruction unit 212 can add the reconstructed residual video block to the corresponding samples of one or more predicted video blocks generated by prediction unit 202 to produce a reconstructed video block associated with the current block, which is stored in buffer 213.

[0454] After the video block is reconstructed by the reconstruction unit 212, a loop filtering operation can be performed to reduce the video block effect in the video block.

[0455] Entropy encoding unit 214 can receive data from other functional components of video encoder 200. When entropy encoding unit 214 receives data, it can perform one or more entropy encoding operations to generate entropy encoded data and output a bit stream including the entropy encoded data.

[0456] Figure 6 This is a block diagram illustrating an example of a video decoder 300, which may be... Figure 4 The video decoder 114 in the system 100 shown.

[0457] The video decoder 300 can be configured to perform any or all of the technologies disclosed herein. Figure 6 In the example, the video decoder 300 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of the video decoder 300. In some examples, the processor can be configured to perform any or all of the techniques described in this disclosure.

[0458] exist Figure 6 In the example, video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, video decoder 300 can perform functions typically associated with video encoder 200. Figure 5 The encoding process described is the opposite of the decoding process.

[0459] The entropy decoding unit 301 can retrieve the encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., encoded blocks of video data). The entropy decoding unit 301 can decode the entropy-coded video data, and from the entropy-coded video data, the motion compensation unit 302 can determine motion information including motion vectors, motion vector precision, reference image list index, and other motion information. The motion compensation unit 302 can determine such information, for example, by executing AMVP and Merge modes.

[0460] The motion compensation unit 302 can generate motion compensation blocks and can perform interpolation based on an interpolation filter. The identifier of the interpolation filter to be used at sub-pixel precision can be included in the syntax element.

[0461] The motion compensation unit 302 can use an interpolation filter, such as that used by the video encoder 200 during the encoding of a video block, to calculate the interpolation of sub-integer pixels of the reference block. The motion compensation unit 302 can determine the interpolation filter used by the video encoder 200 based on the received syntax information, and use the interpolation filter to generate the prediction block.

[0462] The motion compensation unit 302 may use some syntax information to determine the size of the blocks used to encode (multiple) frames and / or (multiple) stripes of the encoded video sequence, segmentation information describing how each macroblock of the image of the encoded video sequence is segmented, a pattern indicating how each segment is encoded, one or more reference frames (and a list of reference frames) for each inter-frame coded block, and other information for decoding the encoded video sequence.

[0463] Intra-prediction unit 303 can use, for example, an intra-prediction mode received in the bitstream to form prediction blocks from spatially adjacent blocks. Inverse quantization unit 303 performs inverse quantization, i.e., dequantization, on the quantized video block coefficients provided in the bitstream and decoded by entropy decoding unit 301. Inverse transform unit 303 applies an inverse transform.

[0464] The reconstruction unit 306 can add the residual block to the corresponding prediction block generated by the motion compensation unit 202 or the intra-frame prediction unit 303 to form a decoded block. If necessary, a deblocking filter can also be applied to filter the decoded block to remove block artifacts. The decoded video block is then stored in the buffer 307 to provide a reference block for subsequent motion compensation / intra-frame prediction, and also generates the decoded video for presentation on the display device.

[0465] The following provides a list of preferred first solutions for some embodiments.

[0466] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., item 1).

[0467] 1. A video processing method (e.g., Figure 3 The method 3000 includes: determining (3002) that a video block satisfies a condition for a conversion between a video block and a codec representation of the video, wherein the video block is encoded and decoded in the codec representation using an intra-block copy mode, wherein in the intra-block copy mode, reference samples from the same picture as the video block are used to predict the video block; and performing a conversion based on the determination (3004); wherein a portion of the intra-block copy buffer is reset during the conversion because the video block satisfies the condition.

[0468] 2. The method according to Solution 1, wherein the portion includes all corresponding Virtual Pipeline Data Units (VPDUs) in the intra-block copy buffer.

[0469] 3. The method according to Solution 2, wherein the corresponding VPDU overlaps with the video block in the intra-block copy buffer.

[0470] 4. The method according to any one of solutions 2-3, wherein VPDU is reset to a value equal to -1.

[0471] 5. The method according to Solution 1, wherein the portion corresponds to a region with a width equal to the maximum of VSize and the width of the video block, where VSize represents the size of the virtual pipeline data unit.

[0472] 6. The method according to Solution 1, wherein the portion corresponds to a region having a height equal to the maximum of VSize and the height of the video block, where VSize represents the size of the virtual pipeline data unit.

[0473] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., item 2).

[0474] 7. A method of video processing, comprising: performing a conversion between one or more video blocks of a video and a codec representation of the video, wherein the one or more video blocks are encoded and decoded using a palette of representative samples, wherein the palette is predicted and encoded / decoded in the codec representation using palette prediction values, and wherein the palette prediction values ​​are updated before processing each of the one or more video blocks.

[0475] 8. The method according to Solution 7, wherein the palette prediction value is updated using information from previous video blocks from one or more video blocks.

[0476] 9. The method according to Solution 7, wherein the palette prediction value is updated using a previous palette prediction value with the same entries.

[0477] 10. The method according to any one of solutions 7-9, wherein the encoding / decoding representation includes a field indicating the difference between the palette prediction value and the updated value of the palette prediction value.

[0478] 11. The method according to any one of solutions 1 to 17, wherein the conversion includes encoding the video into a codec representation.

[0479] 12. The method according to any one of solutions 1 to 17, wherein the conversion includes decoding the codec representation to generate pixel values ​​of the video.

[0480] 13. A video decoding apparatus, comprising a processor configured to implement the method according to one or more of solutions 1 to 19.

[0481] 14. A video encoding apparatus, comprising a processor configured to implement the method according to one or more of solutions 1 to 19.

[0482] 15. A computer program product storing computer code, which, when executed by a processor, causes the processor to perform the method according to any one of solutions 1 to 19.

[0483] 16. A method, apparatus or system described in this document.

[0484] The following examples list a set of second solutions for preferred implementations of some embodiments.

[0485] 1. A video processing method (e.g., Figure 12 The method 1200 includes: determining (1202) that the video block satisfies a condition for the conversion between a video block of a video and a bitstream of a video, wherein the video block is encoded and decoded in the bitstream using an intra-block copy mode; and performing the conversion based on the determination (1204); wherein a portion of the intra-block copy buffer is reset during the conversion because the video block satisfies the condition.

[0486] 2. The method according to Example 1, wherein the portion includes all corresponding Virtual Pipeline Data Units (VPDUs) in the intra-block copy buffer.

[0487] 3. The method according to Example 2, wherein the corresponding VPDU overlaps with the video block in the intra-block copy buffer.

[0488] 4. The method according to any one of Examples 2-3, wherein VPDU is reset to a value equal to -1.

[0489] 5. The method according to Example 1, wherein the portion corresponds to a region with a width equal to the maximum of VSize and the width of the video block, where VSize represents the size of the virtual pipeline data unit.

[0490] 6. The method according to Example 1, wherein the portion corresponds to a region having a height equal to the maximum of VSize and the height of the video block, where VSize represents the size of the virtual pipeline data unit.

[0491] 7. The method according to any one of Examples 1-6, wherein an intra-frame block copy mode is used to predict block derivation from the sample values ​​of the same decoded strip determined by the block vector corresponding to the video block.

[0492] 8. A method for video processing (e.g., Figure 11Method 1100 in the video includes: performing a conversion between one or more video blocks of the video and a bitstream of the video (1102), wherein the one or more video blocks are encoded and decoded using a palette of representative samples, wherein the palette is predicted and encoded and decoded in the bitstream using palette prediction values, and wherein the palette prediction values ​​are updated before processing each of the one or more video blocks.

[0493] 9. The method according to Example 8, wherein the palette prediction value is updated using information from previous video blocks that were encoded or decoded before one or more video blocks.

[0494] 10. According to the method of Example 8, the palette prediction value is updated using the previous palette prediction value with the same entries.

[0495] 11. The method according to any one of Examples 8-10, wherein the bit stream includes a field indicating the difference between the palette prediction value and the updated value of the palette prediction value.

[0496] 12. The method according to any one of Examples 1 to 11, wherein performing the conversion includes encoding video blocks into a bitstream.

[0497] 13. The method according to any one of Examples 1 to 11, wherein performing the conversion includes generating a bitstream based on the video, and the method further includes storing the bitstream in a non-transitory computer-readable recording medium.

[0498] 14. The method according to any one of Examples 1 to 11, wherein performing the conversion includes decoding video from the bitstream.

[0499] 15. A video decoding apparatus, comprising a processor configured to implement one or more of the methods described in Examples 1 to 11.

[0500] 16. A video encoding apparatus comprising a processor configured to implement one or more of the methods described in Examples 1 to 11.

[0501] 17. A computer program product storing computer instructions that, when executed by a processor, cause the processor to perform the method according to any one of Examples 1 to 14.

[0502] 18. A non-transitory computer-readable storage medium for storing a bit stream generated according to any one of Examples 1 to 11.

[0503] 19. A non-transitory computer-readable storage medium for storing instructions that cause a processor to perform the method according to any one of Examples 1 to 14.

[0504] 20. A method for generating a bitstream, comprising: generating a bitstream of video according to any one of Examples 1 to 11, and storing the bitstream on a computer-readable program medium.

[0505] 21. A method, an apparatus, or a bit stream generated according to the disclosed method or system described in this document.

[0506] In this document, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm can be applied during the conversion from the pixel representation of a video to the corresponding bitstream representation, and vice versa. As defined in the syntax, the bitstream representation of the current video block can, for example, correspond to bits that are co-occurring or scattered throughout the bitstream. For example, a macroblock can be encoded using the error residuals from the transformation and encoding / decoding, and also using bits from the header and other fields in the bitstream. Furthermore, during the conversion, the decoder can, based on this determination, parse the bitstream knowing that some fields may or may not be present, as described in the solutions above. Similarly, the encoder can determine whether to include or exclude specific syntax fields and generate the codec representation accordingly by including or excluding syntax fields from the codec representation.

[0507] The disclosed and other solutions, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware, or hardware (including the structures disclosed in this document and their structural equivalents), or in a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by or control of the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances affecting machine-readable propagation signals, or a combination of one or more of them. The term "data processing apparatus" includes all means, 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 also include code that creates an execution environment for the computer program in question, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. Propagation signals are artificially generated signals, such as machine-generated electrical signals, optical signals, or electromagnetic signals, generated to encode information for transmission to a suitable receiver device.

[0508] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language (including compiled or interpreted languages) and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing one or more modules, subroutines, or code sections). A computer program can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected via a communications network.

[0509] The processes and logic described in this document can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processes and logic can also be executed by dedicated logic circuits, and the devices can be implemented as dedicated logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).

[0510] Processors suitable for executing computer programs include, for example, general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, a processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled to receive data from, transfer data to, or receive data from and transfer data to such mass storage devices. However, a computer does not require such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. The processor and memory may be supplemented by or incorporated into special-purpose logic circuitry.

[0511] While this patent document contains numerous details, these details should not be construed as limiting any subject matter or potentially claimed scope, but rather as descriptions of features specific to particular embodiments of a particular art. Certain features described in this patent document within the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually in multiple embodiments or in any suitable sub-combination. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed in this way, in some cases one or more features from the claimed combination may be excluded from the combination, and the claimed combination may be for sub-combinations or variations thereof.

[0512] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring the operations to be performed in the specific order shown or in a sequential manner, or as performing all shown operations to achieve the desired result. Furthermore, the separation of various system components in the embodiments described in this patent document should not be construed as requiring such separation in all embodiments.

[0513] Only some implementation methods and examples are described, and other implementation methods, enhancements and variations can be made based on the content described and shown in this patent document.

Claims

1. A method of processing video data, comprising: for a conversion between a video block of a video picture of a video and a bitstream of the video, determining that a first prediction mode is applied to the video block, For the first prediction mode, an IBC buffer comprising reference samples derived from the video picture is maintained, wherein in the first prediction mode, prediction samples of the video block are derived from reference samples in the IBC buffer determined by a block vector; and performing the conversion based on the determining; wherein reference samples in a first region of the IBC buffer are set to -1 and unavailable for deriving the prediction samples, the first region comprising a virtual unit overlapping with the video block mapped to the IBC buffer, wherein the first region maps to a second region of the video picture, wherein when a width of the video block is larger than a size of the virtual unit, a width of the second region is equal to the width of the video block, and when a height of the video block is larger than the size of the virtual unit, a height of the second region is equal to the height of the video block, and wherein when x0 % VSize is equal to 0 and y0 % VSize is equal to 0, a position (x, y) in the second region is mapped to a position ((x + (IbcBufWidthY » 1)) % IbcBufWidthY), (y % CtbSizeY)) in the first region, IbcBufWidthY represents a width of the IBC buffer, CtbSizeY represents a size of a luma coding tree block, x0 and y0 represent starting coordinates of the virtual unit, and VSize represents a size of the virtual unit.

2. The method of claim 1, wherein, a top-left corner of the second region is a top-left corner of the virtual unit.

3. The method of claim 1, wherein, when the width of the video block is smaller than the size of the virtual unit, the width of the second region is equal to the width of the virtual unit.

4. The method of claim 3, wherein, when the height of the video block is smaller than the size of the virtual unit, the height of the second region is equal to the height of the virtual unit.

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

6. The method of claim 1, wherein, the conversion comprises decoding the video block from the bitstream.

7. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to: for a conversion between a video block of a video picture of a video and a bitstream of the video, determine that a first prediction mode is applied to the video block, For the first prediction mode, an IBC buffer comprising reference samples derived from the video picture is maintained, wherein in the first prediction mode, prediction samples of the video block are derived from reference samples in the IBC buffer determined by a block vector; and perform the conversion based on the determining; wherein reference samples in a first region of the IBC buffer are set to -1 and unavailable for deriving the prediction samples, the first region comprising a virtual unit overlapping with the video block mapped to the IBC buffer, wherein the first region maps to a second region of the video picture, wherein a width of the second region is equal to a width of the video block when the width of the video block is greater than a size of a virtual unit, and a height of the second region is equal to a height of the video block when the height of the video block is greater than the size of the virtual unit, and wherein a position (x, y) in the second region is mapped to a position ((x + (IbcBufWidthY » 1)) % IbcBufWidthY), (y % CtbSizeY)) in the first region when x0 % VSize is equal to 0 and y0 % VSize is equal to 0, IbcBufWidthY denotes a width of the IBC buffer, and CtbSizeY denotes a size of a luma coding tree block.

8. The apparatus of claim 7, wherein, a top-left corner of the second region is a top-left corner of the virtual unit.

9. The apparatus of claim 7, wherein, a width of the second region is equal to a width of the virtual unit when the width of the video block is less than the size of the virtual unit; a height of the second region is equal to a height of the virtual unit when the height of the video block is less than the size of the virtual unit.

10. A non-transitory computer-readable storage medium storing instructions that cause a processor to: for a conversion between a video block of a video picture of a video and a bitstream of the video, determine that a first prediction mode is applied to the video block, For the first prediction mode, an IBC buffer comprising reference samples derived from the video picture is maintained, wherein in the first prediction mode, prediction samples of the video block are derived from reference samples in the IBC buffer determined by a block vector; and perform the conversion based on the determination; wherein reference samples in a first region of the IBC buffer are set to -1 and are unavailable for deriving the prediction samples, the first region comprising a virtual unit overlapping with a video block mapped to the IBC buffer, wherein the first region maps to a second region of the video picture, wherein a width of the second region is equal to a width of the video block when the width of the video block is greater than a size of a virtual unit, and a height of the second region is equal to a height of the video block when the height of the video block is greater than the size of the virtual unit, and wherein a position (x, y) in the second region is mapped to a position ((x + (IbcBufWidthY » 1)) % IbcBufWidthY), (y % CtbSizeY)) in the first region when x0 % VSize is equal to 0 and y0 % VSize is equal to 0, IbcBufWidthY denotes a width of the IBC buffer, and CtbSizeY denotes a size of a luma coding tree block.

11. The non-transitory computer-readable storage medium of claim 10, wherein, a top-left corner of the second region is a top-left corner of the virtual unit.

12. The non-transitory computer-readable storage medium of claim 10, wherein, a width of the second region is equal to a width of the virtual unit when the width of the video block is less than the size of the virtual unit; a height of the second region is equal to a height of the virtual unit when the height of the video block is less than the size of the virtual unit. wherein a height of the second region is equal to a height of the virtual unit when a height of the video block is smaller than a size of the virtual unit.

13. A non-transitory computer-readable recording medium that stores a video bitstream generated by a method performed by a video processing apparatus, wherein, The method comprises: for a conversion between a video block of a video picture of a video and a bitstream of the video, determining that a first prediction mode is applied to the video block, for the first prediction mode, maintaining an IBC buffer that includes reference samples derived from the video picture, wherein in the first prediction mode, prediction samples of the video block are derived from reference samples in the IBC buffer determined by a block vector; and generating the bitstream based on the determining; wherein reference samples in a first region of the IBC buffer are set to -1 and unavailable for deriving the prediction samples, the first region including a virtual unit overlapping with a video block mapped to the IBC buffer, wherein the first region maps to a second region of the video picture, wherein a width of the second region is equal to a width of the video block when a width of the video block is greater than a size of a virtual unit, and a height of the second region is equal to a height of the video block when a height of the video block is greater than the size of the virtual unit, and wherein when x0 % VSize is equal to 0 and y0 % VSize is equal to 0, a position (x, y) in the second region is mapped to a position ((x + (IbcBufWidthY » 1)) % IbcBufWidthY), (y % CtbSizeY)) in the first region, IbcBufWidthY representing a width of the IBC buffer, CtbSizeY representing a size of a luma coding tree block. 14.The non-transitory computer-readable recording medium of claim 13, wherein, a top-left corner of the second region is a top-left corner of the virtual unit; wherein a width of the second region is equal to a width of the virtual unit when a width of the video block is smaller than a size of the virtual unit; wherein a height of the second region is equal to a height of the virtual unit when a height of the video block is smaller than a size of the virtual unit.

15. A method for storing a bitstream of a video, comprising: for a conversion between a video block of a video picture of a video and a bitstream of the video, determining that a first prediction mode is applied to the video block, for the first prediction mode, maintaining an IBC buffer that includes reference samples derived from the video picture, wherein in the first prediction mode, prediction samples of the video block are derived from reference samples in the IBC buffer determined by a block vector; generating the bitstream based on the determining; and storing the bitstream in a non-transitory computer-readable recording medium, wherein reference samples in a first region of the IBC buffer are set to -1 and unavailable for deriving the prediction samples, the first region including a virtual unit overlapping with a video block mapped to the IBC buffer, wherein the first region maps to a second region of the video picture, wherein a width of the second region is equal to a width of the video block when the width of the video block is greater than a size of a virtual unit and a height of the second region is equal to a height of the video block when the height of the video block is greater than the size of the virtual unit, and wherein when x0 % VSize is equal to 0 and y0 % VSize is equal to 0, a position (x, y) in the second region is mapped to a position ((x + (IbcBufWidthY » 1)) % IbcBufWidthY), (y % CtbSizeY)) in the first region, IbcBufWidthY representing a width of the IBC buffer, CtbSizeY representing a size of a luma coding tree block.

Images