Bitstream compatibility constraints for intra block copies in video coding.

Abstract

1. A method for processing visual media, comprising: transforming between a video block of a current picture of the visual media data and a bitstream representation of the visual media data using a buffer containing reference samples from the current picture to derive a prediction block of the current video block, the transformation being based on rules specifying that the reference samples in the buffer shall satisfy bitstream compatibility constraints so that the bitstream representation is compliant with the rules.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a national stage application of International Patent Application No. PCT / CN2020 / 100998, filed July 9, 2020, which claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 095656, filed July 11, 2019, International Patent Application No. PCT / CN2019 / 095913, filed July 13, 2019, and International Patent Application No. PCT / CN2019 / 096048, filed July 15, 2019. For all purposes under law, the entire disclosures of the above applications are incorporated by reference as part of the disclosure herein.

[0002] This patent specification relates to video encoding and decoding techniques, devices and systems. [Background technology]

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

[0004] This specification describes various embodiments and techniques for buffer management and block vector coding in intra block copy mode for decoding or encoding video or images.

[0005] In one exemplary aspect, a visual media processing method is disclosed, which includes: determining a block vector (BVx, BVy) for a conversion between a current video block of a current picture of visual media data and a bitstream representation of the current video block, the validity of the block vector (BVx, BVy) being independent of (1) a position (P, Q) of a sample block and / or (2) whether to reconstruct a sample at position (P, Q) and / or (3) a position of the current video block (wherein the block vector (BVx, BVy) represents a pixel displacement between the current video block and the sample block); and performing the conversion using the block vector in an intra block copy mode based on a reconstructed block located in the same video region as the current video block, which is made of reference samples used to derive a prediction block of the current video block, and during the conversion, determining a prediction sample having a position (A, B) from the reference samples in the buffer depending on at least a size of the buffer and / or a size of the block vector (BVx, BVy).

[0006] In another exemplary aspect, another method of visual media processing is disclosed, the method including: determining whether a block vector (BVx, BVy) corresponding to a current video block of a current picture of visual media data is valid for conversion between the current video block and a bitstream representation of the visual media data according to a rule, the block vector (BVx, BVy) representing a pixel displacement between the current video block and a sample block, and performing the conversion using the block vector based on a reference region from a current picture that includes reference samples used to derive a prediction block of the current video block, the rule being valid if the block vector (BVx, BVy) is: (1) one or more samples from the sample block are outside the current picture, and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and / or (3) one or more samples from the sample block fail to be reconstructed.

[0007] In yet another exemplary aspect, another method of visual media processing is disclosed, the method including performing a conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, the conversion being based on a reference region from the current picture comprising reference samples used to derive a predictive block of the current video block, and a virtual buffer of a defined size is used to track availability of the reference samples for deriving the predictive block.

[0008] In yet another exemplary aspect, another method of visual media processing is disclosed that includes maintaining a buffer including reference samples from a current picture for deriving a prediction block of a current video block of a current picture for conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, where one or more reference samples in the buffer that are marked as unavailable for the derivation have values ​​outside a range of pixel values.

[0009] In another exemplary aspect, another method of video processing is disclosed that includes performing a conversion between a video block of a current picture of the visual media data and a bitstream representation of the visual media data using a buffer including reference samples from the current picture to derive a prediction block of the current video block, the conversion being based on a rule that specifies that the reference samples in the buffer satisfy a bitstream compatibility constraint in order for the bitstream representation to be compliant with the rule.

[0010] In yet another exemplary aspect, a video encoder or decoder device is disclosed, comprising a processing device configured to implement the above-described method.

[0011] In another exemplary aspect, a computer readable program medium is disclosed that stores code embodying processor executable instructions for implementing one of the disclosed methods.

[0012] These and other aspects are described in greater detail herein. [Brief description of the drawings]

[0013] [Figure 1] 1 illustrates current picture reference or intra block copy video or image coding techniques. [Diagram 2] 1 illustrates a dynamic reference region. [Diagram 3] The coding of the block starting at (x,y) is illustrated below. [Figure 4] 1 illustrates possible alternative methods for selecting a previously coded 64x64 block. [Diagram 5] 1 illustrates possible alternative ways to change the encoding / decoding order of a 64x64 block. [Figure 6] 1 is a flow chart illustrating an example of a video or image processing method. [Figure 7] FIG. 1 is a block diagram illustrating a hardware platform for encoding or decoding video or images. [Figure 8] Another possible alternative method for selecting the previous coded 64x64 block when the decoding order of the 64x64 blocks is top-to-bottom, left-to-right is shown. [Figure 9] Another possible alternative for selecting the previously coded 64x64 block is shown. [Figure 10] 1 shows an exemplary flowchart of a decoding process with reshape. [Figure 11] Another possible alternative method for selecting the previous coded 64x64 block is shown when the decoding order of the 64x64 blocks is left-to-right, top-to-bottom. [Figure 12] FIG. 1 shows the IBC reference buffer status, where one block represents a 64×64 CTU. [Figure 13] One arrangement of reference regions for IBC is shown. [Figure 14] 1 shows an alternative arrangement of reference regions for IBCs. [Figure 15] 13 illustrates an alternative placement of reference areas for an IBC when the current virtual pipeline data unit (VPDU) is to the right of a picture boundary. [Figure 16] 1 shows an example of the state of the virtual buffer when VPDUs in one CTU row are decoded sequentially. [Figure 17] FIG. 1 is a block diagram illustrating an example video processing system in which the disclosed techniques can be implemented. [Figure 18]1 is a flow chart illustrating an example of a method for processing visual media. [Figure 19] 1 is a flow chart illustrating an example of a method for processing visual media. [Figure 20] 1 is a flow chart illustrating an example of a method for processing visual media. [Figure 21] 1 is a flow chart illustrating an example of a method for processing visual media. [Figure 22] 1 is a flow chart illustrating an example of a method for processing visual media. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Section headings are used herein for ease of understanding and are not intended to limit embodiments disclosed in a section to only that section. This specification describes various embodiments and techniques for buffer management and block vector coding in intra block copy mode for decoding or encoding video or images.

[0015] 1. Overview

[0016] This specification relates to video coding techniques. In particular, to intra block copy in video coding. This may be applied to standards under development, such as, for example, generic video coding. The present invention is also applicable to future video coding standards or video codecs.

[0017] 2. Brief Description

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

[0019] 2.1 Inter Prediction in HEVC / H.265 Each inter-predicted PU has motion parameters for one or two reference picture lists. The motion parameters include a motion vector and a reference picture index. The use of one of the two reference picture lists may be signaled using inter_pred_idc. The motion vector may be explicitly coded as a delta to the predictor.

[0020] If one CU is coded in skip mode, one PU is associated with this CU, there are no significant residual coefficients, and there are no coded motion vector differentials or reference picture indexes. A merge mode is specified, which obtains motion parameters for the current PU from neighboring PUs, including spatial and temporal candidates. The merge mode can be applied to any inter-predicted PU, not just for skip mode. As an alternative to the merge mode, there is an explicit transmission of motion parameters, where the motion vectors (more precisely, the motion vector differentials (MVDs) compared to the motion vector predictors), the corresponding reference picture indexes of each reference picture list, and the usage status of the reference picture lists are explicitly signaled to each PU. Such a mode is referred to as Advanced Motion Vector Prediction (AMVP) in this disclosure.

[0021] If the signaling indicates to use one of the two reference picture lists, the PU is generated from one block of samples. This is called "uni-prediction." Uni-prediction is available for both P and B slices.

[0022] If the signaling indicates to use both reference picture lists, generate the PU from two blocks of samples. This is called "bi-prediction." Bi-prediction is only available for B slices.

[0023] The inter prediction modes defined in HEVC will be described in detail below. First, the merge mode will be described.

[0024] 2.2 Referencing the current picture Current Picture Referencing (CPR), also known as Intra Block Copy (IBC), is adopted in the HEVC Screen Content Coding Extension (HEVC-SCC) and the current VVC test model. IBC extends the concept of motion compensation from inter-frame coding to intra-frame coding. As shown in Figure 1, the current block is predicted by one reference block in the same picture when CPR is applied. Before encoding or decoding the current block, the samples in the reference block must already be reconstructed. CPR is not very efficient for most camera-captured sequences, but it shows significant coding gain for screen content. The reason is that there are many repeating patterns in screen content pictures, such as icons, characters, etc. CPR can effectively remove the redundancy between these repeating patterns. In HEVC-SCC, an inter-coding unit (CU) can apply CPR if it selects the current picture as its reference picture. In this case, the MV is renamed as the block vector (BV), and the BV always has integer pixel accuracy. To comply with the Main Profile HEVC, the current picture is marked as a "long-term" reference picture in the Decoded Picture Buffer (DPB), just as in the Multiple View / 3D Video Coding standard, inter-view reference pictures are also marked as "long-term" reference pictures.

[0025] After the BV finds its reference block, it can generate a prediction by copying this reference block. The residual can be obtained by subtracting the reference pixels from the original signal. Then, transforms and quantization can be applied as in other coding modes.

[0026] FIG. 1 is an illustration of a current picture reference.

[0027] However, if the reference block is outside the picture, or overlaps with the current block, or is outside the reconstructed region, or is outside the valid region limited by some constraint, some or all of the pixel values ​​are undefined. Basically, there are two solutions to deal with such problems. One is to not allow such situations, e.g. bitstream conformance. The other is to apply padding to these undefined pixel values. The following sub-sections will explain the solutions in detail.

[0028] 2.3 CPR in HEVC Screen Content Encoding Extensions In the screen content coding extensions of HEVC, when a block uses the current picture as a reference, it should be ensured that the entire reference block is within the available reconstructed region, as indicated in the specification text below. The variables offsetX and offsetY are derived as follows: offsetX=(ChromaArrayType==0)?0:(mvCLX[0]&0x7?2:0) (8-104) offsetY=(ChromaArrayType==0)?0:(mvCLX[1]&0x7?2:0) (8-105) It is a bitstream compatibility requirement that if the reference picture is the current picture, the luma motion vector mvLX should obey the following constraints: - When the derivation process for z scan order block availability as specified in Section 6.4.1 is invoked with inputs (xCurr,yCurr) set equal to (xCb,yCb) and nearby luminance location (xNbY,yNbY) set equal to (xPb+(mvLX[0]>>2)-offsetX, yPb+(mvLX[1]>>2)-offsetY), the output is TRUE. - When the derivation process for z scan order block availability as specified in Section 6.4.1 is invoked with inputs (xCurr,yCurr) set equal to (xCb,yCb) and nearby luminance locations (xNbY,yNbY) set equal to (xPb+(mvLX[0]>>2)+nPbW-1+offsetX, yPb+(mvLX[1]>>2)+nPbI-I-1+offsetY), the output is TRUE. - One or both of the following conditions are true: - The value of (mvLX[0]>>2) + nPbW + xB1 + offsetX is less than or equal to 0. - The value of (mvLX[1]>>2) + nPbH + yB1 + offsetY is less than or equal to 0. - The following conditions are true: (xPb+(mvLX[0]>>2)+nPbSw-1+offsetX) / CtbSizeY-xCb / CtbSizeY<=yCb / CtbSizeY-(yPb+(mvLX[1]>>2)+nPbSh-1+offsetY) / CtbSizeY (8-106)

[0029] In this way, cases where the reference block overlaps with the current block or where the reference block is outside the picture do not occur. There is no need to pad the reference block or the predicted block.

[0030] 2.4 CPR / IBC Example In the VVC test model, the entire reference block should have a current coding tree unit (CTU) and does not overlap with the current block, so there is no need to pad the reference or predicted blocks.

[0031] When dual trees are enabled, the partitioning structure may be different for luma and chroma CTUs, so for a 4:2:0 color format, one chroma block (e.g., CU) may correspond to one co-located luma region that is partitioned into multiple luma CUs.

[0032] A chroma block can only be coded in CPR mode if the following conditions are true: 1) Each of the luma CUs of the collocated luma block should be coded in CPR mode. 2) Each of the luma 4x4 blocks' BV is first converted to a chroma block's BV, which is then a valid BV.

[0033] If either of the two conditions is false, the chroma block is not coded in CPR mode.

[0034] The definition of a valid BV is subject to the following constraints: 1) All samples of a reference block identified by a BV should be within a bounded search range (e.g., within the same CTU in the current VVC design). 2) All samples of the reference block identified by BV have been reconstructed.

[0035] 2.5 CPR / IBC Example In some embodiments, the reference region for CPR / IBC is limited to the current CTU, with a maximum of 128 x 128. The reference region is dynamically changed to reuse memory to store the reference samples for CPR / IBC, so that the CPR / IBC block can have more reference candidates while the reference buffer for CPR / IBC can be maintained or reduced from one CTU.

[0036] Figure 2 shows one method, where a block is 64x64 and a CTU contains four 64x64 blocks. When encoding a 64x64 block, the previous three 64x64 blocks can be used as references. By doing so, the decoder only needs to store four 64x64 blocks to support CPR / IBC.

[0037] Let (x,y) be the position of the current luma CU relative to the top-left corner of the picture, and (BVx,BVy) be the block vector. In the current design, BV is valid because luma position ((x+BVx)>>6<<6+(1<<7),(y+BVy)>>6<<6) is not reconstructed and ((x+BVx)>>6<<6+(1<<7),(y+BVy)>>6<<6) is not equal to (x>>6<<6,y>>6<<6).

[0038] 2.6 In-Loop Reshape (ILR) The basic idea of ​​In-Loop Reshape (ILR) is to transform an original (in a first domain) signal (the predicted / reconstructed signal) into a second domain (the reshaped domain).

[0039] The in-loop luma reshaper is implemented as a pair of look-up tables (LUTs), but only one of the two LUTs needs to be signaled, since the other can be calculated from the signaled LUT. Each LUT is a one-dimensional 10-bit 1024-entry mapping table (1D-LUT). One LUT is the forward LUT, FwdLUT, which is a LUT that maps input luma code values ​​Y i The changed value Y r :Y r =FwdLUT[Yi]. The other LUT is the inverse LUT, InvLUT, which maps the modified code values ​​Y r to Y^ i :Y^ i :InvLUT[Y r ]. (Y^ i is Y i represents the reconstruction value of

[0040] 2.6.1 PWL model Conceptually, piecewise linear (PWL) is implemented as follows:

[0041] Let x1 and x2 be two input fulcrums, and y1 and y2 be output fulcrums corresponding to one piece. The output value y for any input value x between x1 and x2 can be interpolated by the following formula:

[0042] y=((y2-y1) / (x2-x1))*(x-x1)+y1

[0043] In a fixed-point implementation, this equation can be rewritten as: y=((m*x+2 FP_PREC-1 )>>FP_PREC)+c

[0044] m is a scalar, c is an offset, and FP_PREC is a constant that specifies the precision.

[0045] In some embodiments, the PWL model is used to pre-calculate the 1024-entry FwdLUT and InvLUT mapping tables, but the PWL model also allows implementations to calculate the same mapping values ​​on-the-fly without pre-calculating the LUTs.

[0046] 2.6.2.1 Reshaping Luminance The in-loop luma reshape method provides a lower complexity pipeline and eliminates the decoding latency for block-wise intra prediction in inter slice reconstruction. Intra prediction is performed in the reshaped domain for both inter and intra slices.

[0047] Intra prediction is always performed in the reshaped domain, regardless of slice type. With this configuration, intra prediction can start immediately after the last TU reconstruction. This configuration can also provide a unified process for intra modes instead of being slice dependent. Figure 10 is a block diagram showing the decoding process based on the CE12-2 scheme.

[0048] Luminance and chroma residual scaling was performed using a 16-piece piecewise linear (PWL) model instead of the 32-piece PWL model.

[0049] Inter-slice reconstruction with in-loop luma reshaper (light green shaded blocks show the signal in the reshaped domain. Luma residual, intra-luma prediction, and intra-luma reconstruction)

[0050] 2.6.2.2 Luminance-Dependent Chroma Residual Scaling Luma-dependent chroma residual scaling is a multiplication operation implemented in fixed-point integer arithmetic. Chroma residual scaling compensates for the interaction of the luma signal with the chroma signal. We apply chroma residual scaling at the TU level. Specifically, the following applies: - For intra, average the reconstructed luminance. - For inter, average the predicted luminance.

[0051] This average value is used to determine an index in the PWL model, which in turn determines the scaling factor cScaleInv by which the chroma residual is multiplied.

[0052] Note that the chroma scaling coefficients are calculated from the forward-mapped predicted luma values ​​rather than the reconstructed luma values.

[0053] 2.6.2.3 Signaling of ILR side information The parameters are (currently) transmitted in tile group headers (similar to ALF), which reportedly take up 40-100 bits.

[0054] In some examples, the added syntax is highlighted in italics.

[0055] [Table 1]

[0056] [Table 2]

[0057] Add a new syntax table tile group reshaper.

[0058] [Table 3]

[0059] In general, the semantics of a sequence parameter set RBSP adds the following semantics: sps_reshaper_enabled_flag equal to 1 specifies that the reshaper is used in the Coded Video Sequence (CVS). sps_reshaper_enabled_flag equal to 0 specifies that the reshaper is not used in the CVS. In the tile group header syntax, the following semantics are added: tile_group_reshaper_model_present_flag equal to 1 specifies that tile_group_reshaper_model() is present in the tile group. tile_group_reshaper_model_present_flag equal to 0 specifies that tile_group_reshaper_model() is not present in the tile group header. If tile_group_reshaper_model_present_flag is not present, it is inferred to be equal to 0. tile_group_reshaper_enabled_flag equal to 1 specifies that the reshaper is enabled for the current tile group. tile_group_reshaper_enabled_flag equal to 0 specifies that the reshaper is not enabled for the current tile group. If tile_group_reshaper_enable_flag is not present, it is inferred to be 0. tile_group_reshaper_chroma_residual_scale_flag equal to 1 specifies that chroma residual scaling is enabled for the current tile group. tile_group_reshaper_chroma_residual_scale_flag equal to 0 specifies that chroma residual scaling is not enabled for the current tile group. If tile_group_reshaper_chroma_residual_scale_flag is not present, it is inferred to be 0. Add tile_group_reshaper_model() syntax reshape_model_min_bin_idx specifies the minimum bin (or piece) index to be used in the reshaper construction process. The value of reshape_model_min_bin_idx shall be within the range of 0 to MaxBinIdx. Let the value of MaxBinIdx be equal to 15. reshape_model_delta_max_bin_idx specifies that the maximum allowed bin (or piece) index MaxBinIdx minus the maximum bin index will be used in the reshaper construction process. The value of reshape_model_max_bin_idx is set equal to MaxBinIdx-reshape_model_delta_max_bin_idx. reshaper_model_bin_delta_abs_cw_prec_minus1+1 specifies the number of bits used to express the syntax reshaper_model_bin_delta_abs_CW[i]. reshape_model_bin_delta_abs_CW[i] specifies the absolute delta code value for the i-th bin. reshaper_model_bin_delta_sign_CW_flag[i] describes the sign of reshaper_model_bin_delta_abs_CW[i] as follows: - If reshape_model_bin_delta_sign_CW_flag[i] is equal to 0, then the corresponding variable RspDeltaCW[i] is positive. - Otherwise (reshape_model_bin_delta_sign_CW_flag[i] is not equal to 0), the corresponding variable RspDeltaCW[i] is negative.

[0060] If reshape_model_bin_delta_sign_CW_flag[i] is not present, it is inferred to be equal to 0.

[0061] The variable RspDeltaCW[i]=(1 2*reshape_model_bin_delta_sign_CW[i])*reshape_model_bin_delta_abs_CW[i]; the variable RspCW[i] is derived as the following steps:

[0062] The variable OrgCW is (1< <BitDepth Y ) / (MaxBinIdx+1). -If reshaper_model_min_bin_idx<=i<=reshaper_model_max_bin_idx, then RspCW[i]=OrgCW+RspDeltaCW[i]. - Otherwise, RspCW[i] = 0.

[0063] BitDepth Y If the value of is equal to 10, the value of RspCW[i] will be in the range of 32~2*OrgCW_1.

[0064] The variable InputPivot[i], where i is in the range of 0 to MaxBinIdx+1, is derived as follows. InputPivot[i]=i*OrgCW

[0065] The variables ScaleCoef[i] and InvScaleCoeff[i], where i is in the range of 0 to MaxBinIdx+1, and i is in the range of 0 to MaxBinIdx, respectively. The variable ReshapePivot[i], where i is in the range of 0 to MaxBinIdx, is derived as follows. shiftY=14 ReshapePivot[0] = 0; for(i=0;i<=MaxBinIdx;i++) ReshapePivot[i+1]=ReshapePivot[i]+RspCW[i] ScaleCoef[i]=(RspCW[i]*(1< <shiftY)+(1<<(Log2(OrgCW)-1)))> >(Log2(OrgCW)) if(RspCW[i]==0) InvScaleCoeff[i]=0 else InvScaleCoeff[i] = OrgCW * (1< <shiftY) / RspCW[i] }

