JP7384910B2 - Buffer management for intra block copy in video encoding - Google Patents

Description

Cross-reference of related applications
This application is based on International Patent Application No. PCT/CN2020/074155 filed on February 2, 2020, which timely claims priority and benefit of International Patent Application No. PCT/CN2019/074598 filed on February 2, 2019. Based on . For all purposes under law, the entire disclosure of the above application is incorporated by reference as part of the disclosure herein.

This patent specification relates to video encoding and decoding techniques, devices and systems.

Despite advances in video compression, digital video still accounts for the largest amount of bandwidth usage on the Internet and other digital communication networks. Bandwidth demands for digital video usage are expected to continue to increase as the number of connected user equipment capable of receiving and displaying video increases.

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

In one exemplary aspect, a method of video and/or image processing is disclosed. This method includes determining a buffer size for storing reference samples for prediction in intra-block copy mode, and using the reference samples stored in the buffer to converting to and from a bitstream representation of a video block, where the conversion is based on motion information about a reconstructed block located in the same video region as the current video block, without reference to a reference picture. This is done in block copy mode.

In another exemplary aspect, another method of video data processing is disclosed. The method includes determining a buffer storing reconstructed samples for prediction in intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. and, the buffer is used to store reconstructed samples before the loop filtering step, and the reconstructed samples stored in the buffer are used to perform this transformation, the transformation including It is performed in an intra-block copy mode based on motion information about reconstructed blocks located in the same video area as the current video block, without referring to pictures.

Additionally, in another exemplary aspect, another method of video data processing is disclosed. The method includes determining a buffer storing reconstructed samples for prediction in intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. and the buffer is used to store reconstructed samples after a loop filtering step, and the reconstructed samples stored in the buffer are used to perform the transformation, the transformation comprising a reference picture This is done in an intra-block copy mode based on motion information about reconstructed blocks located in the same video area as the current video block, without reference to the current video block.

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reconstructed samples for prediction in intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. and this buffer is used to store reconstructed samples before the loop filtering step and after the loop filtering step, and the reconstructed samples stored in the buffer are used to perform this transformation. This transformation is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture.

In another exemplary aspect, another method of video processing is disclosed. The method uses a buffer to store reference samples for prediction in intra block copy mode, and a first bit depth of the buffer is used to represent visual media data in a bitstream representation. converting between a current video block of visual media data and a bitstream representation of the current video block using reference samples stored in a buffer, different from the second bit depth; This conversion is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture.

In yet another exemplary aspect, another method of video processing is disclosed. The method includes, in intra block copy mode, initializing a buffer to store reference samples for prediction; and initializing the buffer with a first value and using the reference samples stored in the buffer. , performing a transformation between a current video block of visual media data and a bitstream representation of the current video block, the transformation being performed in the same video region as the current video block without reference to a reference picture. This is done in an intra-block copy mode based on motion information about reconstructed blocks located at .

In yet another exemplary aspect, another method of video processing is disclosed. The method initializes a buffer to store reference samples for prediction in an intra-block copy mode and stores one or more of the visual media data based on the availability of one or more video blocks. A bitstream representation of a current video block and a current video block that does not belong to one or more video blocks of visual media data using reference samples initialized with the video block's pixel values and stored in a buffer. The transformation is performed in an intra-block copy mode based on motion information about a reconstructed block located in the same video region as the current video block, without referring to a reference picture.

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. , the reference samples stored in the buffer are used to perform this transformation, and the transformation is based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture. This is performed in the intra block copy mode, and the reference position (P mod M, Q mod N ), (where mod is a modulo operation and M and N are integers representing the x and y dimensions of the buffer); ) is determined using the block vector (BVx, BVy) and position (x0, y0).

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. , the reference samples stored in the buffer are used to perform this transformation, and the transformation is based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture. This is performed in the intra block copy mode, and the pixel spatially located at the position (x0, y0) and having the block vector (BVx, BVy) included in the motion information is copied based on the reference position (P, Q). and calculating a corresponding reference in the buffer, where the reference position (P, Q) is determined using the block vector (BVx, BVy) and the position (x0, y0).

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reconstructed samples for prediction in intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. , the pixel location in the buffer is addressed using the x and y numbers, and performing this transformation based on the x and y numbers, and this transformation using the reference samples stored in the buffer. , and this transformation is performed in an intra-block copy mode based on motion information about a reconstructed block located in the same video region as the current video block, without referring to a reference picture.

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. , this transformation is done in intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture, and spatially, the current video block's position For a pixel located at (x0, y0) and having block vector (BVx, BVy), calculating the corresponding reference in the buffer based on the reference position (P, Q); ) is determined using the block vector (BVx, BVy) and the position (x0, y0), and when it is determined that there is a reference position (P, Q) outside the buffer, it is determined using the samples inside the buffer. recalculating the reference position.

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. , this transformation is done in intra-block copy mode based on motion information about the reconstructed blocks located in the same video region as the current video block, without referring to reference pictures, and spatially contains the current video block. For a pixel located at position (x0, y0) of the current video block with respect to the upper left position of the encoding tree unit and having block vector (BVx, BVy), the correspondence in the buffer is determined based on the reference position (P, Q). The reference position (P,Q) is determined using the block vector (BVx, BVy) and the position (x0,y0), and the reference position (P,Q) is outside the buffer If it is determined that there is a reference position, at least a part of the reference position is suppressed to be located within a predefined range.

In yet another exemplary aspect, another method of video processing is disclosed. The method includes determining a buffer storing reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. , this transformation is done in intra-block copy mode based on motion information about the reconstructed blocks located in the same video region as the current video block, without referring to reference pictures, and spatially contains the current video block. For a pixel located at position (x0, y0) of the current video block with respect to the upper left position of the encoding tree unit and having block vector (BVx, BVy), the correspondence in the buffer is determined based on the reference position (P, Q). The reference position (P, Q) is determined using the block vector (BVx, BVy) and the position (x0, y0), and the block vector (BVx, BVy) is and padding the block vector (BVx, BVy) with the block vector of sample values in the buffer.

In yet another exemplary aspect, another method of video processing is disclosed. This method consists of resetting a buffer that stores reference samples for prediction in intra-block copy mode at video boundaries during the conversion between a video and a bitstream representation of that video, and performing this transformation using reference samples, and the transformation of the video block of the video is based on motion information about the reconstructed block located in the same video region as the video block, without reference to the reference picture. This is done in intra block copy mode.

In yet another exemplary aspect, another method of video processing is disclosed. This method performs the conversion between the current video block and the bitstream representation of the current video block and updates the buffer used to store reference samples for prediction in intra block copy mode. and the buffer is used for converting between the subsequent video block and the bitstream representation of the subsequent video block, and the buffer is used for converting between the subsequent video block and the bitstream representation of the subsequent video block. The conversion between is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the subsequent video block, without reference to reference pictures.

In yet another exemplary aspect, another method of video processing is disclosed. The method determines a buffer to use to store reconstructed samples for prediction in intra-block copy mode for conversion between a current video block and a bitstream representation of the current video block. , this transformation is done in intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to any reference pictures, and the reconstructed image stored in the buffer performing a preprocessing operation on the reconstructed samples stored in the buffer upon determining that the samples are to be used to predict sample values during the transformation.

In yet another exemplary aspect, another method of video processing is disclosed. The method selectively converts even-numbered rows of a video region for conversion between a current video block of a current virtual pipeline data unit (VPDU) of the video region and a bitstream representation of the current video block. determining whether to use the K1 preprocessed VPDUs of the current row and/or the K2 preprocessed VPDUs of the odd row; This transformation is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture.

In yet another exemplary aspect, a video encoder or decoder device is disclosed that includes a processing device configured to implement the method described above.

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

These and other aspects are described in more detail herein.

2 illustrates current picture reference or intra block copy video or image coding techniques. Illustrating a dynamic reference region. The encoding of a block starting from (x, y) is illustrated. 3 illustrates a possible alternative method for selecting a previously encoded 64x64 block. 3 illustrates possible alternative methods for changing the encoding/decoding order of 64×64 blocks. 3 is a flowchart illustrating an example of a video or image processing method. 1 is a block diagram illustrating a hardware platform that encodes or decodes video or images; FIG. If the order of decoding of 64x64 blocks is from top to bottom and left to right, we show another possible alternative for selecting the last encoded 64x64 block. 2 shows another possible alternative method for selecting a previously encoded 64x64 block. 2 shows an exemplary flowchart of a decoding process with reshaping. If the order of decoding of 64x64 blocks is from left to right, top to bottom, we show another possible alternative method for selecting the last encoded 64x64 block. FIG. 6 is a diagram showing IBC reference buffer status, where one block shows 64×64 CTUs. Figure 1 shows one arrangement of reference areas for IBC. Figure 3 shows another arrangement of reference areas for IBC. FIG. 7 shows another placement of the reference area for IBC when the current virtual pipeline data unit (VPDU) is on the right side of the picture boundary. An example of the state of a virtual buffer when sequentially decoding VPDUs within one CTU row is shown. FIG. 1 is a block diagram illustrating an example video processing system in which the disclosed techniques may be implemented. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method. 3 is a flowchart illustrating an example of a video data processing method.

Chapter headings are used herein to facilitate understanding, and the embodiments disclosed in one chapter are not limited to that chapter. This specification describes various embodiments and techniques for buffer management and block vector encoding in intra block copy mode for decoding or encoding video or images.

1. overview

The present specification relates to video encoding technology. Specifically, it relates to intra block copy in video encoding. This may apply, for example, to standards under development, such as general purpose video coding. The present invention is also applicable to future video encoding standards or video codecs.

2. easy explanation

Video coding standards have evolved primarily through the development of the well-known ITU-T and ISO/IEC standards. ITU-T is H. 261 and H. ISO/IEC created MPEG-1 and MPEG-4 Visual, and both organizations created H.263. 262/MPEG-2 Video and H.262/MPEG-2 Video. 264/MPEG-4 AVC (Advanced Video Coding) and H.264/MPEG-4 AVC (Advanced Video Coding). They jointly created the H.265/HEVC standard. H. Since H.262, video coding standards are based on a hybrid video coding structure in which temporal prediction and transform coding are utilized. In 2015, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) to explore future video encoding technologies beyond HEVC. Since then, many new methods have been adopted by JVET and incorporated into a 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), resulting in a 50% bit rate reduction compared to HEVC. We are working on the formulation of VVC standards with the goal of

2.1 HEVC/H. Inter prediction in 265

Each inter-predicted PU has motion parameters for one or two reference picture lists. 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. Motion vectors may be explicitly coded as deltas to predictors.

When one CU is encoded in skip mode, one PU is associated with this CU and there are no significant residual coefficients, no encoded motion vector differences, and no reference picture index. Specify a merge mode, whereby motion parameters for the current PU are obtained from neighboring PUs including spatial and temporal candidates. Merge mode can be applied to any inter-predicted PU, not only for skip mode. An alternative to merge mode is the explicit transmission of motion parameters, including the motion vector (more precisely, the motion vector difference (MVD) compared to the motion vector predictor), the corresponding reference picture index of each reference picture list, and reference picture list usage are explicitly signaled to each PU. Such a mode is referred to in this disclosure as Advanced Motion Vector Prediction (AMVP).

If the signaling indicates to use one of the two reference picture lists, generate a PU from one block of samples. This is called "single prediction." Single prediction is available for both P and B slices.

If the signaling indicates to use both reference picture lists, generate a PU from two blocks of samples. This is called "bidirectional prediction." Bidirectional prediction is available for B slices only.

The inter prediction mode defined in HEVC will be described in detail below. First, merge mode will be explained.

2.2 Reference to current picture

Current Picture Reference (CPR), sometimes referred to as Intra Block Copy (IBC), is employed in the HEVC Screen Content Coding Extensions (HEVC-SCC) and current VVC test models. IBC extends the concept of motion compensation from interframe coding to intraframe coding. As shown in Figure 1, the current block is predicted by one reference block within the same picture when CPR is applied. Before encoding or decoding the current block, the samples in the reference block must already be reconstructed. Although CPR is not very efficient for most camera-captured sequences, it shows significant coding gain for screen content. The reason for this is that there are many repeated patterns of icons, characters, etc. in screen content pictures. CPR can effectively remove redundancy between these repeating patterns. In HEVC-SCC, an inter-coding unit (CU) may apply CPR when selecting a current picture as its reference picture. In this case, MV is renamed block vector (BV), and BV always has integer pixel precision. To conform to the main profile HEVC, the current picture is marked as a "long term" reference picture in the decoded picture buffer (DPB). Note that similarly, in the multiple-view/3D video coding standard, inter-view reference pictures are also marked as "long-term" reference pictures.

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 pixel from the original signal. Transformation and quantization can then be applied, similar to other encoding modes.

FIG. 1 is an illustration of a current picture reference.

However, if the reference block is outside the picture, or overlaps with the current block, or is outside the reconstructed region, or outside the valid region limited by some constraints, the pixel values Some or all of the above shall not be stipulated. Basically, there are two solutions to deal with such problems. One is to disallow such situations, e.g. bitstream conformance. Another is to apply padding to these undefined pixel values. The following subsessions will explain the solution in detail.

2.3 CPR in HEVC Screen Content Coding Extensions

In the Screen Content Coding extension of HEVC, if one block uses the current picture as a reference, the entire reference block must be within the available reconstructed area, as shown in the specification text below. should be guaranteed.

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 conformance requirement that if the reference picture is the current picture, the luminance motion vector mvLX should obey the following constraints.

- The derivation for the availability of z-traversal order blocks as specified in Section 6.4.1, with (xCurr, yCurr) set equal to (xCb, yCb) and (xPb + (mvLX[0] >> 2) When the nearby luminance position (xNbY, yNbY) set equal to -offsetX, yPb+(mvLX[1]>>2)-offsetY) is called as an input, the output becomes TRUE.

- The derivation process for the availability of z-traversal order blocks as specified in Section 6.4.1, with (xCurr, yCurr) set equal to (xCb, yCb) and (xPb + (mvLX[0] >> 2) When the nearby luminance position (xNbY, yNbY) set equal to +nPbW-1+offsetX, yPb+(mvLX[1]>>2)+nPbI-I-1+offsetY) is called as input, the output becomes TRUE. .

- One or both of the following conditions are true:

- The value of (mvLX[0]>>2)+nPbW+xB1+offsetX is 0 or less.
- The value of (mvLX[1]>>2)+nPbH+yB1+offsetY is 0 or less.

- 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).

In this way, the case where the reference block overlaps the current block or the case where the reference block is outside the picture does not occur. No need to fill reference or prediction blocks.

2.4 CPR/IBC example

In the VVC test model, the entire reference block should have a current coding tree unit (CTU) and not overlap with the current block. Therefore, there is no need to pad the reference or prediction blocks.

If dual-tree is enabled, the partitioning structure may be different for the luma CTU and chroma CTU. Thus, for a 4:2:0 color format, one chroma block (eg, CU) may correspond to one collocated luminance region divided into multiple luminance CUs.

A chroma block can only be encoded in CPR mode if the following conditions are true:
1) Each of the luminance CUs of the collocated luminance block should be encoded in CPR mode.
2) Each of the luminance 4x4 block' BVs is first converted to the BV of a chroma block, and the BV of the chroma block is the valid BV.

If either of the two conditions is false, the chroma block is not encoded in CPR mode.

Note that the definition of a valid BV has the following restrictions.
1) All samples of the reference block identified by the BV should be within the restricted search range (eg, within the same CTU in current VVC designs).
2) All samples of the reference block identified by the BV have been reconstructed.

2.5 CPR/IBC Examples

In some embodiments, the reference region for CPR/IBC is limited to the current CTU and is at most 128x128. The reference area can be dynamically changed to reclaim memory so that the CPR/IBC block can have more reference candidates while the CPR/IBC reference buffer can be maintained or reduced from one CTU. and store reference samples for CPR/IBC.

FIG. 2 shows one method, where one block is 64x64 and one CTU includes 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.

Let the current luminance CU position with respect to the upper left corner of the picture be (x, y) and the block vector be (BVx, BVy). In the current design, whether BV is valid or not depends on whether the brightness position ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) is not reconstructed. , ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) is not equal to (x>>6<<6, y>>6<<6) You can know by.

2.6 In-loop reshape (ILR)

The basic idea of in-loop reshaping (ILR) is to transform the original (in the first domain) signal (the predicted/reconstructed signal) into the second domain (the reshaped domain).

The in-loop luminance 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 computed from the signaled LUT. be. Each LUT is a one-dimensional 10-bit 1024-entry mapping table (1D-LUT). One LUT is a forward LUT, FwdLUT, which maps the input luminance code value Y _i to a modified value Y _r :Y _r =FwdLUT[Yi]. The other LUT is an inverse LUT, InvLUT, which maps the modified code value Y _r to Y^ _i :Y^ _i :InvLUT[ _Yr ]. (Y^ _i represents the reconstructed value of Y _i ).

2.6.1 PWL model

Conceptually, piecewise linear (PWL) is implemented as follows.

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

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

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

m is a scalar, c is an offset, and FP_PREC is a constant for defining precision.

In some embodiments, the PWL model is used to precompute a 1024-entry FwdLUT mapping table and an InvLUT mapping table, but the PWL model can be used to precompute the 1024-entry FwdLUT mapping table and InvLUT mapping table without precomputing the LUT. It also makes it possible to calculate on the fly.

2.6.2.1 Reshaping brightness

The method of in-loop luminance reshaping provides a less complex 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.

Intra prediction is always performed on the reshaped domain, regardless of slice type. According to such a configuration, intra prediction can be started immediately after performing the previous TU reconfiguration. Such a configuration may also provide unified processing for intra mode instead of relying on slices. FIG. 10 is a block diagram showing decoding processing based on the CE12-2 method.

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

Interslice reconstruction using in-loop luma reshaper (light green shaded blocks indicate signal in the reshaped domain; luma residuals, intra-luminance prediction, and intra-luminance reconstruction)

2.6.2.2 Luminance dependent chroma residual scaling

Luminance-dependent chroma residual scaling is a multiplication process implemented with fixed-point integer arithmetic. Chroma residual scaling compensates for the interaction of the luminance signal with the chroma signal. Apply chroma residual scaling at the TU level. Specifically, the following applies:
- For intra, average the reconstructed luminance.
- For inter, average the predicted brightness.

This average value is used to identify the index in the PWL model. This index specifies the scaling factor cScaleInv. Multiply the chroma residual by that number.

Note that the chroma scaling coefficient is calculated not from the reconstructed brightness value but from the forward-mapped predicted brightness value.