[0066] The variable ChromaScaleCoef[i], where i is in the range of 0 to MaxBinIdx, is derived as follows. ChromaResidualScaleLut

[64] ={16384,16384,16384,16384,16384,16384,16384,8192,8192,8192,8192 ,5461,5461,5461,5461,4096,4096,4096,4096,3277,3277,3277,3277,2731,2731,2731,2731,2341,234 1,2341,2048,2048,2048,1820,1820,1820,1638,1638,1638,1638,1489,1489,1489,1489,1365,1365,1365,1365,1260,1260,1260,1260,1170,1170,1170,1170,1092,1092,1092,1024,1024,1024,1024}; shiftC=11 -if(RspCW[i]==0) ChromaScaleCoef[i]=(1< <shiftC) -Otherwise(RspCW[i]!=0),ChromaScaleCoef[i]= ChromaResidualScaleLut[RspCW[i]>>1]

[0067] 2.6.2.4 Using ILR On the encoder side, we first transform each picture (or tile group) into the reshaped domain. Then all the coding process is done in the reshaped domain. For intra prediction, the neighboring blocks are in the reshaped domain, and for inter prediction, we first transform the reference block (generated from the original domain from the decoded picture buffer) into the reshaped domain. Then we generate the residual and code it into the bitstream.

[0068] After the entire picture (or a group of tiles) has been coded / decoded, the samples in the reshaped domain are transformed back to the original domain, and then the deblocking and other filters are applied.

[0069] Forward reshaping to the prediction signal is disabled if:

[0070] The current block is intra-coded.

[0071] The current block is coded as CPR (with reference to the current picture, also known as Intra Block Copy, IBC).

[0072] The current block is coded as combined inter-intra mode (CIIP) and forward reshape is disabled for intra predicted blocks.

[0073] 3. Examples of Problems Solved by Various Embodiments Several problems exist with current CPR / IBC designs. 1) The reference region changes dynamically, which complicates the encoder / decoder processing. 2) Invalid block vectors are easy to generate and hard to check, complicating both the encoder and the decoder. 3) Irregular reference regions lead to inefficient coding of block vectors. 4) It is unclear how to deal with CTU sizes smaller than 128x128. 5) In the process of determining whether a BV is valid or invalid, for a chroma block, the decision is made based on the availability of luma samples, which may result in erroneous decisions due to the dual tree partition structure.

[0074] 4. Exemplary Embodiments In some embodiments, a regular buffer can be used for the CPR / IBC block to obtain the reference.

[0075] A function isRec(x,y) is defined to indicate whether pixel (x,y) is reconstructed and referenced by IBC mode. If (x,y) is out of the picture in a different slice / tile / brick, isRec(x,y) returns false, and if (x,y) is not reconstructed, isRec(x,y) returns false. In another example, if sample (x,y) is reconstructed but some other condition is met, the sample may be marked as unavailable, such as out of reference region / in a different VPDU, and isRec(x,y) returns false.

[0076] The function isRec(c,x,y) is defined to indicate whether sample(x,y) of component c is available. For example, if sample(x,y) has not yet been reconstructed, it is marked as unavailable. In another example, if sample(x,y) has been reconstructed but some other condition is met, it may also be marked as unavailable, e.g., if sample(x,y) is unavailable, such as out of picture / in a different slice / tile / brick / in a different VPDU, in an allowed reference region, etc., isRec(c,x,y) returns false, otherwise it returns true.

[0077] In the following description, the reference sample may be a reconstructed sample. Note that a "pixel buffer" may correspond to a "buffer of one color component" or a "buffer of multiple color components".

[0078] Reference buffer for CPR / IBC 1. It is proposed to use M×N pixel buffers to store luma reference samples for CPR / IBC. In one example, the buffer size is 64x64. b. In one example, the buffer size is 128x128. c. In one example, the buffer size is 64x128. d. In one example, the buffer size is 128x64. e. In one example, N is equal to the height of the CTU. f. In one example, N=nH, where H is the height of the CTU and n is a positive integer. g. In one example, M is equal to the width of the CTU. h. In one example, M=mW, where W is the width of the CTU and m is a positive integer. i. In one example, the buffer size is not equal to the CTU size, for example, 96x128 or 128x96. j. In one example, the buffer size is equal to the CTU size. k. In one example, M=mW, N=H, where W and H are the width and height of the CTU, and m is a positive integer. l. In one example, M=W, N=nH, where W and H are the width and height of the CTU, and n is a positive integer. In one example, M=mW, N=nH, where W and H are the width and height of the CTU, and m and n are positive integers. n. In the above example, m and n may depend on the size of the CTU. i. In one example, if the size of the CTU is 128×128, then m=1 and n=1. ii. In one example, if the size of the CTU is 64×64, then m=4 and n=1. iii. In one example, if the size of the CTU is 32×32, then m=16 and n=1. iv. In one example, if the size of the CTU is 16x16, then m=64 and n=1. Alternatively, the buffer size corresponds to the CTU size. p. Alternatively, this buffer size corresponds to the size of a Virtual Pipeline Data Unit (VPDU). q. M and / or N may be signaled from the encoder to the decoder, for example in the VPS / SPS / PPS / picture header / slice header / tile group header, etc. 2. M and / or N may be different for different profiles / levels / layers defined in the standard. It is proposed to use a separate Mc×Nc pixel buffer to store chroma reference samples for CPR / IBC. In one example, for 4:2:0 video, Mc=M / 2 and Nc=N / 2. b. In one example, for 4:4:4 video, Mc=M and Nc=N. c. In one example, for 4:2:2 video, Mc=M and Nc=N / 2. d. Alternatively, Mc and Nc may be independent of M and N. e. In one example, the chroma buffer includes two channels corresponding to Cb and Cr. f. In one example, Mc=M and Nc=N. 3. It is proposed to use an M×N sample buffer to store RGB reference samples for PR / IBC. In one example, the buffer size is 64x64. b. In one example, the buffer size is 128x128. c. In one example, the buffer size is 64x128. d. In one example, the buffer size is 128x64. e. Alternatively, the buffer size corresponds to the CTU size. f. Alternatively, this buffer size corresponds to the size of a Virtual Pipeline Data Unit (VPDU). 4. It is proposed that a buffer can store the reconstructed pixels before loop filtering, which may refer to a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO), a cross-component ALF, or any other filter. In one example, a buffer can store samples in the current CTU. b. In one example, a buffer can store samples outside of the current CTU. c. In one example, the buffer can store samples from any portion of the current picture. d. In one example, the buffer may store samples from other pictures. 5. It is proposed that a buffer can store the reconstructed pixels after loop filtering, which may refer to a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO), a cross-component ALF, or any other filter. In one example, a buffer can store samples in the current CTU. b. In one example, a buffer can store samples outside of the current CTU. c. In one example, the buffer can store samples from any portion of the current picture. d. In one example, the buffer may store samples from other pictures. 6. It is proposed that the buffer can store reconstructed samples both before and after loop filtering, which may refer to a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO), a cross-component ALF, or any other filter. In one example, the buffer may store samples from the current picture and samples from other pictures based on the availability of those samples. b. In one example, the reference samples from other pictures are from the reconstructed samples after loop filtering. c. In one example, the reference samples from other pictures are from reconstructed samples before loop filtering. 7. It is proposed that the buffer stores samples with a given bit-depth, which may differ from the bit-depth of the encoded video data. In one example, the bit depth of the reconstructed buffer / encoded video data is greater than the bit depth of the IBC reference samples stored in the buffer. b. In one example, if the internal bit depth is different from the input bit depth for a video sequence, e.g. (10 bits vs. 8 bits), the IBC reference samples are stored aligned to the input bit depth. c. In one example, the bit depth is the same as the bit depth of the reconstruction buffer. d. In one example, the bit depth is the same as the bit depth of the input image / video. e. In one example, the bit depth is equal to a predefined number. f. In one example, the bit depth depends on the standard profile. g. In one example, the bit depth or the bit depth difference compared to the output bit depth / input bit depth / internal bit depth may be signaled in the SPS / PPS / sequence header / picture header / slice header / tile group header / tile header or other type of video data unit. h. The proposed method may be applied to the proposed buffer definitions mentioned in the other bullets, or alternatively, to existing designs of IBCs. i. The bit depth of each color component of the buffer may be different.

[0079] Buffer Start 8. It is suggested to initialize the buffer with a given value. In one example, a buffer is initialized with a given value. i. In one example, the given value may depend on the input bit depth and / or the internal bit depth. ii. In one example, the buffer is initialized with a mid-gray value, eg, 128 for an 8-bit signal, 512 for a 10-bit signal, etc. In one example, if ILR is used, the buffer is initialized with forwardLUT(m), e.g. m=1<<(Bitdepth-1). b. Alternatively, the buffers are initialized with values ​​signaled in the SPS / VPS / APS / PPS / Sequence Header / Tile Group Header / Picture Header / tile / CTU / coding unit / VPDU / area. c. In one example, this given value may be derived from samples of a row or CTU or CU of a previously decoded picture or slice or CTU. d. This given value may be different for different color components. 9. Alternatively, it is proposed to initialize the buffer using decoded pixels from the previously coded block. In one example, the decoded pixels are the pixels before in-loop filtering. b. In one example, if the buffer size is a CTU, the buffer is initialized with the decoded pixels of the previous decoded CTU, if available. c. In one example, if the buffer size is 64x64, the buffer size is initialized with the decoded pixels of the previous decoded 64x64 block, if available. d. Alternatively, in addition, if no previously coded block is available, the method of bullet 8 may be applied.