2.6.2.3 Signaling of ILR side information

Parameters are (currently) sent in the tile group header (similar to ALF). These are reported to require 40-100 bits.

In some examples, added syntax is highlighted in italics.

新しい構文表タイルグループリシェイパを追加する。

Add new syntax table tile group reshaper.

一般的に、シーケンスパラメータセットＲＢＳＰの意味論では、次の意味論を追加する。
ｓｐｓ＿ｒｅｓｈａｐｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１と等しい場合は、符号化映像シーケンス（ＣＶＳ）においてリシェイパが使用されていることを規定している。ｓｐｓ＿ｒｅｓｈａｐｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０と等しい場合は、ＣＶＳにおいてリシェイパが使用されていないことを規定している。

タイルグループヘッダ構文において、以下の意味論を追加する。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１と等しい場合は、ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ（）がタイルグループ内に存在することを規定している。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが０と等しい場合は、ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ（）がタイルグループヘッダに存在しないことを規定している。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが存在しない場合は、０に等しいと推論される。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１と等しい場合は、現在のタイルグループに対してリシェイパが有効になっていることを規定している。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０と等しい場合は、現在のタイルグループに対してリシェイパが有効になっていないことを規定している。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇが存在しない場合、０であると推論される。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｃｈｒｏｍａ＿ｒｅｓｉｄｕａｌ＿ｓｃａｌｅ＿ｆｌａｇが１と等しい場合は、現在のタイルグループに対してクロマ残差スケーリングを有効であることを規定している。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｃｈｒｏｍａ＿ｒｅｓｉｄｕａｌ＿ｓｃａｌｅ＿ｆｌａｇが０と等しい場合は、現在のタイルグループに対してクロマ残差スケーリングが有効でないことを規定している。
ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｃｈｒｏｍａ＿ｒｅｓｉｄｕａｌ＿ｓｃａｌｅ＿ｆｌａｇが存在しない場合は、０であると推測される。

ｔｉｌｅ＿ｇｒｏｕｐ＿ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ（）構文を追加する
ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｍｉｎ＿ｂｉｎ＿ｉｄｘは、最小のビン（またはピース）インデックスを、リシェイパ構築処理に使用するように規定している。ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｍｉｎ＿ｂｉｎ＿ｉｄｘの値が０～ＭａｘＢｉｎＩｄｘの範囲内にあるものとする。
ＭａｘＢｉｎＩｄｘの値は１５と等しいとする。
ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｄｅｌｔａ＿ｍａｘ＿ｂｉｎ＿ｉｄｘは、最大許容ビン（またはピース）インデックスＭａｘＢｉｎＩｄｘから最大ビンインデックスを引いたものが、リシェイパ構築処理で使用されることを規定している。ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｍａｘ＿ｂｉｎ＿ｉｄｘの値は、ＭａｘＢｉｎＩｄｘ－ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｄｅｌｔａ＿ｍａｘ＿ｂｉｎ＿ｉｄｘに等しく設定される。
ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ ｂｉｎ＿ｄｅｌｔａ＿ａｂｓ＿ｃｗ＿ｐｒｅｃ＿ｍｉｎｕｓ１＋１は、構文ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ａｂｓ＿ＣＷ［ｉ］の表現に使用するビット数を規定している。
ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ａｂｓ＿ＣＷ［ｉ］は、ｉ番目のビンの絶対デルタコード名値を規定する。
ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ｓｉｇｎ＿ＣＷ＿ｆｌａｇ［ｉ］は、ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ａｂｓ＿ＣＷ［ｉ］のサインを次のように記述する。
－ ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ｓｉｇｎ＿ＣＷ＿ｆｌａｇ［ｉ］が０と等しい場合、対応する変数ＲｓｐＤｅｌｔａＣＷ［ｉ］は正の値である。
－ そうでない場合（ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ｓｉｇｎ＿ＣＷ＿ｆｌａｇ［ｉ］が０と等しくない）、対応する変数ＲｓｐＤｅｌｔａＣＷ［ｉ］は負の値である。
ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ｓｉｇｎ＿ＣＷ＿ｆｌａｇ［ｉ］が存在しない場合、０に等しいと推測される。
変数ＲｓｐＤｅｌｔａＣＷ［ｉ］＝（１ ２＊ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ｓｉｇｎ＿ＣＷ［ｉ］）＊ｒｅｓｈａｐｅ＿ｍｏｄｅｌ＿ｂｉｎ＿ｄｅｌｔａ＿ａｂｓ＿ＣＷ［ｉ］；
変数ＲｓｐＣＷ［ｉ］は、以下のステップとして導出される。
変数ＯｒｇＣＷは、（１＜＜ＢｉｔＤｅｐｔｈ_Ｙ）／（ＭａｘＢｉｎＩｄｘ＋１）に等しく設定される。
－ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ＿ｍｉｎ＿ｂｉｎ＿ｉｄｘ＜＝ｉ＜＝ｒｅｓｈａｐｅｒ＿ｍｏｄｅｌ＿ｍａｘ＿ｂｉｎ＿ｉｄｘの場合、ＲｓｐＣＷ［ｉ］＝ＯｒｇＣＷ＋ＲｓｐＤｅｌｔａＣＷ［ｉ］である。
－ そうでない場合、ＲｓｐＣＷ［ｉ］＝０である。

ＢｉｔＤｅｐｔｈ_Ｙの値が１０に等しい場合、ＲｓｐＣＷ［ｉ］の値は、３２～２＊ＯｒｇＣＷ＿１の範囲内にくる。
ｉが０～ＭａｘＢｉｎＩｄｘ＋１の範囲にある変数ＩｎｐｕｔＰｉｖｏｔ［ｉ］は、以下のように導出される。
ＩｎｐｕｔＰｉｖｏｔ［ｉ］＝ｉ＊ＯｒｇＣＷ
ｉが０～ＭａｘＢｉｎＩｄｘ＋１の範囲にあり、変数ＳｃａｌｅＣｏｅｆ［ｉ］およびＩｎｖＳｃａｌｅＣｏｅｆｆ［ｉ］がそれぞれ０～ＭａｘＢｉｎＩｄｘの範囲にあり、ｉが０～ＭａｘＢｉｎＩｄｘの範囲にある変数ＲｅｓｈａｐｅＰｉｖｏｔ［ｉ］は、以下のように導出される。

ｓｈｉｆｔＹ＝１４
ＲｅｓｈａｐｅＰｉｖｏｔ［０］＝０；
ｆｏｒ（ｉ＝０；ｉ＜＝ＭａｘＢｉｎＩｄｘ；ｉ＋＋）｛
ＲｅｓｈａｐｅＰｉｖｏｔ［ｉ＋１］＝ＲｅｓｈａｐｅＰｉｖｏｔ［ｉ］＋ＲｓｐＣＷ［ｉ］
ＳｃａｌｅＣｏｅｆ［ｉ］＝（ＲｓｐＣＷ［ｉ］＊（１＜＜ｓｈｉｆｔＹ）＋（１＜＜（Ｌｏｇ２（ＯｒｇＣＷ）－１）））＞＞（Ｌｏｇ２（ＯｒｇＣＷ））
ｉｆ（ＲｓｐＣＷ［ｉ］＝＝０）
ＩｎｖＳｃａｌｅＣｏｅｆｆ［ｉ］＝０
ｅｌｓｅ
ＩｎｖＳｃａｌｅＣｏｅｆｆ［ｉ］＝ＯｒｇＣＷ＊（１＜＜ｓｈｉｆｔＹ）／ＲｓｐＣＷ［ｉ］
｝

ｉが０～ＭａｘＢｉｎＩｄｘの範囲内にある変数ＣｈｒｏｍａＳｃａｌｅＣｏｅｆ［ｉ］は、以下のように導出される。
ＣｈｒｏｍａＲｅｓｉｄｕａｌＳｃａｌｅＬｕｔ［６４］＝｛１６３８４，１６３８４，１６３８４，１６３８４，１６３８４，１６３８４，１６３８４，８１９２，８１９２，８１９２，８１９２，５４６１，５４６１，５４６１，５４６１，４０９６，４０９６，４０９６，４０９６，３２７７，３２７７，３２７７，３２７７，２７３１，２７３１，２７３１，２７３１，２３４１，２３４１，２３４１，２０４８，２０４８，２０４８，１８２０，１８２０，１８２０，１６３８，１６３８，１６３８，１６３８，１４８９，１４８９，１４８９，１４８９，１３６５，１３６５，１３６５，１３６５，１２６０，１２６０，１２６０，１２６０，１１７０，１１７０，１１７０，１１７０，１０９２，１０９２，１０９２，１０９２，１０２４，１０２４，１０２４，１０２４｝；
ｓｈｉｆｔＣ＝１１
－ｉｆ（ＲｓｐＣＷ［ｉ］＝＝０）
ＣｈｒｏｍａＳｃａｌｅＣｏｅｆ［ｉ］＝（１＜＜ｓｈｉｆｔＣ）
－Ｏｔｈｅｒｗｉｓｅ（ＲｓｐＣＷ［ｉ］！＝０），ＣｈｒｏｍａＳｃａｌｅＣｏｅｆ［ｉ］＝
ＣｈｒｏｍａＲｅｓｉｄｕａｌＳｃａｌｅＬｕｔ［ＲｓｐＣＷ［ｉ］＞＞１］

Generally, the semantics of the sequence parameter set RBSP adds the following semantics.
When sps_reshaper_enabled_flag is equal to 1, it specifies that a reshaper is used in a coded video sequence (CVS). If sps_reshaper_enabled_flag is equal to 0, it specifies that the reshaper is not used in CVS.

Add the following semantics to the tile group header syntax:
When tile_group_reshaper_model_present_flag is equal to 1, it specifies that tile_group_reshaper_model() exists in the tile group.
When tile_group_reshaper_model_present_flag is equal to 0, it 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.
If tile_group_reshaper_enabled_flag is equal to 1, it specifies that the reshaper is enabled for the current tile group.
If tile_group_reshaper_enabled_flag is equal to 0, it 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.
When tile_group_reshaper_chroma_residual_scale_flag is equal to 1, it specifies that chroma residual scaling is enabled for the current tile group.
When tile_group_reshaper_chroma_residual_scale_flag is equal to 0, it specifies that chroma residual scaling is not enabled for the current tile group.
If tile_group_reshaper_chroma_residual_scale_flag does not exist, it is assumed to be 0.

The reshape_model_min_bin_idx that adds the tile_group_reshaper_model() syntax specifies that the minimum bin (or piece) index is to be used for the reshaper construction process. It is assumed that the value of reshape_model_min_bin_idx is within the range of 0 to MaxBinIdx.
It is assumed that the value of MaxBinIdx is equal to 15.
reshape_model_delta_max_bin_idx specifies that the maximum allowed bin (or piece) index MaxBinIdx minus the maximum bin index is 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 defines the number of bits used to express the syntax reshape_model_bin_delta_abs_CW[i].
reshape_model_bin_delta_abs_CW[i] specifies the absolute delta codename value for the i-th bin.
reshaper_model_bin_delta_sign_CW_flag[i] describes the sign of reshape_model_bin_delta_abs_CW[i] as follows.
- If reshape_model_bin_delta_sign_CW_flag[i] is equal to 0, the corresponding variable RspDeltaCW[i] is a positive value.
- Otherwise (reshape_model_bin_delta_sign_CW_flag[i] is not equal to 0), the corresponding variable RspDeltaCW[i] is a negative value.
If reshape_model_bin_delta_sign_CW_flag[i] is not present, it is assumed to be equal to 0.
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.
The variable OrgCW is set equal to (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.

If the value of BitDepth _Y is equal to 10, the value of RspCW[i] will be in the range of 32 to 2*OrgCW_1.
The variable InputPivot[i] where i is in the range of 0 to MaxBinIdx+1 is derived as follows.
InputPivot[i]=i*OrgCW
The variable ReshapePivot[i] where i is in the range of 0 to MaxBinIdx+1, the variables ScaleCoef[i] and InvScaleCoeff[i] are each in the range of 0 to MaxBinIdx, and the variable ReshapePivot[i] where i is in the range of 0 to MaxBinIdx is as follows. derived.

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]
}

The variable ChromaScaleCoef[i] where i is within 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, 2341, 2341, 2048, 2048, 2048, 1820, 1820, 1820, 1638, 1638, 1638, 1638, 1489, 1489, 1489, 1489, 1365, 1365, 1 365, 1365, 1260, 1260, 1260, 1260, 1170, 1170, 1170, 1170, 1092, 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]

2.6.2.4 How to use ILR

On the encoder side, each picture (or tile group) is first transformed into a reshaped domain. All encoding processing is then performed 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. A residual is then generated and encoded into a bitstream.

After the entire picture (or tile group) is encoded/decoded, the samples of the reshaped domain are transformed to the original domain, and then the deblocking filter and other filters are applied.

Forward reshaping to the predicted signal is disabled in the following cases:

The current block is intra-coded.

The current block is encoded as a CPR (Reference to Current Picture, also known as Intra Block Copy, IBC).

The current block is encoded as combined inter-intra mode (CIIP) and forward reshaping is disabled for intra-predicted blocks.

3. Examples of problems solved by various embodiments

Several problems exist in current CPR/IBC designs.
1) Encoder/decoder processing becomes complicated because the reference area changes dynamically.
2) Invalid block vectors are easily generated and difficult to check, complicating both the encoder and decoder.
3) If the reference region is irregular, encoding of block vectors becomes inefficient.
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 chroma blocks, this decision is made based on the availability of luminance samples, and this may result in false errors due to the dual-tree partition structure. It may result in judgment.

4. Exemplary embodiment

In some embodiments, regular buffers can be used for CPR/IBC blocks to obtain references.

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

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

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

Reference buffer for CPR/IBC1. It is proposed to use M×N pixel buffers to store luminance reference samples for CPR/IBC.
a. 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, eg, 96x128 or 128x96.
j. In one example, the buffer size is equal to the CTU size.
k. In one example, M=mW, N=H, 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.
m. In one example, M=mW, N=nH, W and H are the width and height of the CTU, and m and n are positive integers.
n. In the example above, m and n may depend on the size of the CTU.
i. In one example, if the CTU size is 128x128, m=1 and n=1.
ii. In one example, if the CTU size is 64x64, m=4 and n=1.
iii. In one example, if the CTU size is 32x32, m=16 and n=1.
iv. In one example, if the CTU size is 16x16, m=64 and n=1.
o. 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.
a. 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 from 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.
a. 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 reconstructed pixels before loop filtering. Loop filtering may refer to a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO), a cross-component ALF, or any other filter.
a. In one example, the buffer can store samples in the current CTU.
b. In one example, the 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 can store samples from other pictures.
5. It is proposed that a buffer can store the reconstructed pixels after loop filtering. Loop filtering may refer to a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO), a cross-component ALF, or any other filter.
a. In one example, the buffer can store samples in the current CTU.
b. In one example, the 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 can store samples from other pictures.
6. It is proposed that the buffer can store reconstructed samples both before and after loop filtering. Loop filtering may refer to a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO), a cross-component ALF, or any other filter.
a. 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 the reconstructed samples before loop filtering.
7. It is proposed that the buffer stores samples with a given bit depth, which may be different from the bit depth of the encoded video data.
a. In one example, the bit depth of the reconstruction 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 than the input bit depth for one 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 the same as a predefined number.
f. In one example, the bit depth depends on the standard profile.
g. In one example, the bit depth or bit depth difference compared to the output bit depth/input bit depth/internal bit depth is the bit depth or bit depth difference of the SPS/PPS/sequence header/picture header/slice header/tile group header/tile header or other types of It may also be signaled in the video data unit.
h. The proposed method may be applied to the proposed buffer definitions mentioned in other bullets, or alternatively to existing designs of IBCs.
i. The bit depth of each color component of the buffer may be different.

Buffer start 8. It is proposed to initialize the buffer with a given value.
a. In one example, the 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 medium gray value, eg, set to 128 for an 8-bit signal, and set to 512 for a 10-bit signal.
iii. In one example, if ILR is used, the buffer is initialized with forwardLUT(m). Example m=1<<(Bitdepth-1).
b. Alternatively, the buffer is initialized with values signaled in SPS/VPS/APS/PPS/sequence header/tile group header/picture header/tile/CTU/coding unit/VPDU/region.
c. In one example, this given value may be derived from a previously decoded picture or slice or CTU row or CTU or CU sample.
d. This given value may be different for different color components.
9. Alternatively, it is proposed to initialize the buffer using decoded pixels from a previously encoded block.
a. In one example, the decoded pixels are the pixels before in-loop filtering.
b. In one example, if the buffer size is 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, the method of bullet 8 may also be applied if the previously encoded block is not available.

Buffer reference 10. In order for one block to use pixels in the buffer as a reference, this block will use the pixels in the buffer at positions (x, y), x=0, 1, 2, . ．． ．． , M-1; y=0, 1, 2, . ．． ．． , N-1, can be used to indicate a reference destination.
11. Alternatively, this reference position is l=y*M+x, l=0,1, . ．． ．． , M*N-1.
12. Note that it is also possible to send the block vector (BVx, BVy) = (x-x0, y-y0) to the decoder, with the upper left position of the block related to the current CTU as (x0, y0), and indicate the reference destination in the buffer. good.
13. Alternatively, the block vector (BVx, BVy) may be defined as (x−x0+Tx,y−y0+Ty), where Tx and Ty are predefined offsets.
14. For any pixels (x0, y0) and (BVx, BVy), its reference in the buffer can be found at (x0+BVx, y0+BVy).
a. 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, its reference value is predefined as a given value, eg, mid-gray.
c. Alternatively, the reference position is defined as ((x0+BVx) mod M, (y0+BVy) mod N), such that it is always in the buffer.
15. For any pixels (x0, y0) and (BVx, BVy), if (x0+BVx, y0+BVy) is outside the buffer, its reference value may be derived from the value in the buffer.
a. 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. Certain coordinates outside the buffer range may not be allowed.
a. In one example, for any pixel (x0, y0) for the upper left corner of the CTU and block vector (BVx, BVy), y0+BVy is [0, . ．． , N-1] is the bitstream constraint.
b. In one example, for any pixel (x0, y0) in the upper left corner of the CTU and block vector (BVx, BVy), x0+BVx is [0, . ．． , M-1] is the bitstream constraint.
c. In one example, for any pixel (x0, y0) in the upper left corner of the CTU and block vector (BVx, BVy), y0+BVy is [0, . ．． , N-1] and x0+BVx is [0, . ．． , M-1] is the bitstream constraint.
17. If one block's signaled or derived block vector points somewhere outside the buffer, padding may be done based on the buffer.
a. In one example, the value of any sample outside the buffer is defined with a predefined value.
i. In one example, this value may be 1<(bit depth-1), eg, 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). Example m=1<<(Bitdepth-1).
iii. Alternatively, the indication of predefined values may be signaled or displayed at 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. How buffer references are handled may be different horizontally and vertically, or depending on the location of the current block (eg, closer to a picture boundary or not).
a. In one example, if y0+BVy is outside [0,N-1], the sample value of (x0+BVx,y0+BVy) is assigned as the predefined value.
b. In one example, if x0+BVx is outside [0,M-1], a sample value of (x0+BVx,y0+BVy) is assigned as the predefined value.
c. Alternatively, assign the sample value of (x0+BVx, y0+BVy) as the sample value of ((x0+BVx) mod M, y0+BVy), so that if ((x0+BVx) mod M, y0+BVy) is still outside the buffer, may call other methods to further derive its value.
d. Alternatively, assign the sample value of (x0+BVx, y0+BVy) as the sample value of (x0+BVx, (y0+BVy) mod N), so that if (x0+BVx, (y0+BVy) mod N) is still outside the buffer , may call other methods to further derive its value.