[0080] Referencing a Buffer 10. For a block to use pixels in a buffer as references, the block can point to a location (x,y) in the buffer, x=0,1,2,...,M-1; y=0,1,2,...,N-1. 11. Alternatively, this reference position can be expressed as l=y*M+x, l=0,1,...,M*N-1. 12. Note that the top left position of the block for the current CTU may be (x0, y0), and a block vector (BVx, BVy) = (x-x0, y-y0) may be sent to the decoder to indicate the reference in the buffer. 13. Alternatively, a block vector (BVx, BVy) may be defined as (x-x0+Tx, y-y0+Ty), where Tx and Ty are predefined offsets. 14. For any pixel (x0,y0) and (BVx,BVy), its reference in the buffer can be found at (x0+BVx,y0+BVy). In one example, if (x0+BVx, y0+BVy) is outside the buffer, it is clipped to the boundary. b. Alternatively, if (x0+BVx, y0+BVy) is outside the buffer, then the reference value is predefined as a given value, for example mid-grey. c. Alternatively, the reference position is defined as ((x0+BVx) mod M, (y0+BVy) mod N) so that it is always within the buffer. 15. For any pixel (x0,y0) and (BVx,BVy), if (x0+BVx,y0+BVy) is outside the buffer, then its reference value may be derived from the value in the buffer. In one example, this value is derived from the samples in the buffer ((x0+BVx) mod M, (y0+BVy) mod N). b. In one example, this value is derived from the samples in the buffer ((x0+BVx) mod M, clip(y0+BVy,0,N-1)). c. In one example, this value is derived from the samples in the buffer: (clip(x0+BVx,0,M-1),(y0+BVy) mod N). d. In one example, this value is derived from the samples in the buffer (clip(x0+BVx,0,M-1), clip(y0+BVy,0,N-1)). 16. May not allow certain coordinates outside the buffer range. a. In one example, for any pixel (x0, y0) relative to the top-left corner of the CTU and block vector (BVx, BVy), it is a bitstream constraint that y0+BVy should be in the range of [0, .., N-1]. b. In one example, it is a bitstream constraint that for any pixel (x0, y0) in the top-left corner of the CTU and block vector (BVx, BVy), x0+BVx should be in the range of [0, .., M-1]. c. In one example, it is a bitstream constraint that for any pixel (x0, y0) in the top left corner of the CTU and block vector (BVx, BVy), y0+BVy should be in the range of [0, .., N-1] and x0+BVx should be in the range of [0, .., M-1]. 17. If the signaled or derived block vector for one block points somewhere outside the buffer, padding may be done based on the buffer. In one example, the value of any sample outside the buffer is defined to a predefined value. i. In one example, this value may be 1<(bit depth-1), e.g., 128 for an 8-bit signal and 512 for a 10-bit signal. ii. In one example, if ILR is used, this value may be forwardLUT(m), where m=1<<(Bitdepth-1). iii. Alternatively, the indication of the predefined value may be signaled or indicated at the SPS / PPS / Sequence Header / Picture Header / Slice Header / Tile Group / Tile / CTU / CU level. b. In one example, any sample outside the buffer is defined as the value of the closest sample in the buffer. 18. The handling of buffer references may differ horizontally and vertically, or depending on the location of the current block (eg, closer to a picture boundary or not). In one example, if y0+BVy is outside [0,N-1], the sample value of (x0+BVx,y0+BVy) is assigned as a predefined value. b. In one example, if x0+BVx is outside [0,M-1], the sample value of (x0+BVx,y0+BVy) is assigned as the predefined value. c. Alternatively, the sample value of (x0+BVx, y0+BVy) may be assigned as the sample value of ((x0+BVx) mod M, y0+BVy), thereby invoking other methods to further derive the value of (((x0+BVx) mod M, y0+BVy) if it is still outside the buffer. d. Alternatively, the sample value of (x0+BVx,y0+BVy) may be assigned as the sample value of (x0+BVx,(y0+BVy) mod N), thereby invoking other methods to further derive the value of (x0+BVx,(y0+BVy) mod N) if it is still outside the buffer.

[0081] Block Vector Representation 19. Each component of the block vector (BVx, BVy) or one of its components may be normalized to a certain range. In one example, BVx may be replaced with (BVx mod M). b. Alternatively, BVx may be replaced by ((BVx+X) mod M)-X, where X is a predefined value. i. In one example, X is 64. ii. In one example, X is M / 2. iii. In one example, X is the horizontal coordinate of the block relative to the current CTU. c. In one example, BVy may be replaced with (BVy mod N). d. Alternatively, BVy may be replaced by ((BVy+Y) mod N)-Y, where Y is a predefined value. i. In one example, Y is 64. ii. In one example, Y is N / 2. iii. In one example, Y is the vertical coordinate of the block relative to the current CTU. 20. BVx and BVy may have different normalization ranges. 21. The block vector differences (BVDx, BVDy) can be normalized to a certain range. In one example, BVDx may be replaced with (BVDx mod M), where the function mod returns the remainder. b. Alternatively, BVDx may be replaced by ((BVDx+X) mod M)-X, where X is a predefined value. i. In one example, X is 64. ii. In one example, X is M / 2. c. In one example, BVy may be replaced with (BVDy mod N). d. Alternatively, BVy may be replaced by ((BVDy+Y) mod N)-Y, where Y is a predefined value. i. In one example, Y is 64. ii. In one example, Y is N / 2. 22. BVDx and BVDy may have different normalization ranges.

[0082] Block Vector Validation The width and height of the IBC buffer are W buf and H buf For a WxH block (which may be a luma block, chroma block, CU, TU, 4x4, 2x2, or other sub-block) starting at (X,Y) relative to the top-left corner of the picture, the following may be applied to indicate whether a block vector (BVx, BVy) is valid: pic , H pic Let be the width and height of one picture, and W ctu , H ctu Let be the width and height of one CTU. The function floor(x) returns the largest integer not greater than x. The function isRec(x,y) returns the sample (x,y) if it is reconstructed. 23. A block vector (BVx,BVy) may be set as valid even if any of the reference positions are outside the picture boundary. In one example, a block vector may be set as valid even if X+BVx<0. b. In one example, the block vector is X+W+BVx>W pic However, it may be set as valid even if the c. In one example, a block vector may be set as valid even if Y+BVy<0. d. In one example, Y+H+BVy>H pic A block vector may be set as valid even if 24. A block vector (BVx,BVy) may be set as valid even if the reference position is outside the current CTU row. In one example, the block vector is Y+BVy <floor(Y / H ctu )*H ctu may be set as valid even if b. In one example, the block vector is Y+H+BVy>=floor(Y / H ctu )*H ctu +H ctu may be set as valid even if 25. A block vector (BVx, BVy) may be set as valid even if any of the reference positions are outside the current CTU and the left (n-1) CTUs, where n is the number of CTUs (including or excluding the current CTU) that can be used as the reference area for the IBC. In one example, the block vector is X+BVx <floor(X / W ctu )*W ctu -(n-1)*W ctu may be set as valid even if b. In one example, the block vector is X+W+BVx>floor(X / W ctu )*W ctu +W ctu However, it may be set as valid even if the 26. A block vector (BVx,BVy) may be set as valid even if the particular sample has not been reconstructed. In one example, a block vector may be set as valid even if isRec(X+BVx, Y+BVy) is false. b. In one example, a block vector may be set as valid even if isRec(X+BVx+W-1,Y+BVy) is false. c. In one example, a block vector may be set as valid even if isRec(X+BVx, Y+BVy+H-1) is false. d. In one example, a block vector may be set as valid even if isRec(X+BVx+W-1, Y+BVy+H-1) is false. 27. A block vector (BVx, BVy) may be set as always valid if the block is not the first CTU block in a CTU row. Alternatively, the block vectors may be set as always valid. 28. A block vector (BVx, BVy) may be set as always valid if all of the following three conditions are satisfied: X+BVx>=0 Y+BVy>=floor(Y / H ctu ) ·isRec(X+BVx+W-1,Y+BVy+H-1)==true Alternatively, for a block of the first CTU in a CTU row, if all three conditions are met, the block vector may always be set as valid. 29. If the block vector (BVx, BVy) is valid, then a sample copy of the block may be made based on the block vector. In one example, the prediction for sample (X,Y) is ((X+BVx)%W buf ,(Y+BVy)%H buf ) can be obtained.

[0083] Buffer Update 30. When encoding a new picture or tile, the buffer may be reset. The term "reset" may refer to a buffer being initialized. b. The term "reset" may refer to all samples / pixels in a buffer being set to a given value (e.g., 0 or -1). 31. After finishing encoding the VPDU, the buffer may be updated with the reconstructed values ​​of the VPDU. 32. After finishing encoding the CTU, the buffer may be updated with the reconstructed value of the CTU. In one example, if the buffer is not full, the buffer can be updated sequentially CTU by CTU. b. In one example, if the buffer is full, update the buffer area corresponding to the oldest CTU. c. In one example, if M=mW, N=H (W, H are the size of the CTU, and M, N are the buffer sizes), and the last updated region started at (kW,0), the next starting position to update would be ((k+1)W mod M,0). 33. The buffer may be reset at the beginning of each CTU row. Alternatively, the buffer may be reset at the start of decoding of each CTU. b. Alternatively, the buffer may be reset at the start of decoding one tile. c. Alternatively, the buffer may be reset at the start of decoding one tile group / picture. 34. After finishing coding the block starting at (x,y), the corresponding area of ​​the buffer starting at (x,y) is updated by reconstruction from the block. In one example, (x,y) is the position relative to the top left corner of the CTU. 35. After a block has been coded for a picture, the corresponding area of ​​the buffer is updated by reconstruction from the block. In one example, the value at location (x mod M, y mod N) in the buffer may be updated with the reconstructed pixel value at location (x, y) relative to the top-left corner of the picture. b. In one example, the value at position (x mod M, y mod N) in the buffer may be updated with the reconstructed pixel value at position (x, y) relative to the top-left corner of the current tile. c. In one example, the value at position (x mod M, y mod N) in the buffer may be updated with the reconstructed pixel value at position (x, y) relative to the top-left corner of the current CTU row. d. In one example, the values ​​in the buffer may be updated with the reconstructed pixel values ​​after bit-depth alignment. 36. After finishing coding the block starting at (x,y), the corresponding area of ​​the buffer starting at (xb,yb) is updated by reconstruction from the block, where (xb,yb) and (x,y) are two different coordinates. In one example, (x,y) is a position relative to the top left corner of the CTU, and (xb,yb) is (x+update_x,y+update_y), where update_x and update_y indicate the updateable positions in the buffer. 37. In the above example, the reconstructed value of one block may refer to the reconstructed value before applying a filter (eg, a deblocking filter). a. Alternatively, the reconstructed value of a block may refer to the reconstructed value after a filter (eg, a deblocking filter) has been applied. 38. When the buffer is updated from reconstructed samples, the reconstructed samples may first be modified before being stored, for example to change the bit depth of the samples. In one example, the buffer is updated with the reconstructed sample values ​​after bit-depth alignment to the bit-depth of the buffer. b. In one example, the buffer value is updated based on the value {p+[1<<(b-1)]}>>b, where p is the reconstructed sample value and b is a predefined bit shift value. c. In one example, the buffer value is updated based on the value of clip({p + [1 << (b - 1)]} >> b, 0, (1 << bitdepth) - 1), where p is the reconstructed sample value, b is a predefined bit shift value, and bitdepth is the buffer bit depth. d. In one example, the buffer value is updated based on the value {p + [1 < (b - 1) - 1]} > b, where p is the reconstructed sample value and b is a predefined bit shift value. e. In one example, the buffer value is updated based on the value of clip({p + [1 << (b - 1) - 1]} >> b, 0, (1 << bitdepth) - 1), where p is the reconstructed sample value, b is a predefined bit shift value, and bitdepth is the buffer bit depth. f. In one example, the buffer value is updated based on the value p >> b. g. In one example, the buffer value is updated based on the value of clip(p >> b, 0, (1 << bitdepth) - 1), where bitdepth is the buffer bit depth. h. In the above example, b may be reconstructed as the bit depth minus the input sample bit depth. 39. When forming a prediction using buffer samples, preprocessing can be applied. a. In one example, the predicted value is p << b, where p is the sample value in the buffer and b is a predefined value. b. In one example, the predicted value is clip(p << b, 0, 1 << bitdepth), where bitdepth is the bit depth of the reconstructed sample. c. In one example, the predicted value is (p << b) + (1 << (bitdepth - 1)), where p is the sample value in the buffer, b is a predefined value, and bitdepth is the bit depth of the reconstructed sample. d. In the above example, b may be reconstructed as the bit depth minus the input sample bit depth. 40. Buffers may be updated in a given order. In one example, the buffer may be updated sequentially. b. In one example, the buffer may be updated based on the order of the reconstructed blocks. 41. If the buffer is full, the samples in the buffer may be replaced with the most recently reconstructed samples. In one example, samples may be updated on a first-in, first-out basis. b. In one example, the oldest sample is replaced. c. In one example, samples may be assigned priorities and replaced based on the priorities. d. In one example, a sample may be marked as "long-term" so that other samples will be replaced first. e. In one example, a flag may be sent with a block to indicate high priority. f. In one example, a number may be sent with a block to indicate priority. g. In one example, samples from a reconstructed block that have certain characteristics are assigned a higher priority so that other samples are replaced first. i. In one example, if the percentage of samples coded in IBC mode is greater than a threshold, then all samples of a block may be assigned a high priority. ii. In one example, if the percentage of samples coded in Palette mode is greater than a threshold, then all samples of a block may be assigned a high priority. iii. In one example, if the percentage of samples coded in IBC or Palette mode is greater than a threshold, then all samples of a block may be assigned a high priority. iv. In one example, if the percentage of samples coded in transform skip mode is greater than a threshold, then all samples of a block may be assigned a high priority. v. This threshold may vary based on block size, color components, and CTU size. vi. The threshold may be signaled in the SPS / PPS / sequence header / slice header / tile group / tile level / region. h. In one example, the buffer being full may mean that the number of available samples in the buffer is equal to or greater than a given threshold. i. In one example, the buffer may be determined to be full if the number of available samples in the buffer is equal to or greater than 64x64x3 luma samples.

[0084] Alternative Buffer Combinations 42. Instead of always using the three previously coded 64x64 blocks as the reference region, it is proposed to adaptively change it based on the position of the current block (or VPDU). In one example, when encoding / decoding a 64x64 block, three previous 64x64 blocks can be used as reference. More previous 64x64 blocks may be combined compared to Figure 2. Figure 2 shows examples of different combinations of previous 64x64 blocks. 43. Instead of using z scan order, a vertical scan order may be used. In one example, if one block is split into four VPDUs with indices 0..3 in the z-scan order, the encoding / decoding order is 0,2,1,3. b. In one example, when encoding / decoding a 64×64 block, the previous three 64×64 blocks can be used as references. Compared with Fig. 2, more kinds of encoding / decoding orders of 64×64 blocks can be applied. Fig. 4 shows examples of different encoding / decoding orders of 64×64 blocks. c. Alternatively, the above method may be applied to the coding of screen content only. d. Alternatively, the above method may be applied only when CPR is enabled for one tile / tile group / picture. e. Alternatively, the above method may be applied only when CPR is enabled for one CTU or one row of CTUs.

[0085] Virtual IBC Buffer Hereinafter, the width and height of a VPDU in luma samples will be denoted as WVPDU (e.g., 64) and HVPDU (e.g., 64), respectively. Alternatively, the WVPDU and / or HVPDU may represent the width and / or height of another video unit (e.g., a CTU). 44. A virtual buffer may be maintained to keep track of the state of the IBC reference region. In one example, the virtual buffer size is VPDU ×nH VPDU It is. In one example, m is equal to 3 and n is equal to 2. ii. In one example, m and / or n may depend on the picture resolution, CTU size. iii. In one example, m and / or n may be signaled or predefined. b. In one example, the methods described in the bullets and sub-bullets above may be applied to a virtual buffer. c. In one example, sample (x,y) relative to the top left corner of the picture / slice / tile / brick may be mapped to (x%(mWVPDU),y%(nHVPDU)). 45. An array may be used to track the availability of each sample associated with a virtual buffer. In one example, a flag may be associated with a sample in the virtual buffer to specify whether the sample in the buffer can be used as an IBC reference. b. In one example, each 4x4 block containing luma and chroma samples may share one flag to indicate whether any of the samples associated with that block can be used as an IBC reference. c. In one example, an array corresponding to 3×2 VPDUs (eg, each 4×4 block may share the same availability flag) is maintained to track the availability of IBC reference samples. d. In one example, an array corresponding to 4×2 VPDUs (eg, each 4×4 block may share the same availability flag) is maintained to track the availability of IBC reference samples. 46. ​​After completing the decoding of a VPDU or video unit, certain samples associated with a virtual buffer may be marked as unavailable for IBC reference. In one example, which samples are unavailable may depend on the position of the most recently decoded VPDU. b. If a sample is marked as unavailable, no predictions are allowed from this sample. i. Alternatively, other methods (eg, using default values) may be further applied to derive predictors and replace unavailable samples. 47. The location of recently decoded VPDUs may be recorded to facilitate identifying which samples associated with a virtual buffer have been marked as unavailable. In one example, at the start of decoding a VPDU, some samples associated with the virtual buffer may be marked as unavailable based on the location of the recently decoded VPDU. i. In one example, let (xPrevVPDU, yPrevVPDU) be the top-left position relative to the top-left corner of the picture / slice / tile / brick / other video processing unit of the most recently decoded VPDU, and yPrevVPDU%(nH VPDU ) is equal to 0, a particular position (x,y) can be marked as unavailable. 1. In one example, x is [xPrevVPDU-2W VPDU +2mW VPDU )% mW VPDU ,((xPrevVPDU-2W VPDU +2mW VPDU )%mW VPDU )-1+W VPDU ] may be within a range such as: 2. In one example, y is [yPrevVPDU%(nH VPDU ),(yPrevVPDU%(nH VPDU ))-1+H VPDU ] may be within a range such as: 3. In one example, x is [xPrevVPDU-2W VPDU +2mW VPDU ]%mW VPDU , ((xPrevVPDU-2W VPDU +2mW VPDU )%mW VPDU , ((xPrevVPDU-2W VPDU +2mW VPDU )%mW VPDU )-1+W VPDU ], and y may be in the range [yPrevVPDU%(nH VPDU ),(yPrevVPDU%(nH VPDU ))-1+H VPDU ] may be within a range such as: ii. In one example, let (xPrevVPDU, yPrevVPDU) be the top-left position relative to the top-left corner of the picture / slice / tile / brick / other video processing unit of the most recently decoded VPDU, and yPrevVPDU%(nH VPDU ) is not equal to 0, a particular position (x,y) can be marked as unavailable. 1. In one example, x is [xPrevVPDU-W VPDU +2mW VPDU )%mW VPDU ,((xPrevVPDU-W VPDU +2mW VPDU )%mW VPDU )-1+W VPDU ] may be within a range such as: 2. In one example, y is [yPrevVPDU%(nH VPDU ),(yPrevVPDU%(nH VPDU ))-1+H VPDU ] may be within a range such as: 3. In one example, x is [xPrevVPDU-W VPDU +2mW VPDU )%mW VPDU ,((xPrevVPDU-W VPDU +2mW VPDU )%mW VPDU )-1+W VPDU ], and y may be in the range [yPrevVPDU%(nH VPDU ),(yPrevVPDU%(nH VPDU ))-1+H VPDU ] may be within a range such as: 48. If one CU contains multiple VPDUs, instead of applying the IBC reference availability marking process based on the VPDU, the IBC reference availability marking process may follow the following CU. In one example, at the start of decoding a CU that contains multiple VPDUs, an IBC reference availability marking process may be applied for each VPDU before decoding the VPDUs in the CU. b. In such cases, 128x64 and 64x128 IBC blocks may not be allowed. i. In one example, pred_mode_ibc_flag for 128×64 and 64×128 CUs may not be sent and may be inferred to be equal to 0. 49. For a reference block or sub-block, it may not be necessary to check the reference availability status in the top right corner to determine if the block vector associated with this reference block is valid. In one example, only the top-left, bottom-left and bottom-right corners of the block / sub-block are checked to determine if the block vector is valid. 50. The IBC buffer size may depend on the size of the VPDU (width / height represented by vSize) and / or the size of the CTB / CTU (width / height represented by ctbSize). In one example, the height of the buffer may be equal to ctbSize. b. In one example, the width of the buffer may depend on min(ctbSize,64). i. In one example, the width of the buffer may be (128*128 / vSize, min(ctbSize, 64)). 51. The IBC buffer may contain values ​​that are out of pixel range, indicating that this location may not be available for IBC reference (eg, not used to predict other samples). The sample value may be set to a value that indicates that the sample is not available. b. In one example, this value may be -1. c. In one example, this value may be any value outside of [0,1<<(internal_bit_depth)-1], where internal_bit_depth is a positive integer value. For example, internal_bit_depth is the internal bit depth used to encode / decode samples of one color component. d. In one example, this value may be any value outside the range of [0,1<<(input_bit_depth)-1], where input_bit_depth is a positive integer value. For example, input_bit_depth is the input bit depth used to encode / decode samples of one color component. 52. The availability marking of a sample in the IBC buffer may depend on the position of the current block, the size of the current block, the size of the CTU / CTB, and the size of the VPDU. In one example, (xCb, yCb) represent the position of the block relative to the top left of the picture, ctbSize is the size of the CTU / CTB (i.e., width and / or height), vSize=min(ctbSize,64), and wIbcBuf and hIbcBuf are the width and height of the IBC buffer. In one example, if (xCb % vSize) is equal to 0 and (yCb % vSize) is equal to 0, then a particular set of locations in the IBC buffer can be marked as unavailable. b. In one example, if the size of the current block is less than the size of the VPDU, i.e., min(ctbSize, 64), the region marked as unavailable may follow the size of the VPDU. c. In one example, if the size of the current block is larger than the size of the VPDU, ie, min(ctbSize, 64), the area marked as unavailable may follow the size of the CU. 53. At the start of decoding a video unit (eg, VPDU(xV,yV)) for the top-left position of a picture, the corresponding position in the IBC buffer may be set to a value outside the pixel range. In one example, a buffer sample with position (x%wIbcBuf, y%hIbcBuf) in the buffer, where x=xV,...,xV+ctbSize-1,y=yV,...,yV+ctbSize-1, is set to the value -1, where wIbcBuf and hIbcBuf are the width and height of the IBC buffer, and ctbSize is the width of the CTU / CTB. i. In one example, hIbcBuf may be equal to ctbSize. 54. Bitstream conformance constraints may be subject to the values ​​of samples in the IBC buffer. a. In one example, if a reference block associated with one block vector in the IBC buffer contains values outside the pixel range, this bitstream may be invalid. 55. Based on the availability indication in the IBC buffer, constraints on bitstream conformity may be set. a. In one example, if any reference sample mapped to the IBC buffer is marked as unavailable for encoding / decoding one block, this bitstream may be invalid. b. In one example, when a single tree is used, if any luminance reference sample mapped to the IBC buffer for encoding / decoding one block is marked as unavailable, this bitstream may be invalid. c. A conforming bitstream, in the case of an IBC-encoded block, may point to a reference block where the associated block vector is mapped to the IBC buffer, and can satisfy the requirement that each luminance reference sample located in the IBC buffer for encoding / decoding one block is marked as available (e.g., the sample values are within the range [K0, K1], for example, K0 is set to 0 and K1 is set to (1 << BitDepth - 1), where BitDepth is the internal bit depth or the input bit depth). 56. The constraints on bitstream conformity may depend on the type of split tree and the treeType of the encoding of the current CU. a. In one example, when dual trees are permitted at a high level (e.g., slice / picture / brick / tile) and the current video block (e.g., CU / PU / CB / PB) is encoded with a single tree, the bitstream constraints may need to check whether the positions of all components mapped to the IBC buffer are marked as unavailable. b. In one example, if a dual tree is permitted at a high level (e.g., slice / picture / block / tile) and the current luminance video block (e.g., CU / PU / CB / PB) is encoded with a dual tree, it may be ignored whether the positions mapped in the IBC buffer of the chroma component are marked as unavailable due to bitstream constraints. i. Alternatively, in such a case, the bitstream constraints may still check whether all component positions mapped to the IBC buffer are marked as unavailable. c. In one example, if a single tree is used, the bitstream constraints may be able to ignore whether the positions of the chroma components mapped to the IBC buffer are unavailable.

[0086] Improvements to the current VTM design 57. The prediction of IBC may have lower accuracy than reconstruction. a. In one example, the predicted value is based on the value clip{{p + [1<<(b - 1)]}>>b, 0, (1<<bitdepth)-1}<<b, where p is the reconstructed sample value, b is a predefined bit shift value, and bitdepth is the bit depth of the predicted sample bits. b. In one example, the predicted value is based on the value clip{{p + [1<<(b - 1)-1]}>>b, 0, (1<<bitdepth)-1}<<b, where p is the reconstructed sample value and b is a predefined bit shift value. c. In one example, the predicted value is based on the value ((p>>b)+(1<<(bitdepth - 1)))<<b, and the bit depth is the bit depth of the predicted sample. d. In one example, the predicted value is based on the value (clip((p>>b), 0, (1<<(bitdepth - b)))+(1<<(bitdepth - 1)))<<b, and the bit depth is the bit depth of the predicted sample. e. In one example, the predicted values ​​are clipped differently based on whether ILR is applied. f. In the above example, b may be reconstructed as the bit depth minus the input sample bit depth. g. In one example, the bit depth or the bit depth difference compared to the output bit depth / input bit depth / internal bit depth may be signaled in the SPS / PPS / sequence header / picture header / slice header / tile group header / tile header or other type of video data unit. 58. Some of the IBC predictions may be less accurate, while other parts have the same accuracy as the reconstruction. In one example, the permissible reference range may include samples with different precision (eg, bit depth). b. In one example, references from other 64x64 blocks that the current 64x64 block has not been decoded have lower precision, and references from the current 64x64 block have the same precision as the reconstruction. c. In one example, references from CTUs other than the current CTU being decoded have lower accuracy, and references from the current CTU have the same accuracy as the reconstruction. d. In one example, references from a particular collection of color components have low precision, while references from other color components have the same precision as the reconstruction. 59. If a CTU has size M×M and a reference region has size nM×nM, the reference region is the nearest available n×n CTU in the CTU's row. In one example, if the size of the reference region is 128x128 and the size of the CTU is 64x64, the nearest four available CTUs in one CTU row can be used for IBC reference. b. In one example, if the size of the reference region is 128x128 and the size of the CTU is 32x32, the nearest available 16 CTUs in one CTU row can be used for IBC reference. 60. If the size of a CTU is M and the size of the reference region is nM, then the reference region is the nearest available n-1 CTUs in the row / tile of the CTU. a. In one example, if the size of the reference region is 128x128 or 256x64 and the size of the CTU is 64x64, the three closest available CTUs in one CTU row can be used for IBC reference. b. In one example, if the size of the reference region is 128x128 or 512x32 and the size of the CTU is 32x32, the nearest available 15 CTUs in one CTU row can be used for IBC reference. 61. If the size of a CTU is M, then the size of the VPDU is kM, the size of the reference region is nM, and the reference region is the nearest available nk CTUs in the row / tile of the CTU. a. In one example, the size of a CTU is 64x64, the size of a VPDU is also 64x64, the size of a reference is 128x128, and the three nearest CTUs in a row of one CTU can be used for IBC reference. b. In one example, the size of a CTU is 32x32, the size of a VPDU is 64x64, the size of a reference is 128x128, and the nearest (16-4)=12 CTUs in one CTU row can be used for IBC reference. 62. Using IBC, for a w × h block whose top-left corner is (x,y), there is a constraint that keeps the reference block from a certain region for memory reclamation, where w and h are the width and height of the current block. a. In one example, if the size of the CTU is 128x128 and (x,y)=(mx64,nx64), the reference block cannot overlap with the 64x64 region starting at ((m-2)x64,nx64). b. In one example, if the size of the CTU is 128x128, the reference block cannot overlap if the top-left corner of the wxh block is (x-128,y). c. In one example, if the size of the CTU is 128x128, then (x+BVx,y+BVy) does not lie within the w*h block whose top-left corner is (x-128,y), and BVx and BVy represent the block vectors of the current block. d. In one example, if the size of the CTU is M×M and the IBC buffer size is k×M×M, the reference block cannot overlap with the w×h block, and the top left corner is (xk×M, y), and BVx and BVy represent the block vectors of the current block. e. In one example, if the size of the CTU is M×M and the IBC buffer size is k×M×M, then (x+BVx,y+BVy) cannot be within a w×h intra block, the top left corner is (xk×M,y), and BVx and BVy represent the block vectors of the current block. 63. If the size of a CTU is not M×M and the size of the reference region is nM×nM, the reference region is the nearest available n×n-1 CTUs in the CTU's row. a. In one example, if the size of the reference region is 128x128 and the size of the CTU is 64x64, the three closest available CTUs in one CTU row can be used for IBC reference. b. In one example, if the size of the reference region is 128x128 and the size of the CTU is 32x32, the nearest available 15 CTUs in one CTU row can be used for IBC reference. 64. For a CU of 64x64 blocks starting at (2m*64,2n*64), i.e., the top-left 64x64 block in a 128x128 CTU, its IBC prediction can be made from the reconstructed samples in the 64x64 block starting at ((2m-2)*64,2n*64), the 64x64 block starting at ((2m-1)*64,2n*64), and the 64x64 block starting at ((2m-1)*64,(2n+1)*64), and the current 64x64 block. 65. For a 64x64 block CU starting at ((2m+1)*64, (2n+1)*64), i.e., the bottom-right 64x64 block in a 128x128 CTU, its IBC prediction may be from the current 128x128 CTU. 66. For a CU of 64x64 blocks starting at ((2m+1)*64,2n*64), i.e., the top right 64x64 block in a 128x128 CTU, its IBC prediction can be made from reconstructed samples in the 64x64 block starting at ((2m-1)*64,2n*64), the 64x64 block starting at ((2m-1)*64,(2n+1)*64), the 64x64 block starting at (2m*64,2n*64), and the current 64x64 block. a. Alternatively, if a 64×64 block starting at (2m*64,(2n+1)*64) is reconstructed, IBC prediction can be made from reconstructed samples in the 64×64 block starting at ((2m-1)*64,2n*64), the 64×64 block starting at (2m*64,2n*64), the 64×64 block starting at (2m*64,(2n+1)*64), and the current 64×64 block. 67. For a CU of 64x64 blocks starting at (2m*64,(2n+1)*64), i.e., the bottom-left 64x64 block in a 128x128 CTU, its IBC prediction can be made from reconstructed samples in the 64x64 block starting at ((2m-1)*64,(2n+1)*64), the 64x64 block starting at (2m*64,2n*64), the 64x64 block starting at ((2m+1)*64,2n*64), and the current 64x64 block. a. Alternatively, if the 64×64 block starting at ((2m+1)*64, 2n*64) has not been reconstructed, IBC prediction can be made from reconstructed samples in the 64×64 block starting at ((2m-1)*64, 2n*64), the 64×64 block starting at ((2m-1)*64, (2n+1)*64), the 64×64 block starting at (2m*64, 2n*64), and the current 64×64 block. 68. It is proposed to adjust the reference region based on which 64x64 block the current CU belongs to. a. In one example, for a CU starting at (x,y), if (y>>6)&1==0, the two or two previous 64x64 blocks starting at ((x>>6<<6)-128,y>>6<<6) and ((x>>6<<6)-64,y>>6<<6) can be referenced by IBC mode. b. In one example, for a CU starting at (x, y), when (y>>6)&1==1, the previous 64x64 block starting at ((x>>6<<6)-64, y>>6<<<6) can be referenced by IBC mode. 69. For a block starting at (x,y) and with block vector (BVx,BVy), if isRec(((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+(x%64),((y+BVy)>>6<<6)+(y%64)) is true, then the block vector is invalid. In one example, the block is a luminance block. b. In one example, this block is a chroma block in a 4:4:4 format. c. In one example, this block contains both luma and chroma components. 70. For a 4:2:0 chroma block starting at (x,y) and with block vector (BVx,BVy), if isRec(((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32),((y+BVy)>>5<<5)+(y%32)) is true, then the block vector is invalid. 71. The decision whether BV is invalid for a block of component c may depend on the availability of samples of component X instead of checking only luma samples. For a block of component c starting at (x,y) and with block vector (BVx,BVy), if isRec(c,((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+(x%64),((y+BVy)>>6<<6)+(y%64)) is true, then the block vector may be treated as invalid. i. In one example, this block is a luminance block (eg, c is the luminance component or the G component for RGB coding). ii. In one example, this block is a chroma block in 4:4:4 format (eg, c is the cb or cr component, or the B / R component for RGB encoding). iii. In one example, the availability of samples for both luma and chroma components may be checked, eg, this block includes both luma and chroma components. b. For a 4:2:0 format chroma block starting at (x,y) of component c with block vector (BVx,BVy), if isRec(c,((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32),((y+BVy)>>5<<5)+(y%32)) is true, the block vector may be treated as invalid. c. For a chroma block or sub-block starting at (x,y) of component c and with block vector (BVx,BVy), if isRec(c,x+BVx+Chroma_CTU_size,y) for the chroma component is true, the block vector may be treated as invalid, where Chroma_CTU_size is the CTU size of the chroma component. i. In one example, for 4:2:0 format, Chroma_CTU_size may be 64. ii. In one example, the chroma sub-blocks may be 2x2 blocks in 4:2:0 format. iii. In one example, the chroma sub-blocks may be 4x4 blocks in a 4:4:4 format. iv. In one example, the chroma sub-blocks may correspond to the smallest CU size in the luma component. 1. Alternatively, the chroma sub-block may correspond to the smallest CU size of the chroma components. 72. For all the bullets above, we assume that the reference buffer contains multiple MxM blocks, where M=64. However, this can be extended to other cases, such as when the reference buffer contains multiple NxM blocks (e.g., N=128, M=64). 73. For all bullets above, a further constraint may be applied: the reference buffer should be in the same brick / tile / tile group / slice as the current block. In one example, if any part of the reference buffer is outside the current brick / tile / tile group / slice, the use of IBC may be disabled and signaling of IBC related syntax elements may be skipped. b. Alternatively, if part of the reference buffer is outside the current brick / tile / tile group / slice, IBC may still be enabled for one block, but the block vector associated with the one block may only point to the remaining reference buffer. 74. It is proposed that the reference field of an IBC shall have, excluding the current VPDU, the K1 most recently coded VPDUs in the first VPDU row of a CTU / CTB row, if available, and the K2 most recently coded VPDUs in the second VPDU row of a CTU / CTB row, if possible. In one example, K1 is equal to 2 and K2 is equal to 1. b. In one example, the above method may be applied when the CTU / CTB size is 128×128 and the VPDU size is 64×64. c. In one example, the above method may be applied when the CTU / CTB size is 64×64 and the VPDU size is 64×64 and / or 32×32. d. In one example, the above method may be applied when the CTU / CTB size is 32×32 and the VPDU size is less than or equal to 32×32. 75. The methods described above may be applied at different stages. In one example, a modulus operation (eg, mod b) on a block vector (BV) may be invoked in a BV availability check process to determine whether the BV is valid. b. In one example, a modular operation (e.g., mod b) of a block vector (BV) may be invoked to determine the position of a reference sample (e.g., based on the position of the current sample and the modular result of the BV) in the IBC virtual buffer or reconstructed picture buffer (e.g., before the in-loop filtering process).

[0087] 5. Embodiments 5.1 Embodiment #1 One implementation of a buffer for the IBC is described below.

[0088] The buffer size is 128x128. The size of the CTU is also 128x128. For encoding the first CTU in one CTU row, the buffer is initialized with 128 (for an 8-bit video signal). For encoding the k-th CTU in a CTU row, the buffer is initialized with reconstruction before loop filtering of the (k-1)-th CTU.

[0089] FIG. 3 illustrates the coding of a block starting at (x,y).

[0090] When encoding a block starting at (x,y) for the current CTU, we send a block vector (BVx,BVy)=(x-x0,y-y0) to the decoder to indicate that the reference block is from (x0,y0) in the IBC buffer. Let w and h be the width and height of the block, respectively. When we finish encoding the block, the wxh region starting at (x,y) in the IBC buffer is updated by the reconstruction of the block before loop filtering.

[0091] 5.2 Example #2 FIG. 4 illustrates a possible alternative method for selecting a previously coded 64×64 block.

[0092] 5.3 Example #3 FIG. 5 illustrates an alternative way in which the encoding / decoding order of a 64×64 block can be changed.

[0093] 5.4 Example #4 FIG. 8 shows another possible alternative method of selecting the previous coded 64×64 block when the decoding order of the 64×64 blocks is top-to-bottom, left-to-right.

[0094] 5.5 Embodiment #5 FIG. 9 shows another possible alternative for selecting the previously coded 64×64 block.

[0095] 5.6 Example #6 FIG. 11 shows another possible alternative method for selecting the previous coded 64×64 block when the decoding order of the 64×64 blocks is left-to-right, top-to-bottom.

[0096] 5.7 Example #7 If the CTU has size W×W, and in the decoder we implement an IBC buffer of size mW×W and bit depth B, then:

[0097] At the start of decoding a CTU row, initialize the buffer with the value (1<<(B-1)) and set the update starting point (xb, yb) to (0, 0).

[0098] When decoding a CU starting at (x,y) with size w×h relative to the top-left corner of the CTU, after aligning the bit depth to B bits, update the area starting at (xb+x,yb+y) and size w×h with the reconstructed pixel values ​​of the CU.

[0099] After decoding the CTU, set the update starting point (xb, yb) as ((xb+W) mod mW,0).

[0100] When decoding an IBC CU with block vector (BVx, BVy), for any pixel (x, y) relative to the top-left corner of the CTU, extract its prediction from buffer location ((x+BVx) mod mW, (y+BVy) mode W) after bit-depth alignment to the bit-depth of the prediction signal.

[0101] In one example, B may be set to 7 or 8, while the output / input bit depth of the block may be equal to 10.

[0102] 5.8 Example #8 For a luma CU or combined luma / chroma CU starting at (x,y) and block vector (BVx,BVy) relative to the top-left corner of the picture, the block vector is invalid if isRec(((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+(x%64),((y+BVy)>>6<<6)+(y%64)) is true.

[0103] For a chroma CU starting at (x,y) and block vector (BVx,BVy) relative to the top-left corner of the picture, the block vector is invalid if isRec(((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32),((y+BVy)>>5<<5)+(y%32)) is true.

[0104] 5.9 Example #9 For a chroma block or sub-block starting at (x,y) in 4:2:0 format relative to the top-left corner of the picture, and a block vector (BVx,BVy), the block vector is invalid if isRec(c,(x+BVx+64,y+BVy)) is true and c is a chroma component.

[0105] For a chroma block or sub-block starting at (x,y) in 4:4:4 format with respect to the top-left corner of the picture, and a block vector (BVx,BVy), if isRec(c,(x+BVx+64,y+BVy)) is true and c is a chroma component, then the block vector is invalid.

[0106] 5.10 Example #10 For a luma CU or combined luma / chroma CU starting at (x,y) and block vector (BVx,BVy) relative to the top-left corner of the picture, the block vector is invalid if isRec(((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+(x%64),((y+BVy)>>6<<6)+(y%64)) is true.

[0107] For a chroma block or sub-block starting at (x,y) in 4:2:0 format relative to the top-left corner of a picture, and a block vector (BVx,BVy), if isRec(c,((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32),((y+BVy)>>5<<5)+(y%32)) is true and c is a chroma component, the block vector is invalid.

[0108] 5.11 Example #11 In this embodiment, the emphasis is on an implementation that keeps the two most coded VPDUs in the first VPDU row and the one most coded VPDU in the second VPDU row of the first CTU / CTB row, excluding the current VPDU.

[0109] If the coding order is top-to-bottom, left-to-right, the reference region is shown as in Figure 13.

[0110] If the coding order of the VPDUs is left-to-right and top-to-bottom, and the current VPDU is not to the right of a picture boundary, the reference area is shown as in FIG.

[0111] If the coding order of the VPDU is from left to right and top to bottom, and the current VPDU is on the right side of the picture boundary, the reference region can be shown as in FIG.

[0112] If the size of a luminance block (x,y) is w×h, then we can know whether a block vector (BVx,BVy) is valid by checking the following condition:

[0113] isRec(((x+BVx+128)>>6<<6)-(refy&0x40)+(x%64),((y+BVy)>>6<<6)+(refy>>6==y>>6)?(y%64):0). Here, refy=(y&0x40)?(y+BVy):(y+BVy+w-1).

[0114] If the above function returns true, then the block vector (BVx, BVy) is invalid; otherwise, the block vector may be valid.

[0115] 5.12 Example #12 If the size of the CTU is 192x128, a virtual buffer of size 192x128 is maintained to track the reference samples of the IBC.

[0116] A sample (x,y) relative to the top-left corner of the picture is associated with a position (x%192,y%128) relative to the top-left corner of the buffer. The following steps show how to mark the availability of a sample associated with a virtual buffer for IBC reference:

[0117] Record the position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the picture to represent the top-left sample of the most recently decoded VPDU. 1) At the start of decoding one VPDU row, all positions in the buffer are marked as unavailable: (xPrevVPDU, yPrevVPDU) are set as (0,0). 2) At the start of decoding of the first CU of a VPDU, we may mark as unavailable position (x,y) where x=(xPrevVPDU-2WVPDU+2mWVPDU)%(mWVPDU),..,((xPrevVPDU-2WVPDU+2mWVPDU)%(mWVPDU))-1+WVPDU; and y=yPrevVPDU%(nHVPDU),..,(yPrevVPDU%(nHVPDU))-1+HVPDU. Then we set (xPrevVPDU,yPrevVPDU) as (xCU,yCU), i.e. the top-left position of the CU with respect to the picture. 3) After decoding one CU, position (x,y), where x=xCU%(mWVPDU),...,(xCU+CU_width-1)%(mWVPDU) and y=yCU%(nHVPDU),...,(yCU+CU_height-1)%(nHVPDU), is marked as available. 4) For an IBCCU with block vector (xBV, yBV), position (x, y) where x=(xCU+xBV)%(mWVPDU),...,(xCU+xBV+CU_width-1)%(mWVPDU) and y=(yCU+yBV)%(nHVPDU),...,(yCU+yBV+CU_height-1)%(nHVPDU) is marked as unavailable and the block vector is considered invalid.

[0118] FIG. 16 shows the buffer status for a picture together with the decoding status of a VPDU.

[0119] 5.13 Embodiment #13 If the size of the CTU is 128x128 or if the size of the CTU is larger than the size of the VPDU (e.g., 64x64 in the current design), or if the size of the CTU is larger than the size of the VPDU (e.g., 64x64 in the current design), a virtual buffer of size 192x128 is maintained to track the reference samples for the IBC. In the following, if a<0, (a%b) is defined as floor(a / b)*b, and floor(c) returns the largest integer less than or equal to c.

[0120] A sample (x,y) relative to the top-left corner of the picture is associated with a position (x%192,y%128) relative to the top-left corner of the buffer. The following steps show how to mark the availability of a sample associated with a virtual buffer for IBC reference:

[0121] Record the position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the picture to represent the top-left sample of the most recently decoded VPDU. 1) At the start of decoding one VPDU row, all positions in the buffer are marked as unavailable: (xPrevVPDU, yPrevVPDU) are set as (0,0). 2) At the beginning of decoding of the first CU of a VPDU, a. If yPrevVPDU%64 is equal to 0, then positions (x,y) where x=(xPrevVPDU-128)%192,..,((xPrevVPDU-128)%192)+63; and y=yPrevVPDU%128,..,(yPrevVPDU%128)+63 are marked as unavailable. Then, set (xPrevVPDU,yPrevVPDU) as (xCU,yCU), i.e., the top-left position of the CU relative to the picture. b. Otherwise, positions (x,y) where x=(xPrevVPDU-64)%192,..,((xPrevVPDU-64)%192)+63; and y=yPrevVPDU%128,..,(yPrevVPDU%128)+63 are marked as unavailable, and (xPrevVPDU,yPrevVPDU) is set as (xCU,yCU), i.e., the top-left position of the CU relative to the picture. 3) After decoding one CU, position (x,y), where x=xCU%192,...,(xCU+CU_width-1)%192 and y=yCU%128,...,(yCU+CU_height-1)%128, is marked as available. 4) For an IBCCU with block vector (xBV, yBV), the position (x, y) where x=(xCU+xBV)%192,...,(xCU+xBV+CU_width-1)%192 and y=(yCU+yBV)%128,...,(yCU+yBV+CU_height-1)%128 is marked as unavailable and the block vector is considered invalid.