Block vector representation 19. Each component of the block vector (BVx, BVy) or one of its components may be normalized to a certain range.
a. 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 for 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 difference (BVDx, BVDy) can be normalized to a certain range.
a. In one example, BVDx may be replaced with (BVDx mod M) and the function mod returns a reminder.
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.

Block Vector Validation Let the width and height of the IBC buffer be W _buf and H _buf . For a W×H block (can be a luma block, chroma block, CU, TU, 4×4, 2×2, or other sub-block) starting at (X,Y) for the top left corner of the picture , the following may be applied to indicate whether the block vector (BVx, BVy) is valid. Let W _pic , H _pic be the width and height of one picture, and let W _ctu , H _ctu 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. The block vectors (BVx, BVy) may be set as valid even if any reference position is outside the picture boundary.
a. In one example, the block vector may be set to be valid even if X+BVx<0.
b. In one example, a block vector may be set as valid even if X+W+BVx>W _pic .
c. In one example, a block vector may be set as valid even if Y+BVy<0.
d. In one example, a block vector may be set as valid even if Y+H+BVy>H _pic .
24. The block vector (BVx, BVy) may be set as valid even if the reference position exists outside the current CTU row.
a. In one example, the block vector may be set to be valid even if Y+BVy<floor(Y/H _ctu )*H _ctu .
b. In one example, the block vector may be set to be valid even if Y+H+BVy>=floor(Y/H _ctu )*H _ctu +H _ctu .
25. The block vectors (BVx, BVy) may be set to be valid even if any reference position is outside the current CTU and the left (n-1) CTU, where n is due to IBC. is the number of CTUs (including or excluding the current CTU) that can be used as a reference region for the current CTU.
a. In one example, the block vector may be set to be valid even if X+BVx<floor(X/W _ctu )*W _ctu -(n-1)*W _ctu .
b. In one example, the block vector may be set to be valid even if X+W+BVx>floor(X/W _ctu )*W _ctu +W _ctu .

26. The block vector (BVx, BVy) may be set as valid even if a particular sample has not been reconstructed.
a. 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. The block vector (BVx, BVy) may be set as always valid if one block is not the block of the first CTU in a CTU row.
a. Alternatively, the block vector may be set as always valid.
28. If all of the following three conditions are satisfied, the block vector (BVx, BVy) may be set as always valid.
・X+BVx＞=0
・Y+BVy＞=floor(Y/H _ctu )
・isRec(X+BVx+W-1, Y+BVy+H-1)==true
a. Alternatively, for a block of the first CTU in one CTU row, the block vector may be set as always valid if all three conditions are met.
29. If the block vector (BVx, BVy) is valid, a sample copy of the block may be performed based on the block vector.
a. In one example, the prediction for sample (X,Y) can be obtained from ((X+BVx)%W _buf , (Y+BVy)%H _buf ).

Buffer update 30. The buffer may be reset when encoding a new picture or tile.
a. The term "reset" can refer to the buffer being initialized.
b. The term "reset" can refer to all samples/pixels in the buffer being set to a given value (eg, 0 or -1).
31. Once the VPDU has been encoded, the buffer may be updated with the reconstructed value of the VPDU.
32. Once the CTU has been encoded, the buffer may be updated with the reconstructed value of the CTU.
a. In one example, if the buffer is not full, the buffer may update CTU by CTU sequentially.
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 CTU sizes and M, N are the buffer sizes) and the last updated area starts from (kW, 0), then update The next starting position is ((k+1)W mod M,0).
33. The buffer may be reset at the beginning of each CTU row.
a. Alternatively, the buffer may be reset at the start of decoding each CTU.
b. Alternatively, the buffer may be reset at the beginning of decoding one tile.
c. Alternatively, the buffer may be reset at the start of decoding one tile group/picture.
34. After encoding the block starting from (x, y), the corresponding area of the buffer starting from (x, y) is updated by reconstruction from the block.
a. In one example, (x,y) is the position relative to the upper left corner of the CTU.
35. Once a block has been encoded for a picture, the corresponding area of the buffer is updated by reconstruction from the block.
a. 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 upper 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 upper 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 upper left corner of the current CTU row.
d. In one example, the values in the buffer may be updated with reconstructed pixel values after bit depth alignment.
36. After we finish encoding the block starting from (x, y), the corresponding area of the buffer starting from (xb, yb) is updated by reconstruction from the block, and (xb, yb) and (x, y) are Two different coordinates.
a. In one example, (x, y) is the position relative to the upper left corner of the CTU, (xb, yb) is (x+update_x, y+update_y), and update_x and update_y are updatable 37. in the buffer. In the above example, the reconstructed value of one block may represent the reconstructed value before applying a filter (eg, a deblocking filter).
a. Alternatively, the reconstructed value of one block may represent the reconstructed value after a filter (eg, a deblocking filter) has been applied.
38. When the buffer is updated from the reconstructed samples, the reconstructed samples may first be modified before being stored, eg, changing the bit depth of the samples.
a. In one example, the buffer is updated with 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 the predefined bit value. It is a 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 b is a predefined bit shift value, and bit depth 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 the predefined bit value. It is a 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 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 example above, b may be reconstructed as the bit depth minus the input sample bit depth.
39. When using buffer samples to form predictions, preprocessing can be applied.
a. In one example, the predicted value is p<<b, where p is a 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 samples.
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 , is the bit depth of the reconstructed samples.
d. In the example above, b may be reconstructed as the bit depth minus the input sample bit depth.
40. Buffers may be updated in a given order.
a. In one example, the buffer may be updated sequentially.
b. In one example, the buffer may be updated based on the reconstructed block order.
41. If the buffer is full, the samples in the buffer can be replaced with the latest reconstructed samples.
a. 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 can be assigned priorities and replaced based on this priority.
d. In one example, a sample may be marked as "long-term" so that other samples are replaced first.
e. In one example, one flag may be sent with one block to indicate high priority.
f. In one example, one number may be sent with one block to indicate priority.
g. In one example, samples from the reconstructed block that have certain characteristics are assigned higher priority so that other samples are replaced first.
i. In one example, all samples of a block may be assigned a high priority if the percentage of samples encoded in IBC mode is greater than a threshold.
ii. In one example, all samples of a block may be assigned a high priority if the percentage of samples encoded in Palette mode is greater than a threshold.
iii. In one example, all samples of a block may be assigned a high priority if the percentage of samples encoded in IBC or Palette mode is greater than a threshold.
iv. In one example, all samples of a block may be assigned a high priority if the percentage of samples encoded in transform skip mode is greater than a threshold.
v. This threshold may vary based on block size, color components, and CTU size.
vi. Thresholds may be signaled in 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 greater than or equal to 64x64x3 luminance samples.

Alternative buffer combination 42. Instead of always using the three previously encoded 64x64 blocks as a reference region, it is proposed to adaptively change it based on the position of the current block (or VPDU).
a. In one example, when encoding/decoding a 64x64 block, three previous 64x64 blocks can be used as references. Compared to FIG. 2, more of the previous 64×64 blocks may be combined. Figure 2 shows examples of different combinations of previous 64x64 blocks.
43. Instead of using a z-scan order, a vertical scan order may be used.
a. In one example, one block is in the z-scan order at index 0. ．． 3, the encoding/decoding order is 0, 2, 1, 3.
b. In one example, when encoding/decoding a 64x64 block, three previous 64x64 blocks can be used as a reference. Compared to FIG. 2, more types of 64x64 block encoding/decoding orders can be applied. FIG. 4 shows an example of different encoding/decoding orders for 64×64 blocks.
c. Alternatively, the method may be applied only to encoding screen content.
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 CTU row.

Virtual IBC Buffer Hereinafter, in a luminance sample, the width and height of a VPDU are denoted as WVPDU (eg, 64) and HVPDU (eg, 64), respectively. Alternatively, the WVPDU and/or HVPDU may represent the width and/or height of other video units (eg, CTUs).
44. A virtual buffer may be maintained to keep track of the state of the IBC reference area.
a. In one example, the virtual buffer size is mWVPDU x nHVPDU.
i. 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 picture resolution, CTU size.
iii. In one example, m and/or n may be signaled or predefined.
b. In one example, the methods described above with bullets and sub-bullets may be applied to virtual buffers.
c. In one example, the sample (x, y) for the top left corner of a 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.
a. In one example, a flag may be associated with a sample in a virtual buffer to identify whether a 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 samples associated with that block can be used as an IBC reference.
46. After finishing decoding a VPDU or video unit, certain samples associated with the virtual buffer may be marked as unavailable for IBC reference.
a. In one example, which samples are unavailable may depend on the location of the most recently decoded VPDU.
b. If one sample is marked as unavailable, predictions from this sample are not allowed.
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 help identify which samples associated with a virtual buffer are marked as unavailable.
a. In one example, at the beginning of decoding a VPDU, some samples associated with a virtual buffer may be marked as unavailable based on the location of the recently decoded VPDU.
i. In one example, represent (xPrevVPDU, yPrevVPDU) as the top left position with respect to the top left corner of the picture/slice/tile/brick/other video processing unit of the most recently decoded VPDU, and yPrevVPDU% (nHVPDU) is equal to 0. , a particular location (x,y) can be marked as unavailable.
1. In one example, x may be in a range such as [xPrevVPDU-2WVPDU+2mWVPDU)% mWVPDU, ((xPrevVPDU-2WVPDU+2mWVPDU)% mWVPDU)-1+WVPDU].
2. In one example, y may be in a range such as [yPrevVPDU%(nHVPDU), (yPrevVPDU%(nHVPDU))-1+HVPDU].
3. In one example, x is [xPrevVPDU-2WVPDU+2mWVPDU]%mWVPDU, ((xPrevVPDU-2WVPDU+2mWVPDU)%mWVPDU, ((xPrevVPDU-2WVPDU+2mWVPDU)%mWVPDU)-1+WVPDU]. y may be within the range [ yPrevVPDU%(nHVPDU), (yPrevVPDU%(nHVPDU))−1+HVPDU].
ii. In one example, for the top left corner of the picture/slice/tile/brick/other video processing unit of the most recently decoded VPDU, (xPrevVPDU, yPrevVPDU) is expressed as the top left position, and yPrevVPDU% (nHVPDU) is 0. If not, the particular location (x,y) can be marked as unavailable.
1. In one example, x may be in a range such as [xPrevVPDU-WVPDU+2mWVPDU)% mWVPDU, ((xPrevVPDU-WVPDU+2mWVPDU)% mWVPDU)-1+WVPDU].
2. In one example, y may be in a range such as [yPrevVPDU%(nHVPDU), (yPrevVPDU%(nHVPDU))-1+HVPDU].
3. In one example, x may be in a range such as [xPrevVPDU - WVPDU + 2mWVPDU)% mWVPDU, ((xPrevVPDU - WVPDU + 2mWVPDU)% mWVPDU) - 1 + WVPDU], and y is [yPrevVPDU% (nHVPDU), (yPr evVPDU% (nHVPDU))-1+HVPDU].
48. If one CU includes multiple VPDUs, instead of applying the VPDU-based IBC reference availability marking process, the IBC reference availability marking process may follow the following CUs.
a. In one example, at the beginning of decoding a CU that includes multiple VPDUs, an IBC reference availability marking process may be applied to each VPDU before decoding the VPDUs in the CU.
b. In such cases, 128x64 IBC blocks and 64x128 IBC blocks may not be allowed.
i. In one example, pred_mode_ibc_flag for 128x64 and 64x128 CUs may not be sent and may be assumed equal to 0.
49. For reference blocks or sub-blocks, it may not be necessary to check the reference availability status in the upper right corner to determine whether the block vector associated with this reference block is valid.
a. In one example, only the top left, bottom left, and bottom right corners of the block/subblock 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 denoted by vSize) and/or the size of the CTB/CTU (width/height denoted by ctbSize).
a. In one example, the buffer height 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 outside the pixel range, indicating that this location may not be available for IBC reference (eg, not used for prediction of other samples).
a. The sample value may be set to a value indicating that the sample is unavailable.
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 [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 sample availability marking in the IBC buffer may depend on the current block position, current block size, CTU/CTB size, and VPDU size. In one example, (xCb, yCb) represents the position of the block relative to the top left of the picture, ctbSize is the size (i.e., width and/or height) of the CTU/CTB, and vSize=min(ctbSize, 64) Yes, wIbcBuf and hIbcBuf are the width and height of the IBC buffer.
a. In one example, a particular set of locations in the IBC buffer may be marked as unavailable if (xCb%vSize) is equal to 0 and (yCb%vSize) is equal to 0.
b. In one example, if the current block size is smaller than the VPDU size, i.e. min(ctbSize, 64), the area marked as unavailable may follow the VPDU size c. In one example, if the current block size is larger than the VPDU size, ie, min(ctbSize, 64), the area marked as unavailable may follow the CU size.
53. At the beginning 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.
a. In one example, we have a position in the buffer (x%wIbcBuf, y%hIbcBuf), x=xV, . ．． ．． , xV+ctbSize-1, y=yV, . ．． ．． , yV+ctbSize-1 is set to the value -1. wIbcBuf and hIbcBuf are the width and height of the IBC buffer, and ctbSize is the width of CTU/CTB.
i. In one example, hIbcBuf may be equal to ctbSize.
54. The bitstream conformance constraint may follow the value of the samples in the IBC buffer.
a. In one example, if one reference block associated with one block vector in the IBC buffer contains a value outside the pixel range, the bitstream may be invalid.
55. Bitstream conformance constraints may be set based on the availability indication in the IBC buffer.
a. In one example, if any reference samples mapped to the IBC buffer are marked as unavailable for encoding/decoding a block, this bitstream may be invalid. There is.
b. In one example, if a singletree is used, this bit Stream may be fraudulent.
c. One conforming bitstream may, in the case of an IBC coded block, point to one reference block whose associated block vector is mapped to an IBC buffer, and for encoding/decoding one block Mark as available each luminance reference sample located at , K1 are set to (1<<BitDepth-1), where BitDepth is the internal bit depth or input bit depth).
56. The bitstream conformance constraints may depend on the type of partitioning tree and the treeType of the current CU's encoding.
a. In one example, if dualtree is allowed 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, then the bitstream constraints may need to check whether all component locations mapped to the IBC buffer are marked as unavailable.
b. In one example, if dualtree is enabled at a high level (e.g. slice/picture/brick/tile) and the current luminance video block (e.g. CU/PU//CB/PB) is encoded with dualtree. may ignore whether the mapped location in the IBC buffer of the chroma component is marked as unavailable due to bitstream constraints.
i. Alternatively, in such a case, the bitstream constraints may still check whether all component locations mapped to the IBC buffer are marked as unavailable.
c. In one example, if a single tree is used, the bitstream constraints may ignore whether the location of the chroma component mapped to the IBC buffer is unavailable.

Improvements to the current VTM design 57. IBC prediction 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 constructed 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, where the bit depth is the bit depth of the predicted samples.
d. In one example, the predicted value is based on the value (clip((p>>b),0,(1<<(bitdepth-b)))+(1<<(bitdepth-1)))<<b. , bit depth is the bit depth of the predicted samples.
e. In one example, the predicted values are clipped differently based on whether ILR is applied.
f. In the example above, b may be reconstructed as the bit depth minus the input sample bit depth.
g. In one example, the bit depth or bit depth difference compared to the output bit depth/input bit depth/internal bit depth is the bit depth or bit depth difference of the SPS/PPS/sequence header/picture header/slice header/tile group header/tile header or other types of It may also be signaled in the video data unit.
58. Parts of the IBC prediction may be less accurate, while other parts have the same accuracy as the reconstruction.
a. In one example, the allowed reference regions may include samples with different precisions (eg, bit depths).
b. In one example, references from other 64x64 blocks that the current 64x64 block has not been decoded have low accuracy, and references from the current 64x64 block have the same accuracy as the reconstruction.
c. In one example, references from CTUs other than the current CTU being decoded have low precision, and references from the current CTU have the same precision as the reconstruction.
d. In one example, references from a particular collection of color components have low precision, and references from other color components have the same precision as the reconstruction.
59. If the CTU size is M×M and the reference region size is nM×nM, the reference region is the nearest available n×n CTU in the CTU row.
a. In one example, if the reference area size is 128x128 and the CTU size is 64x64, the four closest available CTUs in one CTU row can be used for IBC reference.
b. In one example, if the reference area size is 128x128 and the CTU size is 32x32, the closest available 16 CTUs in one CTU row can be used for IBC reference.
60. If the CTU size is M and the reference area size is nM, the reference area is the nearest available n-1 CTUs in the CTU's row/tile.
a. In one example, if the reference region size is 128x128 or 256x64 and the CTU size is 64x64, the three closest available CTUs in one CTU row can be used for IBC reference.
b. In one example, if the reference area size is 128x128 or 512x32 and the CTU size is 32x32, the closest available 15 CTUs in one CTU row can be used for IBC reference.
61. If the CTU size is M, the VPDU size is kM and the reference area size is nM, where the reference area is the nearest available n−k CTUs in the CTU row/tile.
a. In one example, the CTU size is 64x64, the VPDU size is also 64x64, the reference size is 128x128, and the closest three CTUs in one CTU row are used for IBC reference. Can be used.
b. In one example, the CTU size is 32x32, the VPDU size is 64x64, the reference size 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 area for memory reuse, and w and h are the width and height.
a. In one example, if the CTU size is 128x128 and (x,y) = (mx64, nx64), the reference block is from ((m-2)x64, nx64) It cannot overlap with the starting 64x64 area.
b. In one example, if the CTU size is 128x128, the reference blocks cannot overlap if the upper 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) cannot exist in a w*h block whose upper left corner is (x-128,y), and BVx and BVy are Represents the block vector of the current block.
d. In one example, if the CTU size is M×M and the IBC buffer size is k×M×M, the reference block cannot overlap with w×h blocks and the upper left corner is (x−k× M,y), and BVx and BVy represent the block vectors of the current block.
e. In one example, if the CTU size is M×M and the IBC buffer size is k×M×M, then (x+BVx,y+BVy) cannot exist in a w×h intrablock and the upper left corner is ( x−k×M,y), and BVx and BVy represent the block vectors of the current block.
63. If the size of the CTU is not MxM and the size of the reference region is nMxnM, then the reference region is the nearest available nxn-1 CTUs in the row of the CTU.
a. In one example, if the reference area size is 128x128 and the CTU size is 64x64, the three closest available CTUs in one CTU row can be used for IBC reference.
b. In one example, if the reference area size is 128x128 and the CTU size is 32x32, the closest available 15 CTUs in one CTU row can be used for IBC reference.
64. For a CU of 64x64 blocks starting from (2m*64, 2n*64), that is, a 64x64 block at the top left in a 128x128 CTU, its IBC prediction is ((2m-2)*64, 2n*64 ), 64×64 blocks starting from ((2m-1)*64, 2n*64), and 64×64 blocks starting from ((2m-1)*64, (2n+1)*64) , and from the reconstructed samples in the current 64x64 block.
65. For a 64x64 block CU starting from ((2m+1)*64, (2n+1)*64), i.e., the bottom right 64x64 block in a 128x128 CTU, its IBC prediction is from the current 128x128 CTU. There may be.
66. For a 64x64 block CU starting from ((2m+1)*64, 2n*64), that is, a 64x64 block on the upper right in a 128x128 CTU, its IBC prediction is ((2m-1)*64, 2n *64), a 64x64 block starting from ((2m-1)*64, (2n+1)*64), and a 64x64 block starting from (2m*64, 2n*64), and This can be done from reconstructed samples in the current 64x64 block.
a. Alternatively, if we reconstruct a 64x64 block starting from (2m*64, (2n+1)*64), the IBC prediction is a 64x64 block starting from ((2m-1)*64, 2n*64). , a 64x64 block starting from (2m*64, 2n*64), a 64x64 block starting from (2m*64, (2n+1)*64), and the reconstructed samples in the current 64x64 block. can.
67. For a CU of 64x64 blocks starting from (2m*64, (2n+1)*64), i.e., the lower left 64x64 block in a 128x128 CTU, its IBC prediction is ((2m-1)*64, (2n+1) )*64), a 64x64 block starting from (2m*64, 2n*64), a 64x64 block starting from ((2m+1)*64, 2n*64), and the current 64x This can be done from reconstructed samples in 64 blocks.
a. Alternatively, if a 64x64 block starting from ((2m+1)*64,2n*64) is not reconstructed, the IBC prediction is a 64x64 block starting from ((2m-1)*64,2n*64). 64 block, 64x64 block starting from ((2m-1)*64, (2n+1)*64), 64x64 block starting from (2m*64, 2n*64), and replay in the current 64x64 block. This can be done from the configuration sample.
68. It is proposed to adjust the reference region based on which 64x64 block the current CU belongs to.
a. In an example, for a CU starting from (x, y), when (y>>6)&1==0, ((x>>6<<6)-128,y>>6<<6) and ( The two or two 64×64 blocks starting from (x>>6<<6)-64, y>>6<<6) can be referenced in IBC mode.
b. In one example, for a CU starting from (x, y), when (y>>6)&1==1, ((x>>6<<6)-64,y>>6<<<6) One previous 64x64 block starting from can be referenced by IBC mode.
69. For a block starting from (x, y) and having block vector (BVx, BVy), isRec(((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+( x%64), ((y+BVy)>>6<<6)+(y%64)), the block vector is invalid.
a. 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 includes both luminance and chroma components.
70. For a 4:2:0 format chroma block starting at (x, y) and having block vectors (BVx, BVy), isRec(((x+BVx)>>5<<5)+64-(((y+BVy)> If >5)&1)*32+(x%32), ((y+BVy)>>5<<5)+(y%32)) is true, the block vector is invalid.
71. The determination of whether the BV is invalid for a block of component c may depend on the availability of samples of component X instead of checking only the luminance samples.
a. For a block of component c starting at (x, y) and having block vector (BVx, BVy), isRec(c, ((x+BVx)>>6<<6)+128-(((y+BVy)>>6) &1)*64+(x%64), ((y+BVy)>>6<<6)+(y%64)) is true, 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 encoding).
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 luminance and chroma components may be checked, eg, this block includes both luminance and chroma components.
b. For a chroma block in 4:2:0 format starting at (x, y) with component c and having block vectors (BVx, BVy), isRec(c, ((x+BVx)>>5<<5)+64-( If ((y+BVy)>>5)&1)*32+(x%32), ((y+BVy)>>5<<5)+(y%32)) is true, the block vector is treated as invalid. Good too.
c. For a chroma block or subblock starting at (x,y) of component c and having block vector (BVx, BVy), if isRec(c,x+BVx+Chroma_CTU_size,y) for the chroma component is true, then the block vector is It may be treated as invalid, and Chroma_CTU_size is the CTU size of the chroma component.
i. In one example, Chroma_CTU_size may be 64 for a 4:2:0 format.
ii. In one example, a chroma subblock may be a 2x2 block in a 4:2:0 format.
iii. In one example, a chroma subblock may be a 4x4 block in a 4:4:4 format.
iv. In one example, the chroma subblock may correspond to the smallest CU size in the luminance component.
1. Alternatively, the chroma subblock may correspond to the minimum CU size of the chroma component.
72. For all the bullets mentioned above, assume that the reference buffer contains multiple M×M blocks (M=64). However, this can be extended to other cases as well, such as where the reference buffer includes multiple N×M blocks (eg, N=128, M=64).
73. For all the bullets mentioned above, a further restriction may apply that the reference buffer should be in the same brick/tile/tile group/slice as the current block.
a. In one example, the use of IBC may be disabled if a portion of the reference buffer is outside the current brick/tile/tile group/slice. 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 not associated with one block. The referenced block vector may point only to the remaining reference buffer.
74. As a reference area of the IBC, excluding the current VPDU, have K1 most recently encoded VPDUs in the first VPDU row of the CTU/CTB row, if available, and the CTU/CTB row, if available. It is proposed to have K2 most recently encoded VPDUs in the second VPDU row of .
a. 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 128x128 and the VPDU size is 64x64.
c. In one example, the above method may be applied when the CTU/CTB size is 64x64 and the VPDU size is 64x64 and/or 32x32.
d. In one example, the above method may be applied when the CTU/CTB size is 32x32 and the VPDU size is 32x32 or less.
75. The method described above may be applied in different stages.
a. In one example, a block vector (BV) module operation (eg, mod b) may be called in a BV availability check process to determine whether the BV is valid.
b. In one example, a block vector (BV) module operation (e.g., mod b) is called to determine the position of a reference sample in the IBC virtual buffer or reconstructed picture buffer (e.g., based on the current sample position and the BV's module result). ) may be specified (e.g., before in-loop filtering processing).

5. Embodiment

5.1 Embodiment #1

One implementation of a buffer for IBC is described below.

The buffer size is 128x128. The size of 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). To encode the kth CTU in a CTU row, the buffer is initialized at the reconstruction before loop filtering of the (k-1)th CTU.

FIG. 3 illustrates the encoding of a block starting at (x,y).

When encoding a block starting from (x, y) for the current CTU, we send the block vector (BVx, BVy) = (x-x0, y-y0) to the decoder and the reference block is (x0, y) in the IBC buffer. y0). In each case, the width of the block is w and the height of the block is h. When finishing encoding a block, the wxh area starting from (x,y) in the IBC buffer is updated by the reconstruction of the block before loop filtering.