[0122] If the size of the CTU is S x S, then let Wbuf equal 128*128 / S since S is not equal to 128. A virtual buffer of size WbufxS is maintained to keep track of the reference samples of the IBC. In this case, the size of the VPDU is equal to the size of the CTU.

[0123] Record the position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the picture to represent the top-left sample of the most recently decoded VPDU. 1) At the start of decoding one VPDU row, all positions in the buffer are marked as unavailable: (xPrevVPDU, yPrevVPDU) are set as (0,0). 2) At the start of decoding the first CU of a VPDU, x = (xPrevVPDU-W buf *S)%S,..,((xPrevVPDU-W buf *Position if S)%S)+S-1;andy=yPrevVPDU%S,..,(yPrevVPDU%S)+S-1 (x,y) is marked as unavailable, and (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the top-left position of the CU relative to the picture. 3) After decoding one CU, x=xCU%(W buf ),...,(xCU+CU_width-1)%(W buf ) and the position (x,y) where y=yCU%S,...,(yCU+CU_height-1)%S is marked as available. 4) For an IBCCU with block vector (xBV, yBV), position (x, y) where x=(xCU+xBV)%(Wbuf),...,(xCU+xBV+CU_width-1)%(Wbuf) and y=(yCU+yBV)%S,...,(yCU+yBV+CU_height-1)%S is marked as unavailable and the block vector is considered invalid.

[0124] 5.14 Embodiment #14 If the size of the CTU is 128x128 or if the size of the CTU is larger than the size of the VPDU (e.g., 64x64 in the current design), or if the size of the CTU is larger than the size of the VPDU (e.g., 64x64 in the current design), a virtual buffer of size 256x128 is maintained to track the reference samples for the IBC. In the following, if a<0, we define (a%b) as floor(a / b)*b, and floor(c) returns the largest integer less than or equal to c.

[0125] A sample (x,y) relative to the top-left corner of the picture is associated with a position (x%256,y%128) relative to the top-left corner of the buffer. The following steps show how to mark the availability of a sample associated with a virtual buffer for IBC reference:

[0126] Record the position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the picture to represent the top-left sample of the most recently decoded VPDU. 1) At the start of decoding one VPDU row, all positions in the buffer are marked as unavailable: (xPrevVPDU, yPrevVPDU) are set as (0,0). 2) At the beginning of decoding of the first CU of a VPDU, a. If yPrevVPDU%64 is equal to 0, then positions (x,y) where x=(xPrevVPDU-128)%256,..,((xPrevVPDU-128)%256)+63; and y=yPrevVPDU%128,..,(yPrevVPDU%128)+63 are marked as unavailable. Then, set (xPrevVPDU,yPrevVPDU) as (xCU,yCU), i.e., the top-left position of the CU relative to the picture. b. Otherwise, positions (x,y) where x=(xPrevVPDU-64)%256,..,((xPrevVPDU-64)%256)+63; and y=yPrevVPDU%128,..,(yPrevVPDU%128)+63 are marked as unavailable, and (xPrevVPDU,yPrevVPDU) is set as (xCU,yCU), i.e., the top-left position of the CU relative to the picture. 3) After decoding one CU, position (x,y), where x=xCU%256,...,(xCU+CU_width-1)%256 and y=yCU%128,...,(yCU+CU_height-1)%128, is marked as available. 4) For an IBCCU with block vector (xBV, yBV), position (x, y) where x=(xCU+xBV)%256,...,(xCU+xBV+CU_width-1)%256 and y=(yCU+yBV)%128,...,(yCU+yBV+CU_height-1)%128 is marked as unavailable and the block vector is considered invalid.

[0127] If the size of the CTU is not 128x128, or is less than 64x64, or is less than 64x64, the same processing as in the previous example, ie, embodiment #14, is applied.

[0128] 5.15 Embodiment #15 The IBC Reference Availability Marking process is explained below, with the changes shown in this document in bold, underlined, and italicized type.

[0129] [Table 4]

[0130] [Table 5] [ka]

[0131] 7.3.7.5 Coding Unit Syntax

[0132] [Table 6]

[0133] 8.6.2 Motion Vector Component Derivation Process for IBC Blocks 8.6.2.1 General ... [ka] ...

[0134] 8.6.3 Decoding process of ibc block 8.6.3.1 General This process is invoked when decoding a coding unit that was coded in ibc prediction mode.

[0135] The inputs to this process are: - a luminance position (xCb, yCb) that defines the top-left sample of the current coding block relative to the top-left luminance sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, a variable cbHeight that specifies the height of the current coding block in luma samples, the variables numSbX and numSbY defining the number of luminance-coding sub-blocks in the horizontal and vertical directions, - Motion vector mv[xSbIdx][ySbIdx] where xSbIdx=0..numSbX-1 and ySbIdx=0..numSbY-1 - Variable cIdx that specifies the color component index of the current block [ka] ...

[0136] For each coding sub-block of sub-block index (xSbIdx, ySbIdx), where xSbIdx=0..numSbX-1, and ySbIdx=0..numSbY-1, the following applies: - The luminance position (xSb, ySb) that defines the top-left sample of the current coding sub-block relative to the top-left luminance sample of the current picture is derived as follows: (xSb,ySb)=(xCb+xSbIdx*sbWidth,yCb+ySbIdx*sbHeight) (8-913) [ka] [ka]

[0137] 8.7.5 Picture Reconstruction Process 8.7.5.1 General The inputs to this process are: - a position (xCurr, yCurr) that defines the top-left sample of the current block relative to the top-left sample of the current picture component, - the variables nCurrSw and nCurrSh, which respectively define the width and height of the current block, - the variable cIdx, which specifies the color components of the current block, - predSamples, a (nCurrSw) by (nCurrSh) array specifying the predicted samples of the current block; - resamples, a (nCurrSw) by (nCurrSh) array specifying the residual samples of the current block.

[0138] The output of this process is: - The reconstructed picture sample array recSamples. [ka]

[0139] 5.16 Embodiment #16 This is the same as the above embodiment, except for the following changes.

[0140] [Table 7]

[0141] [Table 8] [ka]

[0142] 5.17 Embodiment #17 In this specification, the changes in some instances are indicated by bold, underlined text.

[0143] 7.3.7 Slice Data Syntax 7.3.7.1 General slice data syntax

[0144] [Table 9]

[0145] 7.4.8.5 Coding Unit Syntax

[0146] If all of the following conditions are true, the history-based motion vector predictor for shared merge candidate list regions is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i], for i=0..NumHmvpIbcCand-1: - IsInSmr[x0][y0] is equal to TRUE. - SmrX[x0][y0] is equal to x0. - SmrY[x0][y0] is equal to y0.

[0147] For x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1, make the following assignments: CbPosX[x][y]=x0 (7-135) CbPosY[x][y]=y0 (7-136) CbWidth[x][y]=cbWidth (7-137) CbHeight[x][y]=cbHeight (7-138) [ka]

[0148] 8.6.2 Motion Vector Component Derivation Process for IBC Blocks 8.6.2.1 General The inputs to this process are: - the luminance position (xCb, yCb) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, A variable cbHeight that specifies the height of the current coding block in luma samples.

[0149] The output of this process is: - Luminance motion vectors at 1 / 16 fractional sample accuracy mvL.

[0150] The luminance motion vector mvL is derived as follows. - The IBC luma motion vector prediction derivation process specified in subclause 8.6.2.2 is invoked with the luma position (xCb, yCb) and the variables cbWidth and cbHeight as input, and its output is the luma motion vector mvL. - If general_merge_flag[xCb][yCb] is 0, the following applies: 1. The variable mvd is derived as follows: mvd[0]=MvdL0[xCb][yCb][0] (8-883) mvd[1]=MvdL0[xCb][yCb][1] (8-884) 2. The motion vector rounding process as specified in Section 8.5.2.14 is invoked with mvX set equal to mvL, rightShift set equal to MvShift+2, and leftShift set equal to MvShift+2 as input, and the rounded mvL is the output. 3. The luma motion vector mvL is modified as follows: u[0]=(mvL[0]+mvd[0]+2 18 )%2 18 (8-885) mvL[0]=(u[0]>=2 17 )?(u[0]-2 18 ):u[0](8-886) u[1]=(mvL[1]+mvd[1]+2 18 )%2 18 (8-887) mvL[1]=(u[1]>=2 17 )?(u[1]-2 18 ):u[1] (8-888) NOTE 1 - The result value of mvL[0] and mvL[1] specified above is always -2. 17 ~2 17 Included in the range -1.

[0151] The history-based motion vector predictor list update process as specified in Section 8.6.2.6 is invoked using the luma motion vector mvL. [ka]

[0152] 8.7.5 Picture Reconstruction Process 8.7.5.1 General The inputs to this process are: - a position (xCurr, yCurr) that defines the top-left sample of the current block relative to the top-left sample of the current picture component, - the variables nCurrSw and nCurrSh, which respectively define the width and height of the current block, - the variable cIdx, which specifies the color components of the current block, - predSamples, a (nCurrSw) by (nCurrSh) array specifying the predicted samples of the current block; - resamples, a (nCurrSw) by (nCurrSh) array specifying the residual samples of the current block.

[0153] [ka]

[0154] Based on the value of the color component cIdx, the following assignments are made: - If cIdx is equal to 0, recSamples is the reconstructed picture sample array S L The function clipCidx1 corresponds to Clip1 Y Corresponds to. - Otherwise, if cIdx is equal to 1, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array SCb, and the function clipCidx1 is set equal to Clip1. C Corresponds to. - Otherwise (cIdx is equal to 2), set tuCbfChroma equal to tu_cbf_cr[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array SCr, and function clipCidx1 returns Clip1 C Corresponds to.

[0155] Depending on the value of slice_lmcs_enabled_flag, the following applies: - if slice_lmcs_enabled_flag is equal to 0, the (nCurrSw) × (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr), for i = 0..nCurrSw-1, j = 0..nCurrSh-1, is derived as follows: recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992) - Otherwise (slice_lmcs_enabled_flag is equal to 1), the following applies: - If cIdx is equal to 0, the following applies: - Picture reconstruction with luma sample mapping as specified in subclause 8.7.5.2 is called with the luma position (xCurr, yCurr), the block width nCurrSw and height nCurrSh, the predicted luma sample array preSamples, and the residual luma sample array reSamples; the output is the reconstructed luma sample array reCamples. - Otherwise (cIdx is greater than 0), the picture reconstruction by luma-dependent chroma residual scaling of chroma samples as specified in subclause 8.7.5.3 is called with the chroma position (xCurr, yCurr), the width and height of the transform block nCurrSw and nCurrSh, the coded block flag of the current chroma transform block tuCbfChroma, the predicted chroma sample array predSamples, the residual chroma sample array resSamples, and the reconstructed chroma sample array recSamples as output. [ka]

[0156] 5.18 Embodiment #18 In some examples, the changes are shown in bold, underlined, and italicized type herein.

[0157] 7.3.7 Slice Data Syntax 7.3.7.1 General slice data syntax

[0158] [Table 10]

[0159] 7.4.8.5 Coding Unit Syntax

[0160] If all of the following conditions are true, the history-based motion vector predictor for shared merge candidate list regions is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i], for i=0..NumHmvpIbcCand-1: - IsInSmr[x0][y0] is equal to TRUE. - SmrX[x0][y0] is equal to x0. - SmrY[x0][y0] is equal to y0.

[0161] For x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1, make the following assignments: CbPosX[x][y]=x0 (7-135) CbPosY[x][y]=y0 (7-136) CbWidth[x][y]=cbWidth (7-137) CbHeight[x][y]=cbHeight (7-138) [ka]

[0162] 8.6.2 Motion Vector Component Derivation Process for IBC Blocks 8.6.2.1 General The inputs to this process are: - the luminance position (xCb, yCb) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, A variable cbHeight that specifies the height of the current coding block in luma samples.

[0163] The output of this process is: - Luminance motion vectors at 1 / 16 fractional sample accuracy mvL.

[0164] The luminance motion vector mvL is derived as follows. - The IBC luma motion vector prediction derivation process specified in subclause 8.6.2.2 is invoked with the luma position (xCb, yCb) and the variables cbWidth and cbHeight as input, and its output is the luma motion vector mvL. - if general_merge_flag[xCb][yCb] is equal to 0, the following applies: 1. The variable mvd is derived as follows: mvd[0]=MvdL0[xCb][yCb][0] (8-883) mvd[1]=MvdL0[xCb][yCb][1] (8-884) 2. The motion vector rounding process as specified in Section 8.5.2.14 is invoked with mvX set equal to mvL, rightShift set equal to MvShift+2, and leftShift set equal to MvShift+2 as input, and the rounded mvL is the output. 3. The luma motion vector mvL is modified as follows: u[0]=(mvL[0]+mvd[0]+2 18 )%2 18 (8-885) mvL[0]=(u[0]>=2 17 )?(u[0]-2 18 ):u[0] (8-886) u[1]=(mvL[1]+mvd[1]+2 18 )%2 18 (8-887) mvL[1]=(u[1]>=2 17 )?(u[1]-2 18 ):u[1] (8-888) NOTE 1 - The result value of mvL[0] and mvL[1] specified above is always -2. 17 ~2 17 Included in the range -1.

[0165] The history-based motion vector predictor list update process as specified in Section 8.6.2.6 is invoked using the luma motion vector mvL. [ka]

[0166] 8.6.3 Decoding process of ibc block 8.6.3.1 General This process is invoked when decoding a coding unit that was coded in ibc prediction mode.

[0167] The inputs to this process are: - a luminance position (xCb, yCb) that defines the top-left sample of the current coding block relative to the top-left luminance sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, a variable cbHeight that specifies the height of the current coding block in luma samples, - color component index of the current block, [ka]

[0168] The output of this process is: - The array of prediction samples, predSamples. [ka]

[0169] 8.7.5 Picture Reconstruction Process 8.7.5.1 General The inputs to this process are: - a position (xCurr, yCurr) that defines the top-left sample of the current block relative to the top-left sample of the current picture component, - the variables nCurrSw and nCurrSh, which respectively define the width and height of the current block, - the variable cIdx, which specifies the color components of the current block, - predSamples, a (nCurrSw) by (nCurrSh) array specifying the predicted samples of the current block; - resamples, a (nCurrSw) by (nCurrSh) array specifying the residual samples of the current block.

[0170] [ka]

[0171] Based on the value of the color component cIdx, the following assignments are made: - If cIdx is equal to 0, recSamples is the reconstructed picture sample array S L The function clipCidx1 corresponds to Clip1 Y Corresponds to. - Otherwise, if cIdx is equal to 1, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr] and recSamples is the reconstructed chroma sample array S Cb The function clipCidx1 corresponds to Clip1 C Corresponds to. - Otherwise, (if cIdx is equal to 2, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr] and recSamples is the reconstructed chroma sample array S Cb The function clipCidx1 corresponds to Clip1 C Corresponds to.

[0172] Depending on the value of slice_lmcs_enabled_flag, the following applies: - if slice_lmcs_enabled_flag is equal to 0, the (nCurrSw) × (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr), for i = 0..nCurrSw-1, j = 0..nCurrSh-1, is derived as follows: recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992) - Otherwise (slice_lmcs_enabled_flag is equal to 1), the following applies: - If cIdx is equal to 0, the following applies: - Picture reconstruction with luma sample mapping as specified in subclause 8.7.5.2 is called with the luma position (xCurr, yCurr), the block width nCurrSw and height nCurrSh, the predicted luma sample array preSamples, and the residual luma sample array reSamples; the output is the reconstructed luma sample array reCamples. - Otherwise (cIdx is greater than 0), the picture reconstruction by luma-dependent chroma residual scaling of chroma samples as specified in subclause 8.7.5.3 is called with the chroma position (xCurr, yCurr), the width and height of the transform block nCurrSw and nCurrSh, the coded block flag of the current chroma transform block tuCbfChroma, the predicted chroma sample array predSamples, the residual chroma sample array resSamples, and the reconstructed chroma sample array recSamples as output. [ka]

[0173] 5.19 Embodiment #19 In this specification, the changes in some instances are indicated by bold, underlined text.

[0174] 7.3.7 Slice Data Syntax 7.3.7.1 General slice data syntax

[0175] [Table 11]

[0176] 7.4.8.5 Coding Unit Syntax If all of the following conditions are true, the history-based motion vector predictor for shared merge candidate list regions is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i], for i=0..NumHmvpIbcCand-1: - IsInSmr[x0][y0] is equal to TRUE. - SmrX[x0][y0] is equal to x0. - SmrY[x0][y0] is equal to y0.

[0177] For x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1, make the following assignments: CbPosX[x][y]=x0 (7-135) CbPosY[x][y]=y0 (7-136) CbWidth[x][y]=cbWidth (7-137) CbHeight[x][y]=cbHeight (7-138) [ka]

[0178] 8.6.2 Motion Vector Component Derivation Process for IBC Blocks 8.6.2.1 General The inputs to this process are: - the luminance position (xCb, yCb) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, A variable cbHeight that specifies the height of the current coding block in luma samples.

[0179] The output of this process is: - Luminance motion vectors at 1 / 16 fractional sample accuracy mvL.