5.2 Embodiment #2

FIG. 4 illustrates a possible alternative method for selecting previously encoded 64x64 blocks.

5.3 Embodiment #3

FIG. 5 illustrates an alternative method in which the encoding/decoding order of 64x64 blocks can be changed.

5.4 Embodiment #4

FIG. 8 shows another possible alternative for selecting the last encoded 64x64 block when the order of decoding of the 64x64 blocks is from top to bottom and from left to right.

5.5 Embodiment #5

FIG. 9 shows another possible alternative method of selecting the previously encoded 64x64 block.

5.6 Embodiment #6

FIG. 11 shows another possible alternative method for selecting the last encoded 64×64 block when the order of decoding of the 64×64 blocks is from left to right and top to bottom.

5.7 Embodiment #7

If the CTU has a size of W×W and an IBC buffer with a size of mW×W and a bit depth of B is implemented in the decoder, the following results.

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).

If we want to decode a CU starting from (x,y) with size w×h for the upper left corner of the CTU, after aligning the bit depth to B bits, we start from (xb+x,yb+y) and w×h size. Update the region with the reconstructed pixel values of the CU.

After decoding the CTU, the update start point (xb, yb) is set as ((xb+W) mod mW, 0).

When decoding an IBC CU with a block vector (BVx, BVy), for any pixel (x, y) regarding the upper left corner of the CTU, after bit depth alignment to the bit depth of the predicted signal, the buffer position ((x+BVx ) mod mW, (y+BVy) mode W).

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.

5.8 Embodiment #8

For a luminance CU or a combined luminance/chroma CU starting at (x,y) and block vector (BVx, BVy) for the top left corner of the picture, the block vector is isRec(((x+BVx)>>6<<6)+128− It is invalid if (((y+BVy)>>6)&1)*64+(x%64), ((y+BVy)>>6<<6)+(y%64)) is true.

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

5.9 Embodiment #9

For a chroma block or subblock starting at (x,y) in 4:2:0 format for the upper left corner of the picture, and a block vector (BVx, BVy), isRec(c, (x+BVx+64,y+BVy) is true and c When is a chroma component, the block vector is invalid.

For a chroma block or subblock starting from (x,y) in 4:4:4 format and block vector (BVx,BVy) for the upper left corner of the picture, isRec(c, (x+BVx+64,y+BVy) is true; When c is a chroma component, the block vector is invalid.

5.10 Embodiment #10

For a luminance CU or a combined luminance/chroma CU starting at (x,y) and block vector (BVx, BVy) for the top left corner of the picture, the block vector is isRec(((x+BVx)>>6<<6)+128− It is invalid if (((y+BVy)>>6)&1)*64+(x%64), ((y+BVy)>>6<<6)+(y%64)) is true.

For a chroma block or subblock starting from (x,y) in 4:2:0 format and a block vector (BVx, BVy) for the top left corner of the picture, 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 the chroma component. At some point, the block vector is invalid.

5.11 Embodiment #11

In this embodiment, excluding the current VPDU, the two most encoded VPDUs in the first VPDU row and the one most encoded VPDU in the second VPDU row of the first CTU/CTB row. Emphasis is placed on implementations that maintain encoded VPDUs.

When the encoding order is from top to bottom and from left to right, the reference area is shown as shown in FIG.

If the coding order of VPDUs is left to right and top to bottom, and the current VPDU is not on the right side of a picture boundary, the reference area is shown as in FIG. 14.

If the coding order of VPDUs is left to right and top to bottom, and the current VPDU is on the right side of the picture boundary, the reference area can be shown as FIG. 15.

Assuming that the size of the luminance block (x, y) is w×h, whether or not the block vector (BVx, BVy) is valid can be determined by checking the following conditions.

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).

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

5.12 Embodiment #12

If the CTU size is 192x128, a virtual buffer of size 192x128 is maintained to track the IBC reference samples.

The sample (x,y) for the top left corner of the picture is associated with the position (x%192, y%128) for the top left corner of the buffer. The following steps show how to mark the availability of samples associated with virtual buffers for IBC reference.

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 beginning of decoding one VPDU row, all positions of the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set as (0,0).
2) At the start of decoding of the first CU of VPDU, x=(xPrevVPDU-2WVPDU+2mWVPDU)%(mWVPDU), . ．． , ((xPrevVPDU-2WVPDU+2mWVPDU)%(mWVPDU))-1+WVPDU; and y=yPrevVPDU%(nHVPDU), . ．． , (yPrevVPDU%(nHVPDU))-1+HVPDU may be marked as unavailable. Then, (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), that is, at the upper left position with respect to the CU picture.
3) After decoding one CU, x=xCU%(mWVPDU), . ．． ．． , (xCU+CU_width-1)%(mWVPDU) and y=yCU%(nHVPDU), . ．． ．． , (yCU+CU_height-1)%(nHV PDU), the location (x,y) is marked as available.
4) For IBCCU with block vector (xBV, yBV), x=(xCU+xBV)%(mWVPDU), . ．． ．． , (xCU+xBV+CU_width-1)%(mWVPDU) and y=(yCU+yBV)%(nHVPDU), . ．． ．． , (yCU+yBV+CU_height-1)%(nHVPDU), the location (x,y) is marked as unavailable and the block vector is considered invalid.

FIG. 16 shows the buffer status in a picture along with the VPDU decoding status.

5.13 Embodiment #13

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

The sample (x,y) for the top left corner of the picture is associated with the position (x%192, y%128) for the top left corner of the buffer. The following steps show how to mark the availability of samples associated with virtual buffers for IBC reference.

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 beginning of decoding one VPDU row, all positions of the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set as (0,0).
2) At the beginning of the decoding of the first CU of the VPDU,
a. If yPrevVPDU%64 is equal to 0, then x=(xPrevVPDU-128)%192, . ．． , ((xPrevVPDU-128)%192)+63; and y=yPrevVPDU%128, . ．． , (yPrevVPDU%128)+63 location (x,y) is marked as unavailable. Then, (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), that is, at the upper left position with respect to the CU picture.
b. Otherwise, x=(xPrevVPDU-64)%192, . ．． , ((xPrevVPDU-64)%192)+63; and y=yPrevVPDU%128, . ．． , (yPrevVPDU%128)+63 location (x,y) is marked as unavailable. Then, (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), that is, at the upper left position with respect to the CU picture.
3) After decoding one CU, x=xCU%192, . ．． ．． , (xCU+CU_width-1)%192 and y=yCU%128, . ．． ．． , (yCU+CU_height-1)%128, the location (x,y) is marked as available.
4) For IBCCU with block vector (xBV, yBV), x=(xCU+xBV)%192, . ．． ．． , (xCU+xBV+CU_width-1)%192 and y=(yCU+yBV)%128, . ．． ．． , (yCU+yBV+CU_height-1)%128, the location (x,y) is marked as unavailable and the block vector is considered invalid.

If the size of the CTU is S×S, then S is not equal to 128, so make Wbuf equal to 128*128/S. A virtual buffer of size WbufxS is maintained to keep track of the IBC reference samples. In this case, the size of the VPDU is equal to the size of the CTU.

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 beginning of decoding one VPDU row, all positions of the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set as (0,0).
2) At the start of decoding of the first CU of a VPDU, x=(xPrevVPDU−W _buf *S)%S, . ．． , ((xPrevVPDU-W _buf *S)%S)+S-1; andy=yPrevVPDU%S, . ．． , (yPrevVPDU%S)+S-1, the location (x,y) is marked as unavailable. Then, (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), that is, at the upper left position with respect to the CU picture.
3) After decoding one CU, x=xCU%(W _buf ), . ．． ．． , (xCU+CU_width-1)%(W _buf ) and y=yCU%S, . ．． ．． , (yCU+CU_height-1)%S, then the location (x,y) is marked as available.
4) For an IBCCU with block vectors (xBV, yBV), x=(xCU+xBV)%(Wbuf), . ．． ．． , (xCU+xBV+CU_width-1)%(Wbuf) and y=(yCU+yBV)%S, . ．． ．． , (yCU+yBV+CU_height-1)%S, the location (x,y) is marked as unavailable and the block vector is considered invalid.

5.14 Embodiment #14

If the CTU size is 128x128, or the CTU size is larger than the VPDU size (e.g., 64x64 in the current design), or the CTU size is larger than the VPDU size (e.g. , in the current design, a virtual buffer of size 256x128 is maintained to track the reference samples for the IBC. Hereinafter, when a<0, (a%b) is defined as floor(a/b)*b, and floor(c) returns the largest integer less than or equal to c.

The sample (x,y) for the top left corner of the picture is associated with the position (x%256, y%128) for the top left corner of the buffer. The following steps show how to mark the availability of samples associated with virtual buffers for IBC reference.

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 beginning of decoding one VPDU row, all positions of the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set as (0,0).
2) At the beginning of the decoding of the first CU of the VPDU,
a. If yPrevVPDU%64 is equal to 0, then x=(xPrevVPDU-128)%256, . ．． , ((xPrevVPDU-128)%256)+63; and y=yPrevVPDU%128, . ．． , (yPrevVPDU%128)+63 location (x,y) is marked as unavailable. Then, (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), that is, at the upper left position with respect to the CU picture.
b. Otherwise, x=(xPrevVPDU-64)%256, . ．． , ((xPrevVPDU-64)%256)+63; and y=yPrevVPDU%128, . ．． , (yPrevVPDU%128)+63 location (x,y) is marked as unavailable. Then, (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), that is, at the upper left position with respect to the CU picture.
3) After decoding one CU, x=xCU%256, . ．． ．． , (xCU+CU_width-1)%256 and y=yCU%128, . ．． ．． , (yCU+CU_height-1)%128, the location (x,y) is marked as available.
4) For IBCCU with block vector (xBV, yBV), x=(xCU+xBV)%256, . ．． ．． , (xCU+xBV+CU_width-1)%256 and y=(yCU+yBV)%128, . ．． ．． , (yCU+yBV+CU_height-1)%128, the location (x,y) is marked as unavailable and the block vector is considered invalid.

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

5.15 Embodiment #15

The IBC reference availability marking process will be explained as follows. This document indicates changes in bold, underlined, or italic type.

ＢｕｆＷｉｄｔｈ は（ＣｔｂＳｉｚｅＹ＝＝１２８）？２５６：（１２８＊１２８／ＣｔｂＳｉｚｅＹ）に等しく、ＢｕｆＨｅｉｇｈｔはＣｔｂＳｉｚｅＹに等しい。

BufWidth is (CtbSizeY==128)? 256: equals (128*128/CtbSizeY) and BufHeight equals CtbSizeY.

7.3.7.5 Coding unit syntax

8.6.2 IBC block motion vector component derivation process