[0180] The luminance motion vector mvL is derived as follows. - The IBC luma motion vector prediction derivation process specified in subclause 8.6.2.2 is It is called with inputs (xCb, yCb), variables cbWidth and cbHeight, and its output is the luminance motion vector mvL. - If general_merge_flag[xCb][yCb] is 0, the following applies: 1. The variable mvd is derived as follows: mvd[0]=MvdL0[xCb][yCb][0] (8-883) mvd[1]=MvdL0[xCb][yCb][1] (8-884) 2. The motion vector rounding process as specified in Section 8.5.2.14 is invoked with mvX set equal to mvL, rightShift set equal to MvShift+2, and leftShift set equal to MvShift+2 as input, and the rounded mvL is the output. 3. The luma motion vector mvL is modified as follows: u[0]=(mvL[0]+mvd[0]+2 18 )%2 18 (8-885) mvL[0]=(u[0]>=2 17 )?(u[0]-2 18 ):u[0] (8-886) u[1]=(mvL[1]+mvd[1]+2 18 )%2 18 (8-887) mvL[1]=(u[1]>=2 17 )?(u[1]-2 18 ):u[1] (8-888) NOTE 1 - The result value of mvL[0] and mvL[1] specified above is always -2. 17 ~2 17 Included in the range -1.

[0181] The history-based motion vector predictor list update process as specified in Section 8.6.2.6 is invoked using the luma motion vector mvL. [ka]

[0182] 8.6.3 Decoding process of ibc block 8.6.3.1 General This process is invoked when decoding a coding unit that was coded in ibc prediction mode.

[0183] The inputs to this process are: - a luminance position (xCb, yCb) that defines the top-left sample of the current coding block relative to the top-left luminance sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, a variable cbHeight that specifies the height of the current coding block in luma samples, [ka]

[0184] 8.7.5 Picture Reconstruction Process 8.7.5.1 General The inputs to this process are: - a position (xCurr, yCurr) that defines the top-left sample of the current block relative to the top-left sample of the current picture component, - the variables nCurrSw and nCurrSh, which respectively define the width and height of the current block, - the variable cIdx, which specifies the color components of the current block, - predSamples, a (nCurrSw) by (nCurrSh) array specifying the predicted samples of the current block; - resamples, a (nCurrSw) by (nCurrSh) array specifying the residual samples of the current block.

[0185] The output of this process is the reconstructed picture sample array recSamples and the IBC buffer array ibcBuf. L , ibcBuf Cb , ibcBuf Cr It is.

[0186] Based on the value of the color component cIdx, the following assignments are made: - If cIdx is equal to 0, recSamples corresponds to the reconstructed picture sample array SL, and the function clipCidx1 returns Clip1 Y Corresponds to. - Otherwise, if cIdx is equal to 1, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr] and recSamples is the reconstructed chroma sample array S Cb The function clipCidx1 corresponds to Clip1 C Corresponds to. - Otherwise, (if cIdx is equal to 2, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr] and recSamples is the reconstructed chroma sample array S Cr The function clipCidx1 corresponds to Clip1 C Corresponds to.

[0187] Depending on the value of slice_lmcs_enabled_flag, the following applies: - if slice_lmcs_enabled_flag is equal to 0, the (nCurrSw) × (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr), for i = 0..nCurrSw-1, j = 0..nCurrSh-1, is derived as follows: recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992) - Otherwise (slice_lmcs_enabled_flag is equal to 1), the following applies: - If cIdx is equal to 0, the following applies: - Picture reconstruction with luma sample mapping as specified in subclause 8.7.5.2 is called with the luma position (xCurr, yCurr), the block width nCurrSw and height nCurrSh, the predicted luma sample array preSamples, and the residual luma sample array reSamples; the output is the reconstructed luma sample array reCamples. - Otherwise (cIdx is greater than 0), the picture reconstruction by luma-dependent chroma residual scaling process of chroma samples as specified in subclause 8.7.5.3 is called with the chroma position (xCurr, yCurr), the width and height of the transform block nCurrSw and nCurrSh, the coded block flag of the current chroma transform block tuCbfChroma, the predicted chroma sample array predSamples, the residual chroma sample array resSamples, and the reconstructed chroma sample array recSamples as output. [ka]

[0188] 5.20 Example #20 In some examples, the changes are shown in bold, underlined, and italicized type herein.

[0189] 7.3.7 Slice Data Syntax 7.3.7.1 General slice data syntax

[0190] [Table 12]

[0191] 7.4.8.5 Coding Unit Syntax If all of the following conditions are true, the history-based motion vector predictor for shared merge candidate list regions is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i], for i=0..NumHmvpIbcCand-1: - IsInSmr[x0][y0] is equal to TRUE. - SmrX[x0][y0] is equal to x0. - SmrY[x0][y0] is equal to y0.

[0192] For x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1, make the following assignments: CbPosX[x][y]=x0 (7-135) CbPosY[x][y]=y0 (7-136) CbWidth[x][y]=cbWidth (7-137) CbHeight[x][y]=cbHeight (7-138) [ka]

[0193] 8.6.2 Motion Vector Component Derivation Process for IBC Blocks 8.6.2.1 General The inputs to this process are: - the luminance position (xCb, yCb) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, A variable cbHeight that specifies the height of the current coding block in luma samples.

[0194] The output of this process is: - Luminance motion vectors at 1 / 16 fractional sample accuracy mvL.

[0195] The luminance motion vector mvL is derived as follows. - The IBC luma motion vector prediction derivation process specified in subclause 8.6.2.2 is invoked with the luma position (xCb, yCb) and the variables cbWidth and cbHeight as input, and its output is the luma motion vector mvL. - if general_merge_flag[xCb][yCb] is equal to 0, the following applies 1. The variable mvd is derived as follows: mvd[0]=MvdL0[xCb][yCb][0] (8-883) mvd[1]=MvdL0[xCb][yCb][1] (8-884) 2. The motion vector rounding process as specified in Section 8.5.2.14 is invoked with mvX set equal to mvL, rightShift set equal to MvShift+2, and leftShift set equal to MvShift+2 as input, and the rounded mvL is the output. 3. The luma motion vector mvL is modified as follows: u[0]=(mvL[0]+mvd[0]+2 18 )%2 18 (8-885) mvL[0]=(u[0]>=2 17 )?(u[0]-2 18 ):u[0] (8-886) u[1]=(mvL[1]+mvd[1]+2 18 )%2 18 (8-887) mvL[1]=(u[1]>=2 17 )?(u[1]-2 18 ):u[1] (8-888) NOTE 1 - The result value of mvL[0] and mvL[1] specified above is always -2. 17 ~2 17Included in the range -1.

[0196] The history-based motion vector predictor list update process as specified in Section 8.6.2.6 is invoked using the luma motion vector mvL. [ka]

[0197] 8.6.3 Decoding process of ibc block 8.6.3.1 General This process is invoked when decoding a coding unit that was coded in ibc prediction mode.

[0198] The inputs to this process are: - a luminance position (xCb, yCb) that defines the top-left sample of the current coding block relative to the top-left luminance sample of the current picture, a variable cbWidth that specifies the width of the current coding block in luma samples, a variable cbHeight that specifies the height of the current coding block in luma samples, - a variable cIdx that specifies the color component index of the current block, [ka]

[0199] 8.7.5 Picture Reconstruction Process 8.7.5.1 General The inputs to this process are: - a position (xCurr, yCurr) that defines the top-left sample of the current block relative to the top-left sample of the current picture component, - the variables nCurrSw and nCurrSh, which respectively define the width and height of the current block, - the variable cIdx, which specifies the color components of the current block, - predSamples, a (nCurrSw) by (nCurrSh) array specifying the predicted samples of the current block; - resamples, a (nCurrSw) by (nCurrSh) array specifying the residual samples of the current block. [ka]

[0200] Based on the value of the color component cIdx, the following assignments are made: - If cIdx is equal to 0, recSamples is the reconstructed picture sample array S L The function clipCidx1 corresponds to Clip1 Y Corresponds to. - Otherwise, if cIdx is equal to 1, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr] and recSamples is the reconstructed chroma sample array S Cb The function clipCidx1 corresponds to Clip1 C Corresponds to. - Otherwise, (if cIdx is equal to 2, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr] and recSamples is the reconstructed chroma sample array S Cb The function clipCidx1 corresponds to Clip1 C Corresponds to.

[0201] Depending on the value of slice_lmcs_enabled_flag, the following applies: - if slice_lmcs_enabled_flag is equal to 0, the (nCurrSw) x (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr), for i = 0..nCurrSw-1, j = 0..nCurrSh-1, is derived as follows: recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992) - Otherwise (slice_lmcs_enabled_flag is equal to 1), the following applies: - If cIdx is equal to 0, the following applies: - Picture reconstruction with luma sample mapping as specified in subclause 8.7.5.2 is called with the luma position (xCurr, yCurr), the block width nCurrSw and height nCurrSh, the predicted luma sample array preSamples, and the residual luma sample array reSamples; the output is the reconstructed luma sample array reCamples. - Otherwise (cIdx is greater than 0), the picture reconstruction by luma-dependent chroma residual scaling of chroma samples as specified in subclause 8.7.5.3 is called with the chroma position (xCurr, yCurr), the width and height of the transform block nCurrSw and nCurrSh, the coded block flag of the current chroma transform block tuCbfChroma, the predicted chroma sample array predSamples, the residual chroma sample array resSamples, and the reconstructed chroma sample array recSamples as output. [ka]

[0202] 6 is a flow chart illustrating an example of an exemplary method for visual media (video or image) processing. Method 600 includes determining a buffer size for storing reference samples for a current video block using an intra block copying coding mode for converting between the current video block and a bitstream representation of the current video block (602) and performing the conversion using the reference samples stored in the buffer (604).

[0203] The following sections describe some exemplary preferred features implemented by embodiments of method 600 and other methods. Additional examples are provided in Section 4 of this specification.

[0204] 1. A video processing method comprising: determining a buffer size for storing reference samples for a current video block using an intra block copying coding mode for converting between a current video block and a bitstream representation of the current video block; and performing the conversion using the reference samples stored in the buffer.

[0205] 2. The method of claim 1, wherein the buffer size is a predetermined constant.

[0206] 3. The method of any of claims 1 to 2, wherein the size is M x N, where M and N are integers.

[0207] 4. The method of claim 3, wherein M×N is equal to 64×64 or 128×128 or 64×128.

[0208] 5. The method of claim 1, wherein the buffer size is equal to the size of a coding tree unit of the current video block.

[0209] 6. The method of claim 1, wherein the buffer size is equal to the size of a virtual pipeline data unit used for the transformation.

[0210] 7. The method of claim 1, wherein the buffer size corresponds to one field in the bitstream representation.

[0211] 8. The method according to claim 7, wherein the field is included in a video parameter set, a sequence parameter set or a picture parameter set, or in a bitstream representation at picture header, slice header or tile group header level.

[0212] 9. The method according to any one of claims 1 to 8, wherein the sizes of the buffers are different for reference samples of luma components and reference samples of chroma components.

[0213] 10. The method of any of claims 1 to 8, wherein the size of the buffer depends on a chroma subsampling format of the current video block.

[0214] 11. The method according to any one of claims 1 to 8, wherein the reference samples are stored in RGB format.

[0215] 12. A method according to any one of claims 1 to 11, wherein the buffer is used to store reconstructed samples before and after loop filtering.

[0216] 13. The method of claim 12, wherein the loop filtering comprises deblocking filtering, or adaptive loop filtering (ALF), or sample adaptive offset (SAO) filtering.

[0217] 14. A video processing method comprising: initializing a buffer that stores reference samples for the current video block using an intra block copying coding mode using initial values ​​of the reference samples for conversion between a current video block and a bitstream representation of the current video block; and performing the conversion using the reference samples stored in the buffer.

[0218] 15. The method of claim 14, wherein the initial value corresponds to a constant.

[0219] 16. A method according to any one of clauses 14 to 15, wherein the initial value is a function of the bit depth of the current video block.

[0220] 17. The method of claim 15, wherein the constant corresponds to a median gray value.

[0221] 18. The method of claim 14, wherein the initial values ​​correspond to pixel values ​​of a previously decoded video block.

[0222] 19. The method of clause 18, wherein the previously decoded video block corresponds to a decoded block before in-loop filtering.

[0223] 20. A method according to any one of claims 14 to 19, wherein the buffer size is one according to claims 1 to 13.

[0224] 21. A method according to any one of clauses 1 to 20, wherein x and y numbers are used to address pixel locations within the buffer.

[0225] 22. A method according to any of claims 1 to 20, wherein pixel locations within the buffer are addressed using a single number ranging from 0 to M*N-1, where M and N are the pixel width and pixel height of the buffer.

[0226] 23. A method according to any of claims 1 to 20, wherein the current bitstream representation includes a block vector for the transform, the block vector represented as (BVx, BVy) being equal to (x-x0, y-y0), where (x0, y0) corresponds to a top-left position of a coding tree unit of the current video block.

[0227] 24. A method according to any of clauses 1 to 20, wherein the current bitstream representation includes a block vector for the transform, the block vector represented as (BVx, BVy) being equal to (x-x0+Tx, y-y0+Ty), where (x0, y0) corresponds to a top-left position of a coding tree unit of the current video block, and Tx and Ty are offset values.

[0228] 25. The method of claim 24, wherein Tx and Ty are predefined offset values.

[0229] 26. A method according to any of claims 1 to 20, wherein during the transformation, for a pixel at position (x0, y0) and having a block vector (BVx, BVy), a corresponding reference in the buffer is found at reference position (x0+BVx, y0+BVy).

[0230] 27. The method of claim 26, wherein if the reference location is outside the buffer, the reference in the buffer is determined by clipping at the boundaries of the buffer.

[0231] 28. The method of claim 26, wherein the reference in the buffer is determined to have a predetermined value if the reference position is outside the buffer.

[0232] 29. A method according to any one of clauses 1 to 20, wherein during the transformation, for a pixel at position (x0, y0) and with block vector (BVx, BVy), a corresponding reference in the buffer is found at reference position ((x0+BVx) mod M, (y0+BVy) mod N), where "mod" is the modulo operation and M and N are integers representing the x and y dimensions of the buffer.

[0233] 30. A method of video processing comprising resetting a buffer that stores reference samples for intra block copy encoding at video boundaries during conversion between a video and a bitstream representation of a current video block, and performing the conversion using the reference samples stored in the buffer.

[0234] 31. The method of claim 30, wherein the image boundary corresponds to a new picture or a new tile.

[0235] 32. The method of claim 30, wherein the conversion is performed by updating the buffer with a reconstructed value of a virtual pipeline data unit (VPDU) after the reset.

[0236] 33. The method of claim 30, wherein the conversion is performed by updating the buffer with reconstructed values ​​of the coding tree unit after the reset.

[0237] 34. The method of claim 30, wherein the reset occurs at the beginning of each coding tree unit row.

[0238] 35. The method of claim 1, wherein the size of the buffer corresponds to L previously decoded blocks of 64x64, where L is an integer.

[0239] 36. The method of any of claims 1 to 35, wherein a vertical scan order is used to read or store samples in the buffer during the transformation.

[0240] 37. A video processing method comprising: using a buffer to store reference samples for a current video block using an intra block copying encoding mode for converting between a current video block and a bitstream representation of the current video block, wherein a first bit depth of the buffer is different from a second bit depth of the encoded data; and performing the conversion using the reference samples stored in the buffer.

[0241] 38. The method of claim 37, wherein the first bit depth is greater than the second bit depth.

[0242] 39. A method according to any one of clauses 37 to 38, wherein the first bit depth is the same as the bit depth of a reconstruction buffer used during conversion.

[0243] 40. A method according to any of clauses 37 to 39, wherein the first bit depth is signalled as a value or a difference value in the bitstream representation.

[0244] 41. The method according to any one of claims 37 to 40, wherein the conversion uses different bit depths for chroma and luminance components.

[0245] Additional embodiments and examples up to claims 37 to 41 are described in item 7 of Chapter 4.

[0246] 42. A video processing method including performing a conversion between a current video block and a bitstream representation of the current video block using an intra block copy mode, wherein a first accuracy used for prediction calculation during the conversion is lower than a second accuracy used for reconstruction calculation during the conversion.

[0247] 43. The method according to claim 43, wherein the prediction calculation includes determining a predicted sample value from a reconstructed sample value using clip{{p+[1<<(b-1)]}>>b,0,(1<<bitdepth)-1}<<b, where p is the reconstructed sample value, b is a predefined bit shift value, and bitdepth is the predicted sample accuracy.

[0248] Additional embodiments and examples up to claims 42 to 43 are described in items 28 to 31 and 34 of Chapter 4.

[0249] 44. A video processing method including performing a conversion between a current video block and a bitstream representation of the current video block using an intra block copy mode, wherein a size nM×nM is used for an encoding tree unit size M×M, n and N are integers, the current video block is positioned in the encoding tree unit, and the reference region is the encoding tree unit closest to the current video block and is an available n×n encoding tree unit.

[0250] Additional embodiments and examples of item 4 are described in item 35 of Chapter 4.

[0251] 45. A method of video processing comprising: converting between a current video block and a bitstream representation of the current video block using an intra block copy mode, wherein a size nM×nM is used other than a coding tree unit size, M×M, where n and N are integers, the current video block is positioned in the coding tree unit, and the reference region is the nearest available n×n-1 coding tree units in the coding tree unit corresponding to the current video block.

[0252] Additional embodiments and examples of Section 4 are described in Chapter 4, Section 36. Further exemplary embodiments are shown in Figures 8 and 9.

[0253] 46. ​​The method of claim 3, wherein M=mW, N=H, where W and H are the width and height of a coding tree unit (CTU) of a current video block, and m is a positive integer.

[0254] 47. The method of claim 3, wherein M=W and N=nH, where W and H are the width and height of a coding tree unit (CTU), and n is a positive integer.

[0255] 48. The method of claim 3, wherein M=mW, N=nH, W and H are the width and height of a coding tree unit (CTU), and m and n are positive integers.

[0256] 49. The method of any one of claims 46 to 48, wherein n and m depend on the size of the CTU.

[0257] 50. A method of video processing comprising: determining validity of a block vector of a component c of the video using a component X of the video, the component X being different from a luma component of the video, for conversion between a current video block and a bitstream representation of the current video block, and performing the conversion using the block vector upon determining that the block vector is valid for the current video block, where a block vector denoted as (BVx,BVy) is equal to (x-x0,y-y0), where (x0,y0) corresponds to a top-left position of a coding tree unit of the current video block.

[0258] 51. The method of claim 50, wherein the component c corresponds to a luminance component of the image.

[0259] 52. The method of claim 50, wherein the current image block is a chroma block and the image is in 4:4:4 format.