8.6.2.1 General. ．． ．．
It is a requirement for bitstream collaboration performance that isBVvalid is true when the block vector validation process is called on block vector mvL in Section 8.6.3.2.
．． ．． ．．

8.6.3 Ibc block decoding process

8.6.3.1 General

This process is called when decoding a coding unit coded in ibc prediction mode.

The inputs to this process are as follows.
- a luminance position (xCb, yCb) that defines the upper left sample of the current coded block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples;
- variables numSbX and numSbY, which define the number of luminance coding subblocks in the horizontal and vertical directions;
- Motion vector mv[xSbIdx][ySbIdx]withxSbIdx=0. ．． numSbX-1, and ySbIdx=0. ．． numSbY-1,
- the variable cIdx, which defines the color component index of the current block;
- a (nIbcBufW) x (ctbSize) array ibcBuf
．． ．． ．．

xSbIdx=0. ．． numSbX-1, and ySbIdx=0. ．． For each coding subblock with subblock index (xSbIdx, ySbIdx) where numSbY-1, the following applies.
- The luminance position (xSb, ySb) defining the upper left sample of the current encoded subblock relative to the upper left luminance sample of the current picture is derived as follows:
(xSb, ySb) = (xCb+xSbIdx*sbWidth, yCb+ySbIdx*sbHeight) (8-913)

If cIdx is equal to 0, set nIbcBufW to ibcBufferWidth, otherwise set nIbcBufW to (ibcBufferWidth/SubWidthC). The following applies:
predSamples[xSb+x][ySb+y]=ibcBuf[(xSb+x+(mv[xSb][ySb][0]>>4))% nIbcRefW][ySb+y+(mv[xSb][ySb][1]>>4)]with x=0. ．． sbWidth-1 and y=0. ．． sbHeight-1.
．． ．． ．．

8.6.3.2 Block Vector Validation Process The inputs to this process are as follows.
- a luminance position (xCb, yCb) that defines the upper left sample of the current coded block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples;
- variables numSbX and numSbY, which define the number of luminance coding subblocks in the horizontal and vertical directions;
-xSbIdx=0. ．． numSbX-1, and ySbIdx=0. ．． Block vector mv[xSbIdx][ySbIdx] in case of numSbY-1,
- a variable cIdx specifying the color component index of the current block;
- a(nIbcBufW) x (ctbSize) array ibcBuf
The output of this process is a flag isBVvalid to indicate whether the block vector is valid.
The following applies: 1. isBVvalid is set equal to true.
2. If ((yCb &(ctbSize−1)+mv[0][0][1]+cbHeight)>ctbSize, then isBVvalid is set equal to false.
3. Otherwise, xSbIdx=0. ．． numSbX-1, and ySbIdx=0. ．． For each subblock index xSbIdx, ySbIdx that is numSbY-1, derive its position relative to the upper left luminance sample of ibcBuf.
xTL=(xCb+xSbIdx*sbWidth+mv[xSbIdx][ySbIdx][0])&(nIbcBufW-1)
yTL=(yCb&(ctbSize-1))+ySbIdx*sbHeight+mv[xSbIdx][ySbIdx][1]
xBR=(xCb+xSbIdx*sbWidth+sbWidth-1+mv[xSbIdx][ySbIdx][0])&(nIbcBufW-1)
yBR=(yCb & (ctbSize-1))+ySbIdx*sbHeight+sbHeight-1+mv[xSbIdx][ySbIdx][1]
If (isDecoded[xTL>>2][yTL>>2]==0) or (isDecoded[xBR>>2][yTL>>2]==0) or (isDecoded[xBR>>2][yBR>>2]==0), then isBVvalid is set equal to false.

8.7.5 Picture reconstruction processing

8.7.5.1 General

The inputs to this process are as follows.
- 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;
- variables nCurrSw and nCurrSh, which define the width and height of the current block, respectively;
- variable cIdx, which defines the color components of the current block;
- an(nCurrSw)×(nCurrSh) array predSamples, which defines the predicted samples of the current block;
- an(nCurrSw)×(nCurrSh) array defining the residual samples of the current block.

The output of this process is as follows.
- Reconstructed picture sample array recSamples.
- IBC reference array ibcBuf
．． ．． ．．
nIbcBufW indicates the width of ibcBuf, and the following applies.
ibcBuf[(xCurr+i)&(nIbcBufW-1)][(yCurr+j)&(ctbSize-1)]=recSamples[xCurr+i][yCurr+j]
with i=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.

5.16 Embodiment #16

This embodiment is the same as the above embodiment except for the following changes.

ＢｕｆＷｉｄｔｈは（ＣｔｂＳｉｚｅＹ＝＝１２８）？１９２：（１２８＊１２８／ＣｔｂＳｉｚｅＹ）に等しく、ＢｕｆＨｅｉｇｈｔはＣｔｂＳｉｚｅＹに等しい。

BufWidth is (CtbSizeY==128)? 192: equals (128*128/CtbSizeY), BufHeight equals CtbSizeY.

5.17 Embodiment #17

Changes in some examples are indicated herein with bold, underlined text.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

7.4.8.5 Coding unit syntax

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

x=x0. ．． x0+cbWidth-1 and y=y0. ．． The following allocation is made to y0+cbHeight-1.
CbPosX[x][y]=x0 (7-135)
CbPosY[x][y]=y0 (7-136)
CbWidth[x][y]=cbWidth (7-137)
CbHeight[x][y]=cbHeight (7-138)
Let vSize be min(ctbSize, 64), and wIbcBuf be (128*128/ctbSize). The width and height of ibcBuf follows wIbcBuf and ctbSize.
If refresHIbcBuf is equal to 1, the following applies.
-ibcBuf[x%wIbcBuf][y%ctbSize]=-1, for x=x0. ．． x0+wIbcBuf-1 and y=y0. ．． y0+ctbSize-1
-resetIbcBuf=0
When (x0 % vSize) is equal to 0 and (y0 % vSize) is equal to 0, provided that x=x0. ．． x0+vSize-1 and y=y0. ．． y0+vSize -1, but the following applies.
ibcBuf[x%wIbcBuf][y%ctbSize]=-1

8.6.2 IBC block motion vector component derivation process

8.6.2.1 General

The inputs to this process are as follows.
- the luminance position (xCb, yCb) of the upper left sample of the current luminance coding block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- the variable cbHeight, which defines the height of the current coded block in luminance samples;

The output of this process is as follows.
- Luminance motion vector at 1/16 fractional sample precision mvL.

The luminance motion vector mvL is derived as follows.
- The IBC luminance motion vector prediction derivation process specified in Section 8.6.2.2 is called with the luminance position (xCb, yCb), variables cbWidth and cbHeight as input, 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 uses as input the mvX set equal to mvL, the rightShift set equal to MvShift+2, and the leftShift set equal to MvShift+2. is called, and the output is a rounded mvL.
3. The luminance motion vector mvL is modified as follows.
u[0]=(mvL[0]+mvd[0]+2 ¹⁸ )% 2 ¹⁸ (8-885)
mvL[0]=(u[0]>=2 ¹⁷ )? (u[0]-2 ¹⁸ ):u[0](8-886)
u[1]=(mvL[1]+mvd[1]+2 ¹⁸ )% 2 ¹⁸ (8-887)
mvL[1]=(u[1]>=2 ¹⁷ )? (u[1]-2 ¹⁸ ): u[1] (8-888)
Note 1 - The resulting values of mvL[0] and mvL[1] specified above are always in the range of -2 ¹⁷ to 2 ¹⁷ -1.

The history-based motion vector predictor list update process as defined in Section 8.6.2.6 is invoked using the luminance motion vector mvL.
It is a requirement of bitstream conformance that the luminance block vector mvL should obey the following constraints.
−(((yCb+(mvL[1]>4))% wIbcBuf)+cbHeight is less than or equal to ctbSize.
-x=xCb. ．． xCb+cbWidth-1 and y=yCb. ．． For yCb+cbHeight-1, ibcBuf[(x+(mvL[0]>>4))% wIbcBuf][(y+(mvL[1]>>4))% ctbSize] is not equal to -1.

8.7.5 Picture reconstruction processing

8.7.5.1 General

The inputs to this process are as follows.
- 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;
- variables nCurrSw and nCurrSh, which define the width and height of the current block, respectively;
- variable cIdx, which defines the color components of the current block;
- an(nCurrSw)×(nCurrSh) array predSamples, which defines the predicted samples of the current block;
- an(nCurrSw)×(nCurrSh) array defining the residual samples of the current block.

The output of this process is a reconstructed picture sample array recSamples and an IBC buffer array ibcBuf.

The following assignment is made based on the value of the color component cIdx.
- If cIdx is equal to 0, recSamples corresponds to the reconstructed picture sample array S _L and the function clipCidx1 corresponds to Clip1 _Y.
- Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array SCb, and function clipCidx1 corresponds to Clip1 _C.
- Otherwise (cIdx equals 2), set tuCbfChroma equal to tu_cbf_cr[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array SCr, and function clipCidx1 corresponds to Clip1 _C.

Depending on the value of slice_lmcs_enabled_flag, the following applies.
- If slice_lmcs_enabled_flag is equal to 0, then the (nCurrSw) × (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr) has i=0. ．． nCurrSw-1,j=0. ．． For nCurrSh-1, it is derived as follows.
recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992)
- Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:
- If cIdx is equal to 0, the following applies:
- Picture reconstruction involving the mapping process of luminance samples as specified in Section 8.7.5.2 is performed using the luminance position (xCurr, yCurr), block width nCurrSw and height nCurrSh, predicted luminance sample array preSamples, and It is called with the residual luminance sample array resSamples as input, and the output is the reconstructed luminance sample array reCamples.
- In other cases (when cIdx is greater than 0), picture reconstruction by luminance-dependent chroma residual scaling processing of chroma samples specified in Section 8.7.5.3 is performed at the chroma position (xCurr, yCurr), width nCurrSw and height nCurrSh of the transform block, encoding block flag tuCbfChroma of the current chroma transform block, predicted chroma sample array predSamples, and reconstructed chroma sample array called with the residual chroma sample array resSamples as input. The output is recSamples.

After decoding the current coding unit, the following applies.
ibcBuf[(xCurr+i)% wIbcBuf][(yCurr+j)% ctbSize]
=recSamples[xCurr+i][yCurr+j]
for i=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.

5.18 Embodiment #18

Changes in some examples are shown herein in bold, underlined, or italic type.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

7.4.8.5 Coding unit syntax

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

x=x0. ．． x0+cbWidth-1 and y=y0. ．． The following allocation is made to y0+cbHeight-1.
CbPosX[x][y]=x0 (7-135)
CbPosY[x][y]=y0 (7-136)
CbWidth[x][y]=cbWidth (7-137)
CbHeight[x][y]=cbHeight (7-138)

Set vSize to min(ctbSize, 64) and wIbcBufY to (128*128/CtbSizeY).
ibcBuf _L is an array with a width of wIbcBufY and a height of CtbSizeY.
ibcBuf _Cb and ibcBuf _Cr are arrays with width wIbcBufC=(wIbcBufY/SubWidthC) and height (CtbSizeY/SubHeightC), ie, CtbSizeC.

If resetIbcBuf is equal to 1, the following applies.
- ibcBuf _L [x % wIbcBufY] [y % CtbSizeY] = -1, for x = x0. ．． x0+wIbcBufY-1 and y=y0. ．． y0+CtbSizeY-1
- ibcBuf _Cb [x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0. ．． x0+wIbcBufC-1 and y=y0. ．． y0+CtbSizeC -1
- ibcBuf _Cr [x% wIbcBufC] [y% CtbSizeC]=-1, for x=x0. ．． x0+wIbcBufC-1 and y=y0. ．． y0+CtbSizeC-1
- resetIbcBuf=0

If (x0 % vSizeY) is equal to 0 and (y0 % vSizeY) is equal to 0, then the following applies.
- ibcBuf _L [x% wIbcBufY] [y% CtbSizeY]=-1, for x=x0. ．． x0+vSize -1 and y=y0. ．． y0+vSize -1
- ibcBuf _Cb [ x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0/SubWidthC. ．． x0/SubWidthC+vSize/SubWidthC-1 and y=y0/SubHeightC. ．． y0/SubHeightC+vSize/SubHeightC-1
- ibcBuf _Cr [x% wIbcBufC][y% CtbSizeC]=-1, for x=x0/SubWidthC. ．． x0/SubWidthC+vSize/SubWidthC-1 and y=y0/SubHeightC. ．． y0/SubHeightC+vSize/SubHeightC-1

8.6.2 IBC block motion vector component derivation process

8.6.2.1 General

The inputs to this process are as follows.
- the luminance position (xCb, yCb) of the upper left sample of the current luminance coding block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples.

The output of this process is as follows.
- Luminance motion vector at 1/16 fractional sample precision mvL.

The luminance motion vector mvL is derived as follows.
- The IBC luminance motion vector prediction derivation process specified in Section 8.6.2.2 is called with the luminance position (xCb, yCb), variables cbWidth and cbHeight as input, and its output is the luminance motion vector mvL. .
- If general_merge_flag[xCb][yCb] is equal to 0, the following applies:
4. The variable mvd is derived as follows.
mvd[0]=MvdL0[xCb][yCb][0] (8-883)
mvd[1]=MvdL0[xCb][yCb][1] (8-884)
5. The motion vector rounding process as specified in Section 8.5.2.14 uses as input an mvX set equal to mvL, a rightShift set equal to MvShift+2, and a leftShift set equal to MvShift+2. is called, and the output is a rounded mvL.
6. The luminance motion vector mvL is modified as follows.
u[0]=(mvL[0]+mvd[0]+2 ¹⁸ )% 2 ¹⁸ (8-885)
mvL[0]=(u[0]>=2 ¹⁷ )? (u[0]-2 ¹⁸ ):u[0] (8-886)
u[1]=(mvL[1]+mvd[1]+2 ¹⁸ )% 2 ¹⁸ (8-887)
mvL[1]=(u[1]>=2 ¹⁷ )? (u[1]-2 ¹⁸ ):u[1] (8-888)
Note 1 - The resulting values of mvL[0] and mvL[1] specified above are always in the range -2 ¹⁷ to 2 ¹⁷ -1.

The history-based motion vector predictor list update process as defined in Section 8.6.2.6 is invoked using the luminance motion vector mvL.

Section 8.6.2.5 is called with mvL as input and mvC as output.
It is a requirement of bitstream conformance that the luminance block vector mvL should obey the following constraints.
- (((yCb+(mvL[1]>4))% CtbSizeY)+cbHeight is less than or equal to CtbSizeY.
- x=xCb. ．． xCb+cbWidth-1 and y=yCb. ．． For yCb+cbHeight-1, ibcBuf _L [(x+(mvL[0]>>4))% wIbcBufY][(y+(mvL[1]>>4))% CtbSizeY] cannot be equal to -1.
- If treeType is equal to SINGLE_TREE, then x=xCb. ．． xCb+cbWidth-1 and y=yCb. ．． For yCb+cbHeight-1, ibcBuf _Cb [(x+(mvC[0]>5))% wIbcBufC][(y+(mvC[1]>>5))% CtbSizeC]] is not equal to -1. It won't happen.

8.6.3 IBC block decoding process

8.6.3.1 General

This process is called when decoding a coding unit coded in ibc prediction mode.

The inputs to this process are as follows.
- a luminance position (xCb, yCb) that defines the upper left sample of the current coded block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples;
- the color component index of the current block,
- motion vector mv,
- an(wIbcBufY)×(CtbSizeY) array ibcBuf _L , an(wIbcBufC)×(CtbSizeC) array ibcBuf _Cb , an(wIbcBufC)×(CtbSizeC) array ibcB _ufCr .

The output of this process is as follows.
- an array of predicted samples predSamples;

x=xCb. ．． xCb+Width-1 and y=yCb. ．． For yCb+Height-1, the following applies if cIdx equals 0 predSamples[x][y]=ibcBuf _L [(x+mv[0]>>4))% wIbcBufY][(y+(mv[1]>>4))% CtbSizeY]
If cIdx is equal to 1, predSamples[x][y]=ibcBuf _Cb [(x+mv[0]>>5))% wIbcBufC] [(y+(mv[1]>>5))% CtbSizeC]
If cIdx is equal to 2, predSamples[x][y]=ibcBuf _Cr [(x+mv[0]>>5))% wIbcBufC] [(y+(mv[1]>>5))% CtbSizeC]

8.7.5 Picture reconstruction processing

8.7.5.1 General

The inputs to this process are as follows.
- 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;
- variables nCurrSw and nCurrSh, which define the width and height of the current block, respectively;
- variable cIdx, which defines the color components of the current block;
- an(nCurrSw)×(nCurrSh) array predSamples, which defines the predicted samples of the current block;
- an(nCurrSw)×(nCurrSh) array defining the residual samples of the current block.

The output of this process is a reconstructed picture sample array recSamples and IBC buffer arrays ibcBuf _L , ibcBuf _Cb , ibcBuf _Cr .

The following assignment is made based on the value of the color component cIdx.
- If cIdx is equal to 0, recSamples corresponds to the reconstructed picture sample array S _L and the function clipCidx1 corresponds to Clip1 _Y.
- Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S _Cb , and function clipCidx1 corresponds to Clip1 _C.
- otherwise (if cIdx is equal to 2, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S _Cb , and function clipCidx1 corresponds to Clip1 _C .

Depending on the value of slice_lmcs_enabled_flag, the following applies.
- If slice_lmcs_enabled_flag is equal to 0, then the (nCurrSw) x (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr) has i=0. ．． nCurrSw-1,j=0. ．． For nCurrSh-1, it is derived as follows.
recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992)
- Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:
- If cIdx is equal to 0, the following applies:
- Picture reconstruction involving the mapping process of luminance samples as specified in Section 8.7.5.2 is performed using the luminance position (xCurr, yCurr), block width nCurrSw and height nCurrSh, predicted luminance sample array preSamples, and It is called with the residual luminance sample array resSamples as input, and the output is the reconstructed luminance sample array reCamples.
- In other cases (when cIdx is greater than 0), picture reconstruction by luminance-dependent chroma residual scaling processing of chroma samples specified in Section 8.7.5.3 is performed at the chroma position (xCurr, yCurr), the width nCurrSw and height nCurrSh of the transform block, the encoding block flag tuCbfChroma of the current chroma transform block, the predicted chroma sample array predSamples, and the residual chroma sample array resSamples, and the reconstructed chroma sample array is called as input. The output is recSamples.

After decoding the current coding unit, the following can be applied.
If cIdx is equal to 0 and treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, the following applies.
ibcBuf _L [(xCurr+i)% wIbcBufY] [(yCurr+j)% CtbSizeY]=recSamples[xCurr+i][yCurr+j]
for i=0. ．． nCurrSw-1, j=0. ．． nCurrSh-1.
If cIdx is equal to 1 and treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, the following applies.
ibcBuf _Cb [(xCurr+i)% wIbcBufC] [(yCurr+j)% CtbSizeC] = recSamples[xCurr+i] [yCurr+j]
for i=0. ．． nCurrSw-1, j=0. ．． nCurrSh-1.
If cIdx is equal to 2 and treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies.
ibcBuf _Cr [(xCurr+i)% wIbcBufC] [(yCurr+j)% CtbSizeC] = recSamples[xCurr+i] [yCurr+j]
for i=0. ．． nCurrSw-1, j=0. ．． nCurrSh-1.

5.19 Embodiment #19

Changes in some examples are indicated herein with bold, underlined text.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

7.4.8.5 Coding unit syntax

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

x=x0. ．． x0+cbWidth-1 and y=y0. ．． The following allocation is made to y0+cbHeight-1.
CbPosX[x][y]=x0 (7-135)
CbPosY[x][y]=y0 (7-136)
CbWidth[x][y]=cbWidth (7-137)
CbHeight[x][y]=cbHeight (7-138)

Set vSize to min(ctbSize, 64) and wIbcBufY to (128*128/CtbSizeY).
ibcBuf _L is an array with a width of wIbcBufY and a height of CtbSizeY.
ibcBuf _Cb and ibcBuf _Cr are arrays with width wIbcBufC=(wIbcBufY/SubWidthC) and height (CtbSizeY/SubHeightC), ie, CtbSizeC.
If resetIbcBuf is equal to 1, the following applies.
- ibcBuf _L [x % wIbcBufY] [y % CtbSizeY] = -1, for x = x0. ．． x0+wIbcBufY-1 and y=y0. ．． y0+CtbSizeY-1
- ibcBuf _Cb [x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0. ．． x0+wIbcBufC-1 and y=y0. ．． y0+CtbSizeC-1
- ibcBuf _Cr [x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0. ．． x0+wIbcBufC-1 and y=y0. ．． y0+CtbSizeC-1
- resetIbcBuf=0
If (x0 % vSizeY) is equal to 0 and (y0 % vSizeY) is equal to 0, then the following applies.
- ibcBuf _L [x% wIbcBufY][y% CtbSizeY]=-1, for x=x0. ．． x0+min(vSize, cbWidth)-1 and y=y0. ．． y0+min(vSize, cbHeight)-1
- ibcBuf _Cb [ x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0/SubWidthC. ．． x0/SubWidthC+min(vSize/SubWidthC, cbWidth)-1 and y=y0/SubHeightC. ．． y0/SubHeightC+min(vSize/SubHeightC, cbHeight)-1
- ibcBuf _Cr [x% wIbcBufC][y% CtbSizeC]=-1, for x=x0/SubWidthC. ．． x0/SubWidthC+min(vSize/SubWidthC, cbWidth)-1 and y=y0/SubHeightC. ．． y0/SubHeightC+min(vSize/SubHeightC, cbHeight)-1

8.6.2 IBC block motion vector component derivation process

8.6.2.1 General

The inputs to this process are as follows.
- the luminance position (xCb, yCb) of the upper left sample of the current luminance coding block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples.

The output of this process is as follows.
- Luminance motion vector at 1/16 fractional sample precision mvL.

The luminance motion vector mvL is derived as follows.
- The IBC luminance motion vector prediction derivation process specified in Section 8.6.2.2 is called with the luminance position (xCb, yCb), variables cbWidth and cbHeight as input, and its output is the luminance motion vector mvL. .
- If general_merge_flag[xCb][yCb] is 0, the following applies 7. The variable mvd is derived as follows.
mvd[0]=MvdL0[xCb][yCb][0] (8-883)
mvd[1]=MvdL0[xCb][yCb][1] (8-884)
8. The motion vector rounding process as specified in Section 8.5.2.14 uses as input an mvX set equal to mvL, a rightShift set equal to MvShift+2, and a leftShift set equal to MvShift+2. is called, and the output is a rounded mvL.
9. The luminance motion vector mvL is modified as follows.
u[0]=(mvL[0]+mvd[0]+2 ¹⁸ )% 2 ¹⁸ (8-885)
mvL[0]=(u[0]>=2 ¹⁷ )? (u[0]-2 ¹⁸ ):u[0] (8-886)
u[1]=(mvL[1]+mvd[1]+2 ¹⁸ )% 2 ¹⁸ (8-887)
mvL[1]=(u[1]>=2 ¹⁷ )? (u[1]-2 ¹⁸ ): u[1] (8-888)
Note 1 - The resulting values of mvL[0] and mvL[1] specified above are always in the range -2 ¹⁷ to 2 ¹⁷ -1.

The history-based motion vector predictor list update process as defined in Section 8.6.2.6 is invoked using the luminance motion vector mvL.
Section 8.6.2.5 is called with mvL as input and mvC as output.
It is a requirement of bitstream conformance that the luminance block vector mvL should obey the following constraints.
- (((yCb+(mvL[1]>4))% CtbSizeY)+cbHeight is less than or equal to CtbSizeY.
- x=xCb. ．． xCb+cbWidth-1 and y=yCb. ．． For yCb+cbHeight-1, ibcBufL[(x+(mvL[0]>>4))% wIbcBufY][(y+(mvL[1]>>4))% CtbSizeY] cannot be equal to -1.
- if treeType is equal to SINGLE_TREE, then x=xCb. ．． xCb+cbWidth-1 and y=yCb. ．． For yCb+cbHeight-1, ibcBuf _Cb [(x+(mvC[0]>5))%wIbcBufC][(y+(mvC[1]>>5))%CtbSizeC]] must not be equal to -1 .

8.6.3 Ibc block decoding process

8.6.3.1 General

This process is called when decoding a coding unit coded in ibc prediction mode.

The inputs to this process are as follows.
- a luminance position (xCb, yCb) that defines the upper left sample of the current coded block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples;
- a variable cIdx specifying the color component index of the current block;
- ・Motion vector mv,
- an (wIbcBufY) x (CtbSizeY) array ibcBuf _L , an (wIbcBufC) x (CtbSizeC) array ibcBuf _Cb , an (wIbcBufC) x (CtbSizeC) array ibcB _ufCr .

The output of this process is as follows.
- array of predicted samples predSamples

x=xCb. ．． xCb+Width-1 and y=yCb. ．． If yCb+Height-1, then the following applies If cIdx is equal to 0 then predSamples[x][y]=ibcBuf _L [(x+mv[0]>>4))% wIbcBufY][(y+(mv[1] >>4))% CtbSizeY]
If cIdx is equal to 1 then predSamples[x][y]=ibcBuf _Cb [(x+mv[0]>>5))% wIbcBufC] [(y+(mv[1]>>5))% CtbSizeC]
If cIdx is equal to 2, predSamples[x][y]=ibcBuf _Cr [(x+mv[0]>>5))% wIbcBufC] [(y+(mv[1]>>5))% CtbSizeC]

8.7.5 Picture reconstruction processing

8.7.5.1 General

The inputs to this process are as follows.
- 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;
- variables nCurrSw and nCurrSh, which define the width and height of the current block, respectively;
- variable cIdx, which defines the color components of the current block;
- an(nCurrSw)×(nCurrSh) array predSamples, which defines the predicted samples of the current block;
- an(nCurrSw)×(nCurrSh) array defining the residual samples of the current block.

The output of this process is a reconstructed picture sample array recSamples and IBC buffer arrays ibcBuf _L , ibcBuf _Cb , ibcBuf _Cr .

The following assignment is made based on the value of the color component cIdx.
- If cIdx is equal to 0, recSamples corresponds to the reconstructed picture sample array SL and the function clipCidx1 corresponds to Clip1 _Y.
- Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S _Cb , and function clipCidx1 corresponds to Clip1 _C.
- otherwise (if cIdx is equal to 2, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S _Cr , and function clipCidx1 corresponds to Clip1 _C .

Depending on the value of slice_lmcs_enabled_flag, the following applies.
- If slice_lmcs_enabled_flag is equal to 0, then the (nCurrSw) × (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr) is set to i=0. ．． nCurrSw-1,j=0. ．． For nCurrSh-1, it is derived as follows.
recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992)
- Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:
- If cIdx is equal to 0, the following applies:
- Picture reconstruction involving the mapping process of luminance samples as specified in Section 8.7.5.2 is performed using the luminance position (xCurr, yCurr), block width nCurrSw and height nCurrSh, predicted luminance sample array preSamples, and It is called with the residual luminance sample array resSamples as input, and the output is the reconstructed luminance sample array reCamples.
In other cases (when cIdx is greater than 0), picture reconstruction by luminance-dependent chroma residual scaling processing of chroma samples specified in Section 8.7.5.3 is performed at the chroma position (xCurr, yCurr ), the width nCurrSw and height nCurrSh of the transform block, the encoding block flag tuCbfChroma of the current chroma transform block, the predicted chroma sample array predSamples, and the residual chroma sample array resSamples, and the reconstructed chroma sample array recSamples is called. Let be the output.

After decoding the current coding unit, the following can be applied.
If cIdx is equal to 0 and treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, the following applies.
ibcBuf _L [(xCurr+i)% wIbcBufY] [(yCurr+j)% CtbSizeY]=recSamples[xCurr+i][yCurr+j]
for i=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.
If cIdx is equal to 1 and treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, the following applies.
ibcBuf _Cb [(xCurr+i)% wIbcBufC] [(yCurr+j)% CtbSizeC] = recSamples[xCurr+i] [yCurr+j]
for i=0. ．． nCurrSw-1, j=0. ．． nCurrSh-1.
If cIdx is equal to 2 and treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies.
ibcBuf _Cr [(xCurr+i)% wIbcBufC] [(yCurr+j)% CtbSizeC] = recSamples[xCurr+i] [yCurr+j]
for i=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.

5.20 Embodiment #20

Changes in some examples are shown herein in bold, underlined, or italic type.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

7.4.8.5 Coding unit syntax

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

x=x0. ．． x0+cbWidth-1 and y=y0. ．． The following allocation is made to y0+cbHeight-1.
CbPosX[x][y]=x0 (7-135)
CbPosY[x][y]=y0 (7-136)
CbWidth[x][y]=cbWidth (7-137)
CbHeight[x][y]=cbHeight (7-138)

Set vSize to min(ctbSize, 64) and wIbcBufY to (128*128/CtbSizeY).
ibcBuf _L is an array with a width of wIbcBufY and a height of CtbSizeY.
ibcBuf _Cb and ibcBuf _Cr are arrays with width wIbcBufC=(wIbcBufY/SubWidthC) and height (CtbSizeY/SubHeightC), ie, CtbSizeC.
If resetIbcBuf is equal to 1, the following applies.
- ibcBuf _L [x% wIbcBufY] [y % CtbSizeY] = -1, for x = x0. ．． x0+wIbcBufY-1 and y=y0. ．． y0+CtbSizeY-1
- ibcBuf _Cb [x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0. ．． x0+wIbcBufC-1 and y=y0. ．． y0+CtbSizeC-1
- ibcBuf _Cr [x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0. ．． x0+wIbcBufC-1 and y=y0. ．． y0+CtbSizeC-1
- resetIbcBuf=0

If (x0 % vSizeY) is equal to 0 and (y0 % vSizeY) is equal to 0, then the following applies.
- ibcBuf _L [x % wIbcBufY] [y % CtbSizeY] = -1, for x = x0. ．． x0+max(vSize, cbWidth)-1 and y=y0. ．． y0+max(vSize,cbHeight)-1
- ibcBuf _Cb [x % wIbcBufC] [y % CtbSizeC]=-1, for x=x0/SubWidthC. ．． x0/SubWidthC+max(vSize/SubWidthC, cbWidth)-1 and y=y0/SubHeightC. ．． y0/SubHeightC+max(vSize/SubHeightC, cbHeight)-1
- ibcBuf _Cr [x % wIbcBufC] [y % CtbSizeC] = -1, for x = x0/SubWidthC. ．． x0/SubWidthC+max(vSize/SubWidthC, cbWidth)-1 and y=y0/SubHeightC. ．． y0/SubHeightC+max(vSize/SubHeightC, cbHeight)-1

8.6.2 IBC block motion vector component derivation process

8.6.2.1 General

The inputs to this process are as follows.
- the luminance position (xCb, yCb) of the upper left sample of the current luminance coding block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples.

The output of this process is as follows.
- Luminance motion vector at 1/16 fractional sample precision mvL.

The luminance motion vector mvL is derived as follows.
- The IBC luminance motion vector prediction derivation process specified in Section 8.6.2.2 is called with the luminance position (xCb, yCb), variables cbWidth and cbHeight as input, and its output is the luminance motion vector mvL. .
- If general_merge_flag[xCb][yCb] is equal to 0, the following applies 10. The variable mvd is derived as follows.
mvd[0]=MvdL0[xCb][yCb][0] (8-883)
mvd[1]=MvdL0[xCb][yCb][1] (8-884)
11. The motion vector rounding process as specified in Section 8.5.2.14 uses as input an mvX set equal to mvL, a rightShift set equal to MvShift+2, and a leftShift set equal to MvShift+2. is called, and the output is a rounded mvL.
12. The luminance motion vector mvL is modified as follows.
u[0]=(mvL[0]+mvd[0]+2 ¹⁸ )% 2 ¹⁸ (8-885)
mvL[0]=(u[0]>=2 ¹⁷ )? (u[0]-2 ¹⁸ ):u[0] (8-886)
u[1]=(mvL[1]+mvd[1]+2 ¹⁸ )% 2 ¹⁸ (8-887)
mvL[1]=(u[1]>=2 ¹⁷ )? (u[1]-2 ¹⁸ ): u[1] (8-888)
Note 1 - The resulting values of mvL[0] and mvL[1] specified above are always in the range -2 ¹⁷ to 2 ¹⁷ -1.

The history-based motion vector predictor list update process as defined in Section 8.6.2.6 is invoked using the luminance motion vector mvL.

Section 8.6.2.5 is called with mvL as input and mvC as output.
It is a requirement of bitstream conformance that the luminance block vector mvL should obey the following constraints.
- (((yCb+(mvL[1]>4))% CtbSizeY)+cbHeight is less than or equal to CtbSizeY.
- x=xCb. ．． xCb+cbWidth-1 and y=yCb. ．． For yCb+cbHeight-1, ibcBufL[(x+(mvL[0]>>4))% wIbcBufY][(y+(mvL[1]>>4))% CtbSizeY] cannot be equal to -1.

8.6.3 Ibc block decoding process

8.6.3.1 General

This process is called when decoding a coding unit coded in ibc prediction mode.

The inputs to this process are as follows.
- a luminance position (xCb, yCb) that defines the upper left sample of the current coded block relative to the upper left luminance sample of the current picture;
- variable cbWidth, which defines the width of the current coding block in luminance samples;
- variable cbHeight, which defines the height of the current coded block in luminance samples;
- a variable cIdx specifying the color component index of the current block;
- motion vector mv
- an(wIbcBufY)×(CtbSizeY) array ibcBuf _L , an(wIbcBufC)×(CtbSizeC) array ibcBuf _Cb , an(wIbcBufC)×(CtbSizeC) array ib _cBufCr .

The output of this process is as follows.
- an array of predicted samples predSamples;

x=xCb. ．． xCb+Width-1 and y=yCb. ．． If yCb+Height-1, then the following applies if cIdx is equal to 0 predSamples[x][y]=ibcBufL[(x+mv[0]>>4))% wIbcBufY][(y+(mv[1]>>4))% CtbSizeY]
If cIdx is equal to 1, predSamples[x][y]=ibcBufCb[(x+mv[0]>>5))% wIbcBufC][(y+(mv[1]>>5))% CtbSizeC]
If cIdx is equal to 2, predSamples[x][y]=ibcBufCr[(x+mv[0]>>5))%wIbcBufC][(y+(mv[1]>>5))%CtbSizeC]

8.7.5 Picture reconstruction processing

8.7.5.1 General

The inputs to this process are as follows.
- 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;
- variables nCurrSw and nCurrSh, which define the width and height of the current block, respectively;
- variable cIdx, which defines the color components of the current block;
- an(nCurrSw)×(nCurrSh) array predSamples, which defines the predicted samples of the current block;
- an(nCurrSw)×(nCurrSh) array defining the residual samples of the current block.

The output of this process is a reconstructed picture sample array recSamples and IBC buffer arrays ibcBuf _L , ibcBuf _Cb , ibcBuf _Cr .

The following assignment is made based on the value of the color component cIdx.
- If cIdx is equal to 0, recSamples corresponds to the reconstructed picture sample array S _L and the function clipCidx1 corresponds to Clip1 _Y.
- Otherwise, if cIdx is equal to 1, tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S _Cb , and function clipCidx1 corresponds to Clip1 _C.
- otherwise (if cIdx is equal to 2, then tuCbfChroma is set equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S _Cb , and function clipCidx1 corresponds to Clip1 _C .

Depending on the value of slice_lmcs_enabled_flag, the following applies.
- If slice_lmcs_enabled_flag is equal to 0, then the (nCurrSw) x (nCurrSh) block of reconstructed samples recSamples at position (xCurr, yCurr) has i=0. ．． nCurrSw-1,j=0. ．． For nCurrSh-1, it is derived as follows.
recSamples[xCurr+i][yCurr+j]=clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992)
- Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:
- If cIdx is equal to 0, the following applies:
- Picture reconstruction involving the mapping process of luminance samples as specified in Section 8.7.5.2 is performed using the luminance position (xCurr, yCurr), block width nCurrSw and height nCurrSh, predicted luminance sample array preSamples, and It is called with the residual luminance sample array resSamples as input, and the output is the reconstructed luminance sample array reCamples.
- In other cases (when cIdx is greater than 0), picture reconstruction by luminance-dependent chroma residual scaling processing of chroma samples specified in Section 8.7.5.3 is performed at the chroma position (xCurr, yCurr), the width nCurrSw and height nCurrSh of the transform block, the encoding block flag tuCbfChroma of the current chroma transform block, the predicted chroma sample array predSamples, and the residual chroma sample array resSamples, and the reconstructed chroma sample array is called as input. The output is recSamples.

After decoding the current coding unit, the following can be applied.
If cIdx is equal to 0 and treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, the following applies.
ibcBuf _L [(xCurr+i)% wIbcBufY] [(yCurr+j)% CtbSizeY]=recSamples[xCurr+i][yCurr+j]
for i=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.
If cIdx is equal to 1 and treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, the following applies.
ibcBuf _Cb [(xCurr+i)% wIbcBufC] [(yCurr+j)% CtbSizeC] = recSamples[xCurr+i] [yCurr+j]
fori=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.
If cIdx is equal to 2 and treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies.
ibcBuf _Cr [(xCurr+i)% wIbcBufC] [(yCurr+j)% CtbSizeC] = recSamples[xCurr+i] [yCurr+j]
fori=0. ．． nCurrSw-1,j=0. ．． nCurrSh-1.

FIG. 6 is a flowchart illustrating an example method of 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 copy encoding mode for converting between the current video block and a bitstream representation of the current video block. (602) and performing the transformation (604) using reference samples stored in the buffer.

The following sections describe some example preferred features implemented by embodiments of method 600 and other methods. Additional examples are provided in Section 4 herein.

1. Determine the buffer size for storing reference samples for the current video block using intra block copy encoding mode for converting between the current video block and a bitstream representation of the current video block. and performing the transformation using the reference samples stored in the buffer.

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

3. 3. The method according to any of clauses 1 to 2, wherein the size is M×N, and M and N are integers.

4. 4. The method of clause 3, wherein MxN is equal to 64x64 or 128x128 or 64x128.

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

6. 2. The method of claim 1, wherein the buffer size is equal to the size of a virtual pipeline data unit used for the conversion.

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

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

9. 9. A method according to any of the preceding clauses, wherein the size of the buffer is different for luminance component reference samples and chroma component reference samples.

10. A method according to any of the preceding clauses, wherein the size of the buffer depends on the chroma subsampling format of the current video block.

11. 9. A method according to any of the preceding clauses, wherein the reference samples are stored in RGB format.

12. 12. A method according to any of the preceding clauses, wherein the buffer is used to store reconstructed samples before and after loop filtering.

13. 13. The method of clause 12, wherein loop filtering comprises deblocking filtering, or adaptive loop filtering (ALF), or sample adaptive offset (SAO) filtering.

14. For conversion between the current video block and the bitstream representation of the current video block, for the current video block using an intra block copy encoding mode using the initial value of the reference sample. and performing the transformation using the reference samples stored in the buffer.

15. 15. The method of clause 14, wherein the initial value corresponds to a constant.

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

17. 16. The method of claim 15, wherein the constant corresponds to an intermediate gray value.

18. 15. The method of clause 14, wherein the initial value corresponds to a pixel value of a previously decoded video block.

19. 19. The method of clause 18, wherein the pre-decoded video block corresponds to the decoded block before in-loop filtering.

20. A method according to any of paragraphs 14 to 19, wherein the buffer size is as described in one of paragraphs 1 to 13.

21. 21. A method according to any of the preceding clauses, wherein x and y numbers are used to address pixel locations within the buffer.

22. Addressing pixel locations within the buffer 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, the first to 21. The method according to any one of Item 20.

23. The current bitstream representation includes a block vector for the transformation, where the block vector denoted as (BVx, BVy) is equal to (x-x0, y-y0) and (x0, y0) is 21. A method according to any of the preceding clauses, corresponding to a top left position of a coding tree unit of the current video block.

24. The current bitstream representation includes a block vector for the transformation, where the block vector denoted as (BVx, BVy) is equal to (x-x0+Tx,y-y0+Ty), where (x0,y0) is 21. The method according to any of the preceding clauses, corresponding to the top left position of the coding tree unit of the current video block, and Tx and Ty are offset values.

25. 25. The method of clause 24, wherein Tx and Ty are predefined offset values.

26. During the transformation, for a pixel located at position (x0, y0) and having block vector (BVx, BVy), the corresponding reference in the buffer is found at reference position (x0+BVx, y0+BVy). The method described in any of the paragraphs.

27. 27. The method of clause 26, wherein if the reference position is outside the buffer, the reference in the buffer is determined by clipping at the boundaries of the buffer.

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

29. During the transformation, for a pixel at position (x0, y0) and having block vector (BVx, BVy), the corresponding reference in the buffer is set to reference position ((x0+BVx) mod M, (y0+BVy) mod N) 21. The method of clauses 1-20, wherein "mod" is a modulo operation, and M and N are integers representing x and y dimensions of the buffer.

30. Resetting a buffer that stores reference samples for intra-block copy encoding at video boundaries and the reference samples stored in this buffer during conversion between the video and the bitstream representation of the current video block; Performing this conversion using a video processing method, including;

31. 31. The method of clause 30, wherein the video boundary corresponds to a new picture or a new tile.

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

33. 31. The method of clause 30, wherein the transformation is performed by updating the buffer with reconstructed values of encoding tree units after the reset.

34. 31. The method of clause 30, wherein the resetting is performed at the beginning of each coding tree unit row.

35. 2. The method of claim 1, wherein the size of the buffer corresponds to L 64x64 pre-decoded blocks, where L is an integer.

36. 36. A method according to any of the preceding clauses, wherein a vertical scan order is used to read or store samples in the buffer during the conversion.

37. A buffer for storing reference samples for the current video block using intra block copy encoding mode for conversion between the current video block and the bitstream representation of the current video block. using the reference samples stored in the buffer, wherein a first bit depth of the buffer is different from a second bit depth of the encoded data; and performing the conversion using a video processing method.

38. 38. The method of clause 37, wherein the first bit depth is greater than the second bit depth.

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

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

41. 41. A method according to any of clauses 37-40, wherein the conversion uses different bit depths for chroma and luminance components.

Additional embodiments and examples from Sections 37 to 41 are described in Section 7 of Chapter 4.

42. converting between a current video block and a bitstream representation of the current video block using an intra-block copy mode, the first precision used for predictive calculations during the conversion being A video processing method that is less accurate than a second precision used for reconstruction calculations during the transformation.

43. The prediction calculation uses clip {{p+[1<<(b-1)]}>>b, 0, (1<<bitdepth)-1}<<b to calculate the predicted sample from the reconstructed sample value. 44. The method of clause 43, comprising determining a value, p is a reconstructed sample value, b is a predefined bit shift value, and bitdepth is a predicted sample precision.

Additional embodiments and examples through Sections 42-43 are described in Sections 28-31 and 34 of Chapter 4.

44. converting between the current video block and a bitstream representation of the current video block using an intra-block copy mode, size nM×nM is used for encoding tree unit size M×M; n and N are integers, the current video block is positioned in the coding tree unit, and the reference area is the nearest available n coding tree unit corresponding to the current video block. A video processing method that is xn encoding tree units.

Additional embodiments and examples of Section 4 are described in Section 4, Section 35.

45. involves converting between the current video block and the bitstream representation of the current video block using an intra-block copy mode, where the size nM x nM is used in addition to the encoding tree unit size, M x M. , n and N are integers, the current video block is positioned in the coding tree unit, and the reference region is closest and available in the coding tree unit corresponding to the current video block. A video processing method in which n×n-1 encoding tree units are used.

Additional embodiments and examples of Section 4 are described in Section 4, Section 36. Further exemplary embodiments are shown in FIGS. 8 and 9.

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

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

48. 4. 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.

49. 49. A method according to any of claims 46 to 48, wherein n and m depend on the size of the CTU.

50. Validity of a block vector corresponding to the current video block of the video component c using the video component X for conversion between the current video block and a bitstream representation of the current video block. determining that the component X is different from a luminance component of the video, and determining that the block vector is valid for the current video block; performing the conversion using a video processing method. Here, the block vector denoted (BVx, BVy) is equal to (x-x0, y-y0), where (x0, y0) corresponds to the top left position of the coding tree unit of the current video block. .

51. 51. The method of clause 50, wherein the component c corresponds to a luminance component of the video.

52. 51. The method of clause 50, wherein the current video block is a chroma block and the video is in 4:4:4 format.

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

54. The video is in 4:2:0 format, the current video block is a chroma block starting from position (x, y), and the determining is that isRec(c, x+BVx+Chroma_CTU_size, y) is true. 51. The method of clause 50, comprising, in some cases, determining that the block vector is invalid.

55. For conversion between the current video block of the current virtual pipeline data unit (VPDU) of the video region and the bitstream representation of the current video block, selectively determining to use the processed VPDU K1 and the preprocessed VPDU K2 of the second row; and performing a conversion, the conversion using the remainder of the current VPDU; A video processing method that includes, excluding, and multiple conversions.

56. 56. The method of clause 55, wherein K1=1 and K2=2.

57. 57. The method of clauses 55-56, wherein the current video block is selectively processed based on the size of the video region or the size of the current VPDU.

58. performing a validity check on a block vector for conversion between a current video block and a bitstream representation of the current video block, the block vector being used in an intra block copy mode; A video processing method comprising: performing a plausibility check; and using the results of the plausibility check to selectively use the block vector during the transformation.

59. If an intra block copy (IBC) buffer is used during the conversion, and the width and height of the IBC buffer are Wbuf and Hbuf, the dimensions of the current video block are W×H, and the block vector is (BV× , BVy), the current video block is in the current picture with dimensions Wpic and Hpic, the encoding tree unit has width and height Wctu and Hctu, and the validity check is: 59. The method according to paragraph 58, using predetermined rules.

60. The current video 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 from pixel coordinates (X, Y); The method according to any of paragraphs 58 to 59.

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

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

Items 23 to 30 of the previous chapter describe additions and modifications to the above items 58 to 62.

63. 63. A method according to any of the preceding clauses, wherein the converting includes generating the bitstream representation from the current video block.

64. 63. A method according to any of the preceding clauses, wherein the converting includes generating pixel values of the current video block from the bitstream representation.

65. Video encoder device comprising a processing device configured to implement a method according to one or more of claims 1 to 62.

66. Video decoder device comprising a processing device configured to implement the method according to one or more of paragraphs 1 to 62.

67. 63. A computer-readable medium having code stored thereon, the code embodying instructions executable by a processing device for implementing the method of any or more of clauses 1-62.

FIG. 7 is a block diagram showing the hardware platform of the video/image processing device 700. Apparatus 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, or the like. Apparatus 700 may include one or more processors 702, one or more memories 704, and video processing hardware 706. One or more processing devices 702 may be configured to implement one or more methods described herein (including, but not limited to, method 600). Memory(s) 704 may be used to store data and code used to implement the methods and techniques described herein. Video processing hardware 706 may be used to implement the techniques described herein in hardware circuitry.

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

Section A: Additional Exemplary Embodiments

Section A presents another exemplary embodiment in which the current version of the VVC standard may be modified to implement some of the techniques described herein.

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

A1. introduction

An intra block copy, or IBC (or current picture reference, or previous CPR) encoding mode is adopted. Note that the IBC reference samples should be stored in on-chip memory, thus defining a limited reference area of one CTU. To limit extra on-chip memory for buffers, the current design reuses 64x64 memory to decode the current VPDU, so the memory required to support IBC is 3 additional There are only 64x64 blocks of memory. The current reference area is shown in FIG. 2 when the CTU size is 128×128.

Thus, the total reference size is CTU.

A2. Potential issues with current design

The current design assumes reusing 64x64 memory to decode the current VPDU, and the IBC standard is tailored to reuse VPDU memory accordingly. Such a design bundles VPDU decoding memory with IBC buffers. Possible problems include the following:
1. Handling smaller CTU sizes can be problematic. Given a CTU size of 32x32, it is unclear whether the current 64x64 memory for decoding VPDUs can efficiently support 32x32 levels of memory reuse in different architectures.
2. The reference regions are significantly different. Therefore, too many bitstream conformance constraints are introduced. This puts extra burden on the encoder to efficiently utilize the reference area and avoid generating a legitimate bitstream. Also, the possibility of having invalid BVs in different modules, such as merge lists, increases. Handling these invalid BVs may introduce extra logic or extra conformance constraints. This not only introduces a burden on the encoder or decoder, but also can cause differences between BV and MV encoding.
3. The design does not scale well. Since the VPDU decoding is mixed with the IBC buffer, it is not easy to increase or decrease the reference area for the current single 128x128 CTU design. Utilizing a lower or higher profile may limit the flexibility to take advantage of better coding efficiency and on-chip memory trade-offs 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 screen content is typically smaller than the bit depth of internal decoding, the buffer still needs to spend memory to store bits representing noise, which are mostly rounded or quantized. . This problem becomes even more acute when considering higher decoding bit depth configurations.

A3. Clear IBC buffer design

To address the problems described in the above subsection, we propose to have a dedicated IBC buffer that is not mixed with the decoding memory.

For 128x128 CTUs, the buffer is defined as 128x128 with 8-bit samples, and if a CU(x,y) of size wxh is being decoded, the reconstruction of the buffer before loop filtering is 8 It is converted into bits and written to a w×h block area starting from position (x%128, y%128). The modulo operator % always returns a positive number. That is, if x<0 and x%L is defined as -(-x%L), then -3%128=125, for example.

Assuming that pixel (x,y) is encoded in IBC mode with BV=(BVx,BVy), the predicted samples in the IBC reference buffer are located at ((x+BVx)%128, (y+BVy)%128). , pixel values are converted to 10 bits before prediction.

If we consider the buffer as (W, H), after decoding the CTU or CU starting from (x, y), we put the reconstructed pixels before loop filtering into the buffer starting from (x%W, y%H). Remember. Thus, after decoding a CTU, the corresponding IBC reference buffer is updated accordingly. Such a setting may occur if the CTU size is not 128x128. For example, for 64x64 CTU, the current buffer size can be considered as 256x64 buffer. The state of the buffer in the case of 64×64 CTU is shown in FIG.

FIG. 12 is a diagram showing the IBC reference buffer status, where one block shows 64×64 CTUs.

In such a design, all IBC reference buffers can be used as references since the IBC buffer is different from the VPDU decoding memory.

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

Further reductions in bit depth can further reduce memory requirements. For example, for a 7-bit buffer, the on-chip memory savings is 100%-(7*4)/(10*3)=6.7%.

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

If initialization to 512 is allowed at the beginning of each CTU row, all bitstream conformance constraints can be removed.

A4. Experimental result

In some embodiments, the disclosed method may be implemented using VTM-4.0 software.

For a 10-bit buffer implementation and CTC, this decoder is fully compatible with current VTM4.0 encoders. That is, this means that the proposed decoder can accurately decode the VTM-4.0 CTC bitstream.

A 7-bit buffer implementation yields the results shown in Table 1.

For the 8-bit buffer implementation, the results are shown in Table 2.

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 system 1700. System 1700 may include an input unit 2802 for receiving video content. The video content may be received in raw or uncompressed format, eg, 8 or 10 bit multi-module pixel values, or in compressed or encoded format. 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 networks (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

System 1700 may include an encoding module 1704 that can implement various encodings or encoding methods described herein. Encoding module 1704 may reduce the average bit rate of the video from input unit 1702 to the output of encoding module 1704 to produce an encoded representation of the video. Therefore, this encoding technique is sometimes referred to as a video compression or video transcoding technique. The output of encoding module 1704 may be stored or transmitted via a connected communication, as represented by module 1706. The bitstream (or encoded) representation of the stored or communicated video received at input unit 1702 is used by module 1708 to generate pixel values or displayable video that is sent to display interface unit 1710. May be generated. The process of generating user-viewable video from a bitstream representation is sometimes referred to as video decompression. Furthermore, while a particular video processing operation is referred to as an "encoding" operation or tool, an encoding tool or operation is defined as an encoder and a corresponding decoding tool or operation performed by the decoder that reverses the result of the decoding. It will be understood that

Examples of peripheral bus interface units or display interface units may include a universal serial bus (USB) or a high-definition multimedia interface (HDMI) or a display port or the like. Examples of storage interfaces include Serial Advanced Technology Attachment (SATA), PCI, IDE interfaces, and the like. The techniques described herein may be implemented in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and/or video display.

FIG. 18 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 1 of Section 4 of this application. In step 1802, the process determines a buffer size for storing reference samples for prediction in intra block copy mode. In step 1804, the process uses the reference samples stored in the buffer to convert between the current video block of visual media data and a bitstream representation of the current video block, the conversion using the reference samples stored in the buffer. It is performed in an intra-block copy mode based on motion information about reconstructed blocks located in the same video area as the current video block, without referring to pictures.

FIG. 19 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 4 of Section 4 of this application. In step 1902, the process creates a buffer that stores reconstructed samples for prediction in an intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. This buffer is used to store the reconstructed samples before the loop filtering step. In step 1904, the process uses the reconstructed samples stored in the buffer to perform this transformation, and the process uses the reconstructed samples located in the same video region as the current video block without reference to reference pictures. This is done in an intra block copy mode based on motion information regarding.

FIG. 20 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 5 of Section 4 of this application. In step 2002, the process creates a buffer that stores reconstructed samples for prediction in an intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. This buffer is used to store the reconstructed samples after the loop filtering step. In step 2004, the process performs this transformation using the reconstructed samples stored in the buffer, and the process performs this transformation using the reconstructed samples located in the same video region as the current video block, without reference to reference pictures. This is done in an intra block copy mode based on motion information regarding.

FIG. 21 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 6 of Section 4 of this application. In step 2102, the process creates a buffer that stores reconstructed samples for prediction in an intra-block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. This buffer is used to store the reconstructed samples both before the loop filtering step and after the loop filtering step. In step 2104, the process performs this transformation using the reconstructed samples stored in the buffer, and the process uses the reconstructed samples located in the same video region as the current video block without reference to reference pictures. This is done in an intra block copy mode based on motion information regarding.

FIG. 22 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 7 of Section 4 of this application. In step 2202, the process stores reference samples for prediction in an intra block copy mode using a buffer, the first bit depth of the buffer being used to represent visual media data in a bitstream representation. The second bit depth is different from the second bit depth. In step 2204, the process uses the reference samples stored in the buffer to convert between the current video block of visual media data and a bitstream representation of the current video block, the conversion using the reference samples stored in the buffer. It is performed in an intra-block copy mode based on motion information about reconstructed blocks located in the same video area as the current video block, without referring to pictures.

FIG. 23 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 8 of Section 4 of this application. In step 2302, the process initializes a buffer to store reference samples for prediction in intra block copy mode, and the buffer is initialized with a first value. In step 2304, the process uses the reference samples stored in the buffer to convert between the current video block of visual media data and a bitstream representation of the current video block, the conversion using the reference samples stored in the buffer. It is performed in an intra-block copy mode based on motion information about reconstructed blocks located in the same video area as the current video block, without referring to pictures.

FIG. 24 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 9 of Section 4 of this application. In step 2402, the process initializes a buffer to store reference samples for prediction in intra-block copy mode, and determines whether the buffer is in intra-block copy mode based on the availability of one or more video blocks in the visual media data. Initialized with one or more pixel values. In step 2404, the process uses the reference samples stored in the buffer to intersect the bitstream representation of the current video block and the current video block of the visual media data that does not belong to the one or more video blocks. This transformation is performed in an intra-block copy mode based on motion information about a reconstructed block located in the same video region as the current video block, without referring to a reference picture.

FIG. 25 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 14c in Section 4 of this application. In step 2502, the process determines a buffer that stores reference samples for prediction in an intra block copy mode for converting between a current video block of visual media data and a bitstream representation of the current video block. do. In step 2504, the process performs a transformation using the reference samples stored in the buffer and based on motion information about the reconstructed block located in the same video region as the current video block, without reference to a reference picture. and perform the conversion in intra block copy mode. In step 2506, the process determines the correspondence in the buffer based on the reference position (P mod M, Q mod N), where mod is a modulo operation and M and N are integers representing the x and y dimensions of the buffer. The reference position (P, Q) is a block vector for a pixel having a block vector (BVx, BVy) spatially located at the position (x0, y0) and included in the motion information. Determined using vector (BVx, BVy) and position (x0, y0).

FIG. 26 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiments 14a-14b of Section 4 of this application. In step 2602, the process determines a buffer that stores reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. do. In step 2604, the process performs a transformation using the reference samples stored in the buffer and based on motion information about the reconstructed block located in the same video region as the current video block, without reference to a reference picture. and perform the conversion in intra block copy mode. In step 2606, the process calculates a corresponding reference in the buffer based on the reference position (P, Q), where the reference position (P, Q) is spatially located at the position (x0, y0), and A pixel having a block vector (BVx, BVy) included in the motion information is determined using the block vector (BVx, BVy) and the position (x0, y0).

FIG. 27 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 10 in Section 4 of this application. In step 2702, the process determines a buffer that stores reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block. The x and y numbers are then used to address pixel locations within the buffer. In step 2704, the process performs the transformation using the reference samples stored in the buffer based on the x and y numbers to locate the current video block in the same video region without reference to the reference picture. The transformation is performed in an intra-block copy mode based on motion information about the reconstructed blocks.

FIG. 28 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 15 in Section 4 of this application. In step 2802, the process determines a buffer that stores reference samples for prediction in an intra block copy mode for converting between a current video block of visual media data and a bitstream representation of the current video block. However, this conversion is performed in an intra-block copy mode based on motion information about a reconstructed block located in the same video region as the current video block, without referring to a reference picture. In step 2804, the process calculates a corresponding reference in the buffer at the reference position (P, Q), where the reference position (P, Q) is spatially located at the current video block position (x0, y0). For a pixel that is located and has a block vector (BVx, BVy), it is determined using the block vector (BVx, BVy) and the position (x0, y0). In step 2806, if the process determines that the reference position (P,Q) is outside the buffer, the process recalculates the reference position using the samples within the buffer.

FIG. 29 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 16 in Section 4 of this application. In step 2902, the process determines a buffer that stores reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block; This conversion is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture. In step 2904, the process calculates a corresponding reference in the buffer at reference position (P,Q), where reference position (P,Q) is the current upper left position of the encoding tree unit containing the current video block. For a pixel that is spatially located at a position (x0, y0) of a video block and has a block vector (BVx, BVy), it is determined using the block vector (BVx, BVy) and the position (x0, y0). . In step 2906, if the process determines that the reference position (P, Q) is outside the buffer, the process constrains at least a portion of the reference position to be within a predefined range.

FIG. 30 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 17 of Section 4 of this application. In step 3002, the process determines a buffer that stores reference samples for prediction in an intra block copy mode for conversion between a current video block of visual media data and a bitstream representation of the current video block; This conversion is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture. In step 3004, the process calculates a corresponding reference at reference position (P,Q) in the buffer containing the current video block using block vector (BVx, BVy) and position (x0,y0); Determine the reference position (P, Q) of a pixel spatially located at position (x0, y0) of the current video block with respect to the upper left position of the coding tree unit having block vector (BVx, BVy). In step 1706, if the process determines that the block vector (BVx, BVy) is outside the buffer, the process pads the block vector (BVx, BVy) based on the block vector of sample values inside the buffer.

FIG. 31 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 30 in Section 4 of this application. In step 3102, the process resets a buffer that stores reference samples for prediction in an intra-block copy mode at video boundaries during conversion between a video and a bitstream representation of the video. In step 3104, the process performs a transformation of the video block of the video using the reference samples stored in the buffer, such that the motion with respect to the reconstructed block located in the same video region as the video block is performed without reference to the reference picture. Based on the information, perform the conversion in intra block copy mode.

FIG. 32 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 34 in Section 4 of this application. In step 3202, processing converts between a current video block and a bitstream representation of the current video block. In step 3204, processing includes updating a buffer used to store reference samples for prediction in intra-block copy mode, which buffer is used to store reference samples for prediction in an intra-block copy mode, and the buffer is configured to update the bitstream of the subsequent video block and the subsequent video block. Used for conversion between representations of subsequent video blocks and bitstream representations of subsequent video blocks, without reference to reference pictures, in the same video area as the subsequent video block. This is done in intra-block copy mode based on the motion information about the reconstructed blocks located at.

FIG. 33 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 39 of Section 4 of this application. In step 3302, the process determines a buffer to use to store reconstructed samples for prediction in intra block copy mode for conversion between the current video block and a bitstream representation of the current video block. , this transformation is performed in an intra-block copy mode based on motion information about the reconstructed block located in the same video region as the current video block, without referring to a reference picture. In step 3304, the process performs preprocessing operations on the buffered reconstructed samples when determining that the buffered reconstructed samples will be used to predict sample values during the transformation. Includes things to do and things to do.

FIG. 34 is a flowchart illustrating an example of a video data processing method. The steps of this flowchart are described in connection with exemplary embodiment 42 in Section 4 of this application. In step 3402, for converting between a current video block of a current virtual pipeline data unit (VPDU) of the video region and a bitstream representation of the current video block, an even numbered row of the video region is selectively selected. It is determined whether to use the K1 preprocessed VPDU of the second row and/or the K2 preprocessed VPDU of the odd row. In step 3404, the process performs a transformation that precludes using the remainder of the current VPDU and provides motion information about the reconstructed block located in the same video region as the video block without reference to a reference picture. The conversion is performed in intra block copy mode based on

Some embodiments herein are presented in a section-based format.

1. A visual media processing method, the method comprising:
In intra block copy mode, determining a buffer size for storing reference samples for prediction;
using the reference samples stored in the buffer to convert between a current video block of visual media data and a bitstream representation of the current video block, the conversion comprising A method of visual media processing performed in the intra-block copy mode based on motion information about a reconstructed block located in the same video region as the current video block without reference.

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

3. The method according to any one or more of clauses 1 to 2, wherein the size of the buffer is M×N, and M and N are integers.

4. 4. The method of clause 3, wherein MxN is equal to 64x64 or 128x128 or 64x128 or 96x128 or 128x96.

5. 2. The method of claim 1, wherein the size of the buffer or part thereof is equal to the size of the coding tree unit containing the current video block or part thereof.

6. 2. The method of claim 1, wherein the buffer height is equal to the height of the coding tree unit containing the current video block.

7. 2. The method of claim 1, wherein the buffer size corresponds proportionally to the size of a coding tree unit containing the current video block.

8. The proportional correspondence expressed by integers m and n is, when the CTU size is 128x128, m = 1, n = 1, and when the CTU size is 64x64, m = 4, n = 1. If the CTU size is 32x32, then m=16, n=1, and if the CTU size is 16x16, set the current video block so that m=64, n=1. based on the size of the containing coding tree unit (CTU), where n is equal to the buffer height/the CTU height and m is equal to the buffer width/the CTU width. The method described in.

9. 2. The method of claim 1, wherein the product of the buffer height and the buffer width is a predetermined constant.

10. 2. The method of claim 1, wherein the buffer size corresponds proportionally to a virtual pipeline data unit used for the conversion.

11. 2. The method of claim 1, wherein the buffer size is equal to the size of a virtual pipeline data unit used for the conversion.

12. 2. The method of claim 1, wherein the buffer size corresponds to a field included in the bitstream representation.

13. 13. The method of claim 12, wherein the fields are included in the bitstream representation at a video or sequence or picture or slice or tile group level.

14. 14. The method of claim 13, wherein the field is included in a video parameter set, a sequence parameter set, or a picture parameter set, or at a picture header, slice header, or tile group header level.

15. 15. The method of any one or more of clauses 1-14, wherein the buffer stores reference samples associated with one or more color components.

16. 16. The method of any one or more of clauses 1-15, wherein two or more buffers are maintained.

17. A first buffer and a second buffer are maintained, the first buffer having a first size being used for reference samples associated with the luminance component, and the second buffer having a second size being used for reference samples associated with the luminance component. , and wherein the first buffer is different from the second buffer.

18. 18. The method of clause 17, wherein the second size depends on the first size.

19. 18. The method of claim 17, wherein the second size is independent of the first size.

20. 19. A method according to any one or more of clauses 17-18, wherein the second size depends on the chroma subsampling format of the current video block.

21. 19. The method of clause 18, wherein the second size is equal to the first size.

22. 22. A method according to any of the preceding clauses, wherein the reference samples are stored in RGB format.

23. 23. The method of clause 22, wherein the buffer size is equal to 64x64 or 128x128 or 64x128 or 128x64.

24. Clause 1, wherein the buffer size is based at least in part on the size of a virtual pipeline data unit (VPDU) associated with the transform and/or the size of a coding tree block associated with the current video block. How to describe

25. 25. The method of clause 24, wherein the size of the buffer is equal to the size of the encoded treeblock.

26. 25. The method of clause 24, wherein the buffer height is equal to the height of the encoding tree unit associated with the current video block.

27. The buffer size includes a height, the height being equal to the minimum of (i) a predetermined value and (ii) the size of the encoding tree block associated with the current video block. The method described in section.

28. 28. The method of clause 27, wherein the predetermined value is 64.

29. 25. The method of clause 24, wherein the width of the buffer is equal to 128*128/vSize, where vSize represents the size of the VPDU.

30. 25. The method of clause 24, wherein the buffer height is equal to min(ctbSize, 64), ctbSize represents the size of the coded treeblock, and min(x,y) represents the minimum value of x and y. .

31. 31. A method according to any of the preceding clauses, wherein the converting includes generating the bitstream representation from the current video block.

32. 31. A method according to any of the preceding clauses, wherein said converting comprises generating pixel values of said current video block from said bitstream representation.

33. Video encoder device comprising a processing device configured to implement a method according to one or more of claims 1 to 30.

34. Video decoder device, comprising a processing device configured to implement the method according to one or more of paragraphs 1 to 30.

35. A computer-readable medium having code stored thereon, the code implementing instructions executable by a processing device for implementing the method of any or more of clauses 1-30.

As used herein, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of the current video block may correspond to bits that are spread at the same or different locations within the bitstream, for example, as defined by the syntax. For example, one macroblock may be encoded in terms of transformed and encoded error residual values and using bits in headers and other fields in the bitstream.

Although specific embodiments of the disclosed technology have been described above for purposes of illustration, it will be appreciated that various modifications may be made without departing from the scope of the invention. Accordingly, the technology of this disclosure is not limited except as by the appended claims.

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 structural equivalents thereof. or a combination of one or more thereof. Implementations of the subject matter described herein may include one or more computer program products, i.e., tangible, non-portable computer program products, for execution by or for controlling the operation of a data processing device. It can be implemented as one or more modules of computer program instructions encoded on a computer-readable medium. 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 a combination of one or more of these. The term "data processing unit" or "data processing apparatus" includes all apparatus, devices, and machines for processing data, including, for example, a programmable processing unit, a computer, or a plurality of processing units or computers. In addition to hardware, this device includes code that creates an execution environment for the computer program, such as processing device firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these. be able to.

A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can also be written as a standalone program. or as a module, component, subroutine, or other unit suitable for use in a computing environment. Computer programs do not necessarily correspond to files in a file system. A program may be recorded in part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), or it may be in a single file dedicated to the program. or may be stored in multiple adjustment files (eg, files containing one or more modules, subprograms, or portions of code). It is also possible to deploy a computer program to run on one computer located at one site or on multiple computers distributed at multiple sites and interconnected by a communications network.

The processing and logic flows described herein are performed by one or more programmable processing devices that execute one or more computer programs to perform functions by operating on input data and producing output. be able to. The processing and logic flow can also be performed by special purpose logic circuits, for example FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits), and the device can also be implemented as special purpose logic circuits. Can be done.