[0260] 53. The method of clause 50, wherein the image is in 4:2:0 format, the current image block is a chroma block starting at position (x, y), and said determining includes determining that the block vector is invalid if isRec(c,((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32),((y+BVy)>>5<<5)+(y%32)) is true.

[0261] 54. The method of claim 50, wherein the image is in 4:2:0 format, the current image block is a chroma block starting at position (x,y), and the determining includes determining that the block vector is invalid if isRec(c,x+BVx+Chroma_CTU_size,y) is true.

[0262] 55. A method of video processing comprising: determining to selectively use a preprocessed VPDU, K1, from a first row of the video domain and a preprocessed VPDU, K2, from a second row of the video domain for converting between a current video block of a current virtual pipeline data unit (VPDU) in the video domain and a bitstream representation of the current video block, the conversion excluding the use of the remainder of the current VPDU.

[0263] 56. The method of claim 55, wherein K1=1 and K2=2.

[0264] 57. A method according to any one of claims 55 to 56, wherein the current video block is selectively processed based on the dimensions of the video area or the dimensions of the current VPDU.

[0265] 58. A method of video processing comprising: performing a validity check on block vectors for conversion between a current video block and a bitstream representation of the current video block, the block vectors being for use in an intra block copy mode; and selectively using the block vectors during the conversion using a result of the validity check.

[0266] 59. The method of clause 58, wherein an intra block copy (IBC) buffer is used during the transformation, the width and height of the IBC buffer are Wbuf and Hbuf, the dimensions of the current video block are W×H, the block vector is expressed as (BVx, BVy), the current video block is in a current picture with dimensions Wpic and Hpic, a coding tree unit has Wctu and Hctu as its width and height, and the validity check uses a predetermined rule.

[0267] 60. A method according to any of clauses 58 to 59, wherein the current image block is a luminance block, a chroma block, a coding unit CU, a transform unit TU, a 4x4 block, a 2x2 block, or a sub-block of a parent block starting at pixel coordinates (X,Y).

[0268] 61. A method according to any one of clauses 58 to 60, wherein the validity check considers the block vectors that are outside the boundaries of the current picture to be valid.

[0269] 62. A method according to any one of clauses 58 to 60, wherein the validity check considers block vectors that are outside the boundaries of a coding tree unit to be valid.

[0270] Paragraphs 23 to 30 of the previous chapter provide additional examples and variations of paragraphs 58 to 62 above.

[0271] 63. A method according to any one of clauses 1 to 62, wherein the transforming comprises generating the bitstream representation from the current video block.

[0272] 64. A method according to any of clauses 1 to 62, wherein the converting comprises generating pixel values ​​for the current video block from the bitstream representation.

[0273] 65. A video encoder apparatus comprising a processing device configured to implement a method according to one or more of claims 1 to 62.

[0274] 66. A video decoder device comprising a processing device configured to implement a method according to one or more of clauses 1 to 62.

[0275] 67. A computer readable medium having code stored thereon, the code embodying instructions executable by a processor for implementing a method according to any one or more of clauses 1-62.

[0276] FIG. 7 is a block diagram illustrating a hardware platform of a video / image processing device 700. The device 700 may be used to implement one or more of the methods described herein. The device 700 may be implemented by a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 700 may include one or more processors 702, one or more memories 704, and video processing hardware 706. The one or more processing devices 702 may be configured to implement one or more methods described herein, including but not limited to the method 600. The memory(s) 704 may be used to store data and code used to implement the methods and techniques described herein. The video processing hardware 706 may be used to implement the techniques described herein in a hardware circuit.

[0277] The bitstream representation corresponding to the current video block does not necessarily have to be a contiguous set of bits, but may be distributed across headers, parameter sets, and network abstraction layer (NAL) packets.

[0278] Section A: Additional Exemplary Embodiments

[0279] In Section A, we present another example embodiment in which the current version of the VVC standard may be modified to implement some of the techniques described herein.

[0280] In this section, we analyze some issues in the current IBC reference buffer design and present a different design to address these issues. Instead of mixing with the decoding memory, an independent IBC reference buffer is proposed. Compared to the current anchors, the proposed scheme shows a luminance BD ratio of AI / RA / LD-B of -0.99% / -0.71% / -0.79% for class F and -2.57% / -1.81% / -1.36% for 4:2:0 TGM, a reduction of 6.7% memory, or an increase of 6.7% memory, of -1.31% / -1.01% / -0.81% for class F and -3.23% / -2.33% / -1.71% for 4:2:0 TGM.

[0281] A1. Introduction Intra block copy, or IBC (or current picture reference, or previous CPR) coding mode is adopted. Note that IBC reference samples should be stored in on-chip memory, and thus a limited reference region of one CTU is defined. To limit extra on-chip memory for buffering, the current design reuses 64x64 memory to decode the current VPDU, so only three additional 64x64 blocks of memory are needed to support IBC. The current reference region when the CTU size is 128x128 is shown in Figure 2.

[0282] In the current draft (VVC Draft 4), area is defined as follows:

[0283] [Table 13]

[0284] Thus, the total reference size is the CTU.

[0285] A2. Potential issues with the current design The current design assumes that 64x64 memory is reused to decode the current VPDU, and the IBC standard is adapted to reuse the VPDU memory accordingly. Such a design bundles the VPDU decode memory with the IBC buffer. The following problems can be considered: 1. Dealing with smaller CTU sizes can be problematic: Given a CTU size of 32x32, it is unclear whether the current 64x64 memory that decodes current VPDUs can efficiently support 32x32 level memory reuse in a different architecture. 2. The reference regions are significantly different. Thus, too many bitstream conformance constraints are introduced. This puts extra burden on the encoder to efficiently utilize the reference regions and avoid generating legal bitstreams. It also increases the possibility of having invalid BVs in different modules, e.g., merge lists. Handling these invalid BVs may introduce extra logic or extra conformance constraints. This not only puts a burden on the encoder or decoder, but may also cause discrepancies between BV and MV encoding. 3. The design does not scale well. Because VPDU decoding is mixed with the IBC buffer, it is not easy to increase or decrease the reference region for the current single 128x128 CTU design. Using 128x128 CTU may limit the flexibility to take advantage of better coding efficiency vs. on-chip memory tradeoffs in later developments, such as lower or higher profiles. 4. The bit depth of the IBC reference buffer is connected to the decoding buffer. Although the bit depth of the screen content is usually smaller than the bit depth of the internal decoding, the buffer still needs to spend memory to store bits that represent mostly rounding and quantization noise. This problem becomes even more severe when considering higher decoding bit depth configurations.

[0286] A3. Clear IBC buffer design To address the issues described in the above subsection, we propose to have a dedicated IBC buffer that is not mixed with the decoding memory.

[0287] For a 128x128 CTU, the buffer is defined as 128x128 containing 8-bit samples, and when a CU(x,y) of size wxh is being decoded, the reconstruction of the buffer before loop filtering is converted to 8-bit and written into a wxh block area starting at position (x%128,y%128). The modulo operator % always returns a positive number, i.e., -3%128=125 if x<0 and x%L is defined as -(-x%L).

[0288] Suppose a pixel (x,y) is coded in IBC mode with BV=(BVx,BVy), the predicted sample in the IBC reference buffer is located at ((x+BVx)%128, (y+BVy)%128) and the pixel value is converted to 10 bits before prediction.

[0289] If the buffer is considered as (W,H), after decoding a CTU or CU starting from (x,y), the reconstructed pixels before loop filtering are stored in the buffer starting from (x%W,y%H). Thus, after decoding a CTU, the corresponding IBC reference buffer is updated accordingly. Such a setting may occur when the size of the CTU is not 128x128. For example, for a 64x64 CTU, the current buffer size can be considered as a 256x64 buffer. The state of the buffer for a 64x64 CTU is shown in Figure 2.

[0290] FIG. 12 is a diagram showing the IBC reference buffer status, where one block represents a 64×64 CTU.

[0291] In such a design, all IBC reference buffers can be used as references since the IBC buffers are distinct from the VPDU decoding memory.

[0292] If the IBC buffer bit depth is 8 bits, the increase in on-chip memory is (8*4) / (10*3)-100%=6.7% compared to the current design, which requires three additional 10-bit 64x64 buffers.

[0293] The memory requirements can be further reduced if the bit depth is further reduced: for example, with a 7-bit buffer, the on-chip memory savings is 100%-(7*4) / (10*3)=6.7%.

[0294] In this design, the only bitstream compatibility constraint is that the reference block should be within the reconstructed region in the current CTU row of the current tile.

[0295] If initialization to 512 is allowed at the start of each CTU row, all bitstream compatibility constraints can be removed.

[0296] A4. Experimental results In some embodiments, the disclosed methods may be implemented using VTM-4.0 software.

[0297] For the 10-bit buffer implementation and CTC, the decoder is fully compatible with the current VTM4.0 encoder, which means that the proposed decoder can correctly decode the VTM-4.0 CTC bitstream.

[0298] A 7-bit buffer implementation gives the results shown in Table 1.

[0299] For an 8-bit buffer implementation, the results are shown in Table 2.

[0300] [Table 14]

[0301] [Table 15]

[0302] FIG. 17 is a block diagram illustrating an example video processing system 1700 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the modules of the system 1700. The system 1700 may include an input unit 2802 for receiving video content. The video content may be received in a raw or uncompressed format, for example, 8 or 10 bit multi-module pixel values, or may be received in a compressed or encoded format. The input unit 1702 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

[0303] The system 1700 may include an encoding module 1704 that may implement various encoding or coding methods described herein. The encoding module 1704 may reduce the average bit rate of the video from the input unit 1702 to the output of the encoding module 1704, generating an encoded representation of the video. Thus, this encoding technique may be referred to as a video compression or video transcoding technique. The output of the encoding module 1704 may be stored or transmitted via a connected communication, as represented by module 1706. The bitstream (or encoded) representation of the video received at the input unit 1702, stored or communicated, may be used by module 1708 to generate pixel values ​​or displayable video that are transmitted to the display interface unit 1710. The process of generating a user-viewable video from the bitstream representation may be referred to as video decompression. Additionally, although certain video processing operations are referred to as "encoding" operations or tools, it will be understood that the encoding tools or operations are performed by an encoder and corresponding decoding tools or operations that reverse the results of the decoding, performed by a decoder.

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

[0305] 18 is a flow chart illustrating an example of a video data processing method. The steps of this flow chart are described in relation to Example 23 in Chapter 4 of this application. In step 1802, the process determines a block vector (BVx,BVy) for a conversion between a current video block of a current picture of the video media data and a bitstream representation of the current video block, the validity of the block vector being independent of (1) the position (P,Q) of the sample block, and / or (2) whether to reconstruct samples at position (P,Q), and / or (3) the position of the current video block, where the block vector (BVx,BVy) represents a pixel displacement between the current video block and the sample block. In step 1804, the process uses the block vector to perform a transformation in intra block copy mode based on a reconstructed block located in the same image area as the current image block, which contains a reference sample used to derive a prediction block of the current image block, and during the transformation, determines a prediction sample having a position (A, B) from the reference sample in the buffer based on at least the size of the buffer and / or the block vector (BVx, BVy).

[0306] FIG. 19 is a flow chart illustrating an example of a video data processing method. The steps of this flow chart are described in relation to Example 23 in Chapter 4 of this application. In step 1902, the process determines whether a block vector (BVx, BVy) corresponding to a current video block is valid according to a rule for conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, the block vector (BVx, BVy) representing a pixel displacement between the current video block and a sample block. In step 1904, the process uses the block vector to perform a conversion based on a reference region from the current picture that includes reference samples used to derive a prediction block of the current video block, the rule being valid if the block vector (BVx, BVy) is: (1) one or more samples from the sample block are outside the current picture; and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block; and / or (3) one or more samples from the sample block fail to be reconstructed.

[0307] 20 is a flow chart illustrating an example of a method for processing video data. The steps of this flow chart are described in relation to Example 44 in Chapter 4 of this application. In step 2002, the process performs a conversion between a current video block of a current picture of the visual media data and a bitstream representation of the visual media data, the conversion being based on a reference region from the current picture that contains reference samples used to derive a prediction block of the current video block, and a virtual buffer of a defined size is used to track the availability of reference samples for deriving the prediction block.

[0308] 21 is a flow chart illustrating an example of a method for processing video data. The steps of this flow chart are described in relation to Example 51 in Chapter 4 of this application. In step 2102, the process includes maintaining a buffer including reference samples from a current picture for deriving a prediction block of a current video block for conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, where one or more reference samples in the buffer are marked as unavailable for the derivation have values ​​outside a range of pixel values.

[0309] 22 is a flow chart illustrating an example of a method for processing video data. The steps of this flow chart are described in relation to Example 54 in Chapter 4 of this application. In step 2202, the process includes converting between a video block of a current picture of the visual media data and a bitstream representation of the visual media data using a buffer containing reference samples from the current picture to derive a prediction block of the current video block, the conversion being based on a rule that specifies that the reference samples in the buffer satisfy a bitstream compatibility constraint in order for the bitstream representation to be compliant with the rule.

[0310] Some embodiments of the present specification are presented in a section-based format.

[0311] L1. A visual media processing method, comprising: determining a block vector (BVx, BVy) for a conversion between a current video block of a current picture of the video media data and a bitstream representation of the current video block, the validity of the block vector being independent of (1) a position (P, Q) of a sample block, and / or (2) whether to reconstruct a sample at position (P, Q), and / or (3) a position of the current video block, the block vector (BVx, BVy) representing a pixel displacement between the current video block and the sample block; Using the block vector, a conversion in an intra block copy mode based on a reconstructed block located in the same image area as the current image block, the reconstructed block including a reference sample used to derive a prediction block of the current image block, is performed, during the conversion, a prediction sample having a position (A, B) from the reference sample in the buffer is determined based on at least a size of the buffer and / or the block vector (BVx, BVy).

[0312] L2. A visual media processing method, comprising: determining whether a block vector (BVx, BVy) corresponding to a current video block is valid according to a rule for a conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, the block vector (BVx, BVy) representing a pixel displacement between the current video block and a sample block; and using the block vector to perform a transformation based on a reference region from the current picture that includes reference samples used to derive a prediction block of the current video block, wherein the rule is effective when the block vector (BVx, BVy) is such that (1) one or more samples from the sample block are outside the current picture, and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and / or (3) one or more samples from the sample block fail to be reconstructed.

[0313] L3. The method according to clause L2, wherein upon identifying that the block vector (BVx, BVy) is valid, a predicted sample having a position (A, B) is determined from a reference sample in the buffer depending at least on the size of the buffer and / or the size of the block vector (BVx, BVy).

[0314] L4. The method according to any one or more of items L1 or L3, wherein the reference samples in the buffer correspond to reconstructed samples of an area of ​​the current picture.

[0315] L5. The method of claim L4, wherein the region includes a coding tree unit (CTU) row associated with a current video block.

[0316] L6. A method according to any one or more of items L1 to L5, wherein the block vector (BVx, BVy) is determined to be valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside the boundary of a picture.

[0317] L7. The method according to item L6, wherein the block vector (BVx, BVy) is valid regardless of whether x+BVx<0 or x+BVx>0.

[0318] L8. Block vector (BVx, BVy) is x+W+BVx>W pic or x+W+BVx <W pic where W represents the width of the current image block and W pic represents the width of the picture.

[0319] L9. The method according to item L6, wherein the block vector (BVx, BVy) is valid regardless of whether y+BVy<0 or y+BVy>0.

[0320] L10. Block vector (BVx, BVy) is x+H+BVx>H pic or x+H+BVx <H pic where H represents the height of the current image block, and H pic represents the height of the picture.

[0321] L11. A method according to any one or more of items L1 to L5, wherein the block vector (BVx, BVy) is valid regardless of whether a position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside a coding tree unit that includes the current video block.

[0322] L12.y+BVy <floor(y / H ctu )*H ctu Is y+BVy>floor(y / H ctu )*H ctu Regardless of whether or not the block vector (BVx, BVy) is valid, H ctu The method according to item L11, wherein floor(a) represents the height of a coding tree unit, and floor(a) is the largest integer less than or equal to a.

[0323] L13.y+H+BVy <floor(y / H ctu )*H ctu Is y+H+BVy>floor(y / H ctu )*H ctu Regardless of whether the block vector (BVx, BVy) is valid, H represents the height of the current image block, and H ctu The method according to item L11, wherein floor(a) represents the height of a coding tree unit, and floor(a) is the largest integer less than or equal to a.

[0324] L14. A method according to any one or more of items L1 to L5, wherein the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated according to the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside a coding tree unit including the current video block and (n-1) coding tree units along the left direction.

[0325] L15.x+BVx <floor(x / W ctu )*W ctu -(n-1)*W ctu or x+BVx>floor(X / Wctu )*W ctu -(n-1)*W ctu Regardless of whether the block vector (BVx, BVy) is valid, W ctu The method according to item L14, wherein floor(a) indicates the weight of the coding tree unit, and floor(a) is the largest integer less than or equal to a.

[0326] L16.x+W+BVx>floor(X / W ctu )*W ctu +W ctu or x+W+BVx <floor(X / W ctu )*W ctu +W ctu The block vector (BVx, BVy) is valid regardless of whether the block vector is a vector of the coding tree unit or not, and W indicates the weight of the coding tree unit, and W ctu The method according to item L14, wherein floor(a) indicates the weight of the current image block, and floor(a) is the largest integer less than or equal to a.

[0327] L17. A method according to any one or more of items L1 to L5, wherein the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside the CTU row below that contains the current coding tree unit that contains the current video block.

[0328] L18. The block vector (BVx, BVy) is Y+BVy <floor(Y / H ctu )*H ctu or Y+H+BVy>=floor(Y / H ctu )*H ctu +H ctu It is valid regardless of W ctu and H ctu The method according to item L17, wherein floor(a) is the largest integer less than or equal to a and floor(a) is the width and height of the CTU, respectively.

[0329] L19. The method according to any one or more of items L1 to L5, wherein the block vector (BVx, BVy) is determined to be valid regardless of whether the reconstruction of the sample has failed.

[0330] L20. The method according to item L19, wherein the block vector (BVx, BVy) is valid regardless of whether isRec(x+BVx, y+BVy) is false, and isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode.

[0331] L21. The method described in item L19, wherein a block vector (BVx, BVy) is valid regardless of whether isRec(x+BVx+W-1, y+BVy) is false, and if pixel (x, y) is reconstructed by intra block copy mode, isRec(x, y) is true, and W is the width of the current image block.

[0332] L22. The method described in item L19, wherein a block vector (BVx, BVy) is valid regardless of whether isRec(x+BVx, y+BVy+H-1) is false, and if pixel (x, y) is reconstructed by intra block copy mode, isRec(x, y) is true, and H is the height of the current image block.

[0333] L23. The method described in item L19, wherein a block vector (BVx, BVy) is valid regardless of whether isRec(x+BVx+W-1, y+BVy+H-1) is false, and if pixel (x, y) is reconstructed by intra block copy mode, isRec(x, y) is true, W indicates the width of the current image block, and H is the height of the current image block.

[0334] L24. A method according to any one or more of items L1 to L5, wherein the block vector (BVx, BVy) is determined to be valid regardless of whether the current video block is included in the first coding tree unit of the coding tree unit row.

[0335] L25.(i)x+BVx>=0,(ii)y+BVy>=floor(y / H ctu ), (iii) a block vector (BVx, BVy) is determined to be valid when all of the following conditions are satisfied: (i) isRec(x+BVx+W-1, y+BVy+H-1) is true, where isRec(x, y) is true if sample (x, y) is reconstructed in intra block copy mode, W indicates the width of the current video block, H indicates the height of the current video block, and floor(a) is the largest integer less than or equal to a.

[0336] L26. The method of item L25, wherein the block vector is located in a first CTU in a CTU row.

[0337] L27. The method described in item L3, determining a predicted sample at position (A,B) based on the size of the buffer, the block vector (BVx,BVy), and the top-left position (x,y).

[0338] L28. The predicted sample with the position (A,B) is ((X+BVx)%W buf ,(Y+BVy)%H buf ), and W buf and H buf The method according to item L27, wherein respectively represent the buffer width and the buffer height.

[0339] L29. The method according to any one or more of items L1 to L28, wherein the conversion is performed in an intra block copy mode.

[0340] M1. A visual media processing method, comprising: performing a conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data; the transform is based on a reference region from a current picture that comprises reference samples used to derive a prediction block of a current video block; A method for visual media processing, wherein a virtual buffer of a defined size is used to track availability of the reference samples for deriving the prediction block.

[0341] M2. The virtual buffer is maintained using virtual pipeline data units (VPDUs), and the size of the virtual buffer is m*W VPDU ×n*H VPDU And W VPDU and H VPDU indicates the width and height of the VPDU.

[0342] M3. The method according to item M2, wherein m=4 and n=2.

[0343] The method of claim M2, wherein M4. m and / or n are based at least in part on a resolution of a picture associated with the current video block or a size of a coding tree unit that includes the current video block.

[0344] The method according to item M2, wherein M5.m and / or are predefined quantities.

[0345] The method of item M2, wherein M6.m and / or are signaled as fields in the bitstream representation.

[0346] M7. The samples in the current video block are within (x%(m*W VPDU ),y%(n*H VPDU )), where the sample in the current video block is located at (x,y) relative to the top-left corner of the picture, and “x%y” is defined as y=xy*floor(x / y), where floor(a) is the largest integer less than or equal to a, and W VPDU and H VPDU The method described in item M1, wherein: indicates the width and height of the VPDU.

[0347] M8. The method according to item M1, The method further comprising using an array for tracking availability of samples stored in the virtual buffer.

[0348] M9. The method of item M8, wherein the array includes a flag to indicate whether one or more samples stored in the buffer are used for prediction in an intra block copy mode.

[0349] M10. The method of item M8, wherein the array corresponds to one or more VPDUs of size 3×2.

[0350] M11. The method of item M8, wherein the array corresponds to one or more VPDUs of size 4×2.

[0351] M12. The method of claim M1, further comprising flagging a subset of the samples stored in the virtual buffer as unavailable for prediction.

[0352] M13. The method of claim M12, wherein the subset of samples flagged as unavailable for prediction is based on the position of a recently processed VPDU.

[0353] M14. The method of item M13, wherein the sample is flagged as unavailable at the start of processing a VPDU.

[0354] M15.yPrevVPDU%(n*H VPDU ) is 0, then the subset of samples located at position (x, y) is flagged as unavailable, where x is within a first predetermined range and y is within a second predetermined range, (xPrevVPDU, yPrevVPDU) represents the top left corner of the coding tree unit of the most recently processed VPDU, and W VPDU and H VPDU The method according to item M14, wherein represents the width and height of the VPDU.

[0355] M16. The first range is [xPrevVPDU-2W VPDU +2mW VPDU )%mWVPDU ,((xPrevVPDU-2*W VPDU +2*m*W VPDU )%(m*W VPDU ))-1+W VPDU ] and the second range is [yPrevVPDU%(n*H VPDU ),(yPrevVPDU%(n*H VPDU ))-1+H VPDU The method described in item M15, represented as follows:

[0356] M17. The first range is [xPrevVPDU-2*W VPDU +2*m*W VPDU )%mW VPDU ,((xPrevVPDU-2*W VPDU +2*m*W VPDU )%(m*W VPDU ))-1+W VPDU ] and the second range is [yPrevVPDU%(n*H VPDU ),(yPrevVPDU%(n*H VPDU ))-1+H VPDU The method described in item M15, represented as follows:

[0357] M18.yPrevVPDU%(n*H VPDU If WPrevVPDU is not equal to 0, then the subset of samples located at position (x,y) is flagged as unavailable, where x is within a first predetermined range and y is within a second predetermined range, (xPrevVPDU, yPrevVPDU) represents the top left corner of the coding tree unit of the most recently processed VPDU, and W VPDU and H VPDU The method according to item M14, wherein represents the width and height of the VPDU.

[0358] M19. The first range is [xPrevVPDU-W VPDU +2*m*W VPDU )%(m*W VPDU ),((xPrevVPDU-W VPDU +2*m*W VPDU )%(m*W VPDU ))-1+W VPDU] and the second range is [yPrevVPDU%(n*H VPDU ),(yPrevVPDU%(n*H VPDU ))-1+H VPDU The method described in item M18, represented as follows:

[0359] M20. The first range is [xPrevVPDU-W VPDU +2*m*W VPDU )%mW VPDU ,((xPrevVPDU-W VPDU +2*m*W VPDU )%(m*W VPDU ))-1+W VPDU ] and the second range is [yPrevVPDU%(n*H VPDU ),(yPrevVPDU%(n*H VPDU ))-1+H VPDU The method described in item M18, represented as follows:

[0360] M21. The method of claim M12, wherein if the coding tree includes a VPDU, the subset of samples flagged as unavailable for prediction is based on the position of a recently processed coding tree unit.

[0361] M22. The method of claim M21, wherein the sample is flagged as unavailable at the start of processing of a coding tree unit.

[0362] M23. The method according to any one of items M1 to M22, A method comprising: determining the validity of a block vector corresponding to a current video block based on a top-left position of the current video block, a bottom-left position of the current video block, and a bottom-right position of the current video block, said determining further comprising excluding use of the top-right position of the current video block.

[0363] M24. The method according to any one or more of items M1 to M23, wherein the conversion is performed in intra block copy mode.

[0364] N1. A visual media processing method, comprising: for converting between a video block of a current picture of visual media data and a bitstream representation of the visual media data, maintaining a buffer including reference samples from the current picture for deriving a prediction block of the current video block; A method, wherein one or more reference samples in the buffer marked as unavailable for the derivation have values ​​outside a range of pixel values.

[0365] N2. The method of claim N1, wherein the pixel value range is expressed as [0, 1<<(bit_depth)-1], where bit_depth is a positive integer.

[0366] The method according to item N2, wherein N3.bit_depth is the precision used to process the samples.

[0367] N4. The method comprises: The method of claim N1, further comprising initializing a sample set in a buffer to a predetermined value indicating that the sample set is unavailable.

[0368] N5. The method of claim N4, wherein the predetermined value is −1.

[0369] N6. The method of any one or more of items N4-N5, wherein the position of the set of samples and / or whether to initialize the set of samples to a predetermined value is based on the position of a current video block, the size of the current video block, the size of a VPDU that contains the current video block, and / or the size of a coding tree unit that contains the current video block.

[0370] N7. The method according to item N6, wherein if (xCb%vSize) is equal to 0 and (yCb%vSize) is 0, then the set of samples is marked as unavailable, where xCb, yCb represent the position of the current video block relative to the samples, and vSize=min(ctbSize,64), where ctbSize indicates the width or height of the coding tree unit.

[0371] N8. The method of claim N1, wherein a set of samples in the buffer is marked as unavailable if the size of the current video block is less than min(ctbSize, 64), where ctbSize represents a width or height of the coding tree unit.

[0372] N9. The method of claim N8, wherein the positions of the samples are related to the size of the VPDU.

[0373] N10. The method of claim N8, wherein the position of the set of samples is related to the size of the coding tree unit that contains the current video block.

[0374] N11. The method of item N4, wherein the set of samples in the buffer is represented by position (x%wIbcBuf,y%hIbcBuf), where x=xV,···,xV+ctbSize-1 and y=yV,···,yV+ctbSize-1, where xV,yV represent the top-left position of the VPDU relative to the top-left position of the picture, ctbSize represents the size of the coding tree unit containing the current video block, and wIbcBuf and hIbcBuf represent the buffer width and buffer height.

[0375] N12. The method of item N11, wherein the set of samples in the buffer is initialized to -1.

[0376] N13. The method of claim N4, wherein the set of samples is initialized at the start of decoding of a video unit.

[0377] N14. The method according to any one or more of items N1 to N13, wherein the conversion is performed in an intra-block copy mode.

[0378] O1. A visual media processing method, comprising: performing a conversion between a video block of a current picture of visual media data and a bitstream representation of the visual media data by using a buffer including reference samples from the current picture to derive a predicted block of the current video block; wherein the conversion is based on a rule that specifies that the reference samples in the buffer satisfy bitstream compliance constraints so that the bitstream representation complies with the rule.

[0379] O2. The method according to item O1, wherein the bitstream compliance constraints are based on at least one of (1) the values of the reference samples in the buffer and / or (2) the availability information of the samples in the buffer.

[0380] O3. The method according to any one or more of items O1 to O2, wherein the bitstream compliance constraints specify that the bitstream representation is non-compliant when the samples in the buffer have values outside a single pixel range.

[0381] O4. The method according to item O3, wherein the range is [K0, K1], K0 is set to 0, and K1 is set to (1 << BitDepth - 1), where BitDepth represents the accuracy of the predicted samples.

[0382] O5. The method according to any one or more of items O1 to O2, wherein the bitstream compliance constraints specify that the bitstream representation is non-compliant when the availability information of the samples in the buffer indicates that the samples are not available for the current video block.

[0383] O6. If the sample is a luminance sample and the availability information of the sample in the buffer indicates that this sample is not available for the current video block and a single tree split is used for the current video block, the bitstream compliance constraint stipulates that the bitstream representation is non-compliant, according to the method described in any one or more of items O1 to O2.

[0384] O7. The method according to any one of items O1 to O6, further comprising marking the availability information of the sample according to the value of the sample in the buffer.

[0385] O8. The method according to item O7, wherein when the value of the sample is within the interval represented as [K0, K1], the availability information of the sample is marked as available.

[0386] O9. The method according to item O8, wherein K0 is set to 0 and K1 is set to (1 << BitDepth - 1), and BitDepth represents the accuracy of the predicted sample.

[0387] O10. The bitstream compliance constraint is further based on the split type and tree type of the coding unit associated with the current video block, according to the method described in any one or more of items O1 to O8.

[0388] O11. When the partitioning type is dual tree and the tree type is single tree, the bitstream compliance constraint stipulates checking whether all color components of the sample are marked as unavailable, according to the method described in item O10.

[0389] O12. When the partitioning type is dual tree and the tree type is dual tree, the bitstream compliance constraint does not stipulate checking whether the chroma component of the sample is marked as unavailable, according to the method described in item O10.

[0390] O13. The method according to any one or more of items O1 to O12, wherein the conversion is performed in an intra block copy mode.

[0391] XX. The method of any of items L1 to XX, wherein the transforming includes generating the bitstream representation from the current video block.

[0392] XX. The method of any one of items L1 to XX, wherein the transforming includes generating pixel values ​​of the current video block from the bitstream representation.

[0393] XX. A video encoder apparatus comprising a processing device configured to implement the method according to one or more of items L1 to XX.

[0394] XX. A video decoder device comprising a processing device configured to implement the methods described in one or more of items L1 to XX.

[0395] XX. A computer readable medium having code stored thereon, the code embodying instructions executable by a processor to implement the methods according to any one or more of items L1 to XX.

[0396] As used herein, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion of a pixel representation of a video to a corresponding bitstream representation, or vice versa. A bitstream representation of a current video block may be, for example, as specified by the syntax: These may correspond to bits that are spread to the same or different locations in the bitstream. For example, one macroblock may be divided into several parts in terms of transformed and coded error residual values: And it may be encoded using bits in the header and other fields in the bitstream.

[0397] While specific embodiments of the disclosed technology have been described above for purposes of illustration, it will be understood that various modifications may be made without departing from the scope of the invention. Accordingly, the disclosed technology is not to be limited except as by the appended claims.

[0398] Implementations of the subject matter and functional operations described in this patent specification may be implemented in various systems, digital electronic circuits, or computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in one or more combinations thereof. Implementations of the subject matter described herein may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible, non-transportable computer-readable medium for execution by or for controlling the operation of a data processing device. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter that provides a machine-readable propagated signal, or one or more combinations thereof. The term "data processing unit" or "data processing device" includes all apparatus, devices, and machines for processing data, including, for example, a programmable processing device, a computer, or multiple processing devices or computers. In addition to hardware, the apparatus may include code that creates an environment for the execution of the computer program, such as code that constitutes a processing device firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof.

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

[0400] The processes and logic flows described herein may be performed by one or more programmable processing devices executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by special purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the devices may also include It may be implemented as special purpose logic circuitry.

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

[0402] This specification, together with the drawings, are for illustrative purposes only, and illustrative is intended to mean example. In this specification, the use of "or" is intended to include "and / or" unless the context clearly indicates otherwise.

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

[0404] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring that such operations be performed in the particular order or sequential order shown, or that all of the operations shown be performed, to achieve desired results. It should not be understood that all embodiments require such separation.

[0405] Only some implementations and examples have been described; other embodiments, extensions and variations are possible based on what is described and illustrated in this patent document.

Claims

1. determining that an intra block copy mode is applied to a current video block of a current picture of a video for conversion between the current video block and a bitstream of the video; maintaining, for the intra block copy mode, a buffer containing reference samples obtained from blocks of sample values ​​of the same image region of the current image block in the current picture; maintaining a history-based motion predictor list for the intra block copy mode, the history-based motion predictor list including candidate block vectors; generating a prediction sample for the current video block based on said determining; and performing the conversion between the current video block and the bitstream; resetting all samples in the buffer to a predetermined value that is outside the pixel range if a predetermined condition is met; resetting a variable indicative of a number of candidate block vectors in the history-based motion predictor list to 0 if the predetermined condition is satisfied, In the intra block copy mode, the reference samples determined by the block vectors in the buffer are used to derive predicted samples of the current video block. A method for processing video data.

2. The predetermined value is −1. The method of claim 1.

3. The predetermined condition is satisfied at a start of a coding tree unit (CTU) row, and the buffer is reset at the start of the CTU row; the variable indicating the number of block vector candidates in the history-based motion predictor list is reset to 0 at the beginning of the CTU row. The method according to claim 1 or 2.

4. the transformation is based on a rule specifying that for the bitstream to be conformant, reference samples in the buffer should satisfy a bitstream conformance constraint. The method according to any one of claims 1 to 3.

5. the bitstream conformance constraint specifies that the bitstream is non-conformant if a luma reference sample determined by the block vector in the buffer contains a value equal to the predetermined value. The method according to claim 4.

6. the bitstream conformance constraint specifies that the bitstream is non-conformant if a luma reference sample determined by the block vector in the buffer includes a value indicating unavailability of the luma reference sample. The method according to claim 4.

7. the bitstream conformance constraint specifies that the bitstream is non-conformant if luma reference samples determined by the block vectors in the buffer contain values ​​outside a pixel range. The method according to claim 4.

8. The bitstream conformance constraint specifies that the bitstream is conforming if luma reference samples determined by the block vectors in the buffer contain values ​​in [K0, K1], where K0 is 0, K1 is (1<<BitDepth-1), and BitDepth represents the precision of the reference samples. The method according to claim 4.

9. the transforming includes encoding the current video block into the bitstream. The method according to any one of claims 1 to 8.

10. the converting includes decoding the current video block from the bitstream. The method according to any one of claims 1 to 8.

11. 1. An apparatus for processing video data comprising a processor and a non-transitory memory comprising instructions, the instructions, when executed by the processor, causing the processor to: determining that an intra block copy mode is applied to a current video block of a current picture of a video for conversion between the current video block and a bitstream of the video; maintaining, for the intra block copy mode, a buffer containing reference samples obtained from blocks of sample values ​​of the same image region of the current image block in the current picture; maintaining a history-based motion predictor list for the intra block copy mode, the history-based motion predictor list including candidate block vectors; generating a prediction sample for the current video block based on said determining; and performing the conversion between the current video block and the bitstream; resetting all samples in the buffer to a predetermined value that is outside the pixel range if a predetermined condition is met; resetting a variable indicating a number of candidate block vectors in the history-based motion predictor list to 0 if the predetermined condition is satisfied; In the intra block copy mode, the reference samples determined by the block vectors in the buffer are used to derive predicted samples of the current video block. A device for processing video data.

12. 1. A non-transitory computer-readable medium storing instructions, the instructions configuring a processor to: determining that an intra block copy mode is applied to a current video block of a current picture of a video for conversion between the current video block and a bitstream of the video; maintaining, for the intra block copy mode, a buffer containing reference samples obtained from blocks of sample values ​​of the same image region of the current image block in the current picture; maintaining a history-based motion predictor list for the intra block copy mode, the history-based motion predictor list including candidate block vectors; generating a prediction sample for the current video block based on said determining; and performing the conversion between the current video block and the bitstream; resetting all samples in the buffer to a predetermined value that is outside the pixel range if a predetermined condition is met; resetting a variable indicating a number of candidate block vectors in the history-based motion predictor list to 0 if the predetermined condition is satisfied; In the intra block copy mode, the reference samples determined by the block vectors in the buffer are used to derive predicted samples of the current video block. A non-transitory computer-readable recording medium.

13. 1. A method of storing a video bitstream, the method comprising: determining that an intra block copy mode is applied to a current video block; maintaining, for the intra block copy mode, a buffer containing reference samples obtained from blocks of sample values ​​of the same image region of the current image block in the current picture; maintaining a history-based motion predictor list for the intra block copy mode, the history-based motion predictor list including candidate block vectors; generating a prediction sample for the current video block based on said determining; and generating the bitstream based on the predicted samples; storing the bitstream on a non-transitory computer readable recording medium; resetting all samples in the buffer to a predetermined value that is outside the pixel range if a predetermined condition is met; resetting a variable indicating a number of candidate block vectors in the history-based motion predictor list to 0 if the predetermined condition is satisfied; In the intra block copy mode, the reference samples determined by the block vectors in the buffer are used to derive predicted samples of the current video block. method.

Images