Processing devices suitable for the execution of a computer program include, for example, both general and special purpose microprocessing devices, as well as any one or more processing devices of any type of digital computer. Generally, a processing device receives instructions and data from read-only memory and/or random access memory. The essential elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Generally, a computer may include one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, or may receive data from these mass storage devices. , or may be operably coupled to transfer data thereto. However, a computer does not need to have such a device. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including semiconductor memory devices such as EPROM, EEPROM, flash memory devices, and the like. The processing unit and memory may be supplemented by or incorporated into special purpose logic circuitry.

This specification, together with the drawings, is for purposes of illustration only, and illustrative is intended to mean examples. As used herein, the use of "or" is intended to include "and/or" unless the context clearly dictates otherwise.

Although this patent specification contains many details, these should not be construed as limiting the scope of any invention or claims, but rather as specific to particular embodiments of a particular invention. It should be interpreted as a description of possible characteristics. Certain features that are described in this patent document in the context of separate embodiments may also be implemented in combination in a single example. Conversely, various features that are described in the context of a single example may be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above and initially claimed as operating in a particular combination, one or more features from the claimed combination may, in some cases, be different from the combination. A combination that can be abstracted and claimed may be directed to sub-combinations or variations of sub-combinations.

Similarly, although acts are shown in a particular order in the drawings, this does not mean that such acts may be performed in the particular order shown or in sequential order to achieve a desired result. It should not be construed as requiring that , or all operations shown be performed. Also, the separation of various system components in the examples described in this patent specification is not to be understood as requiring such separation in all embodiments.

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 (17)

determining that a first coding mode is applied to the current video block for converting a current video block of video that is a luminance block and a bitstream of the video;
deriving a first block vector for the current video block;
generating predictive samples of the current video block based on the first block vector and a luminance buffer;
performing the transformation based on the predicted samples;
The luminance buffer stores reconstructed samples of a previous video block that have not been subjected to filtering processing, and in the first coding mode, the predictive samples are derived from the same picture containing the video block;
the size and shape of the luminance buffer are the same for the current video block and other luminance blocks located in the same video area as the current video block;
the dimensions of the luminance buffer are indicated based on fields included in the bitstream ;
Visual media processing methods. the brightness buffer is a rectangular area;
The method according to claim 1. The field is included in a sequence parameter set.
The method according to claim 1 . The field is included in a video parameter set, a picture parameter set, a slice parameter set, or a tile parameter set.
The method according to claim 1 . deriving a chroma buffer size for a chroma block corresponding to the current video block based on the size of the luminance buffer and a color format of the chroma block and the current video block;
The method according to any one of claims 1 to 4 . If the color format is 4:2:0, the width of the chroma buffer is equal to half the width of the luminance buffer, and the height of the chroma buffer is equal to half the height of the luminance buffer.
The method according to claim 5 . If the color format is 4:4:4, the width of the chroma buffer is equal to the width of the luminance buffer, and the height of the chroma buffer is equal to the height of the luminance buffer.
The method according to claim 5 . If the color format is 4:2:2, the width of the chroma buffer is equal to half the width of the luminance buffer, and the height of the chroma buffer is equal to the height of the luminance buffer.
The method according to claim 5 . the chroma buffer includes a Cb channel and a Cr channel;
The method according to any one of claims 5 to 8 . The filtering process includes deblocking filtering, sample adaptive offset filtering, or adaptive loop filtering.
The method according to any one of claims 1 to 9 . the part of the previous video block is located in a different coding tree block than the current coding tree block containing the current video block;
The method according to any one of claims 1 to 10 . the video region is a coding tree block or a slice;
The method according to any one of claims 1 to 11 . The converting includes encoding the current video block into the bitstream.
The method according to any one of claims 1 to 12 . The converting includes decoding the current video block from the bitstream.
The method according to any one of claims 1 to 12 . A video data processing device comprising: a processing device; and a non-temporary memory in which instructions are stored in the processing device, wherein when the instructions are executed by the processing device, the processing device is configured to
determining that a first coding mode is applied to the current video block for converting a current video block of video that is a luminance block and a bitstream of the video;
deriving a first block vector for the current video block;
generating predictive samples of the current video block based on the first block vector and a luminance buffer;
performing the transformation based on the predicted samples;
The luminance buffer stores reconstructed samples of a previous video block that have not been subjected to filtering processing, and in the first coding mode, the predictive samples are derived from the same picture containing the video block,
the size and shape of the luminance buffer are the same for the current video block and other luminance blocks located in the same video area as the current video block;
the dimensions of the luminance buffer are indicated based on fields included in the bitstream ;
Device. In the processing equipment,
determining that a first coding mode is applied to the current video block for converting a current video block of video that is a luminance block and a bitstream of the video;
deriving a first block vector for the current video block;
generating predictive samples of the current video block based on the first block vector and a luminance buffer;
performing the transformation based on the predicted samples;
The luminance buffer stores reconstructed samples of a previous video block that have not been subjected to filtering processing, and in the first coding mode, the predictive samples are derived from the same picture containing the video block,
the size and shape of the luminance buffer are the same for the current video block and other luminance blocks located in the same video area as the current video block;
the dimensions of the luminance buffer are indicated based on fields included in the bitstream ;
Non-transitory computer-readable storage medium. A method for storing a video bitstream, the method comprising:
The method includes:
determining that a first coding mode is applied to a current video block of the video that is a luminance block;
deriving a first block vector for the current video block;
generating predictive samples of the current video block based on the first block vector and a luminance buffer;
generating the bitstream based on the predicted samples;
storing the bitstream on a non-transitory computer-readable recording medium;
The luminance buffer stores reconstructed samples of a previous video block that have not been subjected to filtering processing, and in the first coding mode, the predictive samples are derived from the same picture containing the video block;
the size and shape of the luminance buffer are the same for the current video block and other luminance blocks located in the same video area as the current video block;
the dimensions of the luminance buffer are indicated based on fields included in the bitstream ;
Method .

Images