Validity Check of Block Vectors for Intra-Block Copy in Video Coding and Decoding

Abstract

A method for video processing, including determining a block vector for conversion between a current video block of a current picture of visual media data and a bitstream representation of the current video block, wherein the validity of the block vector is independent of (1) the position (P, Q) of a sample block and / or (2) whether the samples at the position (P, Q) are reconstructed, and / or (3) the position of the current video block. The block vector represents a pixel displacement between the current video block and the sample block. The method includes performing the conversion in an intra block copy mode using the block vector.

Description

[0001] Cross - reference to related applications

[0002] In accordance with applicable patent laws and / or in accordance with the rules of the Paris Convention, this application aims to timely claim the priority and benefits of International Patent Application No. PCT / CN2019 / 093552 filed on June 28, 2019, International Patent Application No. PCT / CN2019 / 094957 filed on July 6, 2019, International Patent Application No. PCT / CN2019 / 095297 filed on July 9, 2019, International Patent Application No. PCT / CN2019 / 095504 filed on July 10, 2019, International Patent Application No. PCT / CN2019 / 095656 filed on July 11, 2019, International Patent Application No. PCT / CN2019 / 095913 filed on July 13, 2019, and International Patent Application No. PCT / CN2019 / 096048 filed on July 15, 2019. For all purposes under the law, the entire disclosure of the foregoing applications is incorporated by reference as part of the disclosure of this application. Technical field

[0003] This patent document relates to video encoding, decoding technologies, devices, and systems. Background art

[0004] Despite the progress in video compression, digital video still accounts for the largest bandwidth usage on the Internet and other digital communication networks. With the increasing number of connected user devices capable of receiving and displaying video, the bandwidth demand for digital video usage is expected to continue to grow. Summary of the invention

[0005] This document describes various embodiments and techniques for buffer management and block vector encoding and decoding of intra - block copy modes for decoding or encoding video or images.

[0006] In an example aspect, a method for visual media processing is disclosed. The method includes: determining a block vector (BVx, BVy) for the conversion between a current video block of a current picture of visual media data and a bitstream representation of the current video block, wherein the validity of the block vector (BVx, BVy) is independent of (1) the position (P, Q) of a sample block and / or (2) whether the samples at the position (P, Q) are reconstructed, and / or (3) the position of the current video block, wherein the block vector (BVx, BVy) represents a pixel displacement between the current video block and the sample block; and performing the conversion in an intra block copy mode using the block vector, wherein the intra block copy mode is based on reconstructed blocks in the same video region as the current video block that include reference samples for deriving a predicted block of the current video block, wherein during the conversion, a predicted sample having a position (A, B) from the reference samples in the buffer is determined at least according to the size of the buffer and / or the block vector (BVx, BVy).

[0007] In another example aspect, another method for visual media processing is disclosed. The method includes: determining whether a block vector (BVx, BVy) corresponding to a current video block of a current picture of visual media data is valid for the conversion between the current video block and a bitstream representation of the visual media data according to a rule, wherein the block vector (BVx, BVy) represents a pixel displacement between the current video block and the sample block; and performing the conversion using the block vector based on a reference region from the current picture that includes reference samples for deriving a predicted block of the current video block, wherein the rule specifies that the block vector (BVx, BVy) is valid when (1) one or more samples from the sample block are outside the current picture and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and / or (3) one or more samples from the sample block fail to be reconstructed.

[0008] In yet another example aspect, another method for visual media processing is disclosed. The method includes performing a conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, wherein the conversion is based on a reference region from the current picture that includes reference samples for deriving a predicted block of the current video block, and wherein a virtual buffer defining a size is used to track the availability of reference samples for deriving the predicted block.

[0009] In yet another example aspect, another method for visual media processing is disclosed. The method includes maintaining a buffer for a conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data, the buffer including reference samples from the current picture for deriving a predicted block of the current video block, wherein one or more reference samples marked as unavailable for derivation in the buffer have values outside a pixel value range.

[0010] In another example aspect, another method of video processing is disclosed. The method includes performing a conversion between a current video block of a current picture of visual media data and a bitstream representation of the visual media data using a buffer, where the buffer includes reference samples from the current picture for deriving a predicted block of the current video block, and where the conversion is based on a rule that specifies that, for the bitstream representation to conform to the rule, the reference samples in the buffer are to satisfy bitstream consistency constraints.

[0011] In yet another example aspect, a video encoder or decoder device is disclosed, including a processor configured to implement the above method.

[0012] In another example aspect, a computer-readable program medium is disclosed. The medium stores code embodying processor-executable instructions for implementing one of the disclosed methods.

[0013] These and other aspects are described in more detail in this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 Shows examples of current picture reference or intra block copy video or image coding / decoding techniques.

[0015] Figure 2 Shows examples of dynamic reference regions.

[0016] Figure 3 Shows an example of coding / decoding of a block starting from (x, y).

[0017] Figure 4 Shows an example of possible alternative ways of selecting a previously coded 64×64 block.

[0018] Figure 5 Shows an example of possible alternative ways of changing the coding / decoding order of a 64×64 block.

[0019] Figure 6 Is a flowchart of an example method of video or image processing.

[0020] Figure 7 Is a block diagram of a hardware platform for video or image coding / decoding or decoding.

[0021] Figure 8 Shows another possible alternative way of selecting a previously coded 64×64 block when the decoding order of the 64×64 block is from top to bottom and from left to right.

[0022] Figure 9 Shows another possible alternative way of selecting a previously coded 64×64 block.

[0023] Figure 10 Shows an example flowchart of a decoding process with shaping.

[0024] Figure 11 Shows another possible alternative for selecting a previously coded / decoded 64×64 block when the decoding order of the 64×64 block is from left to right and from top to bottom.

[0025] Figure 12 Is an illustration of the IBC reference buffer state, where the blocks represent 64×64 CTUs.

[0026] Figure 13 Shows an arrangement of the reference area for IBC.

[0027] Figure 14 Shows another arrangement of the reference area for IBC.

[0028] Figure 15 Shows another arrangement of the reference area for IBC when the current Virtual Pipeline Data Unit (VPDU) is to the right of the picture boundary.

[0029] Figure 16 Shows an example of the state of the virtual buffer when the VPDUs in a CTU row are decoded sequentially.

[0030] Figure 17 Is a block diagram of an example video processing system in which the disclosed technology can be implemented.

[0031] Figure 18 Is a flowchart of an example method for visual media processing.

[0032] Figure 19 Is a flowchart of an example method for visual media processing.

[0033] Figure 20 Is a flowchart of an example method for visual media processing.

[0034] Figure 21 Is a flowchart of an example method for visual media processing.

[0035] Figure 22 Is a flowchart of an example method for visual media processing. Detailed Description

[0036] For ease of understanding, section headings are used in this document, and the scope of the embodiments disclosed in each section is not limited to that section alone. This document describes various embodiments and techniques for buffer management and block vector coding / decoding in the intra-block copy mode for decoding or encoding video or images.

[0037] 1. Overview

[0038] This patent document relates to video coding and decoding technology. Specifically, it relates to intra-block copy in video coding and decoding. It can be applied to the standards under development, such as Versatile Video Coding. It can also be applicable to future video coding and decoding standards or video codecs.

[0039] 2. Brief Discussion

[0040] Video coding and decoding standards have mainly evolved through the development of well-known ITU-T and ISO / IEC standards. ITU-T produced H.261 and H.263, ISO / IEC produced MPEG-1 and MPEG-4 Visual, and the two organizations jointly produced the H.262 / MPEG-2 video and 264 / MPEG-4 Advanced Video Coding (AVC) standards and the H.265 / HEVC standards. Since H.262, video coding and decoding standards have been based on a hybrid video coding and decoding structure, in which temporal prediction plus transform coding is utilized. To explore future video coding and decoding technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and incorporated them into a reference software named the Joint Exploration Model (JEM). In April 2018, the Joint Video Expert Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) was established to work on the VVC standard, with the goal of a 50% bitrate reduction compared to HEVC.

[0041] 2.1 Inter-Frame Prediction in HEVC / H.265

[0042] Each inter-frame prediction PU has motion parameters for one or two reference picture lists. The motion parameters include motion vectors and reference picture indices. inter_pred_idc can also be used to signal the use of one of the two reference picture lists. The motion vectors can be explicitly coded and decoded as deltas relative to the predicted values.

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

[0044] When the signaling indicates that one of the two reference picture lists will be used, a PU is generated from a single sample block. This is referred to as "unidirectional prediction". Unidirectional prediction applies to both P-slices and B-slices.

[0045] When the signaling indicates that both reference picture lists are to be used, a PU is generated from two sample blocks. This is referred to as "bidirectional prediction". Bidirectional prediction applies only to B-slices.

[0046] Details of the inter-prediction modes specified in HEVC are provided below. The description will start with the Merge mode.

[0047] 2.2 Current Picture Referencing

[0048] Current Picture Referencing (CPR), or once named Intra Block Copy (IBC), has been adopted in the HEVC Screen Content Coding extension (HEVC-SCC) and the current VVC test model. IBC extends the concept of motion compensation from inter-coding to intra-coding. As Figure 1As shown, when applying CPR, the current block is predicted by a reference block in the same picture. Before encoding / decoding or decoding the current block, the samples in the reference block must have been reconstructed. Although CPR is not efficient for most sequences captured by cameras, it shows significant encoding / decoding gains for screen content. The reason is that there are many repetitive patterns in screen content pictures, such as icons and text characters. CPR can effectively remove the redundancy between these repetitive patterns. In HEVC-SCC, if an inter-coded Coding Unit (CU) selects the current picture as its reference picture, it can apply CPR. In this case, the MV is renamed as the Block Vector (BV), and the BV always has integer pixel precision. To be compatible with the main profile HEVC, the current picture is marked as a "long-term" reference picture in the Decoded Picture Buffer (DPB). It should be noted that, similarly, in multi-view / 3D video coding standards, the inter-view reference pictures are also marked as "long-term" reference pictures.

[0049] After the BV finds its reference block, the prediction can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixels from the original signal. Then the transform and quantization can be applied as in other coding modes.

[0050] Figure 1 is an example illustration of the current picture reference.

[0051] However, when the reference block is outside the picture, or overlaps with the current block, or is outside the reconstructed area, or is outside the valid area restricted by certain constraints, some or all of the pixel values are not defined. Basically, there are two solutions to solve such problems. One is not to allow such a situation, for example, in bitstream conformance. The other is to apply padding to those undefined pixel values. The following subsections detail the solutions.

[0052] 2.3 CPR in HEVC Screen Content Coding Extension

[0053] In the screen content coding extension of HEVC, when a block uses the current picture as a reference, it should ensure that the entire reference block is within the available reconstructed area, as indicated in the following specification text:

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

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

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

[0057] One requirement for bitstream consistency is that when the reference picture is the current picture, the luma motion vector mvLX shall comply with the following constraints:

[0058] – When invoking the derivation process of z-scan order block availability specified in Clause 6.4.1 with (xCurr, yCurr) set to (xCb, yCb) and the neighboring luma position (xNbY, yNbY) set to (xPb + (mvLX[0] >> 2) – offsetX, yPb + (mvLX[1] >> 2) – offsetY) as input, the output shall be equal to TRUE (true).

[0059] – When invoking the derivation process of z-scan order block availability specified in Clause 6.4.1 with (xCurr, yCurr) set to (xCb, yCb) and the neighboring luma position (xNbY, yNbY) set to (xPb + (mvLX[0] >> 2) + nPbW – 1 + offsetX, yPb + (mvLX[1] >> 2) + nPbH – 1 + offsetY) as input, the output shall be equal to TRUE.

[0060] – One or both of the following conditions shall be true:

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

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

[0063] – The following condition shall be true:

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

[0065] Therefore, there will be no situation where the reference block overlaps with the current block or the reference block is outside the picture. No padding of the reference or prediction block is required.

[0066] 2.4 Examples of CPR / IBC

[0067] In the VVC test model, the entire reference block should have the current Coding Tree Unit (CTU) and not overlap with the current block. Therefore, there is no need to pad the reference or prediction block.

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

[0069] A chroma block can only be coded / decoded in the CPR mode when the following conditions should be true:

[0070] 1) Each luma CU within the collocated luma block should be coded / decoded in the CPR mode

[0071] 2) Each of the BVs in the luma 4×4 blocks is first converted to the BV of the chroma block, and the BV of the chroma block is a valid BV.

[0072] If either of the two conditions is false, the chroma block should not be coded / decoded in the CPR mode.

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

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

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

[0076] 2.5 Examples of CPR / IBC

[0077] In some examples, the reference region for CPR / IBC is restricted to the current CTU, which is up to 128×128. The reference region is dynamically changed to reuse memory to store the reference samples for CPR / IBC, such that the CPR / IBC block can have more reference candidates while the reference buffer for CPR / IBC can be maintained or reduced from one CTU.

[0078] Figure 2 A method is shown where the block is 64×64 and the CTU contains 4 64×64 blocks. When coding / decoding the 64×64 block, the previous 3 64×64 blocks can be used as references. By doing so, the decoder only needs to store 4 64×64 blocks to support CPR / IBC.

[0079] Assume that the position of the current luminance CU relative to the upper left corner of the picture is (x, y), and the block vector is (BVx, BVy). In the current design, whether BV is valid can be determined by checking that the luminance position ((x + BVx) >> 6 << 6 + (1 << 7), (y + BVy) >> 6 << 6) has not been reconstructed and ((x + BVx) >> 6 << 6 + (1 << 7), (y + BVy) >> 6 << 6) is not equal to (x >> 6 << 6, y >> 6 << 6).

[0080] 2.6 In-loop Reshaping (ILR)

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

[0082] 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 because the other LUT can be computed from the signaled LUT. Each LUT is a one-dimensional, 10-bit, 1024-entry mapping table (1D-LUT). One LUT is the forward LUT, FwdLUT, which maps the input luminance code value Y i to the modified value Y r : Y r = FwdLUT[Y i . The other LUT is the inverse LUT, InvLUT, which maps the modified code value Y r to ( denotes the reconstructed value of Y i ).

[0083] 2.6.1 PWL Model

[0084] Conceptually, piece-wise linear (PWL) is implemented in the following way:

[0085] Assume that x1, x2 are two input pivot points, and y1, y2 are their corresponding output pivot points for a piece. The output value y for any input value x between x1 and x2 can be interpolated by the following equation:

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

[0087] In the fixed-point implementation, the equation can be rewritten as:

[0088] y = ((m * x + 2 FP_PREC-1) >> FP_PREC) + c

[0089] where m is a scalar, c is an offset, and FP_PREC is a constant value specifying the precision.

[0090] In some examples, the PWL model is used to pre-compute the FwdLUT and InvLUT mapping tables for 1024 entries; however, the PWL model also allows an implementation that computes the same mapping values on-the-fly without pre-computing the LUT.

[0091] 2.6.2.1 Luminance Shaping

[0092] A method of loop luminance shaping provides a lower complexity pipeline that also eliminates the decoding latency of per-block intra prediction in inter-strip reconstruction. Intra prediction is performed in the shaping domain for both inter and intra strips.

[0093] Regardless of the strip type, intra prediction is always performed in the shaping domain. In this arrangement, intra prediction can start immediately after the previous TU reconstruction is completed. Such an arrangement can also provide a unified process for intra modes instead of relying on the strip. Figure 10 A block diagram of the mode-based CE12-2 decoding process is shown.

[0094] The 16-segment piecewise linear (PWL) model was tested for luminance and chrominance residue scaling instead of the 32-segment PWL model.

[0095] Inter-strip reconstruction using the loop luminance shaper (light green shaded blocks indicate signaling in the shaping domain: luminance residue; of intra luminance prediction; and of intra luminance reconstruction).

[0096] 2.6.2.2 Luminance-Dependent Chrominance Residue Scaling

[0097] Luminance-dependent chrominance residue scaling is a multiplication process implemented using fixed-point integer arithmetic. Chrominance residue scaling compensates for the interaction between the luminance and chrominance signals. Chrominance residue scaling is applied at the TU level. More specifically, the following applies:

[0098] – For intra, the reconstructed luminance is averaged.

[0099] – For inter, the predicted luminance is averaged.

[0100] The average is used to identify the index in the PWL model. This index identifies the scaling factor cScaleInv. The chrominance residue is multiplied by this number.

[0101] Note that the chrominance scaling factor is computed based on the predicted luminance value of the forward mapping rather than the reconstructed luminance value.

[0102] 2.6.2.3 Signaling Notification of ILR Side Information

[0103] The parameter (current) is transmitted in the tile group header (similar to ALF). These are said to require 40 - 100 bits.

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

[0105] Sequence Parameter Set RBSP Syntax in 7.3.2.1

[0106]

[0107] General Tile Group Header Syntax in 7.3.3.1

[0108]

[0109]

[0110] Add a new syntax table tile group reshaper model:

[0111]

[0112] In the general sequence parameter set RBSP semantics, add the following semantics:

[0113] sps_reshaper_enabled_flag being equal to 1 specifies that the reshaper is used in the coded video sequence (CVS). sps_reshaper_enabled_flag being equal to 0 specifies that the reshaper is not used in the CVS.

[0114] In the tile group header syntax, add the following semantics

[0115] tile_group_reshaper_model_present_flag being equal to 1 specifies that tile_group_reshaper_model() is present in the tile group header. tile_group_reshaper_model_present_flag being equal to 0 specifies that tile_group_reshaper_model() is not present in the tile group header. When tile_group_reshaper_model_present_flag is not present, it is inferred to be equal to 0.

[0116] The tile_group_reshaper_enabled_flag being equal to 1 specifies that the reshaper is enabled for the current tile group. The tile_group_reshaper_enabled_flag being equal to 0 specifies that the reshaper is not enabled for the current tile group. When the tile_group_reshaper_enable_flag does not exist, it is inferred to be equal to 0.

[0117] The tile_group_reshaper_chroma_residual_scale_flag being equal to 1 specifies that chroma residual scaling is enabled for the current tile group. The tile_group_reshaper_chroma_residual_scale_flag being equal to 0 specifies that chroma residual scaling is not enabled for the current tile group. When the tile_group_reshaper_chroma_residual_scale_flag does not exist, it is inferred to be equal to 0. Add tile_group_reshaper_model() syntax

[0118] reshape_model_min_bin_idx specifies the minimum bin (or segment) index to be used during reshaper construction. The value of reshape_model_min_bin_idx should be in the range of 0 to MaxBinIdx, inclusive of 0 and MaxBinIdx. The value of MaxBinIdx should be equal to 15.

[0119] reshape_model_delta_max_bin_idx specifies the maximum allowed bin (or segment) index MaxBinIdx minus the maximum bin index to be used during reshaper construction. The value of reshape_model_max_bin_idx is set to be equal to MaxBinIdx – reshape_model_delta_max_bin_idx.

[0120] reshaper_model_bin_delta_abs_cw_prec_minus1 plus 1 specifies the number of bits used to represent the syntax reshape_model_bin_delta_abs_CW[i].

[0121] reshape_model_bin_delta_abs_CW[i] specifies the absolute incremental codeword value for the i-th binary bit. reshaper_model_bin_delta_sign_CW_flag[i] specifies the sign of reshape_model_bin_delta_abs_CW[i] as follows:

[0122] – If reshape_model_bin_delta_sign_CW_flag[i] equals 0, the corresponding variable RspDeltaCW[i] is positive.

[0123] – Otherwise (reshape_model_bin_delta_sign_CW_flag[i] is not equal to 0), the corresponding variable RspDeltaCW[i] is negative.

[0124] When reshape_model_bin_delta_sign_CW_flag[i] does not exist, it is inferred to be equal to 0. The variable RspDeltaCW[i] = (1 - 2 * reshape_model_bin_delta_sign_CW[i]) * reshape_model_bin_delta_abs_CW[i];

[0125] The variable RspCW[i] is derived as follows:

[0126] The variable OrgCW is set to be equal to (1 << BitDepth Y ) / (MaxBinIdx + 1).

[0127] – If reshaper_model_min_bin_idx <= i <= reshaper_model_max_bin_idx, RspCW[i] = OrgCW + RspDeltaCW[i].

[0128] – Otherwise, RspCW[i] = 0.

[0129] If the value of BitDepth Y equals 10, the value of RspCW[i] should be in the range of 32 to 2 * OrgCW - 1.

[0130] The variable InputPivot[i] (where i ranges from 0 to MaxBinIdx + 1, including 0 and MaxBinIdx + 1) is derived as follows

[0131] InputPivot[i] = i * OrgCW

[0132] The variables ReshapePivot[i] (where i ranges from 0 to MaxBinIdx + 1, including 0 and MaxBinIdx + 1), ScaleCoef[i], and InvScaleCoeff[i] (where i ranges from 0 to MaxBinIdx, including 0 and MaxBinIdx) are derived as follows:

[0133]

[0134] The variable ChromaScaleCoef[i] (where i ranges from 0 to MaxBinIdx, including 0 and MaxBinIdx) is derived as follows:

[0135] 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, 1365, 1365, 1260, 1260, 1260, 1260, 1170, 1170, 1170, 1170, 1092, 1092, 1092, 1092, 1024, 1024, 1024, 1024};

[0136] shiftC = 11

[0137] – If (RspCW[i] == 0)

[0138] ChromaScaleCoef[i] = (1 << shiftC)

[0139] – Otherwise (RspCW[i] != 0), ChromaScaleCoef[i] = ChromaResidualScaleLut[RspCW[i] >> 1]

[0140] 2.6.2.4 Use of ILR

[0141] On the encoder side, each picture (or slice group) is first transformed to the integer domain. And all encoding and decoding processes are performed in the integer domain. For intra prediction, neighboring blocks are in the integer domain; for inter prediction, the reference blocks (generated from the original domain in the decoded picture buffer) are first transformed to the integer domain. Then the residuals are generated and encoded / decoded into a bitstream.

[0142] After the entire picture (or slice group) is encoded / decoded, the samples in the integer domain are transformed to the original domain, and then the deblocking filter and other filters are applied.

[0143] For the following cases, positive shaping of the prediction signal is disabled:

[0144] The current block is intra-encoded / decoded

[0145] The current block is encoded / decoded as CPR (Current Picture Reference, also known as Intra Block Copy, IBC)

[0146] The current block is encoded / decoded as a Combined Inter-Intra Mode (CIIP), and positive shaping of the intra prediction block is disabled.

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

[0148] In the current design of CPR / IBC, there are some problems.

[0149] 1) The reference area changes dynamically, which makes the encoder / decoder processing complex.

[0150] 2) Invalid block vectors are easily generated and difficult to check, which makes both the encoder and decoder complex.

[0151] 3) Irregular reference areas lead to inefficient encoding / decoding of block vectors.

[0152] 4) How to handle CTU sizes smaller than 128×128 is not clear.

[0153] 5) In the process of determining whether a BV is valid or invalid, for chrominance blocks, the decision is based on the availability of luma samples, which may lead to incorrect decisions due to the double-tree segmentation structure.

[0154] 4. Example embodiments

[0155] In some embodiments, a conventional buffer can be used for CPR / IBC blocks to obtain references.

[0156] The function isRec(x, y) is defined to indicate whether the pixel (x, y) has been reconstructed and is referenced by the IBC mode. When (x, y) is outside the picture, outside different stripes / slices / bricks, isRec(x, y) returns false; when (x, y) has not been reconstructed, isRec(x, y) returns false. In another example, when the sample point (x, y) has been reconstructed but meets some other conditions, it can also be marked as unavailable, such as outside the reference area / in different VPDUs, and isRec(x, y) returns false.

[0157] The function isRec(c, x, y) is defined to indicate whether the sample point (x, y) of component c is available. For example, if the sample point (x, y) has not been reconstructed yet, it is marked as unavailable. In another example, when the sample point (x, y) has been reconstructed but meets some other conditions, it can also be marked as unavailable, such as outside the picture / in different stripes / slices / bricks / in different VPDUs, outside the allowed reference area. When the sample point (x, y) is unavailable, isRec(c, x, y) returns false, otherwise it returns true.

[0158] In the following discussion, the reference sample points can be reconstructed sample points. Note that the "pixel buffer" can respond to "a buffer for one color component" or "a buffer for multiple color components".

[0159] Reference buffer for CPR / IBC

[0160] 1. It is proposed to use an M×N pixel buffer to store the luma reference sample points for CPR / IBC.

[0161] a. In one example, the buffer size is 64×64.

[0162] b. In one example, the buffer size is 128×128.

[0163] c. In one example, the buffer size is 64×128.

[0164] d. In one example, the buffer size is 128×64.

[0165] e. In one example, N is equal to the height of the CTU.

[0166] f. In one example, N = nH, where H is the height of the CTU and n is a positive integer.

[0167] g. In one example, M is equal to the width of the CTU.

[0168] h. In one example, M = mW, where W is the width of the CTU and m is a positive integer.

[0169] i. In one example, the buffer size is not equal to the CTU size, such as 96×128 or 128×96.

[0170] j. In one example, the buffer size is equal to the CTU size.

[0171] k. In one example, M = mW and N = H, where W and H are the width and height of the CTU, and m is a positive integer.

[0172] l. In one example, M = W and N = nH, where W and H are the width and height of the CTU, and n is a positive integer.

[0173] m. In one example, M = mW and N = nH, where W and H are the width and height of the CTU, and m and n are positive integers.

[0174] n. In the above examples, m and n can depend on the CTU size.

[0175] i. In one example, when the CTU size is 128×128, m = 1 and n = 1.

[0176] ii. In one example, when the CTU size is 64×64, m = 4 and n = 1.

[0177] iii. In one example, when the CTU size is 32×32, m = 16 and n = 1.

[0178] iv. In one example, when the CTU size is 16×16, m = 64 and n = 1.

[0179] o. Alternatively, the buffer size corresponds to the CTU size.

[0180] p. Alternatively, the buffer size corresponds to the Virtual Pipeline Data Unit (VPDU) size.

[0181] q. M and / or N can be signaled from the encoder to the decoder, such as in the VPS / SPS / PPS / picture header / slice header / tile group header.

[0182] 2. In different profiles / levels / layers defined in the standard, M and / or N can be different. It is proposed to use another Mc×Nc pixel buffer to store chrominance reference samples for CPR / IBC.

[0183] a. In one example, for 4:2:0 video, Mc = M / 2 and Nc = N / 2

[0184] b. In one example, for 4:4:4 video, Mc = M and Nc = N

[0185] c. In one example, for 4:2:2 video, Mc = M and Nc = N / 2

[0186] d. Alternatively, Mc and Nc can be independent of M and N.

[0187] e. In one example, the chroma buffer includes two channels corresponding to Cb and Cr.

[0188] f. In one example, Mc = M and Nc = N.

[0189] 3. It is proposed to use an M×N sample buffer to store RGB reference samples for CPR / IBC.

[0190] a. In one example, the buffer size is 64×64.

[0191] b. In one example, the buffer size is 128×128.

[0192] c. In one example, the buffer size is 64×128.

[0193] d. In one example, the buffer size is 128×64.

[0194] e. Alternatively, the buffer size corresponds to the CTU size.

[0195] f. Alternatively, the buffer size corresponds to the Virtual Pipeline Data Unit (VPDU) size. 4. It is proposed that the buffer can store reconstructed pixels before loop filtering. Loop filtering can refer to a deblocking filter, an Adaptive Loop Filter (ALF), a Sample Adaptive Offset (SAO), a cross-component ALF, or any other filter.

[0196] a. In one example, the buffer can store samples in the current CTU.

[0197] b. In one example, the buffer can store samples outside the current CTU.

[0198] c. In one example, the buffer can store samples from any part of the current picture.

[0199] d. In one example, the buffer can store samples from other pictures.

[0200] 5. It is proposed that the buffer can store the reconstructed pixels after loop filtering. Loop filtering can refer to a deblocking filter, an adaptive loop filter (ALF), sample adaptive offset (SAO), cross-component ALF, or any other filter.

[0201] a. In one example, the buffer can store samples in the current CTU.

[0202] b. In one example, the buffer can store samples outside the current CTU.

[0203] c. In one example, the buffer can store samples from any part of the current picture.

[0204] d. In one example, the buffer can store samples from other pictures.

[0205] 6. It is proposed that the buffer can store both the reconstructed samples before loop filtering and the reconstructed samples after loop filtering. Loop filtering can refer to a deblocking filter, an adaptive loop filter (ALF), sample adaptive offset (SAO), cross-component ALF, or any other filter.

[0206] a. In one example, the buffer can store both samples from the current picture and samples from other pictures, depending on the availability of these samples.

[0207] b. In one example, the reference samples from other pictures are from the reconstructed samples after loop filtering.

[0208] c. In one example, the reference samples from other pictures are from the reconstructed samples before loop filtering.

[0209] 7. It is proposed that the buffer stores samples with a given bit-depth, where the given bit-depth can be different from the bit-depth of the coded / decoded video data.

[0210] a. In one example, the bit-depth of the reconstructed buffer / coded video data is greater than the bit-depth of the IBC reference samples stored in the buffer.

[0211] b. In one example, even when the internal bit-depth is different from the input bit-depth of the video sequence, such as (10 bits vs 8 bits), the IBC reference samples are stored aligned with the input bit-depth.

[0212] c. In one example, the bit-depth is the same as the bit-depth of the reconstructed buffer.

[0213] d. In one example, the bit-depth is the same as the bit-depth of the input image / video.

[0214] e. In one example, the bit depth is the same as a predefined number.

[0215] f. In one example, the bit depth depends on the profile of the standard.

[0216] g. In one example, the bit depth or the bit depth difference compared to the output bit depth / input bit depth / internal bit depth can be signaled in the SPS / PPS / sequence header / picture header / strip header / slice group header / slice header or other types of video data units.

[0217] h. The proposed method can be applied together with the proposed buffer definitions mentioned in other profiles. Alternatively, they can also be applicable to existing designs of IBC.

[0218] i. The bit depth of each color component of the buffer can be different.

[0219] Buffer Initialization

[0220] 8. It is proposed to initialize the buffer with a given value.

[0221] a. In one example, the buffer is initialized with a given value.

[0222] i. In one example, the given value can depend on the input bit depth and / or the internal bit depth.

[0223] ii. In one example, the buffer is initialized with a mid - grey value (e.g., 128 for an 8 - bit signal or 512 for a 10 - bit signal).

[0224] iii. In one example, when ILR is used, the buffer is initialized with forwardLUT(m). For example, m = 1<<(Bitdepth - 1).

[0225] b. Alternatively, the buffer is initialized with the value signaled in the SPS / VPS / APS / PPS / sequence header / slice group header / picture header / slice / CTU / coded unit / VPDU / region.

[0226] c. In one example, the given value can be derived from the samples of the previously decoded picture or strip or CTU row or CTU or CU.

[0227] d. For different color components, the given value can be different.

[0228] 9. Alternatively, it is proposed to initialize the buffer with the decoded pixels from the previously coded block.

[0229] a. In one example, the decoded pixels are those before loop filtering.

[0230] b. In one example, when the buffer size is a CTU, if available, the buffer is initialized with the decoded pixels of the previously decoded CTU.

[0231] c. In one example, when the buffer size is 64×64, if available, its buffer size is initialized with the decoded pixels of the previously decoded 64×64 block.

[0232] d. Additionally, alternatively, if no previously encoded or decoded block is available, the method in item 8 can be applied.

[0233] Reference to the buffer

[0234] 10. For a block that uses the pixels in the buffer as a reference, it can use the position (x, y) in the buffer to indicate where to obtain the reference, where x = 0, 1, 2, …, M - 1; y = 0, 1, 2, …, N - 1.

[0235] 11. Alternatively, the reference position can be represented as l = y * M + x, where l = 0, 1, …, M * N - 1.

[0236] 12. Representing the upper - left corner position of the block related to the current CTU as (x0, y0), the block vector (BVx, BVy) = (x - x0, y - y0) can be transmitted to the decoder to indicate where to obtain the reference in the buffer.

[0237] 13. Alternatively, the block vector (BVx, BVy) can be defined as (x - x0+Tx, y - y0+Ty), where Tx and Ty are predefined offsets.

[0238] 14. For any pixel (x0, y0) and (BVx, BVy), its reference in the buffer can be found at (x0 + BVx, y0 + BVy).

[0239] a. In one example, when (x0 + BVx, y0 + BVy) is outside the buffer, it will be clipped to the boundary.

[0240] b. Alternatively, when (x0 + BVx, y0 + BVy) is outside the buffer, its reference value is predefined as a given value, such as medium gray.

[0241] c. Alternatively, the reference position is defined as ((x0 + BVx) mod M, (y0 + BVy) mod N), such that it is always within the buffer.

[0242] 15. For any pixel (x0, y0) and (BVx, BVy), when (x0 + BVx, y0 + BVy)

[0243] is outside the buffer, its reference value can be derived from the values in the buffer.

[0244] a. In one example, the value is derived from the sample point ((x0 + BVx) mod M, (y0 + BVy) mod N) in the buffer.

[0245] b. In one example, the value is derived from the sample point ((x0 + BVx) mod M, clip(y0 + BVy, 0, N - 1)) in the buffer.

[0246] c. In one example, the value is derived from the sample point (clip(x0 + BVx, 0, M - 1), (y0 + BVy) mod N) in the buffer.

[0247] d. In one example, the value is derived from the sample point (clip(x0 + BVx, 0, M - 1), clip(y0 + BVy, 0, N - 1)) in the buffer.

[0248] 16. It may not allow specific coordinates outside the buffer range.

[0249] a. In one example, for any pixel (x0, y0) and block vector (BVx, BVy) relative to the upper left corner of the CTU, the bitstream constraint is that y0 + BVy should be in the range [0,..., N - 1].

[0250] b. In one example, for any pixel (x0, y0) and block vector (BVx, BVy) relative to the upper left corner of the CTU, the bitstream constraint is that x0 + BVx should be in the range [0,..., M - 1].

[0251] c. In one example, for any pixel (x0, y0) and block vector (BVx, BVy) relative to the upper left corner of the CTU, the bitstream constraint is that y0 + BVy should be in the range [0,..., N - 1], and x0 + BVx should be in the range [0,..., M - 1].

[0252] 17. When the signaled or derived block vector of a block points to somewhere outside the buffer, padding can be applied according to the buffer.

[0253] a. In one example, the value of any sample point outside the buffer is defined with a predefined value.

[0254] i. In one example, the value can be 1<<(Bitdepth-1). For example, for an 8-bit signal it is 128, and for a 10-bit signal it is 512.

[0255] ii. In one example, when ILR is used, the value can be forwardLUT(m). For example, m = 1<<(Bitdepth-1).

[0256] iii. Alternatively, the indication of the predefined value can be signaled or indicated at the SPS / PPS / sequence header / picture header / slice header / slice group / slice / CTU / CU level.

[0257] b. In one example, any sample outside the buffer is defined as the value of the nearest sample in the buffer.

[0258] 18. The method of handling out-of-buffer references can be different in the horizontal and vertical directions, or can be different according to the position of the current block (e.g., whether it is closer to the picture boundary).

[0259] a. In one example, when y0+BVy is outside [0, N-1], the sample value of (x0+BVx, y0+BVy) is specified as a predefined value.

[0260] b. In one example, when x0+BVx is outside [0, M-1], the sample value of (x0+BVx, y0+BVy) is specified as a predefined value.

[0261] c. Alternatively, the sample value of (x0+BVx, y0+BVy) is specified as the sample value of ((x0+BVx) mod M, y0+BVy), and if ((x0+BVx) mod M, y0+BVy) is still outside the buffer, other methods can be called to further derive the value.

[0262] d. Alternatively, the sample value of (x0+BVx, y0+BVy) is specified as the sample value of (x0+BVx, (y0+BVy) mod N), and if (x0+BVx, (y0+BVy) mod N) is still outside the buffer, other methods can be called to further derive the value.

[0263] Block vector representation

[0264] 19. Each component or one of the components of the block vector (BVx, BVy) can be normalized to a specific range.

[0265] a. In one example, BVx can be replaced by (BVx mod M).

[0266] b. Alternatively, BVx can be replaced by ((BVx + X) mod M) - X, where X is a predefined value.

[0267] i. In one example, X is 64.

[0268] ii. In one example, X is M / 2;

[0269] iii. In one example, X is the horizontal coordinate of the block relative to the current CTU.

[0270] c. In one example, BVy can be replaced by (BVy mod N).

[0271] d. Alternatively, BVy can be replaced by ((BVy + Y) mod N) - Y, where Y is a predefined value.

[0272] i. In one example, Y is 64.

[0273] ii. In one example, Y is N / 2;

[0274] iii. In one example, Y is the vertical coordinate of the block relative to the current CTU.

[0275] 20. BVx and BVy can have different normalization ranges.

[0276] 21. The block vector difference (BVDx, BVDy) can be normalized to a specific range.

[0277] a. In one example, BVDx can be replaced by (BVDx mod M), where the function mod returns the remainder.

[0278] b. Alternatively, BVDx can be replaced by ((BVDx + X) mod M) - X, where X is a predefined value.

[0279] i. In one example, X is 64.

[0280] ii. In one example, X is M / 2;

[0281] c. In one example, BVy can be replaced by (BVDy mod N).

[0282] d. Alternatively, BVy can be replaced by ((BVDy + Y) mod N) - Y, where Y is a predefined value.

[0283] i. In one example, Y is 64.

[0284] ii. In one example, Y is N / 2;

[0285] 22. BVDx and BVDy can have different normalization ranges.

[0286] Validity check of block vector

[0287] Represent the width and height of the IBC buffer as W buf and H buf . For a W×H block (which can be a luminance block, chrominance block, CU, TU, 4×4, 2×2, or other sub-block) starting from (X, Y) relative to the upper left corner of the picture, the following can be applied to determine whether the block vector (BVx, BVy) is valid. Assume W pic and H pic are the width and height of the picture; and W ctu and H ctu are the width and height of the CTU. The function floor(x) returns the largest integer not greater than x. The function isRec(x, y) returns whether the sample point (x, y) has been reconstructed.

[0288] 23. Even if any reference position is outside the picture boundary, the block vector (BVx, BVy) can be set to be valid.

[0289] a. In one example, even if X + BVx < 0, the block vector can be set to be valid.

[0290] b. In one example, even if X + W + BVx > W pic , the block vector can be set to be valid.

[0291] c. In one example, even if Y + BVy < 0, the block vector can be set to be valid.

[0292] d. In one example, even if Y + H + BVy > H pic , the block vector can be set to be valid.

[0293] 24. Even if any reference position is outside the current CTU row, the block vector (BVx, BVy) can be set to be valid.

[0294] a. In one example, even if Y + BVy < floor(Y / H ctu ) * H ctu , the block vector can be set to be valid.

[0295] b. In one example, even if Y + H + BVy >= floor(Y / H ctu ) * H ctu + H ctu , the block vector can be set to be valid.

[0296] 25. Even if any reference position is outside the current CTU and the left (n - 1) CTUs, the block vector (BVx, BVy) can be set to valid, where n is the number of CTUs (including or not including the current CTU) that can be used as the reference region for IBC.

[0297] a. In one example, even if X + BVx < floor(X / W ctu ) * W ctu - (n - 1) * W ctu , the block vector can be set to valid.

[0298] b. In one example, even if X + W + BVx > floor(X / W ctu ) * W ctu + W ctu , the block vector can be set to valid.

[0299] 26. Even if a specific sample point has not been reconstructed yet, the block vector (BVx, BVy) can be set to valid.

[0300] a. In one example, even if isRec(X + BVx, Y + BVy) is false, the block vector can be set to valid.

[0301] b. In one example, even if isRec(X + BVx + W - 1, Y + BVy) is false, the block vector can be set to valid.

[0302] c. In one example, even if isRec(X + BVx, Y + BVy + H - 1) is false, the block vector can be set to valid.

[0303] d. In one example, even if isRec(X + BVx + W - 1, Y + BVy + H - 1) is false, the block vector can be set to valid.

[0304] 27. When the block is not the first CTU in the CTU row, the block vector (BVx, BVy) can always be set to valid.

[0305] a. Alternatively, the block vector can always be set to valid.

[0306] 28. When all of the following 3 conditions are met, the block vector (BVx, BVy) can always be set to valid

[0307] · X + BVx >= 0

[0308] · Y + BVy >= floor(Y / H ctu )

[0309] ·isRec(X + BVx + W - 1, Y + BVy + H - 1) == true

[0310] a. Alternatively, when all three conditions are met for the block of the first CTU in a CTU row, the block vector can always be set to valid.

[0311] 29. When the block vector (BVx, BVy) is valid, the sample copy of the block can be based on the block vector.

[0312] a. In one example, the prediction of the sample (X, Y) can be according to ((X + BVx) % W buf , (Y + BVy) % H buf ).

[0313] Buffer update

[0314] 30. When encoding or decoding a new picture or slice, the buffer can be reset.

[0315] a. The term "reset" can mean that the buffer is initialized.

[0316] b. The term "reset" can mean that all samples / pixels in the buffer are set to a given value (e.g., 0 or -1).

[0317] 31. When encoding or decoding of a VPDU is completed, the buffer can be updated with the reconstructed value of the VPDU.

[0318] 32. When encoding or decoding of a CTU is completed, the buffer can be updated with the reconstructed value of the CTU.

[0319] a. In one example, when the buffer is not full, the buffer can be updated CTU by CTU sequentially.

[0320] b. In one example, when the buffer is full, the buffer area corresponding to the oldest CTU will be updated.

[0321] c. In one example, when M = mW and N = H (W and H are CTU sizes; M and N are buffer sizes) and the previously updated area starts from (kW, 0), the next starting position to be updated will be ((k + 1)W mod M, 0).

[0322] 33. The buffer can be reset at the start of each CTU row.

[0323] a. Alternatively, the buffer can be reset when starting to decode each CTU.

[0324] b. Alternatively, the buffer can be reset when starting to decode a slice.

[0325] c. Alternatively, the buffer can be reset when starting to decode a slice group / picture.

[0326] 34. When finishing encoding / decoding the block starting from (x, y), the corresponding area of the buffer starting from (x, y) will be updated with the reconstruction according to the block.

[0327] a. In one example, (x, y) is the position relative to the upper left corner of the CTU.

[0328] 35. When finishing encoding / decoding the block relative to the picture, the corresponding area of the buffer will be updated with the reconstruction according to the block.

[0329] a. In one example, the value at the position (x mod M, y mod N) in the buffer can be updated with the reconstructed pixel value at the position (x, y) relative to the upper left corner of the picture.

[0330] b. In one example, the value at the position (x mod M, y mod N) in the buffer can be updated with the reconstructed pixel value at the position (x, y) relative to the upper left corner of the current slice.

[0331] c. In one example, the value at the position (x mod M, y mod N) in the buffer can be updated with the reconstructed pixel value at the position (x, y) relative to the upper left corner of the current CTU row.

[0332] d. In one example, the value in the buffer can be updated with the reconstructed pixel value after bit depth alignment.

[0333] 36. When finishing encoding / decoding the block starting from (x, y), the corresponding area of the buffer starting from (xb, yb) will be updated with the reconstruction according to the block, where (xb, yb) and (x, y)

[0334] are two different coordinates.

[0335] a. In one example, (x, y) is the position related to the upper left corner of the CTU, and (xb, yb) is (x + update_x, y + update_y), where update_x and update_y point to the updatable positions in the buffer.

[0336] 37. For the above examples, the reconstructed value of the block can indicate the reconstructed value before applying the filter (e.g., deblocking filter).

[0337] a. Alternatively, the reconstructed value of the block can indicate the reconstructed value after applying the filter (e.g., deblocking filter).

[0338] 38. When the buffer is updated according to the reconstructed sample, the reconstructed sample can be modified first before being stored. For example, the sample bit depth can be changed.

[0339] a. In one example, the buffer is updated with the reconstructed sample value after bit depth alignment with the bit depth of the buffer.

[0340] b. In one example, the buffer value is updated according to the value {p + [1 << (b - 1)]} >> b, where p is the reconstructed sample value and b is a predefined bit shift value.

[0341] c. In one example, the buffer value is updated according to the value clip({p + [1 << (b - 1)]} >> b, 0, (1 << bitdepth) - 1), where p is the reconstructed sample value, b is a predefined bit shift value, and bitdepth is the buffer bit depth.

[0342] d. In one example, the buffer value is updated according to the value {p + [1 << (b - 1) - 1]} >> b, where p is the reconstructed sample value and b is a predefined bit shift value.

[0343] e. In one example, the buffer value is updated according to the value clip({p + [1 << (b - 1) - 1]} >> b, 0, (1 << bitdepth) - 1), where p is the reconstructed sample value, b is a predefined bit shift value, and bitdepth is the buffer bit depth.

[0344] f. In one example, the buffer value is updated according to the value p >> b.

[0345] g. In one example, the buffer value is updated according to the value clip(p >> b, 0, (1 << bitdepth) - 1), where bitdepth is the buffer bit depth.

[0346] h. In the above examples, b can be the reconstructed bit depth minus the input sample bit depth. 39. When using the buffer sample to form a prediction, preprocessing can be applied.

[0347] a. In one example, the predicted value is p << b, where p is the sample value in the buffer and b is a predefined value.

[0348] b. In one example, the predicted value is clip(p << b, 0, 1 << bitdepth), where bitdepth is the bit depth of the reconstructed sample.

[0349] c. In one example, the predicted value is (p << b) + (1 << (bitdepth - 1)), where p is the sample value in the buffer, b is a predefined value, and bitdepth is the bit depth of the reconstructed sample.

[0350] d. In the above example, b can be the reconstructed bit depth minus the input sample bit depth.

[0351] 40. The buffer can be updated in a given order.

[0352] a. In one example, the buffer can be updated sequentially.

[0353] b. In one example, the buffer can be updated according to the order of the reconstructed blocks.

[0354] 41. When the buffer is full, the samples in the buffer can be replaced with the latest reconstructed samples.

[0355] a. In one example, the samples can be updated in a first-in, first-out manner.

[0356] b. In one example, the oldest sample will be replaced.

[0357] c. In one example, the samples can be assigned priorities and replaced according to the priorities.

[0358] d. In one example, the samples can be marked as "long-term" so that other samples will be replaced first.

[0359] e. In one example, flags can be transmitted together with the blocks to indicate high priority.

[0360] f. In one example, numbers can be transmitted together with the blocks to indicate priorities.

[0361] g. In one example, the samples from the reconstructed blocks with specific characteristics will be assigned higher priorities so that other samples will be replaced first.

[0362] i. In one example, when the percentage of the samples decoded and encoded in the IBC mode is greater than the threshold, all the samples of the block can be assigned high priorities.

[0363] ii. In one example, when the percentage of the samples decoded and encoded in the Palette mode is greater than the threshold, all the samples of the block can be assigned high priorities.

[0364] iii. In one example, when the percentage of the samples decoded and encoded in the IBC or Palette mode is greater than the threshold, all the samples of the block can be assigned high priorities.

[0365] iv. In one example, when the percentage of samples decoded / encoded in transform skip mode is greater than a threshold, all samples of a block can be assigned a high priority.

[0366] v. The threshold can vary according to block size, color component, CTU size.

[0367] vi. The threshold can be signaled in the SPS / PPS / sequence header / slice header / slice group / slice level / region.

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

[0369] i. In one example, when the number of available samples in the buffer is equal to or greater than 64×64×3 luma samples, the buffer can be determined to be full.

[0370] Optional buffer combinations

[0371] 42. Instead of always using the three previously decoded 64×64 blocks as the reference region, it is proposed to adaptively change it based on the position of the current block (or VPDU).

[0372] a. In one example, when decoding / encoding a 64×64 block, the three previous 64×64 blocks can be used as references. Compared with Figure 2 more combinations of the previous 64×64 blocks can be applied. Figure 2 Examples of different combinations of the previous 64×64 blocks are shown.

[0373] 43. Instead of using the z-scan order, the vertical scan order can be utilized instead.

[0374] a. In one example, when a block is divided into 4 VPDUs with indices 0…3 in z-scan order, the encoding / decoding order is 0, 2, 1, 3.

[0375] b. In one example, when decoding / encoding a 64×64 block, the three previous 64×64 blocks can be used as references. Compared with Figure 2 more encoding / decoding orders of the 64×64 blocks can be applied. Figure 4 Examples of different encoding / decoding orders of the 64×64 blocks are shown.

[0376] c. Alternatively, the above method can be applied only to screen content encoding / decoding.

[0377] d. Alternatively, the above method can be applied only when CPR is enabled for a slice / slice group / picture.

[0378] e. Alternatively, the above method can be applied only when CPR is enabled for a CTU or a CTU row.

[0379] Virtual IBC buffer

[0380] Hereinafter, the width and height of the VPDU are represented as W VPDU (e.g., 64) and H VPDU (e.g., 64) in the luma samples, respectively. Alternatively, W VPDU and / or H VPDU can represent the width and / or height of other video units (e.g., CTUs).

[0381] 44. A virtual buffer can be maintained to keep track of the IBC reference region state.

[0382] a. In one example, the size of the virtual buffer is m W VPDU x n H VPDU .

[0383] i. In one example, m equals 3 and n equals 2.

[0384] ii. In one example, m and / or n can depend on the picture resolution, CTU size.

[0385] iii. In one example, m and / or n can be signaled or predefined.

[0386] b. In one example, the methods described in the above bullets and sub-bullets can be applied to the virtual buffer.

[0387] c. In one example, a sample (x, y) relative to the top-left corner of the picture / strip / slice / block can be mapped to (x % (mW VPDU ), y % (nH VPDU ))

[0388] 45. An array can be used to keep track of the availability of each sample associated with the virtual buffer.

[0389] a. In one example, a flag can be associated with a sample in the virtual buffer to specify whether the sample in the buffer can be used as an IBC reference.

[0390] b. In one example, each 4×4 block containing luma and chroma samples can share a flag to indicate whether any sample associated with the block can be used as an IBC reference.

[0391] c. In one example, an array corresponding to 3x2 VPDUs (e.g., each 4x4 block can share the same availability flag) is maintained to track the availability of IBC reference samples.

[0392] d. In one example, an array corresponding to 4x2 VPDUs (e.g., each 4x4 block can share the same availability flag) is maintained to track the availability of IBC reference samples.

[0393] 46. After decoding a VPDU or a video unit is completed, specific samples associated with the virtual buffer can be marked as unavailable for IBC reference.

[0394] a. In one example, which samples can be marked as unavailable depends on the position of the most recently decoded VPDU.

[0395] b. When a sample is marked as unavailable, prediction based on that sample is not allowed.

[0396] i. Alternatively, other means (e.g., using default values) can be further applied to derive a predicted value to replace the unavailable sample.

[0397] 47. The position of the most recently decoded VPDU can be recorded to help identify which samples associated with the virtual buffer can be marked as unavailable.

[0398] a. In one example, when starting to decode a VPDU, specific samples associated with the virtual buffer can be marked as unavailable according to the position of the most recently decoded VPDU.

[0399] i. In one example, represent (xPrevVPDU, yPrevVPDU) as the upper left corner position relative to the upper left corner of the picture / strip / slice / block / other video processing unit of the most recently decoded VPDU. If yPrevVPDU % (nH VPDU ) is equal to 0, the specific position (x, y) can be marked as unavailable.

[0400] 1. In one example, x can be in a range, such as [xPrevVPDU - 2W VPDU + 2mW VPDU ) % mW VPDU , ((xPrevVPDU - 2W VPDU + 2m W VPDU ) % mW VPDU ) - 1 + W VPDU ;

[0401] 2. In one example, y can be in a range, such as [yPrevVPDU % (nH VPDU),(yPrevVPDU%(nH VPDU )) - 1 + H VPDU ;

[0402] 3. In one example, x can be in a range, such as [xPrevVPDU - 2W VPDU +2mW VPDU ) % mW VPDU , ((xPrevVPDU - 2W VPDU +2mW VPDU ) % mW VPDU ) - 1 + W VPDU , and y can be in a range, such as [yPrevVPDU % (nH VPDU ), (yPrevVPDU % (nH VPDU )) - 1 + H VPDU .

[0403] ii. In one example, represent (xPrevVPDU, yPrevVPDU) as the upper - left corner position relative to the upper - left corner of the picture / strip / slice / block / other video processing unit of the most recently decoded VPDU. If yPrevVPDU % (nH VPDU ) is not equal to 0, the specific position (x, y) can be marked as unavailable.

[0404] 1. In one example, x can be in a range, such as [xPrevVPDU - W VPDU +2mW VPDU ) % mW VPDU , ((xPrevVPDU - W VPDU +2mW VPDU ) % mW VPDU ) - 1 + W VPDU ;

[0405] 2. In one example, y can be in a range, such as [yPrevVPDU % (nH VPDU ), (yPrevVPDU % (nH VPDU )) - 1 + H VPDU ;

[0406] 3. In one example, x can be in a range, such as [xPrevVPDU - W VPDU +2mW VPDU ) % mW VPDU , ((xPrevVPDU - W VPDU +2mW VPDU ) % mW VPDU ) - 1 + W VPDU, and y can be within a range, such as [yPrevVPDU%(n H VPDU ),(yPrevVPDU%(n H VPDU )) - 1 + H VPDU .

[0407] 48. When the CU contains multiple VPDUs, instead of applying the IBC reference availability marking process according to the VPDU, the IBC reference availability marking process can be based on the CU.

[0408] a. In one example, when starting to decode a CU containing multiple VPDUs, before the VPDUs within the CU are decoded, the IBC reference availability marking process can be applied to each VPDU.

[0409] b. In this case, 128×64 and 64×128 IBC blocks may not be allowed.

[0410] i. In one example, the pred_mode_ibc_flag of 128×64 and 64×128 CUs may not be transmitted and can be inferred to be equal to 0.

[0411] 49. For a reference block or sub - block, it may not be necessary to check the reference availability status of the upper - right corner to determine whether the block vector associated with the reference block is valid.

[0412] a. In one example, only the upper - left, lower - left, and lower - right corners of the block / sub - block will be checked to determine whether the block vector is valid.

[0413] 50. The IBC buffer size can depend on the VPDU size (where the width / height is represented by vSize) and / or the CTB / CTU size (where the width / height is represented by ctbSize).

[0414] a. In one example, the height of the buffer can be equal to ctbSize.

[0415] b. In one example, the width of the buffer can depend on min(ctbSize, 64).

[0416] i. In one example, the width of the buffer can be (128 * 128 / vSize, min(ctbSize, 64)).

[0417] 51. The IBC buffer can contain values outside the pixel range, which indicates that this location may not be available for IBC reference, for example, not for predicting other samples.

[0418] a. The sample value can be set to a value indicating that the sample is unavailable.

[0419] b. In one example, the value can be -1.

[0420] c. In one example, the value can be any value outside [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 for encoding / decoding samples of color components.

[0421] d. In one example, the value can be any value outside [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 for encoding / decoding samples of color components.

[0422] 52. The availability flag for samples in the IBC buffer can depend on the position of the current block, the size of the current block, the CTU / CTB size, and the VPDU size. In one example, assume (xCb, yCb) represents the position of the block relative to the upper left corner of the picture; ctbSize is the size of the CTU / CTB (i.e., width and / or height); vSize = min(ctbSize, 64); wIbcBuf and hIbcBuf are the IBC buffer width and height.

[0423] a. In one example, if (xCb % vSize) equals 0 and (yCb % vSize) equals 0, a specific set of positions in the IBC buffer can be marked as unavailable.

[0424] b. In one example, when the current block size is less than the VPDU size, i.e., min(ctbSize, 64), the area marked as unavailable can be based on the VPDU size.

[0425] c. In one example, when the current block size is greater than the VPDU size, i.e., min(ctbSize, 64), the area marked as unavailable can be based on the CU size.

[0426] 53. When starting to decode a video unit (e.g., VPDU(xV, yV)) relative to the upper left corner position of the picture, the corresponding position in the IBC buffer can be set to a value outside the pixel range.

[0427] a. In one example, the buffer sample at position (x % wIbcBuf, y % hIbcBuf) in the buffer will be set to the value -1, where x = xV, …, xV + ctbSize - 1 and y = yV, …, yV + ctbSize - 1. Here, wIbcBuf and hIbcBuf are the IBC buffer width and height, and ctbSize is the width of the CTU / CTB.

[0428] i. In one example, hIbcBuf can be equal to ctbSize.

[0429] 54. Bitstream consistency constraints can be based on the values of the samples in the IBC buffer.

[0430] a. In one example, if the reference block associated with the block vector in the IBC buffer contains values outside the pixel range, the bitstream may be illegal.

[0431] 55. Bitstream consistency constraints can be set according to the availability indication in the IBC buffer.

[0432] a. In one example, if any reference sample mapped in the IBC buffer is marked as unavailable for encoding / decoding a block, the bitstream may be illegal.

[0433] b. In one example, when using a singletree, if any luma reference sample mapped in the IBC buffer for encoding / decoding a block is marked as unavailable, the bitstream may be illegal.

[0434] c. The consistency bitstream can satisfy that for an IBC encoded / decoded block, the associated block vector can point to a reference block mapped in the IBC buffer, and each luma reference sample in the IBC buffer used for encoding / decoding the block should be marked as available (e.g., the value of the sample is within the range [K0, K1], where for example, K0 is set to 0, and K1 is set to (1 << BitDepth - 1), where BitDepth is the internal bit depth or the input bit depth).

[0435] 56. Bitstream consistency constraints can depend on the split tree type and the encoding / decoding treeType (tree type) of the current CU.

[0436] a. In one example, if a dualtree is allowed at a high level (e.g., slice / picture / tile / strip) and the current video block (e.g., CU / PU / CB / PB) is encoded / decoded with a singletree, the bitstream constraints may need to check whether the positions of all components mapped in the IBC buffer are marked as unavailable.

[0437] b. In one example, if dual - tree is allowed in a high level (e.g., stripe / picture / block / tile) and the current luminance video block (e.g., CU / PU / CB / PB) is encoded / decoded with dual - tree, the bit - stream constraint may ignore whether the position of the chrominance component mapped in the IBC buffer is marked as unavailable.

[0438] i. Alternatively, in this case, the bit - stream constraint may still check whether the positions of all components mapped in the IBC buffer are marked as unavailable. c. In one example, if single - tree is used, the bit - stream constraint may ignore whether the position of the chrominance component mapped in the IBC buffer is marked as unavailable.

[0439] Improvements to the current VTM design

[0440] 57. Prediction for IBC may have lower accuracy than reconstruction.

[0441] a. In one example, the predicted value is based on the value clip{{p + [1<<(b - 1)]}>>b, 0, (1<<bitdepth)-1}<<b, where p is the reconstructed sample value, b is a predefined bit - shift value, and bitdepth is the bit - depth of the predicted sample.

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

[0443] c. In one example, the predicted value is based on the value ((p>>b)+(1<<(bitdepth - 1)))<<b, where bitdepth is the bit - depth of the predicted sample.

[0444] d. In one example, the predicted value is based on the value (clip((p>>b), 0, (1<<(bitdepth - b)))+(1<<(bitdepth - 1)))<<b, where bitdepth is the bit - depth of the predicted sample.

[0445] e. In one example, depending on whether ILR is applied, the predicted value is clipped in a different way.

[0446] f. In the above examples, b may be the reconstructed bit - depth minus the input sample bit - depth.

[0447] g. In one example, the bit depth or the bit depth difference compared to the output bit depth / input bit depth / internal bit depth can be signaled in the SPS / PPS / sequence header / picture header / slice header / tile group header / picture header or other types of video data units.

[0448] 58. Part of the prediction of IBC may have lower accuracy, and another part has the same accuracy as the reconstruction.

[0449] a. In one example, the allowed reference region may contain samples with different accuracies (e.g., bit depth).

[0450] b. In one example, the reference from other 64×64 blocks other than the current 64×64 block being decoded has low accuracy, and the reference from the current 64×64 block has the same accuracy as the reconstruction.

[0451] c. In one example, the reference from other CTUs other than the current CTU being decoded has low accuracy, and the reference from the current CTU has the same accuracy as the reconstruction.

[0452] d. In one example, the reference from a specific set of color components has low accuracy, and the reference from other color components has the same accuracy as the reconstruction.

[0453] 59. When 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.

[0454] a. In one example, when the reference region size is 128×128 and the CTU size is 64×64, the nearest 4 available CTUs in the CTU row can be used for IBC reference.

[0455] b. In one example, when the reference region size is 128×128 and the CTU size is 32×32, the nearest 16 available CTUs in the CTU row can be used for IBC reference.

[0456] 60. When the CTU size is M and the reference region size is nM, the reference region is the nearest available n - 1 CTUs in the CTU row /

[0457] in the slice.

[0458] a. In one example, when the reference region size is 128×128 or 256×64 and the CTU size is 64×64, the nearest 3 available CTUs in the CTU row can be used for IBC reference.

[0459] b. In one example, when the reference region size is 128×128 or 512×32 and the CTU size is 32×32, the 15 nearest available CTUs in the CTU row can be used for IBC reference.

[0460] 61. When the CTU size is M, the VPDU size is kM, and the reference region size is nM, the reference region is the n-k nearest available CTUs in the CTU row / slice.

[0461] a. In one example, the CTU size is 64×64, the VPDU size is also 64×64, the reference region size is 128×128, and the 3 nearest CTUs in the CTU row can be used for the IBC reference value.

[0462] b. In one example, the CTU size is 32×32, the VPDU size is also 64×64, the reference region size is 128×128, and the (16 - 4) = 12 nearest CTUs in the CTU row can be used for IBC reference.

[0463] 62. For a w×h block with the top left corner at (x, y) using IBC, there are constraints to keep the reference block away from a specific region for memory reuse, where w and h are the width and height of the current block.

[0464] a. In one example, when the CTU size is 128×128 and (x, y) = (m×64, n×64), the reference block cannot overlap with the 64×64 region starting from ((m - 2)×64, n×64).

[0465] b. In one example, when the CTU size is 128×128, the reference block cannot overlap with the w×h block with the top left corner at (x - 128, y).

[0466] c. In one example, when the CTU size is 128×128, (x + BVx, y + BVy) cannot be within the w*h block with the top left corner at (x - 128, y), where BVx and BVy represent the block vector of the current block.

[0467] d. In one example, when the CTU size is M×M and the IBC buffer size is k×M×M, the reference block cannot overlap with the w×h block with the top left corner at (x - k×M, y), where BVx and BVy represent the block vector of the current block.

[0468] e. In one example, when the CTU size is M×M and the IBC buffer size is k×M×M, (x + BVx, y + BVy) cannot be within the w×h block with the top left corner at (x - k×M, y), where BVx and BVy represent the block vector of the current block.

[0469] 63. When the CTU size is not M×M and the reference region size is nM×nM, the reference region is the nearest available n×n - 1 CTUs in the CTU row.

[0470] a. In one example, when the reference region size is 128×128 and the CTU size is 64×64, the nearest 3 available CTUs in the CTU row can be used for IBC reference.

[0471] b. In one example, when the reference region size is 128×128 and the CTU size is 32×32, the nearest 15 available CTUs in the CTU row can be used for IBC reference.

[0472] 64. For a CU within a 64×64 block starting from (2m*64, 2n*64) (i.e., the upper - left 64×64 block in a 128×128 CTU), its IBC prediction can be based on the reconstructed samples in the 64×64 blocks starting from ((2m - 2)*64, 2n*64), from ((2m - 1)*64, 2n*64), from ((2m - 1)*64, (2n + 1)*64), and the current 64×64 block.

[0473] 65. For a CU within a 64×64 block starting from ((2m + 1)*64, (2n + 1)*64) (i.e., the lower - right 64×64 block in a 128×128 CTU), its IBC prediction can be based on the current 128×128 CTU.

[0474] 66. For a CU within a 64×64 block starting from ((2m + 1)*64, 2n*64) (i.e., the upper - right 64×64 block in a 128×128 CTU), its IBC prediction can be based on the reconstructed samples in the 64×64 blocks starting from ((2m - 1)*64, 2n*64), from ((2m - 1)*64, (2n + 1)*64), from (2m*64, 2n*64), and the current 64×64 block.

[0475] a. Alternatively, if the 64×64 block starting from (2m*64, (2n + 1)*64) has been reconstructed, the IBC prediction can be based on the reconstructed samples in the 64×64 blocks starting from ((2m - 1)*64, 2n*64), from (2m*64, 2n*64), from (2m*64, (2n + 1)*64), and the current 64×64 block.

[0476] 67. For the CUs within the 64×64 block starting from (2m*64, (2n+1)*64) (i.e., the bottom-left 64×64 block in a 128×128 CTU), the IBC prediction can be based on the reconstructed samples in the 64×64 block starting from ((2m-1)*64, (2n+1)*64), the 64×64 block starting from (2m*64, 2n*64), the 64×64 block starting from ((2m+1)*64, 2n*64), and the current 64×64 block.

[0477] a. Alternatively, if the 64×64 block starting from ((2m+1)*64, 2n*64) has not been reconstructed yet, the IBC prediction can be based on the reconstructed samples in the 64×64 block starting from ((2m-1)*64, 2n*64), the 64×64 block starting from ((2m-1)*64, (2n+1)*64), the 64×64 block starting from (2m*64, 2n*64), and the current 64×64 block.

[0478] 68. It is proposed to adjust the reference region based on which 64×64 blocks the current CU belongs to.

[0479] a. In one example, for a CU starting from (x, y), when (y>>6)&1 == 0, two or up to two previous 64×64 blocks starting from ((x>>6<<6)-128, y>>6<<6) and ((x>>6<<6)-64, y>>6<<6)

[0480] can be referenced by the IBC mode.

[0481] b. In one example, for a CU starting from (x, y), when (y>>6)&1 == 1, one previous 64×64 block starting from ((x>>6<<6)-64, y>>6<<6) can be referenced by the IBC mode.

[0482] 69. For a block starting from (x, y) and having a block vector (BVx, BVy), if isRec(((x+BVx)>>6<<6)+128 - (((y+BVy)>>6)&1)*64+(x%64),

[0483] ((y+BVy)>>6<<6)+(y%64)) is true, then the block vector is invalid.

[0484] a. In one example, the block is a luma block.

[0485] b. In one example, the block is a chroma block in 4:4:4 format.

[0486] c. In one example, the block contains both luma and chroma components.

[0487] 70. For a chrominance block in 4:2:0 format starting from (x, y) and having a block vector (BVx, BVy), if isRec(((x + BVx) >> 5 << 5) + 64 - (((y + BVy) >> 5) & 1) * 32 + (x % 32), ((y + BVy) >> 5 << 5) + (y % 32)) is true, then the block vector is invalid.

[0488] 71. The determination of whether a BV is invalid for a block of component c can depend on the availability of samples of component X, rather than just checking the luma samples.

[0489] a. For a block of component c starting from (x, y) and having a block vector (BVx, BVy), if isRec(c, ((x + BVx) >> 6 << 6) + 128 - (((y + BVy) >> 6) & 1) * 64 + (x % 64), ((y + BVy) >> 6 << 6) + (y % 64)) is true, then the block vector can be considered invalid.

[0490] i. In one example, the block is a luma block (e.g., c is the luma component, or for RGB coding / decoding is the G component).

[0491] ii. In one example, the block is a chrominance block in 4:4:4 format (e.g., c is the cb or cr component, or for RGB coding / decoding is the B / R component).

[0492] iii. In one example, the availability of samples of both the luma component and the chrominance component can be checked, e.g., the block contains both the luma component and the chrominance component.

[0493] b. For a 4:2:0 format chrominance block starting from (x, y) of component c and having a block vector (BVx, BVy), if isRec(c, ((x + BVx) >> 5 << 5) + 64 - (((y + BVy) >> 5) & 1) * 32 + (x % 32), ((y + BVy) >> 5 << 5) + (y % 32)) is true, then the block vector can be considered invalid.

[0494] c. For a chrominance block or sub - block starting from (x, y) of component c and having a block vector (BVx, BVy), if isRec(c, x + BVx + Chroma_CTU_size, y) of the chrominance component is true, then the block vector can be considered invalid, where Chroma_CTU_size is the CTU size of the chrominance component.

[0495] i. In one example, for 4:2:0 format, Chroma_CTU_size can be 64.

[0496] ii. In one example, the chroma sub-block may be a 2×2 block in 4:2:0 format.

[0497] iii. In one example, the chroma sub-block may be a 4×4 block in 4:4:4 format.

[0498] iv. In one example, the chroma sub-block may correspond to the smallest CU size in the luminance component.

[0499] 1. Alternatively, the chroma sub-block may correspond to the smallest CU size of the chroma component.

[0500] 72. For all the above-mentioned bullet points, it is assumed that the reference buffer contains multiple M×M blocks (M = 64). However, it can be extended to other cases, such as the reference buffer containing multiple N×M blocks (e.g., N = 128, M = 64).

[0501] 73. For all the above-mentioned bullet points, a further restriction can be applied, i.e., the reference buffer should be within the same tile / slice / slice group / strip as the current block.

[0502] a. In one example, if a part of the reference buffer is outside the current tile / slice / slice group / strip, the use of IBC can be disabled. The signaling of IBC-related syntax elements can be skipped.

[0503] b. Alternatively, if a part of the reference buffer is outside the current tile / slice / slice group / strip, IBC can still be enabled for a block. However, the block vector associated with a block can only point to the remaining reference buffer.

[0504] 74. It is proposed to use the K1 most recently decoded VPDUs in the first VPDU row of the CTU / CTB row (if available) and the K2 most recently decoded VPDUs in the second VPDU row of the CTU / CTB row (if available) as the reference region for IBC, excluding the current VPDU.

[0505] a. In one example, K1 is equal to 2 and K2 is equal to 1.

[0506] b. In one example, when the CTU / CTB size is 128×128 and the VPDU size is 64×64, the above method can be applied.

[0507] c. In one example, when the CTU / CTB size is 64×64 and the VPDU size is 64×64 and / or 32×32, the above method can be applied.

[0508] d. In one example, when the CTU / CTB size is 32×32 and the VPDU size is 32×32 or smaller, the above method can be applied.

[0509] 75. The above method can be applied to different stages.

[0510] a. In one example, the modulo operation of the block vector (BV) (e.g., a mod b) can be invoked during the availability check process of the BV to determine whether the BV is valid.

[0511] b. In one example, the modulo operation of the block vector (BV) (e.g., a mod b) can be invoked to identify the position of the reference sample in the IBC virtual buffer or the reconstructed picture buffer (e.g., before the loop filtering process) (e.g., according to the position of the current sample and the modulo result of the BV).

[0512] 5. Embodiments

[0513] 5.1 Embodiment #1

[0514] The implementation of the buffer for IBC is described as follows:

[0515] The buffer size is 128×128. The CTU size is also 128×128. For the encoding and decoding of the first CTU in the CTU row, the buffer is initialized with 128 (for 8-bit video signaling). For the encoding and decoding of the k-th CTU in the CTU row, the buffer is initialized with the reconstruction before the loop filtering of the (k - 1)-th CTU.

[0516] Figure 3 An example of the encoding and decoding of the block starting from (x, y) is shown.

[0517] When encoding and decoding the block starting from (x, y) related to the current CTU, the block vector (BVx, BVy) = (x - x0, y - y0) is transmitted to the decoder to indicate that the reference block comes from (x0, y0) in the IBC buffer. Assume that the width and height of the block are w and h respectively. When the encoding and decoding of the block are completed, the w×h area starting from (x, y) in the IBC buffer will be updated with the reconstruction of the block before the loop filtering.

[0518] 5.2 Embodiment #2

[0519] Figure 4 An example showing a possible alternative for selecting the previously encoded 64×64 block is shown.

[0520] 5.3 Embodiment #3

[0521] Figure 5Shows an example of a possible alternative way to change the encoding / decoding order of a 64×64 block.

[0522] 5.4 Embodiment #4

[0523] Figure 8 Shows another possible alternative for selecting a previously encoded / decoded 64×64 block when the decoding order of the 64×64 block is from top to bottom and from left to right.

[0524] 5.5 Embodiment #5

[0525] Figure 9 Shows another possible alternative for selecting a previously encoded / decoded 64×64 block.

[0526] 5.6 Embodiment #6

[0527] Figure 11 Shows another possible alternative for selecting a previously encoded / decoded 64×64 block when the decoding order of the 64×64 block is from left to right and from top to bottom.

[0528] 5.7 Embodiment #7

[0529] Assume that the CTU size is W×W, and the implementation of the IBC buffer at the decoder with size mM×W and bit depth B is as follows.

[0530] When starting to decode a CTU row, initialize the buffer with the value (1<<(B - 1)), and set the starting point (xb, yb) to be updated to (0, 0).

[0531] When a CU with size w×h is decoded starting from (x, y) related to the top - left corner of the CTU, the region starting from (xb + x, yb + y) with size w×h will be updated with the reconstructed pixel values of the CU after bit - depth alignment with B bits.

[0532] After the CTU is decoded, the starting point (xb, yb) to be updated will be set to ((xb + W) mod mW, 0).

[0533] When decoding an IBC CU with block vector (BVx, BVy), for any pixel (x, y) related to the top - left corner of the CTU, after bit - depth alignment with the bit depth of the prediction signal, its prediction is extracted from the buffer at the position ((x + BVx) mod mW, (y + BVy) mod W).

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

[0535] 5.8 Embodiment #8

[0536] For a luminance CU or a combined luminance / chrominance CU starting from (x, y) related to the upper left corner of the picture and a block vector (BVx, BVy), when isRec(((x + BVx) >> 6 << 6) + 128 - (((y + BVy) >> 6) & 1) * 64 + (x % 64), ((y + BVy) >> 6 << 6) + (y % 64)) is true, the block vector is invalid.

[0537] For a chrominance CU starting from (x, y) related to the upper left corner of the picture and a block vector (BVx, BVy), when isRec(((x + BVx) >> 5 << 5) + 64 - (((y + BVy) >> 5) & 1) * 32 + (x % 32), ((y + BVy) >> 5 << 5) + (y % 32)) is true, the block vector is invalid.

[0538] 5.9 Example 9

[0539] For a chrominance block or sub-block and a block vector (BVx, BVy) starting from (x, y) in 4:2:0 format related to the upper left corner of the picture, when isRec(c, (x + BVx + 64, y + BVy) is true, the block vector is invalid, where c is the chrominance component.

[0540] For a chrominance block or sub-block and a block vector (BVx, BVy) starting from (x, y) in 4:4:4 format related to the upper left corner of the picture, when isRec(c, (x + BVx + 128, y + BVy) is true, the block vector is invalid, where c is the chrominance component.

[0541] 5.10 Example #10

[0542] For a luminance CU or a combined luminance / chrominance CU starting from (x, y) related to the upper left corner of the picture and a block vector (BVx, BVy), when isRec(((x + BVx) >> 6 << 6) + 128 - (((y + BVy) >> 6) & 1) * 64 + (x % 64), ((y + BVy) >> 6 << 6) + (y % 64)) is true, the block vector is invalid.

[0543] For a chrominance block or sub-block and a block vector (BVx, BVy) starting from (x, y) in 4:2:0 format related to the upper left corner of the picture, when isRec(c, ((x + BVx) >> 5 << 5) + 64 - (((y + BVy) >> 5) & 1) * 32 + (x % 32), ((y + BVy) >> 5 << 5) + (y % 32)) is true, the block vector is invalid, where c is the chrominance component.

[0544] 5.11 Example #11

[0545] This embodiment highlights an implementation manner of maintaining two most recently decoded VPDUs in the first VPDU row of the CTU / CTB row and one most recently decoded VPDU in the second VPDU row, excluding the current VPDU.

[0546] When the VPDU decoding order is from top to bottom and from left to right, the reference region is as Figure 13 shown.

[0547] When the VPDU decoding order is from left to right and from top to bottom, and the current VPDU is not on the right side of the picture boundary, the reference region is as Figure 14 shown.

[0548] When the VPDU decoding order is from left to right and from top to bottom, and the current VPDU is on the right side of the picture boundary, the reference region can be as Figure 15 shown.

[0549] Given a luminance block (x, y) of size w×h, whether the block vector (BVx, BVy) is valid can be determined by checking the following conditions:

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

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

[0552] 5.12 Embodiment #12

[0553] If the CTU size is 192×128, a virtual buffer of size 192×128 is maintained to track the reference samples for IBC.

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

[0555] The position (xPrevVPDU, yPrevVPDU) relative to the upper left corner of the picture is recorded to represent the upper left corner sample of the most recently decoded VPDU.

[0556] 1) When starting to decode a VPDU line, all positions in the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0, 0).

[0557] 2) When starting to decode the first CU of a VPDU, the positions (x, y) (where x = (xPrevVPDU - 2WVPDU + 2mWVPDU) % (mWVPDU),.., ((xPrevVPDU - 2WVPDU + 2mWVPDU) % (mWVPDU)) - 1 + WVPDU; and y = yPrevVPDU % (nHVPDU),..,(yPrevVPDU % (nHVPDU)) - 1 + HVPDU) can be marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the position of the CU relative to the upper left corner of the picture.

[0558] 3) After decoding a CU, the positions (x, y) (where x = xCU % (mWVPDU),...,(xCU + CU_width - 1) % (mWVPDU) and y = yCU % (nHVPDU),…,(yCU + CU_height - 1) % (nHVPDU)) are marked as available.

[0559] 4) For an IBC CU with a block vector (xBV, yBV), if any position (x, y) (where x = (xCU + xBV) % (mWVPDU),...,(xCU + xBV + CU_width - 1) % (mWVPDU) and y = (yCU + yBV) % (nHVPDU),…,(yCU + yBV + CU_height - 1) % (nHVPDU)) is marked as unavailable, the block vector is considered invalid.

[0560] Figure 16 Shows the buffer status and the VPDU decoding status in the picture.

[0561] 5.13 Example #13

[0562] If the CTU size is 128×128 or the CTU size is larger than the VPDU size (e.g., 64×64 in the current design) or the CTU size is larger than the VPDU size (e.g., 64×64 in the current design), a virtual buffer with a size of 192×128 is maintained to track the reference samples for IBC. Below, when a < 0, (a % b) is defined as floor(a / b) * b, where floor(c) returns the largest integer not greater than c.

[0563] The sample point (x, y) relative to the upper left corner of the picture is associated with the position (x % 192, y % 128) relative to the upper left corner of the buffer. The following steps show how to mark the availability of the sample points associated with the virtual buffer for IBC reference.

[0564] The position (xPrevVPDU, yPrevVPDU) relative to the upper left corner of the picture is recorded to represent the upper left corner sample point of the most recently decoded VPDU.

[0565] 1) When starting to decode a VPDU row, all positions in the buffer are marked as unavailable.

[0566] (xPrevVPDU, yPrevVPDU) is set to (0, 0).

[0567] 2) When starting to decode the first CU of a VPDU,

[0568] a. If yPrevVPDU % 64 equals 0, the positions (x, y) (where x = (xPrevVPDU – 128) % 192,.., ((xPrevVPDU – 128) % 192) + 63; and y = yPrevVPDU % 128,.., (yPrevVPDU % 128) + 63) are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the position of the CU relative to the upper left corner of the picture.

[0569] b. Otherwise, the positions (x, y) (where x = (xPrevVPDU – 64) % 192,.., ((xPrevVPDU – 64) % 192) + 63; and y = yPrevVPDU % 128,.., (yPrevVPDU % 128) + 63) are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the position of the CU relative to the upper left corner of the picture.

[0570] 3) After decoding the CU, the positions (x, y) (where x = xCU % 192,...,(xCU + CU_width - 1) % 192 and y = yCU % 128,…,(yCU + CU_height - 1) % 128) are marked as available.

[0571] 4) For an IBC CU with a block vector (xBV, yBV), if any position (x, y) (where x = (xCU + xBV) % 192,..., (xCU + xBV + CU_width - 1) % 192 and y = (yCU + yBV) % 128,…, (yCU + yBV + CU_height - 1) % 128) is marked as unavailable, the block vector is considered invalid.

[0572] If the CTU size is S × S and S is not equal to 128, then Wbuf is assumed to be 128 * 128 / S. A virtual buffer of size Wbuf × S is maintained to track the reference samples used for IBC. In this case, the VPDU size is equal to the CTU size.

[0573] The position (xPrevVPDU, yPrevVPDU) relative to the upper left corner of the picture is recorded to represent the upper left corner sample of the most recently decoded VPDU.

[0574] 1) When starting to decode a VPDU row, all positions in the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0, 0).

[0575] 2) When starting to decode the first CU of a VPDU, the positions (x, y) (where x = (xPrevVPDU – W buf * S) % S,.., ((xPrevVPDU – W buf * S) % S) + S - 1; and y = yPrevVPDU % S,.., (yPrevVPDU % S) + S - 1) are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the position of the CU relative to the upper left corner of the picture.

[0576] 3) After decoding a CU, the positions (x, y) (where x = xCU % (W buf ),...,(xCU + CU_width - 1) % (W buf ) and y = yCU % S,…, (yCU + CU_height - 1) % S) are marked as available.

[0577] 4) For an IBC CU with a block vector (xBV, yBV), if any position (x, y) (where x = (xCU + xBV) % (Wbuf),...,(xCU + xBV + CU_width - 1) % (Wbuf) and y = (yCU + yBV) % S,…, (yCU + yBV + CU_height - 1) % S) is marked as unavailable, the block vector is considered invalid.

[0578] 5.14 Example #14

[0579] If the CTU size is 128×128 or the CTU size is greater than the VPDU size (e.g., 64×64 in the current design) or the CTU size is greater than the VPDU size (e.g., 64×64 in the current design), then a virtual buffer with a size of 256×128 is maintained to track the reference samples for IBC. Below, when a < 0, (a % b) is defined as floor(a / b) * b, where floor(c) returns the largest integer not greater than c.

[0580] The sample point (x, y) relative to the upper left corner of the picture is associated with the position (x % 256, y % 128) relative to the upper left corner of the buffer. The following steps show how to mark the availability of the sample points associated with the virtual buffer for IBC reference.

[0581] The position (xPrevVPDU, yPrevVPDU) relative to the upper left corner of the picture is recorded to represent the upper left corner sample point of the most recently decoded VPDU.

[0582] 1) When starting to decode a VPDU row, all positions in the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0, 0).

[0583] 2) When starting to decode the first CU of a VPDU,

[0584] a. If yPrevVPDU % 64 equals 0, then the positions (x, y) (where x = (xPrevVPDU – 128) % 256,.., ((xPrevVPDU – 128) % 256) + 63; and y = yPrevVPDU % 128,.., (yPrevVPDU % 128) + 63) are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the position of the CU relative to the upper left corner of the picture.

[0585] b. Otherwise, the positions (x, y) (where x = (xPrevVPDU – 64) % 256,.., ((xPrevVPDU – 64) % 256) + 63; and y = yPrevVPDU % 128,.., (yPrevVPDU % 128) + 63) are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set to (xCU, yCU), i.e., the position of the CU relative to the upper left corner of the picture.

[0586] 3) After decoding the CU, the positions (x, y) (where x = xCU % 256,..., (xCU + CU_width - 1) % 256 and y = yCU % 128,..., (yCU + CU_height - 1) % 128) are marked as available.

[0587] 4) For an IBC CU with a block vector (xBV, yBV), if any position (x, y) (where x = (xCU + xBV) % 256,..., (xCU + xBV + CU_width - 1) % 256 and y = (yCU + yBV) % 128,..., (yCU + yBV + CU_height - 1) % 128) is marked as unavailable, the block vector is considered invalid.

[0588] When the CTU size is not 128×128 or less than 64×64 or less than 64×64, the same process as in the previous embodiment (i.e., Embodiment #14) applies.

[0589] 5.15 Embodiment #15

[0590] The IBC reference availability marking process is described as follows. In this document, changes are indicated in bold, underlined, and italic text.

[0591] 7.3.7.1 General slice data syntax

[0592]

[0593]

[0594]

[0595] BufWidth is equal to (CtbSizeY == 128)? 256 : (128 * 128 / CtbSizeY) and BufHeight is equal to CtbSizeY.

[0596] 7.3.7.5 Coding unit syntax

[0597]

[0598]

[0599] 8.6.2 Derivation process of the motion vector components of the IBC block

[0600] 8.6.2.1 General

[0601] …

[0602] The requirement for bitstream consistency is that when the block vector validity check in Clause 8.6.3.2 is invoked with block vector mvL the process, isBVvalid shall be true.

[0603] …

[0604] 8.6.3 Decoding Process of IBC Blocks

[0605] 8.6.3.1 General

[0606] This process is called when decoding a coding unit coded in the IBC prediction mode.

[0607] The inputs to this process are as follows:

[0608] – Luminance position (xCb, yCb), specifying the top-left sample of the current coding block relative to the top-left luminance sample of the current picture

[0609] – Variable cbWidth, specifying the width of the current coding block in luminance samples

[0610] – Variable cbHeight, specifying the height of the current coding block in luminance samples

[0611] – Variables numSbX and numSbY, specifying the number of luminance coding sub-blocks in the horizontal and vertical directions

[0612] – Motion vector mv[xSbIdx][ySbIdx], where xSbIdx = 0..numSbX – 1 and ySbIdx = 0..numSbY – 1

[0613] – Variable cIdx, specifying the color component index of the current block

[0614] – (nIbcBufW) × (ctbSize) array ibcBuf

[0615] …

[0616] For each coding sub-block at sub-block index (xSbIdx, ySbIdx) (where xSbIdx = 0..numSbX – 1 and ySbIdx = 0..numSbY – 1), the following applies:

[0617] – The luminance position (xSb, ySb) specifying the top-left sample of the current coding sub-block relative to the top-left luminance sample of the current picture is derived as follows:

[0618] (xSb,ySb) = (xCb + xSbIdx * sbWidth, yCb + ySbIdx * sbHeight) (8-913)

[0619] If cIdx is equal to 0, then nIbcBufW is set to ibcBufferWidth, otherwise nIbcBufW is set to (ibcBufferWidth / SubWidthC). The following applies:

[0620] predSamples[xSb + x][ySb + y] = ibcBuf[(xSb + x + (mv[xSb][ySb][0]

[0621] >> 4)) % nIbcRefW][ySb + y + (mv[xSb][ySb][1] >> 4)]

[0622] where x = 0..sbWidth – 1 and y = 0..sbHeight – 1.

[0623] …

[0624] 8.6.3.2 Block Vector Validity Check Process

[0625] The inputs to this process are:

[0626] – The luma position (xCb, yCb), specifying the upper left corner sample of the current coded block relative to the upper left corner luma sample of the current picture sample,

[0627] – The variable cbWidth, specifying the width of the current coded block in luma samples,

[0628] – The variable cbHeight, specifying the height of the current coded block in luma samples,

[0629] – The variables numSbX and numSbY, specifying the number of luma coded sub - blocks in the horizontal and vertical directions,

[0630] – The block vector mv[xSbIdx][ySbIdx], where xSbIdx = 0..numSbX - 1, and ySbIdx = 0..numSbY - 1,

[0631] – The variable cIdx, specifying the color component index of the current block.

[0632] – (nIbcBufW) × (ctbSize) array ibcBuf

[0633] The output of this process is a flag isBVvalid indicating whether the block vector is valid.

[0634] The following applies

[0635] 1. isBVvalid is set to be equal to true.

[0636] 2. If ((yCb & (ctbSize – 1)) + mv[0][0][1] + cbHeight) > ctbSize, then isBVvalid is set to be equal to false.

[0637] 3. Otherwise, for each sub - block index xSbIdx, ySbIdx (where xSbIdx = 0..numSbX – 1, and ySbIdx = 0..numSbY – 1), its position relative to the upper left corner luma sample of ibcBuf is derived as:

[0638] xTL = (xCb + xSbIdx * sbWidth + mv[xSbIdx][ySbIdx][0]) & (nIbcBufW – 1)

[0639] yTL = (yCb & (ctbSize – 1)) + ySbIdx * sbHeight + mv[xSbIdx][ySbIdx][1]

[0640] xBR = (xCb + xSbIdx * sbWidth + sbWidth – 1 + mv[xSbIdx][ySbIdx][0]) & (nIbcBufW – 1)

[0641] yBR = (yCb & (ctbSize – 1)) + ySbIdx * sbHeight + sbHeight – 1 + mv[xSbIdx][ySbIdx] [1]

[0642] If (isDecoded[xTL >> 2][yTL >> 2] == 0) || (isDecoded[xBR >> 2][yTL >> 2] == 0) || (isDecoded[xBR >> 2][yBR >> 2] == 0), then isBVvalid is set equal to false.

[0643] 8.7.5 Image Reconstruction Process

[0644] 8.7.5.1 General

[0645] The inputs to this process are:

[0646] – The position (xCurr, yCurr), specifying the top-left sample of the current block relative to the top-left sample of the current picture component,

[0647] – The variables nCurrSw and nCurrSh, specifying the width and height of the current block respectively,

[0648] – The variable cIdx, specifying the color component of the current block,

[0649] – The (nCurrSw) x (nCurrSh) array predSamples, specifying the prediction samples of the current block,

[0650] – The (nCurrSw) x (nCurrSh) array resSamples, specifying the residual samples of the current block.

[0651] The outputs of this process are

[0652] – The reconstructed picture sample array recSamples.

[0653] – IBC reference array ibcBuf.

[0654] …

[0655] Denoting the width of ibcBuf by nIbcBufW, the following applies:

[0656] ibcBuf[(xCurr + i) & (nIbcBufW – 1)][(yCurr + j) & (ctbSize – 1)] = recSamples [xCurr + i][yCurr + j]

[0657] where i = 0..nCurrSw – 1, j = 0..nCurrSh – 1.

[0658] 5.16 Example #16

[0659] Same as the previous example, except for the following changes.

[0660]

[0661]

[0662]

[0663] BufWidth is equal to (CtbSizeY == 128)? 192 : (128 * 128 / CtbSizeY) and BufHeight is equal to CtbSizeY.

[0664] 5.17 Example #17

[0665] In this document, the changes in some examples are indicated by bold, underlined text.

[0666] 7.3.7 Syntax of strip data

[0667] 7.3.7.1 General syntax of strip data

[0668]

[0669]

[0670] 7.4.8.5 Semantics of coding / decoding units

[0671] When all of the following conditions are true, the list of history-based motion vector prediction values in the shared Merge candidate list area is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i] for i = 0..NumHmvpIbcCand–1:

[0672] – IsInSmr[x0][y0] is equal to TRUE.

[0673] – SmrX[x0][y0] is equal to x0.

[0674] – SmrY[x0][y0] is equal to y0.

[0675] For x = x0..x0+cbWidth–1 and y = y0..y0+cbHeight-1, the following are specified:

[0676] CbPosX[x][y] = x0 (7-135)

[0677] CbPosY[x][y] = y0 (7-136)

[0678] CbWidth[x][y] = cbWidth (7-137)

[0679] CbHeight[x][y] = cbHeight (7-138)

[0680] Set vSize to min(ctbSize, 64), and set wIbcBuf to (128 * 128 / ctbSize). The width and height of ibcBuf are wIbcBuf and ctbSize respectively.

[0681] If refreshIbcBuf is equal to 1, then the following applies:

[0682] – For x = x0..x0 + wIbcBuf – 1 and y = y0..y0 + ctbSize – 1, ibcBuf[x % wIbcBuf][y % ctbSize] = -1

[0683] – resetIbcBuf = 0

[0684] When for x = x0..x0 + vSize – 1 and y = y0..y0 + vSize – 1, (x0 % vSize) is equal to 0 and (y0 % vSize) is equal to 0, the following applies:

[0685] ibcBuf[x % wIbcBuf][y % ctbSize] = -1

[0686] 8.6.2 Derivation process of motion vector components of IBC blocks

[0687] 8.6.2.1 General

[0688] The input of this process is:

[0689] – 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,

[0690] – The variable cbWidth, specifying the width of the current coding block in the luminance samples,

[0691] – The variable cbHeight, specifying the height of the current coding block in the luminance samples.

[0692] The output of this process is:

[0693] – The luminance motion vector mvL with 1 / 16 fractional sample precision.

[0694] The luminance motion vector mvL is derived as follows:

[0695] – Call the derivation process of IBC luminance motion vector prediction specified in Clause 8.6.2.2 with the luminance position (xCb, yCb), the variables cbWidth and cbHeight as inputs, and the output is the luminance motion vector mvL.

[0696] – When general_merge_flag[xCb][yCb] is equal to 0, the following applies:

[0697] 1. The variable mvd is derived as follows:

[0698] mvd[0] = MvdL0[xCb][yCb][0] (8-883)

[0699] mvd[1] = MvdL0[xCb][yCb][1] (8-884)

[0700] 2. Call the rounding process of the motion vector specified in Clause 8.5.2.14 with mvX set to be equal to mvL, rightShift set to be equal to MvShift+2, leftShift set to be equal to MvShift+2 as inputs and the rounded mvL as the output.

[0701] 3. The luminance motion vector mvL is modified as follows:

[0702] u[0] = (mvL[0] + mvd[0] + 2 18 ) % 2 18 (8 - 885)

[0703] mvL[0] = (u[0] >= 2 17 )? (u[0] - 2 18 ): u[0] (8 - 886)

[0704] u[1] = (mvL[1] + mvd[1] + 2 18 ) % 2 18 (8 - 887)

[0705] mvL[1] = (u[1] >= 2 17 )? (u[1] - 2 18 ): u[1] (8 - 888)

[0706] Note 1 - The resulting values of mvL[0] and mvL[1] specified as above are always in the range -2 17 to 2 17 –1 (including -2 17 and 2 17 -1).

[0707] Call the update process of the history-based motion vector prediction value list specified in Clause 8.6.2.6 with the luminance motion vector mvL.

[0708] The requirement for bitstream consistency is that the luminance block vector mvL shall comply with the following constraints:

[0709] – ((yCb + (mvL[1] >> 4)) % wIbcBuf) + cbHeight is less than or equal to ctbSize

[0710] – For x = xCb..xCb+cbWidth–1 and y = yCb..yCb+cbHeight–1, ibcBuf[(x+(mvL[0]> >4))%wIbcBuf][(y+(mvL[1]>>4))%ctbSize] shall not be equal to -1.

[0711] 8.7.5 Picture reconstruction process

[0712] 8.7.5.1 General

[0713] The inputs to this process are:

[0714] – Position (xCurr, yCurr), specifying the top-left sample of the current block relative to the top-left sample of the current picture component,

[0715] – Variables nCurrSw and nCurrSh, specifying the width and height of the current block respectively,

[0716] – Variable cIdx, specifying the color component of the current block,

[0717] – (nCurrSw) x (nCurrSh) array predSamples, specifying the prediction samples of the current block,

[0718] – (nCurrSw) x (nCurrSh) array resSamples, specifying the residual samples of the current block.

[0719] The output of the process Yes Reconstructed picture sample array resSamples and the IBC buffer array ibcBuf 。

[0720] Depending on the value of color component cIdx, the following is specified:

[0721] – If cIdx is equal to 0, then recSamples corresponds to the reconstructed picture sample array S L , and the function clipCidx1 corresponds to Clip1 Y 。

[0722] – Otherwise, if cIdx is equal to 1, then tuCbfChroma is set to be equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cb , and the function clipCidx1 corresponds to Clip1 C 。

[0723] – Otherwise (cIdx is equal to 2), tuCbfChroma is set to be equal to tu_cbf_cr[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cr , and the function clipCidx1 corresponds to Clip1 C 。

[0724] Depending on the value of slice_lmcs_enabled_flag, the following applies:

[0725] – If slice_lmcs_enabled_flag is equal to 0, then for i = 0..nCurrSw – 1,

[0726] j = 0..nCurrSh-1, the (nCurrSw) x (nCurrSh) block of the reconstructed samples recSamples at position (xCurr, yCurr) is derived as follows:

[0727] recSamples[xCurr+i][yCurr+j] = clipCidx1(predSamples[i][j]+resSamples[i][j]) (8 - 992)

[0728] – Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:

[0729] – If cIdx equals 0, the following applies:

[0730] – Invoke the picture reconstruction and mapping process for luminance samples as specified in Clause 8.7.5.2 with the luminance position (xCurr, yCurr), block width nCurrSw, and height nCurrSh, the predicted luminance sample array predSamples, and the residual luminance sample array resSamples as inputs, and the output is the reconstructed luminance sample array recSamples.

[0731] – Otherwise (cIdx greater than 0), invoke the picture reconstruction and luma-dependent chroma residual scaling process for chrominance samples as specified in Clause 8.7.5.3 with the chrominance position (xCurr, yCurr), transform block width nCurrSw, and height nCurrSh, the coding block flag tuCbfChroma of the current chrominance transform block, the predicted chrominance sample array predSamples, and the residual chrominance sample array resSamples as inputs, and the output is the reconstructed chrominance sample array recSamples.

[0732] After decoding the current coding unit, the following applies:

[0733] For i = 0..nCurrSw–1, j = 0..nCurrSh–1

[0734] ibcBuf[(xCurr+i)%wIbcBuf][(yCurr+j)%ctbSize] = recSamples[xCurr+i] [yCurr+j].

[0735] 5.18 Example #18

[0736] In this document, changes in some examples are indicated by bold, underlined, and italic text.

[0737] 7.3.7 Syntax of Strip Data

[0738] 7.3.7.1 General Syntax of Strip Data

[0739]

[0740]

[0741] 7.4.8.5 Semantics of Coding Units

[0742] When all of the following conditions are true, update the history-based motion vector prediction value list in the shared Merge candidate list area by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand, and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i] for i = 0..NumHmvpIbcCand–1:

[0743] – IsInSmr[x0][y0] is equal to TRUE.

[0744] – SmrX[x0][y0] is equal to x0.

[0745] – SmrY[x0][y0] is equal to y0.

[0746] For x = x0..x0+cbWidth–1 and y = y0..y0+cbHeight-1, the following are specified:

[0747] CbPosX[x][y] = x0 (7-135)

[0748] CbPosY[x][y] = y0 (7-136)

[0749] CbWidth[x][y] = cbWidth (7-137)

[0750] CbHeight[x][y] = cbHeight (7-138)

[0751] Set vSize to min(ctbSize, 64), and set wIbcBufY to (128*128 / CtbSizeY). ibcBuf L is an array with width wIbcBufY and height CtbSizeY.

[0752] ibcBuf Cb and ibcBuf Cr is of width wIbcBufC = (wIbcBufY / SubWidthC) and height (CtbSizeY / SubHeightC) (i.e., CtbSizeC) array.

[0753] If resetIbcBuf is equal to 1, then the following applies

[0754] – For x = x0..x0 + wIbcBufY – 1 and y = y0..y0 + CtbSizeY – 1, ibcBuf L [x % wIbcBufY] [y%CtbSizeY] = -1

[0755] – For x = x0..x0 + wIbcBufC – 1 and y = y0..y0 + CtbSizeC – 1, ibcBuf Cb [x % wIbcBufC] [y%CtbSizeC] = -1

[0756] – For x = x0..x0 + wIbcBufC – 1 and y = y0..y0 + CtbSizeC – 1, ibcBuf Cr [x % wIbcBufC] [y%CtbSizeC] = -1

[0757] – resetIbcBuf = 0

[0758] When (x0%vSizeY) is equal to 0 and (y0%vSizeY) is equal to 0, the following applies

[0759] – For x = x0..x0 + vSize – 1 and y = y0..y0 + vSize – 1, ibcBuf L [x % wIbcBufY][y %CtbSizeY] = -1

[0760] – For x = x0 / SubWidthC..x0 / SubWidthC+vSize / SubWidthC–1 and y = y0 / SubHeightC..y0 / SubHeightC+vSize / SubHeightC–1, ibcBuf Cb [x%wIbcBufC][y% CtbSizeC] = -1

[0761] – 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

[0762] 8.6.2 Derivation Process of Motion Vector Components of IBC Blocks

[0763] 8.6.2.1 General

[0764] The inputs to this process are as follows:

[0765] – The luminance position (xCb, yCb) of the top-left sample of the current luma coding block relative to the top-left luma sample of the current picture

[0766] – The variable cbWidth, which specifies the width of the current coding block in luma samples

[0767] – The variable cbHeight, which specifies the height of the current coding block in luma samples.

[0768] The outputs of this process are as follows:

[0769] – The luminance motion vector mvL with 1 / 16 fractional sample precision.

[0770] The luminance motion vector mvL is derived as follows:

[0771] – Invoke the derivation process of IBC luminance motion vector prediction specified in Clause 8.6.2.2 with the luminance position (xCb, yCb), the variables cbWidth and cbHeight as inputs, and the output is the luminance motion vector mvL.

[0772] – When general_merge_flag[xCb][yCb] is equal to 0, the following applies:

[0773] 1. The variable mvd is derived as follows:

[0774] mvd[0] = MvdL0[xCb][yCb][0] (8 - 883)

[0775] mvd[1] = MvdL0[xCb][yCb][1] (8 - 884)

[0776] 2. Call the rounding process of the motion vector specified in Clause 8.5.2.14 with mvX set to be equal to mvL, rightShift set to be equal to MvShift + 2, and leftShift set to be equal to MvShift + 2 as inputs and the rounded mvL as the output.

[0777] 3. The luminance motion vector mvL is modified as follows:

[0778] u[0] = (mvL[0] + mvd[0] + 2 18 ) % 2 18 (8 - 885)

[0779] mvL[0] = (u[0] >= 2 17 )? (u[0] - 2 18 ): u[0] (8 - 886)

[0780] u[1] = (mvL[1] + mvd[1] + 2 18 ) % 2 18 (8 - 887)

[0781] mvL[1] = (u[1] >= 2 17 )? (u[1] - 2 18 ): u[1] (8 - 888)

[0782] Note 1 - The resulting values of mvL[0] and mvL[1] specified as above are always in the range -2 17 to 2 17 –1 (including -2 17 and 2 17 -1).

[0783] Call the update process of the history-based motion vector prediction value list specified in Clause 8.6.2.6 with the luminance motion vector mvL.

[0784] Call Clause 8.6.2.5 with mvL as the input and mvC as the output.

[0785] The requirement for bitstream consistency is that the luminance block vector mvL shall comply with the following constraints:

[0786] – ((yCb+(mvL[1]>>4))%CtbSizeY)+cbHeight is less than or equal to CtbSizeY

[0787] – For x = xCb..xCb+cbWidth–1 and y = yCb..yCb+cbHeight–1, ibcBuf L [(x+(mvL[0] >>4))%wIbcBufY][(y+(mvL[1]>>4))%CtbSizeY] shall not be equal to -1.

[0788] – If treeType is equal to SINGLE_TREE, then for x = xCb..xCb+cbWidth–1 and y = yCb..yCb +cbHeight–1, ibcBuf Cb [(x+(mvC[0]>>5)) % wIbcBufC][(y+(mvC[1]>>5)) % CtbSizeC]] not shall be equal to -1.

[0789] 8.6.3 Decoding Process of ibc Blocks

[0790] 8.6.3.1 General

[0791] This process is called when decoding a coding unit that is coded in the IBC prediction mode.

[0792] The inputs to this process are:

[0793] – The luma position (xCb, yCb), specifying the top-left sample of the current coding block relative to the top-left luma sample of the current picture

[0794] – The variable cbWidth, specifying the width of the current coding block in luma samples

[0795] – The variable cbHeight, specifying the height of the current coding block in luma samples

[0796] – The color component index of the current block.

[0797] – Motion vector mv,

[0798] – (wIbcBufY)×(CtbSizeY) array ibcBuf L , (wIbcBufC)×(CtbSizeC) array ibcBuf Cb , (wIbcBufC) × (CtbSizeC) array ibcBuf Cr .

[0799] The outputs of this process are:

[0800] – The array predSamples of predicted samples.

[0801] For x = xCb..xCb+Width–1 and y = yCb..yCb+Height-1, the following applies if cIdx is equal to 0

[0802] predSamples[x][y] = ibcBuf L [(x + mv[0] >> 4)) % wIbcBufY][(y + (mv[1] >> 4)) % CtbSizeY]

[0803] If cIdx is equal to 1

[0804] predSamples[x][y] = ibcBuf Cb [(x + mv[0] >> 5)) % wIbcBufC][(y + (mv[1] >> 5)) % CtbSizeC]

[0805] If cIdx is equal to 2

[0806] predSamples[x][y] = ibcBuf Cr [(x + mv[0] >> 5)) % wIbcBufC][(y + (mv[1] >> 5)) % CtbSizeC]

[0807] 8.7.5 Picture reconstruction process

[0808] 8.7.5.1 General

[0809] The inputs to this process are:

[0810] – The position (xCurr, yCurr), specifying the top-left sample of the current block relative to the top-left sample of the current picture component

[0811] – Variables nCurrSw and nCurrSh, which respectively specify the width and height of the current block,

[0812] – Variable cIdx, which specifies the color component of the current block,

[0813] – (nCurrSw)x(nCurrSh) array predSamples, which specifies the prediction samples of the current block,

[0814] – (nCurrSw)x(nCurrSh) array resSamples, which specifies the residual samples of the current block.

[0815] The output of the process Yes Reconstructed picture sample array recSamples and the IBC buffer array ibcBuf L 、 ibcBuf Cb 、ibcBuf Cr 。

[0816] Depending on the value of the color component cIdx, the following is specified:

[0817] – If cIdx is equal to 0, then recSamples corresponds to the reconstructed picture sample array S L , and the function clipCidx1 corresponds to Clip1 Y .

[0818] – Otherwise, if cIdx is equal to 1, then tuCbfChroma is set to be equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cb , and the function clipCidx1 corresponds to Clip1 C .

[0819] – Otherwise (cIdx is equal to 2), tuCbfChroma is set to be equal to tu_cbf_cr[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cr , and the function clipCidx1 corresponds to Clip1 C .

[0820] Depending on the value of slice_lmcs_enabled_flag, the following applies:

[0821] – If slice_lmcs_enabled_flag is equal to 0, then for i = 0..nCurrSw – 1, j = 0..nCurrSh-1, the (nCurrSw)x(nCurrSh) block of the reconstructed samples recSamples at position (xCurr, yCurr) is derived as follows:

[0822] recSamples[xCurr+i][yCurr+j] = clipCidx1(predSamples[i][j] + resSamples[i][j]) (8-992)

[0823] – Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:

[0824] – If cIdx equals 0, the following applies:

[0825] – Call the picture reconstruction and mapping process of luma samples specified in Clause 8.7.5.2 with the luma position (xCurr, yCurr), block width nCurrSw and height nCurrSh, the predicted luma sample array predSamples, and the residual luma sample array resSamples as inputs, and the output is the reconstructed luma sample array recSamples.

[0826] – Otherwise (cIdx is greater than 0), call the picture reconstruction and luma-dependent chroma residual scaling process of chroma samples specified in Clause 8.7.5.3 with the chroma position (xCurr, yCurr), transform block width nCurrSw and height nCurrSh, the coding block flag tuCbfChroma of the current chroma transform block, the predicted chroma sample array predSamples, and the residual chroma sample array resSamples as inputs, and the output is the reconstructed chroma sample array recSamples.

[0827] After decoding the current coding unit, the following may apply:

[0828] If cIdx is equal to 0, and if treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, then the following applies

[0829] For i = 0..nCurrSw–1, j = 0..nCurrSh–1

[0830] ibcBuf L [(xCurr + i) % wIbcBufY][(yCurr + j) % CtbSizeY] = recSamples[xCurr + i][yCurr + j].

[0831] If cIdx is equal to 1, and if treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies

[0832] For i = 0..nCurrSw–1, j = 0..nCurrSh–1

[0833] ibcBuf Cb [(xCurr + i) % wIbcBufC][(yCurr + j) % CtbSizeC] = recSamples[xCurr + i][yCurr + j].

[0834] If cIdx is equal to 2, and if treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies

[0835] For i = 0..nCurrSw–1, j = 0..nCurrSh–1

[0836] ibcBuf Cr [(xCurr + i) % wIbcBufC][(yCurr + j) % CtbSizeC] = recSamples[xCurr + i][yCurr + j].

[0837] 5.19 Example #19

[0838] In this document, changes in some examples are indicated by bold, underlined text.

[0839] 7.3.7 Strip data syntax

[0840] 7.3.7.1 General strip data syntax

[0841]

[0842] 7.4.8.5 Coding unit semantics

[0843] When all of the following conditions are true, the history-based motion vector prediction value list in the shared Merge candidate list area is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i] for i = 0..NumHmvpIbcCand–1:

[0844] – IsInSmr[x0][y0] is equal to TRUE.

[0845] – SmrX[x0][y0] is equal to x0.

[0846] – SmrY[x0][y0] is equal to y0.

[0847] For x = x0..x0+cbWidth–1 and y = y0..y0+cbHeight-1, the following are specified:

[0848] CbPosX[x][y] = x0 (7-135)

[0849] CbPosY[x][y] = y0 (7-136)

[0850] CbWidth[x][y] = cbWidth (7-137)

[0851] CbHeight[x][y] = cbHeight (7-138)

[0852] Set vSize to min(ctbSize, 64), and set wIbcBufY to (128 * 128 / CtbSizeY). ibcBufL is an array with width wIbcBufY and height CtbSizeY.

[0853] ibcBuf Cb and ibcBuf Cr is of width wIbcBufC = (wIbcBufY / SubWidthC) and height (CtbSizeY / SubHeightC) (i.e., CtbSizeC) array.

[0854] If resetIbcBuf is equal to 1, then the following applies

[0855] – For x = x0..x0 + wIbcBufY–1 and y = y0..y0 + CtbSizeY–1, ibcBufL[x % wIbcBufY] [y % CtbSizeY] = -1

[0856] – For x = x0..x0 + wIbcBufC – 1 and y = y0..y0 + CtbSizeC – 1, ibcBuf Cb [x % wIbcBufC] [y % CtbSizeC] = -1

[0857] – For x = x0..x0 + wIbcBufC – 1 and y = y0..y0 + CtbSizeC – 1, ibcBuf Cr [x % wIbcBufC] [y % CtbSizeC] = -1

[0858] – resetIbcBuf = 0

[0859] When (x0 % vSizeY) is equal to 0 and (y0 % vSizeY) is equal to 0, the following applies

[0860] – For x = x0..x0 + min(vSize, cbWidth)–1 and y = y0..y0 + min(vSize, cbHeight)–1, ibcBuf L [x% wIbcBufY][y% CtbSizeY] = -1

[0861] – For x = x0 / SubWidthC..x0 / SubWidthC + min(vSize / SubWidthC, cbWidth)-1 and y = y0 / SubHeightC..y0 / SubHeightC + min(vSize / SubHeightC, cbHeight) – 1, ibcBuf Cb [x% wIbcBufC][y % CtbSizeC] = -1

[0862] – 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

[0863] 8.6.2 Derivation Process of Motion Vector Components of IBC Blocks

[0864] 8.6.2.1 General

[0865] The inputs to this process are as follows:

[0866] – The luminance position (xCb, yCb) of the top-left sample of the current luma coding / decoding block relative to the top-left luma sample of the current picture,

[0867] – The variable cbWidth, specifying the width of the current coding / decoding block in luma samples,

[0868] – The variable cbHeight, specifying the height of the current coding / decoding block in luma samples.

[0869] The outputs of this process are as follows:

[0870] – The luminance motion vector mvL with 1 / 16 fractional sample precision.

[0871] The luminance motion vector mvL is derived as follows:

[0872] – Invoke the derivation process of IBC luminance motion vector prediction specified in Clause 8.6.2.2 with the luminance position (xCb, yCb), the variables cbWidth and cbHeight as inputs, and the output is the luminance motion vector mvL.

[0873] – When general_merge_flag[xCb][yCb] is equal to 0, the following applies:

[0874] 1. The variable mvd is derived as follows:

[0875] mvd[0] = MvdL0[xCb][yCb][0] (8-883)

[0876] mvd[1] = MvdL0[xCb][yCb][1] (8-884)

[0877] 2. Call the rounding process of the motion vector as specified in Clause 8.5.2.14 with mvX set to be equal to mvL, rightShift set to be equal to MvShift+2, and leftShift set to be equal to MvShift+2 as inputs and the rounded mvL as the output.

[0878] 3. The luma motion vector mvL is modified as follows:

[0879] u[0] = (mvL[0] + mvd[0] + 2 18 ) % 2 18 (8-885)

[0880] mvL[0] = (u[0] >= 2 17 )? (u[0] - 2 18 ): u[0] (8-886)

[0881] u[1] = (mvL[1] + mvd[1] + 2 18 ) % 2 18 (8-887)

[0882] mvL[1] = (u[1] >= 2 17 )? (u[1] - 2 18 ): u[1] (8-888)

[0883] Note 1 - The resulting values of mvL[0] and mvL[1] specified as above are always in the range -2 17 to 2 17 –1 (including -2 17 and 2 17 -1).

[0884] Call the update process of the history-based motion vector prediction value list as specified in Clause 8.6.2.6 with the luma motion vector mvL.

[0885] Call clause 8.6.2.5 with mvL as input and mvC as output.

[0886] The requirement for bitstream consistency is that the luma block vector mvL shall comply with the following constraint:

[0887] – ((yCb + (mvL[1] >> 4)) % CtbSizeY) + cbHeight is less than or equal to CtbSizeY

[0888] – For x = xCb..xCb+cbWidth–1 and y = yCb..yCb+cbHeight–1, ibcBuf L [(x+(mvL[0] >>4)) % wIbcBufY][(y + (mvL[1] >> 4)) % CtbSizeY] should not be equal to -1.

[0889] – If treeType is equal to SINGLE_TREE, then for x = xCb..xCb + cbWidth – 1 and y = yCb..yCb +cbHeight–1, ibcBuf Cb [(x + (mvC[0] >> 5)) % wIbcBufC][(y + (mvC[1] >> 5)) % CtbSizeC]] not should be equal to -1.

[0890] 8.6.3 Decoding Process of IBC Blocks

[0891] 8.6.3.1 General

[0892] This process is called when decoding a coding / decoding unit coded / decoded in IBC prediction mode.

[0893] The inputs to this process are:

[0894] – Luminance position (xCb, yCb), specifying the top-left sample of the current coding block relative to the top-left luminance sample of the current picture

[0895] – Variable cbWidth, specifying the width of the current coding block in luminance samples

[0896] – Variable cbHeight, specifying the height of the current coding block in luminance samples

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

[0898] – The motion vector mv,

[0899] – (wIbcBufY)×(CtbSizeY) array ibcBuf L , (wIbcBufC)×(CtbSizeC) array ibcBuf Cb , (wIbcBufC) × (CtbSizeC) array ibcBuf Cr .

[0900] The output of this process is:

[0901] – The array predSamples of predicted samples.

[0902] For x = xCb..xCb + Width – 1 and y = yCb..yCb + Height - 1, the following applies

[0903] If cIdx is equal to 0

[0904] predSamples[x][y] = ibcBuf L [(x + mv[0] >> 4)) % wIbcBufY][(y + (mv[1] >> 4)) % CtbSizeY

[0905] If cIdx is equal to 1

[0906] predSamples[x][y] = ibcBuf Cb [(x + mv[0] >> 5)) % wIbcBufC][(y + (mv[1] >> 5)) % CtbSizeC

[0907] If cIdx is equal to 2

[0908] predSamples[x][y] = ibcBuf Cr [(x + mv[0] >> 5)) % wIbcBufC][(y + (mv[1] >> 5)) % CtbSizeC

[0909] 8.7.5 Picture Reconstruction Process

[0910] 8.7.5.1 General

[0911] The inputs to this process are:

[0912] – Position (xCurr, yCurr), specifying the top-left sample of the current block relative to the top-left sample of the current picture component

[0913] – Variables nCurrSw and nCurrSh, specifying the width and height of the current block respectively

[0914] – Variable cIdx, specifying the color component of the current block

[0915] – (nCurrSw) x (nCurrSh) array predSamples, specifying the predicted samples of the current block

[0916] – (nCurrSw) x (nCurrSh) array resSamples, specifying the residual samples of the current block

[0917] The outputs of this process are the reconstructed picture sample array recSamples and the IBC buffer array ibcBuf L and ibcBuf Cb and ibcBuf Cr .

[0918] Depending on the value of the color component cIdx, the following are specified:

[0919] – If cIdx is equal to 0, recSamples corresponds to the reconstructed picture sample array S L , and the function clipCidx1 corresponds to Clip1Y

[0920] – Otherwise, if cIdx is equal to 1, tuCbfChroma is set to be equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cb , and the function clipCidx1 corresponds to Clip1 C .

[0921] – Otherwise (cIdx equals 2), tuCbfChroma is set to be equal to tu_cbf_cr[xCurr][yCurr], and recSamples corresponds to the reconstructed chroma sample array S Cr , and the function clipCidx1 corresponds to Clip1 C .

[0922] Depending on the value of slice_lmcs_enabled_flag, the following applies:

[0923] – If slice_lmcs_enabled_flag equals 0, then for i = 0..nCurrSw–1, j = 0..nCurrSh-1, the (nCurrSw)x(nCurrSh) block of the reconstructed samples recSamples at position (xCurr, yCurr) is derived as follows:

[0924] recSamples[xCurr+i][yCurr+j] = clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992)

[0925] – Otherwise (slice_lmcs_enabled_flag equals 1), the following applies:

[0926] – If cIdx equals 0, then the following applies:

[0927] – The picture reconstruction and mapping process of the luma samples specified in Clause 8.7.5.2 is called with the luma position (xCurr, yCurr), block width nCurrSw and height nCurrSh, predicted luma sample array predSamples, and residual luma sample array resSamples as inputs, and the output is the reconstructed luma sample array recSamples.

[0928] – Otherwise (cIdx is greater than 0), the picture reconstruction and luma-dependent chroma residual scaling process of the chroma samples specified in Clause 8.7.5.3 is called with the chroma position (xCurr, yCurr), transform block width nCurrSw and height nCurrSh, coding / decoding block flag tuCbfChroma of the current chroma transform block, predicted chroma sample array predSamples, and residual chroma sample array resSamples as inputs, and the output is the reconstructed chroma sample array recSamples.

[0929] After decoding the current coding unit, the following may apply:

[0930] If cIdx is equal to 0, and if treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, then the following applies

[0931] For i = 0..nCurrSw – 1, j = 0..nCurrSh – 1

[0932] ibcBufL[(xCurr + i) % wIbcBufY][(yCurr + j) % CtbSizeY] = recSamples[xCurr + i][yCurr + j].

[0933] If cIdx is equal to 1, and if treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies

[0934] For i = 0..nCurrSw – 1, j = 0..nCurrSh – 1

[0935] ibcBuf Cb [(xCurr + i) % wIbcBufC][(yCurr + j) % CtbSizeC] = recSamples[xCurr + i][yCurr + j].

[0936] If cIdx is equal to 2, and if treeType is equal to SINGLE_TREE or DUAL_TREE_CHROMA, then the following applies

[0937] For i = 0..nCurrSw – 1, j = 0..nCurrSh – 1

[0938] ibcBuf Cr [(xCurr + i) % wIbcBufC][(yCurr + j) % CtbSizeC] = recSamples[xCurr + i][yCurr + j].

[0939] 5.20 Example #20

[0940] In this document, changes in some examples are indicated by bold, underlined, and italic text.

[0941] 7.3.7 Syntax of Strip Data

[0942] 7.3.7.1 General Syntax of Strip Data

[0943]

[0944] 7.4.8.5 Semantics of Coding Units

[0945] When all of the following conditions are true, the history-based motion vector prediction value list in the shared Merge candidate list area is updated by setting NumHmvpSmrIbcCand equal to NumHmvpIbcCand, and setting HmvpSmrIbcCandList[i] equal to HmvpIbcCandList[i] for i = 0..NumHmvpIbcCand–1:

[0946] – IsInSmr[x0][y0] is equal to TRUE.

[0947] – SmrX[x0][y0] is equal to x0.

[0948] – SmrY[x0][y0] is equal to y0.

[0949] For x = x0..x0 + cbWidth – 1 and y = y0..y0 + cbHeight - 1, the following is specified:

[0950] CbPosX[x][y] = x0 (7-135)

[0951] CbPosY[x][y] = y0 (7-136)

[0952] CbWidth[x][y] = cbWidth (7-137)

[0953] CbHeight[x][y] = cbHeight (7-138)

[0954] Set vSize to min(ctbSize, 64), and set wIbcBufY to (128 * 128 / CtbSizeY).

[0955] ibcBuf L is an array with width wIbcBufY and height CtbSizeY.

[0956] ibcBuf Cb and ibcBuf Cr is of width wIbcBufC = (wIbcBufY / SubWidthC) and height The array of (CtbSizeY / SubHeightC) (i.e., CtbSizeC).

[0957] If resetIbcBuf is equal to 1, then the following applies

[0958] – For x = x0..x0 + wIbcBufY – 1 and y = y0..y0 + CtbSizeY – 1, ibcBuf L [x % wIbcBufY] [y % CtbSizeY] = -1

[0959] – For x = x0..x0 + wIbcBufC – 1 and y = y0..y0 + CtbSizeC – 1, ibcBuf Cb [x % wIbcBufC] [y % CtbSizeC] = -1

[0960] – For x = x0..x0 + wIbcBufC – 1 and y = y0..y0 + CtbSizeC – 1, ibcBuf Cr [x % wIbcBufC] [y % CtbSizeC] = -1

[0961] – resetIbcBuf = 0

[0962] When (x0 % vSizeY) is equal to 0 and (y0 % vSizeY) is equal to 0, the following applies

[0963] – For x = x0..x0 + max(vSize, cbWidth) – 1 and y = y0..y0 + max(vSize, cbHeight) – 1, ibcBuf L [x% wIbcBufY][y% CtbSizeY] = -1

[0964] – For x = x0 / SubWidthC..x0 / SubWidthC + max(vSize / SubWidthC, cbWidth) - 1 and y = y0 / SubHeightC..y0 / SubHeightC + max(vSize / SubHeightC, cbHeight) – 1, ibcBuf Cb [x% wIbcBufC][y % CtbSizeC] = -1

[0965] – 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

[0966] 8.6.2 Derivation Process of Motion Vector Components of IBC Blocks

[0967] 8.6.2.1 General

[0968] The inputs to this process are:

[0969] – The luma position (xCb, yCb) of the top-left sample of the current luma coding block with respect to the top-left luma sample of the current picture,

[0970] – The variable cbWidth, specifying the width of the current coding block in luma samples,

[0971] – The variable cbHeight, specifying the height of the current coding block in luma samples.

[0972] The output of this process is:

[0973] – The luma motion vector mvL with 1 / 16 fractional sample precision.

[0974] The luma motion vector mvL is derived as follows:

[0975] – The derivation process of IBC luma motion vector prediction specified in Clause 8.6.2.2 is called with the luma position (xCb, yCb), the variables cbWidth and cbHeight as inputs, and the output is the luma motion vector mvL.

[0976] – When general_merge_flag[xCb][yCb] is equal to 0, the following applies:

[0977] 1. The variable mvd is derived as follows:

[0978] mvd[0] = MvdL0[xCb][yCb][0] (8-883)

[0979] mvd[1] = MvdL0[xCb][yCb][1] (8-884)

[0980] 2. The rounding process of the motion vector specified in Clause 8.5.2.14 is called with mvX set to be equal to mvL, rightShift set to be equal to MvShift+2, leftShift set to be equal to MvShift+2 as inputs and the rounded mvL as the output.

[0981] 3. The luma motion vector mvL is modified as follows:

[0982] u[0] = (mvL[0] + mvd[0] + 2 18 ) % 2 18 (8-885)

[0983] mvL[0] = (u[0] >= 2 17 )? (u[0] - 2 18 ): u[0] (8-886)

[0984] u[1] = (mvL[1] + mvd[1] + 2 18 ) % 2 18 (8 - 887)

[0985] mvL[1] = (u[1] >= 2 17 )? (u[1] - 2 18 ): u[1] (8 - 888)

[0986] Note 1 - The resulting values of mvL[0] and mvL[1] specified as above are always in the range -2 17 to 2 17 –1 (including -2 17 and 2 17 -1).

[0987] Call the update process of the history-based motion vector prediction value list specified in Clause 8.6.2.6 with the luminance motion vector mvL.

[0988] Clause 8.6.2.5 is called with mvL as input and mvC as output.

[0989] The requirement for bitstream conformance is that the luma block vector mvL shall comply with the following constraints:

[0990] – ((yCb + (mvL[1] >> 4)) % CtbSizeY) + cbHeight is less than or equal to CtbSizeY

[0991] – For x = xCb..xCb+cbWidth–1 and y = yCb..yCb+cbHeight–1, ibcBuf L [(x+(mvL[0] >>4)) % wIbcBufY][(y + (mvL[1] >> 4)) % CtbSizeY] shall not be equal to -1.

[0992] 8.6.3 Decoding Process of IBC Blocks

[0993] 8.6.3.1 General

[0994] This process is called when decoding a coding unit coded in the IBC prediction mode.

[0995] The inputs to this process are:[[]]

[0996] – Luminance position (xCb, yCb), specifying the top-left sample of the current coding block relative to the top-left luminance sample of the current picture.

[0997] – Variable cbWidth, specifying the width of the current coding block in luminance samples.

[0998] – Variable cbHeight, specifying the height of the current coding block in luminance samples.

[0999] – Variable cIdx, specifying the color component index of the current block.

[1000] – Motion vector mv,

[1001] – (wIbcBufY) × (CtbSizeY) array ibcBuf L , (wIbcBufC) × (CtbSizeC) array ibcBuf Cb ,(wIbcBufC) × (CtbSizeC) array ibcBuf Cr 。

[1002] The output of the process is:

[1003] – An array predSamples of predicted samples.

[1004] For x = xCb..xCb + Width – 1 and y = yCb..yCb + Height - 1, the following applies

[1005] If cIdx equals 0

[1006] predSamples[x][y] = ibcBuf L [(x + mv[0] >> 4)) % wIbcBufY][(y + (mv[1] >> 4)) % CtbSizeY

[1007] If cIdx equals 1

[1008] predSamples[x][y] = ibcBuf Cb [(x + mv[0] >> 5)) % wIbcBufC][(y + (mv[1] >> 5)) % CtbSizeC

[1009] If cIdx equals 2

[1010] predSamples[x][y] = ibcBuf Cr [(x + mv[0] >> 5)) % wIbcBufC][(y + (mv[1] >> 5)) % CtbSizeC

[1011] 8.7.5 Picture Reconstruction Process

[1012] 8.7.5.1 General

[1013] The inputs to this process are:

[1014] – Location (xCurr, yCurr), specifying the top-left sample of the current block relative to the top-left sample of the current picture component,

[1015] – Variables nCurrSw and nCurrSh, specifying the width and height of the current block respectively,

[1016] – Variable cIdx, specifying the color component of the current block,

[1017] – (nCurrSw) x (nCurrSh) array predSamples, specifying the predicted samples of the current block,

[1018] – (nCurrSw) x (nCurrSh) array resSamples, specifying the residual samples of the current block.

[1019] The output of this process Yes Reconstructed picture sample array recSamples and the IBC buffer array ibcBuf L 、 ibcBuf Cb 、ibcBuf Cr 。

[1020] Depending on the value of the color component cIdx, the following is specified:

[1021] – If cIdx is equal to 0, then recSamples corresponds to the reconstructed picture sample array S L , and the function clipCidx1 corresponds to Clip1 Y .

[1022] – Otherwise, if cIdx is equal to 1, then tuCbfChroma is set to be equal to tu_cbf_cb[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cb , and the function clipCidx1 corresponds to Clip1 C .

[1023] – Otherwise (cIdx is equal to 2), tuCbfChroma is set to be equal to tu_cbf_cr[xCurr][yCurr], recSamples corresponds to the reconstructed chroma sample array S Cr , and the function clipCidx1 corresponds to Clip1 C .

[1024] Depending on the value of slice_lmcs_enabled_flag, the following applies:

[1025] – If slice_lmcs_enabled_flag is equal to 0, then for i = 0..nCurrSw–1, j = 0..nCurrSh-1, the (nCurrSw)x(nCurrSh) block of the reconstructed samples recSamples at position (xCurr, yCurr) is derived as follows:

[1026] recSamples[xCurr+i][yCurr+j] = clipCidx1(predSamples[i][j]+resSamples[i][j]) (8-992)

[1027] – Otherwise (slice_lmcs_enabled_flag is equal to 1), the following applies:

[1028] – If cIdx is equal to 0, then the following applies:

[1029] – The picture reconstruction and mapping process of the luma samples specified in Clause 8.7.5.2 is called with the luma position (xCurr, yCurr), the block width nCurrSw and height nCurrSh, the predicted luma sample array predSamples, and the residual luma sample array resSamples as inputs, and the output is the reconstructed luma sample array recSamples.

[1030] – Otherwise (if cIdx is greater than 0), call the picture reconstruction of chroma samples and the luminance-dependent chroma residual scaling process specified in Clause 8.7.5.3 with the chroma position (xCurr, yCurr), transform block width nCurrSw and height nCurrSh, the coding / decoding block flag tuCbfChroma of the current chroma transform block, the predicted chroma sample array predSamples, and the residual chroma sample array resSamples as inputs, and the output is the reconstructed chroma sample array recSamples.

[1031] After decoding the current coding unit, the following may apply:

[1032] If cIdx equals 0, and if treeType equals SINGLE_TREE or DUAL_TREE_LUMA, then the following Applies

[1033] For i = 0..nCurrSw – 1, j = 0..nCurrSh – 1

[1034] ibcBuf L [(xCurr + i) % wIbcBufY][(yCurr + j) % CtbSizeY] = recSamples[xCurr + i][yCurr + j].[[]END]]

[1035] If cIdx equals 1, and if treeType equals SINGLE_TREE or DUAL_TREE_CHROMA, then the following Applies

[1036] For i = 0..nCurrSw – 1, j = 0..nCurrSh – 1

[1037] ibcBuf Cb [(xCurr + i) % wIbcBufC][(yCurr + j) % CtbSizeC] = recSamples[xCurr + i][yCurr + j].[[]END]]

[1038] If cIdx equals 2, and if treeType equals SINGLE_TREE or DUAL_TREE_CHROMA, then the following Applies

[1039] For i = 0..nCurrSw – 1, j = 0..nCurrSh – 1

[1040] ibcBuf Cr [(xCurr + i) % wIbcBufC][(yCurr + j) % CtbSizeC] = recSamples[xCurr + i][yCurr + j].[[]END]]

[1041] Figure 6 is a flowchart of an example method 600 for visual media (video or image) processing. Method 600 includes: for the conversion between a current video block and its bitstream representation, determining (602) the size of a buffer to store reference samples of the current video block using the intra-block copy coding mode; and performing (604) the conversion using the reference samples stored in the buffer.

[1042] The following clauses describe some example preferred features implemented by embodiments of method 600 and other methods. Additional examples are provided in Section 4 of this document.

[1043] 1. A method for video processing, comprising: determining a size of a buffer to store reference samples of a current video block using an intra block copy codec mode for conversion between the current video block and a bitstream representation of the current video block; and performing the conversion using the reference samples stored in the buffer.

[1044] 2. The method according to clause 1, wherein the size of the buffer is a predetermined constant.

[1045] 3. The method according to any one of clauses 1 - 2, wherein the size is M×N, where M and N are integers.

[1046] 4. The method according to clause 3, wherein M×N is equal to 64×64 or 128×128 or 64×128.

[1047] 5. The method according to clause 1, wherein the size of the buffer is equal to the size of a codec tree unit of the current video block.

[1048] 6. The method according to clause 1, wherein the size of the buffer is equal to the size of a virtual pipeline data unit used during the conversion.

[1049] 7. The method according to clause 1, wherein the size of the buffer corresponds to a field in the bitstream representation.

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

[1051] 9. The method according to any one of clauses 1 - 8, wherein the size of the buffer is different for reference samples of a luminance component and reference samples of a chrominance component.

[1052] 10. The method according to any one of clauses 1 - 8, wherein the size of the buffer depends on the chrominance subsampling format of the current video block.

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

[1054] 12. The method according to any one of clauses 1 - 11, wherein the buffer is used to store reconstructed samples before loop filtering and reconstructed samples after loop filtering.

[1055] 13. The method according to clause 12, wherein the loop filtering includes deblocking filtering or adaptive loop filtering (ALF) or sample adaptive offset (SAO) filtering.

[1056] 14. A method for video processing, comprising: for the conversion between a current video block and a bitstream representation of the current video block, initializing a buffer with an initial value of a reference sample to store the reference sample of the current video block using an intra block copy codec mode; and performing the conversion using the reference sample stored in the buffer.

[1057] 15. The method according to clause 14, wherein the initial value corresponds to a constant.

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

[1059] 17. The method according to clause 15, wherein the constant corresponds to a middle gray value.

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

[1061] 19. The method according to clause 18, wherein the previously decoded video block corresponds to a decoded block before loop filtering.

[1062] 20. The method according to any one of clauses 14-19, wherein the size of the buffer is as described in one of clauses 1-13.

[1063] 21. The method according to any one of clauses 1-20, wherein pixel positions in the buffer are addressed using x numbers and y numbers.

[1064] 22. The method according to any one of clauses 1-20, wherein pixel positions in the buffer are addressed using a single number ranging from 0 to M*N-1, where M and N are the pixel width and pixel height of the buffer.

[1065] 23. The method according to any one of clauses 1-20, wherein the current bitstream representation includes a block vector for the conversion, wherein the block vector represented as (BVx, BVy) is equal to (x-x0, y-y0), where (x0, y0) corresponds to the upper left corner position of the codec tree unit of the current video block.

[1066] 24. The method according to any one of clauses 1-20, wherein the current bitstream representation includes a block vector for the conversion, wherein the block vector represented as (BVx, BVy) is equal to (x-x0+Tx, y-y0+Ty), where (x0, y0) corresponds to the upper left corner position of the codec tree unit of the current video block, and wherein Tx and Ty are offset values.

[1067] 25. The method according to clause 24, wherein Tx and Ty are predefined offset values.

[1068] 26. The method according to any one of clauses 1-20, wherein during the conversion, for a pixel at position (x0, y0) with a block vector (BVx, BVy), the corresponding reference in the buffer is found at the reference position (x0 + BVx, y0 + BVy).

[1069] 27. The method according to clause 26, wherein in the case where the reference position is outside the buffer, the reference in the buffer is determined by clipping at the boundary of the buffer.

[1070] 28. The method according to clause 26, wherein in the case where the reference position is outside the buffer, the reference in the buffer is determined to have a predetermined value.

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

[1072] 30. A method for video processing, comprising: during the conversion between a video and a bitstream representation of a current video block, resetting a buffer storing reference samples for intra-block copy encoding / decoding at video boundaries; and performing the conversion using the reference samples stored in the buffer.

[1073] 31. The method according to clause 30, wherein the video boundary corresponds to a new picture or a new slice.

[1074] 32. The method according to clause 30, wherein the conversion is performed by updating the buffer with the reconstructed values of virtual pipeline data units (VPDUs) after the reset.

[1075] 33. The method according to clause 30, wherein the conversion is performed by updating the buffer with the reconstructed values of coding tree units after the reset.

[1076] 34. The method according to clause 30, wherein the reset is performed at the start of each coding tree unit row.

[1077] 35. The method according to clause 1, wherein the size of the buffer corresponds to L previously decoded blocks of 64×64, where L is an integer.

[1078] 36. The method according to any one of clauses 1-35, wherein a vertical scan order is used to read samples from or store samples in a buffer during the conversion.

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

[1080] 38. The method according to clause 37, wherein the first bit depth is greater than the second bit depth.

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

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

[1083] 41. The method according to any one of clauses 37-40, wherein for chrominance components and luminance components, the conversion uses different bit depths.

[1084] Additional embodiments and examples of clauses 37 to 41 are described in item 7 of Chapter 4.

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

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

[1087] Additional embodiments and examples of clauses 42 to 43 are described in items 28 to 31 and item 34 of Chapter 4.

[1088] 44. A method for video processing, comprising: performing a conversion between a current video block using an intra block copy mode and a bitstream representation of the current video block, wherein in the intra block copy mode, a reference region of size nM×nM is used for a coding tree unit of size M×M, where n and M are integers, and wherein the current video block is located in a coding tree unit, and wherein the reference region is the nearest available n×n coding tree unit in the row of the coding tree unit corresponding to the current video block.

[1089] Additional embodiments and examples of Clause 4 are described in Item 35 of Chapter 4.

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

[1091] Additional embodiments and examples of Clause 4 are described in Item 36 of Chapter 4. Figure 8 and Figure 9 Additional exemplary embodiments are shown.

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

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

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

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

[1096] 50. A method for video processing, comprising: for the conversion between the current video block of a video and the bitstream representation of the current video block, using the component X of the video to determine the validity of a block vector corresponding to the current video block of the component c of the video, wherein the component X is different from the luminance component of the video; and when it is determined that the block vector is valid for the current video block, using the block vector to perform the conversion. Here, the block vector represented as (BVx, BVy) is equal to (x - x0, y - y0), where (x0, y0) corresponds to the upper left corner position of the coding tree unit of the current video block.

[1097] 51. The method according to clause 50, wherein the component c corresponds to the luminance component of the video.

[1098] 52. The method according to clause 50, wherein the current video block is a chrominance block and the video is in 4:4:4 format.

[1099] 53. The method according to clause 50, wherein the video is in 4:2:0 format, and wherein the current video block is a chrominance block starting at position (x, y), and wherein the determination includes determining the block vector to be invalid for the case where isRec(c, ((x + BVx) >> 5 << 5) + 64 - (((y + BVy) >> 5) & 1) * 32 + (x % 32), ((y + BVy) >> 5 << 5) + (y % 32)) is true.

[1100] 54. The method according to clause 50, wherein the video is in 4:2:0 format, and wherein the current video block is a chrominance block starting at position (x, y), and wherein the determination includes determining the block vector to be invalid for the case where if isRec(c, x + BVx + Chroma_CTU_size, y) is true.

[1101] 55. A method for video processing, comprising: for the conversion between the current video block of the current virtual pipeline data unit (VPDU) of a video region and the bitstream representation of the current video block, selectively determining to use K1 previously processed VPDUs from the first row of the video region and K2 previously processed VPDUs from the second row of the video region; and performing the conversion, wherein the conversion does not include using the remaining part of the current VPDU.

[1102] 56. The method according to clause 55, wherein K1 = 1 and K2 = 2.

[1103] 57. The method according to any one 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.

[1104] 58. A method for video processing, comprising: performing a validity check of a block vector for a conversion between a current video block and a bitstream representation of the current video block, wherein the block vector is used for an intra block copy mode; and selectively using the block vector during the conversion using the result of the validity check.

[1105] 59. The method according to clause 58, wherein an intra block copy (IBC) buffer is used during the conversion, wherein the width and height of the IBC buffer are Wbuf and Hbuf, the size of the current video block is W×H, and wherein the block vector is represented as (BVx, BVy), and wherein the current video block is in a current picture having a size of Wpic and Hpic and in a coding tree unit having Wctu and Hctu as the width and height, and wherein the validity check uses a predetermined rule.

[1106] 60. The method according to any one of clauses 58 - 59, wherein the current video block is a sub - block of a luminance block, a chrominance block, a coding unit CU, a transform unit TU, a 4×4 block, a 2×2 block, or a parent block starting from pixel coordinates (X, Y).

[1107] 61. The method according to any one of clauses 58 - 60, wherein the validity check considers a block vector that falls outside the boundaries of the current picture as valid.

[1108] 62. The method according to any one of clauses 58 - 60, wherein the validity check considers a block vector that falls outside the boundaries of the coding tree unit as valid.

[1109] Items 23 - 30 in the previous section provide additional examples and variations of the above clauses 58 - 62.

[1110] 63. The method according to any one of clauses 1 - 62, wherein the conversion includes generating a bitstream representation from the current video block.

[1111] 64. The method according to any one of clauses 1 - 62, wherein the conversion includes generating pixel values of the current video block from the bitstream representation.

[1112] 65. A video encoder device, comprising a processor configured to implement the method according to any one or more of clauses 1 - 62.

[1113] 66. A video decoder device, comprising a processor configured to implement the method according to any one or more of clauses 1 - 62.

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

[1115] Figure 7 It is a block diagram of the hardware platform of the video / image processing device 700. The device 700 can be used to implement one or more of the methods described herein. The device 700 can be embodied in a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. The device 700 can include one or more processors 702, one or more memories 704, and video processing hardware 706. The (multiple) processors 702 can be configured to implement one or more of the methods described in this document (including but not limited to method 600). The memory (multiple memories) 704 can be used to store data and code for implementing the methods and techniques described herein. The video processing hardware 706 can be used to implement some of the techniques described in this document in hardware circuits.

[1116] The bitstream representation corresponding to the current video block need not be a contiguous set of bits and can be distributed across headers, parameter sets, and Network Abstraction Layer (NAL) units.

[1117] Section A: Another Additional Example Embodiment

[1118] In Section A, we present another example embodiment in which the current version of the VVC standard can be modified to implement some of the techniques described in this document.

[1119] This section analyzes several problems in the current IBC reference buffer design and presents different designs to solve the problems. Instead of mixing with the decoding memory, an independent IBC reference buffer is proposed. Compared with the current anchor, the proposed scheme shows AI / RA / LD-B luminance BD-rates of -0.99% / -0.71% / -0.79% for Class F and -2.57% / -1.81% / -1.36% for 4:2:0 TGM, with a 6.7% memory reduction; or AI / RA / LD-B luminance BD-rates of -1.31% / -1.01% / -0.81% for Class F and -3.23% / -2.33% / -1.71% for 4:2:0 TGM, with a 6.7% memory increase.

[1120] A1. Introduction

[1121] Intra block copy, i.e., IBC (or current picture reference, i.e., previous CPR) coding and decoding mode is adopted. It has been realized that IBC reference samples should be stored in on-chip memory, so a limited reference region of a CTU is defined. To limit the additional on-chip memory used for the buffer, the current design reuses 64×64 memory for decoding the current VPDU, such that only 3 additional 64×64 blocks of memory are required to support IBC. When the CTU size is 128×128, the reference region is currently shown in Figure 2 is shown in.

[1122] In the current draft (VVC draft 4), the region is defined as

[1123]

[1124] Therefore, the total reference size is the CTU.

[1125] A2. Potential problems of the current design

[1126] The current design assumes reusing 64×64 memory for decoding the current VPDU and aligns the IBC reference with the VPDU memory reuse accordingly. Such a design bundles the VPDU decoding memory with the IBC buffer. There may be several problems:

[1127] 1. Processing smaller CTUs may be a problem. Assuming the CTU size is 32×32, it is not clear whether the current 64×64 memory used for decoding the current VPDU can effectively support 32×32 level memory reuse in different architectures.

[1128] 2. The reference region changes significantly. Therefore, excessive bitstream consistency constraints are introduced. It adds an extra burden for the encoder to effectively utilize the reference region and avoid generating a legal bitstream. This also increases the possibility of having invalid BVs in different modules (e.g., the Merge list). To handle those invalid BVs, additional logic or additional consistency constraints may be introduced. It not only burdens the encoder or decoder, but may also cause differences between BV coding and decoding and MV coding and decoding.

[1129] 3. The design does not scale well. Since VPDU decoding is mixed with the IBC buffer, it is not easy to increase or decrease the reference region relative to the current design of a 128×128 CTU. This may limit the flexibility of trading off on-chip memory for better coding and decoding efficiency in future development (e.g., lower or higher profiles).

[1130] 4. The bit depth of the IBC reference buffer is associated with the decoding buffer. Even though screen content typically has a lower bit depth than the internal decoding bit depth, the buffer still requires memory to store the bits representing mainly rounding or quantization noise. This problem becomes more severe when considering higher decoding bit depth configurations.

[1131] A3. Clear IBC Buffer Design

[1132] To solve the problems listed in the above subsection, we propose to utilize a dedicated IBC buffer that is not mixed with decoding memory.

[1133] For a 128×128 CTU, the buffer is defined as 128×128 with 8-bit samples. When a CU(x, y) of size w×h has been decoded, its reconstruction before loop filtering is converted to 8 bits and written to a w×h block region starting from the position (x % 128, y % 128). Here, the modulo operator % always returns a positive number, i.e., for x < 0, for example, -3 % 128 = 125.

[1134] Assume that a pixel (x, y) is encoded / decoded in IBC mode with BV = (BVx, BVy). Its predicted sample in the IBC reference buffer is located at ((x + BVx) % 128, (y + BVy) % 128), and the pixel value will be converted to 10 bits before prediction.

[1135] When the buffer is considered as (W, H), after decoding a CTU or CU starting from (x, y), the reconstructed pixels before loop filtering will be stored in the buffer starting from (x % W, y % H). Thus, after decoding a CTU, the corresponding IBC reference buffer will be updated accordingly. This setting may occur when the CTU size is not 128×128. For example, for a 64×64 CTU, in the case of the current buffer size, it can be considered as a 256×64 buffer. For a 64×64 CTU, Figure 2 the buffer status is shown.

[1136] Figure 12 is an illustration of the IBC reference buffer status, where the blocks represent 64×64 CTUs.

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

[1138] When the bit depth of the IBC buffer is 8 bits, the on-chip memory increases by (8 * 4) / (10 * 3) - 100% = 6.7% compared to the current design that requires 3 additional 10-bit 64×64 buffers.

[1139] If we further reduce the bit depth, the memory requirement can be further reduced. For example, for a 7-bit buffer, the on-chip memory savings is 100% - (7 * 4) / (10 * 3) = 6.7%.

[1140] In the case of this design, the only bitstream consistency constraint is that the reference block should be within the reconstruction region in the current CTU row of the current slice.

[1141] When initialization to 512 is allowed at the start of each CTU row, all bitstream consistency constraints can be removed.

[1142] A4. Experimental Results

[1143] In some embodiments, the disclosed method can be implemented using VTM-4.0 software.

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

[1145] For the 7-bit buffer implementation, the results are shown in Table I

[1146] For the 8-bit buffer implementation, the results are shown in Table II.

[1147] Table I. Performance of 7-bit buffer. The anchor is VTM-4.0, where IBC is enabled for all sequences.

[1148]

[1149]

[1150]

[1151] Table II. Performance of 8-bit buffer. The anchor is VTM-4.0, where IBC is enabled for all sequences.

[1152]

[1153]

[1154]

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

[1156] System 1700 may include a codec component 1704 that may implement the various codec or encoding methods described in this document. The codec component 1704 may reduce the average bit rate of the video from input 1702 to the output of the codec component 1704 to produce a coded representation of the video. Codec techniques are thus sometimes referred to as video compression or video transcoding techniques. The output of the codec component 1704 may be stored or transmitted via a communication connection represented by component 1706. The stored or communicatively transmitted bitstream (or coded) representation of the video received at input 1702 may be used by component 1708 to generate pixel values or a displayable video for transmission to a display interface 1710. The process of generating a user-visible video from the bitstream representation is sometimes referred to as video decompression. Additionally, although certain video processing operations are referred to as "codec" operations or tools, it will be understood that codec tools or operations are used at the encoder, and the corresponding decoding tools or operations that reverse the codec results will be performed by the decoder.

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

[1158] Figure 18Flowchart of an example method for visual data processing. The steps of this flowchart are discussed in conjunction with Example 23 discussed in Section 4 of this document. At step 1802, the process determines a block vector (BVx, BVy) for the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the current video block, where the validity of the block vector (BVx, BVy) is independent of (1) the position (P, Q) of the sample block and / or (2) whether the samples at the position (P, Q) are reconstructed, and / or (3) the position of the current video block, where the block vector (BVx, BVy) represents the pixel displacement between the current video block and the sample block. At step 1804, the process performs the conversion in an intra block copy mode using the block vector, where the intra block copy mode is based on reconstructed blocks in the same video region as the current video block that include reference samples for deriving the predicted block of the current video block, where during the conversion, the predicted sample having the position (A, B) from the reference samples in the buffer is determined at least according to the size of the buffer and / or the block vector (BVx, BVy).

[1159] Figure 19 Flowchart of an example method for visual data processing. The steps of this flowchart are discussed in conjunction with Example 23 discussed in Section 4 of this document. At step 1902, the process determines whether the block vector (BVx, BVy) corresponding to the current video block is valid according to a rule for the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the visual media data, where the block vector (BVx, BVy) represents the pixel displacement between the current video block and the sample block. At step 1904, the process performs the conversion using the block vector based on a reference region from the current picture that includes reference samples for deriving the predicted block of the current video block, where the rule specifies that the block vector (BVx, BVy) is valid when (1) one or more samples from the sample block are outside the current picture and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and / or (3) one or more samples from the sample block fail to be reconstructed.

[1160] Figure 20 Flowchart of an example method for visual data processing. The steps of this flowchart are discussed in conjunction with Example 44 discussed in Section 4 of this document. At step 2002, the process performs the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the visual media data, where the conversion is based on a reference region from the current picture that includes reference samples for deriving the predicted block of the current video block, and where a virtual buffer defining a size is used to track the availability of the reference samples for deriving the predicted block.

[1161] Figure 21A flowchart of an example method for visual data processing. The steps of this flowchart are discussed in conjunction with Example 51 discussed in Section 4 of this document. At step 2102, the process maintains a buffer for the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the visual media data, including reference samples from the current picture for deriving the predicted block of the current video block, where one or more reference samples marked as unavailable for derivation in the buffer have values outside the pixel value range.

[1162] Figure 22 A flowchart of an example method for visual data processing. The steps of this flowchart are discussed in conjunction with Example 54 discussed in Section 4 of this document. At step 2202, the process performs the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the visual media data using a buffer, where the buffer includes reference samples from the current picture for deriving the predicted block of the current video block, and where the conversion is based on a rule that specifies that for the bitstream representation to conform to the rule, the reference samples in the buffer must satisfy bitstream consistency constraints.

[1163] Some embodiments of this document are now presented in a clause-based format.

[1164] L1. A method for visual media processing, comprising:

[1165] Determining a block vector (BVx, BVy) for the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the current video block, where the validity of the block vector (BVx, BVy) is independent of (1) the position (P, Q) of the sample block and / or (2) whether the samples at the position (P, Q) are reconstructed, and / or (3) the position of the current video block, where the block vector (BVx, BVy) represents the pixel displacement between the current video block and the sample block; and

[1166] Performing the conversion in an intra block copy mode using the block vector, where the intra block copy mode is based on reconstructed blocks in the same video region as the current video block that include reference samples for deriving the predicted block of the current video block, and where during the conversion, the predicted sample having the position (A, B) from the reference samples in the buffer is determined at least according to the size of the buffer and / or the block vector (BVx, BVy).

[1167] L2. A method for visual media processing, comprising:

[1168] For the conversion between the current video block of the current picture of visual media data and the bitstream representation of the visual media data, determine whether the block vector (BVx, BVy) corresponding to the current video block is valid according to a rule, where the block vector (BVx, BVy) represents the pixel displacement between the current video block and the sample block; and

[1169] Use the block vector to perform the conversion based on a reference region from the current picture that includes reference samples for deriving the predicted block of the current video block, where the rule specifies that the block vector (BVx, BVy) is valid in the following cases: (1) one or more samples from the sample block are outside the current picture and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and / or (3) one or more samples from the sample block fail to be reconstructed.

[1170] L3. The method according to clause L2, wherein when it is recognized that the block vector (BVx, BVy) is valid, the predicted sample having the position (A, B) from the reference samples in the buffer is determined at least according to the size of the buffer and / or the block vector (BVx, BVy).

[1171] L4. The method according to any one or more of clauses L1 or L3, wherein the reference samples in the buffer correspond to the reconstructed samples of the region of the current picture.

[1172] L5. The method according to clause L4, wherein the region includes the coding tree unit (CTU) row associated with the current video block.

[1173] L6. The method according to any one or more of clauses L1-L5, wherein the block vector (BVx, BVy) is determined to be valid regardless of whether the position (P, Q) calculated according to the block vector (BVx, BVy) and the upper left corner position (x, y) of the current video block is outside the boundary of the picture.

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

[1175] L8. The method according to clause L6, wherein the block vector (BVx, BVy) is valid regardless of whether x + W + BVx > W pic or x + W + BVx < W pic where W represents the width of the current video block, and W pic represents the width of the picture.

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

[1177] L10. The method according to clause L6, wherein the block vector (BVx, BVy) is valid regardless of whether x + H + BVx > H pic or x + H + BVx < H pic , where H represents the height of the current video block, and H pic represents the height of the picture.

[1178] L11. The method according to any one or more of clauses L1 - L5, wherein the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated according to the block vector (BVx, BVy) and the upper left corner position (x, y) of the current video block is outside the coding tree unit including the current video block.

[1179] L12. The method according to clause L11, wherein the block vector (BVx, BVy) is valid regardless of whether y + BVy < floor(y / H ctu ) * H ctu or y + BVy > floor(y / H ctu ) * H ctu , where H ctu represents the height of the coding tree unit, and floor(a) is the largest integer not greater than a.

[1180] L13. The method according to clause L11, wherein the block vector (BVx, BVy) is valid regardless of whether y + H + BVy < floor(y / H ctu ) * H ctu or y + H + BVy > floor(y / H ctu ) * H ctu , where H represents the height of the current video block, H ctu represents the height of the coding tree unit, and floor(a) is the largest integer not greater than a.

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

[1182] L15. The method according to clause L14, wherein the block vector (BVx, BVy) is valid regardless of whether x + BVx < floor(x / Wctu ) * W ctu - (n - 1) * W ctu or x + BVx > floor(X / W ctu ) * W ctu - (n - 1) * W ctu , where W ctu represents the weight of the codec tree unit, and floor(a) is the largest integer not greater than a.

[1183] L16. The method according to clause L14, wherein the block vector (BVx, BVy) is valid regardless of whether x + W + BVx > floor(X / W ctu ) * W ctu + W ctu or x + W + BVx < floor(X / W ctu ) * W ctu + W ctu , where W represents the width of the current video block, and W ctu represents the weight of the codec tree unit, and floor(a) is the largest integer not greater than a.

[1184] L17. The method according to any one or more of clauses L1 - L5, wherein the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top - left position (x, y) of the current video block is outside the current CTU row including the current codec tree unit containing the current video block.

[1185] L18. The method according to clause L17, wherein the block vector (BVx, BVy) is valid regardless of whether Y + BVy < floor(Y / Hctu) * Hctu or Y + H + BVy >= floor(Y / Hctu) * Hctu + Hctu, where W ctu and H ctu represent the width and height of the CTU respectively, and floor(a) is the largest integer not greater than a.

[1186] L19. The method according to any one or more of clauses L1 - L5, wherein the block vector (BVx, BVy) is determined to be valid regardless of whether the samples fail to be reconstructed.

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

[1188] L21. The method according to clause L19, wherein the block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx + W - 1, y + BVy) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode, and W represents the width of the current video block.

[1189] L22. The method according to clause L19, wherein the block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx, y + BVy + H - 1) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode, and H represents the height of the current video block.

[1190] L23. The method according to clause L19, wherein the block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx + W - 1, y + BVy + H - 1) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode, W represents the width of the current video block, and H represents the height of the current video block.

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

[1192] L25. The method according to any one or more of clauses L1 - L5, wherein the block vector (BVx, BVy) is determined to be valid when all of the following conditions are met: (i) x + BVx >= 0, (ii) y + BVy >= floor(y / Hctu), and (iii) isRec(x + BVx + W - 1, y + BVy + H - 1) is true, where isRec(x, y) is true if the sample (x, y) is reconstructed by the intra block copy mode, W represents the width of the current video block, H represents the height of the current video block, and floor(a) is the largest integer not greater than a.

[1193] L26. The method according to clause L25, wherein the block vector is located in the first CTU in the CTU row.

[1194] L27. The method according to clause L3, wherein the predicted sample having the position (A, B) is determined according to the size of the buffer, the block vector (BVx, BVy), and the upper left corner position (x, y).

[1195] L28. The method according to clause L27, wherein the predicted sample point with position (A, B) includes a predicted sample point with a position calculated according to ((X + BVx) % Wbuf, (Y + BVy) % Hbuf), where Wbuf and Hbuf represent the width and height of the buffer respectively.

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

[1197] M1. A visual media processing method, comprising:

[1198] Performing a conversion between a current video block of a current picture of visual media data and a bit - stream representation of the visual media data,

[1199] wherein the conversion is based on a reference region from the current picture that includes reference sample points for deriving a predicted block of the current video block, and

[1200] wherein a virtual buffer of defined size is used to track the availability of reference sample points for deriving the predicted block.

[1201] M2. The method according to clause M1, wherein the virtual buffer is maintained using virtual pipeline data units (VPDUs), and wherein the size of the virtual buffer is m * W VPDU x n * H VPDU where W VPDU and H VPDU represent the width and height of the VPDU.

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

[1203] M4. The method according to clause M2, wherein m and / or n are at least partially based on the resolution of the picture associated with the current video block or the size of the codec tree unit that includes the current video block.

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

[1205] M6. The method according to clause M2, wherein m and / or are signaled as fields in the bit - stream representation.

[1206] M7. The method according to clause M1, wherein the sample points in the current video block are mapped to (x % (m * W VPDU ), y % (n * H VPDU)) where the samples in the current video block are at (x, y) relative to the top - left corner of the picture; "x % y" is defined as y = x - y * floor(x / y), where floor(a) is the largest integer not greater than a, and W VPDU and H VPDU represent the width and height of the VPDU.

[1207] M8. The method according to clause M1 further includes:

[1208] Using an array to track the availability of samples stored in the virtual buffer.

[1209] M9. The method according to clause M8, wherein the array includes flags indicating whether one or more samples stored in the buffer are used for prediction in the intra - block copy mode.

[1210] M10. The method according to clause M8, wherein the array corresponds to one or more VPDUs of size 3x2.

[1211] M11. The method according to clause M8, wherein the array corresponds to one or more VPDUs of size 4x2.

[1212] M12. The method according to clause M1, wherein a subset of the samples stored in the virtual buffer is flagged as unavailable for prediction.

[1213] M13. The method according to clause M12, wherein the subset of samples flagged as unavailable for prediction is based on the position of the most recently processed VPDU.

[1214] M14. The method according to clause M13, wherein at the start of processing a VPDU, the samples are flagged as unavailable.

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

[1216] M16. The method according to clause M15, wherein the first range is expressed as [xPrevVPDU - 2W VPDU +2mW VPDU ) % mW VPDU, ((xPrevVPDU - 2 * W VPDU + 2 * m * W VPDU ) % (m * W VPDU )) - 1 + W VPDU , and the second range is expressed as [yPrevVPDU % (n * H VPDU ), (yPrevVPDU % (n * H VPDU )) - 1 + H VPDU .

[1217] M17. The method according to clause M15, wherein the first range is expressed as [xPrevVPDU - 2 * W VPDU + 2 * m * W VPDU ) % mW VPDU , ((xPrevVPDU - 2 * W VPDU + 2 * m * W VPDU ) % (m * W VPDU )) - 1 + W VPDU , and the second range is expressed as [yPrevVPDU % (n * H VPDU ), (yPrevVPDU % (n * H VPDU )) - 1 + H VPDU .

[1218] M18. The method according to clause M14, wherein if yPrevVPDU % (n * H VPDU ) is not equal to 0, a subset of the samples located at the position (x, y) is marked as unavailable, where x is within the first predetermined range and y is within the second predetermined range, where (xPrevVPDU, yPrevVPDU) represents the upper left corner of the coding and decoding tree unit of the most recently processed VPDU, and W VPDU and H VPDU represent the width and height of the VPDU.

[1219] M19. The method according to clause M18, wherein the first range is expressed as [xPrevVPDU - W VPDU + 2 * m * W VPDU ) % (m * W VPDU ), ((xPrevVPDU - W VPDU + 2 * m * W VPDU ) % (m * W VPDU )) - 1 + W VPDU , and the second range is expressed as [yPrevVPDU % (n * H VPDU ), (yPrevVPDU % (n * H VPDU )) - 1 + H VPDU .[[]END]]

[1220] M20. The method according to clause M18, wherein the first range is expressed as [xPrevVPDU - W VPDU + 2*m*W VPDU ) % mW VPDU , ((xPrevVPDU - W VPDU + 2*m*W VPDU ) % (m*W VPDU )) - 1 + W VPDU , and the second range is expressed as [yPrevVPDU % (n*H VPDU ), (yPrevVPDU % (n*H VPDU )) - 1 + H VPDU .

[1221] M21. The method according to clause M12, wherein when the codec tree includes a VPDU, the subset of samples flagged as not available for prediction is based on the position of the most recently processed codec tree unit.

[1222] M22. The method according to clause M21, wherein at the start of processing a codec tree unit, the samples are flagged as not available.

[1223] M23. The method according to any one or more of clauses M1 - M22, further comprising:

[1224] Determining the validity of a block vector corresponding to a current video block based on the top - left position, the bottom - left position, and the bottom - right position of the current video block, wherein the determination excludes using the top - right position of the current video block.

[1225] M24. The method according to any one or more of clauses M1 - M23, wherein the transformation is performed in the intra - block copy mode.

[1226] N1. A visual media processing method, comprising:

[1227] Maintaining a buffer for the transformation between a current video block of a current picture of visual media data and a bit - stream representation of the visual media data, the buffer including reference samples from the current picture for deriving a predicted block of the current video block,

[1228] wherein one or more reference samples marked as not available for derivation in the buffer have values outside the pixel value range.

[1229] N2. The method according to clause N1, wherein the pixel value range is expressed as [0, 1 << (bit_depth) – 1], where bit_depth is a positive integer.

[1230] N3. The method according to clause N2, wherein bit_depth is the precision for processing samples.

[1231] N4. The method according to clause N1, wherein the method further comprises:

[1232] Initializing the set of samples in the buffer to a predetermined value indicating the unavailability of the set of samples.

[1233] N5. The method according to clause N4, wherein the predetermined value is -1.

[1234] N6. The method according to any one or more of clauses N4 - N5, wherein the position of the set of samples and / or whether the set of samples is initialized to a predetermined value is based on one or more of the following: the position of the current video block, the size of the current video block, the size of the VPDU including the current video block, and / or the size of the coding tree unit including the current video block.

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

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

[1237] N9. The method according to clause N8, wherein the positions of the plurality of samples are related to the size of the VPDU.

[1238] N10. The method according to clause N8, wherein the position of the set of samples is related to the size of the coding tree unit including the current video block.

[1239] N11. The method according to clause N4, wherein the set of samples in the buffer has a position expressed as (x % wIbcBuf, y % hIbcBuf), where x = xV,..., xV + ctbSize - 1 and y = yV,..., yV + ctbSize - 1, and xV and yV represent the upper left corner position of the VPDU relative to the upper left corner position of the picture, where ctbSize represents the size of the coding tree unit including the current video block, and wIbcBuf and hIbcBuf represent the buffer width and buffer height.

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

[1241] N13. The method according to clause N4, wherein at the start of decoding a video unit, the set of samples is initialized.

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

[1243] O1. A visual media processing method, comprising:

[1244] Performing a transformation between a current video block of a current picture of visual media data and a bitstream representation of the visual media data using a buffer, wherein the buffer includes reference samples from the current picture for deriving a prediction block of the current video block,

[1245] wherein the transformation is based on a rule that specifies that for the bitstream representation to conform to the rule, the reference samples in the buffer are to satisfy bitstream consistency constraints.

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

[1247] O3. The method according to any one or more of clauses O1 - O2, wherein if a sample in the buffer has a value outside the pixel range, the bitstream consistency constraints specify that the bitstream representation is inconsistent.

[1248] O4. The method according to clause O3, wherein the range is [K0, K1], where K0 is set to 0 and K1 is set to (1 << BitDepth - 1), where BitDepth represents the precision of the prediction samples.

[1249] O5. The method according to any one or more of clauses O1 - O2, wherein if the availability information of a sample in the buffer indicates that the sample is unavailable for the current video block, the bitstream consistency constraints specify that the bitstream representation is inconsistent.

[1250] O6. The method according to any one or more of clauses O1 - O2, wherein the samples are luminance samples, and wherein if the availability information of a sample in the buffer indicates that the sample is unavailable for the current video block and a single tree segmentation is used for the current video block, the bitstream consistency constraints specify that the bitstream representation is inconsistent.

[1251] O7. The method according to any one or more of clauses O1 - O6, further comprising:

[1252] Mark the availability information of the sample points according to the values of the sample points in the buffer.

[1253] O8. According to the method described in clause O7, wherein, if the value of the sample point is within the interval represented as [K0, K1], the availability information of the sample point is marked as available.

[1254] O9. According to the method described in clause O8, wherein, K0 is set to 0, and K1 is set to (1 << BitDepth - 1), where BitDepth represents the precision of the predicted sample point.

[1255] O10. According to the method described in any one or more of clauses O1 - O8, wherein, the bitstream consistency constraint is further based on the partition type and tree type of the codec unit associated with the current video block.

[1256] O11. According to the method described in clause O10, wherein, if the partition type is a dual tree and the tree type is a single tree, the bitstream consistency constraint specifies to check whether all color components of the sample point are marked as unavailable.

[1257] O12. According to the method described in clause O10, wherein, if the partition type is a dual tree and the tree type is a dual tree, the bitstream consistency constraint specifies to exclude checking whether the chrominance components of the sample point are marked as unavailable.

[1258] O13. According to the method described in any one or more of clauses O1 - O12, wherein, the transformation is performed in the intra block copy mode.

[1259] XX. According to the method described in any one of clauses L1 - XX, wherein, the transformation includes generating a bitstream representation from the current video block.

[1260] XX. According to the method described in any one of clauses L1 - XX, wherein, the transformation includes generating pixel values of the current video block from the bitstream representation.

[1261] XX. A video encoder device, including a processor configured to implement the method described in any one or more of clauses L1 - XX.

[1262] XX. A video decoder device, including a processor configured to implement the method described in any one or more of clauses L1 - XX.

[1263] XX. A computer - readable medium storing code that embodies processor - executable instructions for implementing the method described in any one or more of clauses L1 - XX.

[1264] In this document, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from the pixel representation of a video to the corresponding bitstream representation, and vice versa. The bitstream representation of a current video block may, for example, correspond to bits juxtaposed within the bitstream or scattered in different places, as defined by the syntax. For example, a macroblock may be encoded based on transform and codec error residual values and also using bits in the headers and other fields in the bitstream.

[1265] As can be understood from the foregoing, for purposes of illustration, specific embodiments of the presently disclosed techniques have been described herein, but various modifications may be made without departing from the scope of the invention. Accordingly, the presently disclosed techniques are not limited except as by the appended claims.

[1266] Embodiments of the subject matter and the functional operations described in this patent document can be implemented in various systems, in digital electronic circuitry, or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents), or in a combination of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible and non-transitory computer-readable medium for execution by, or to control the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances that affect a machine-readable propagated signal, or a combination of one or more of them. The term "data processing unit" or "data processing apparatus" includes all apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus may also include code that creates an execution environment for the computer programs being discussed, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[1267] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (such as one or more scripts stored in a markup language document), in a single file dedicated to the program being discussed, or in multiple coordinated files (such as files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[1268] The processes and logical flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

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

[1270] This specification, together with the drawings, is to be considered as merely exemplary, where exemplary means an example. As used herein, the use of "or" is intended to include "and / or" unless the context clearly dictates otherwise.

[1271] Although this patent document contains many details, these details should not be construed as limiting any invention or the scope that may be claimed, but rather as descriptions of features specific to particular embodiments of a particular invention. Certain features described in the context of separate embodiments in this patent document may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Moreover, although features may be described as acting in certain combinations and even initially claimed as such, in some cases one or more features from a claimed combination may be excluded from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination.

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

[1273] Only some embodiments and examples have been described, and other embodiments, enhancements, and variations may be made based on what is described and illustrated in this patent document.

Claims

1. A method for visual media processing, comprising: Determining a block vector (BVx, BVy) for the conversion between a current video block of a current picture of visual media data and a bitstream representation of the current video block, wherein the validity of the block vector (BVx, BVy) is independent of (1) the position (P, Q) of a sample block and / or (2) whether the samples at the position (P, Q) are reconstructed, and / or (3) the position of the current video block, and wherein the block vector (BVx, BVy) represents a pixel displacement between the current video block and the sample block; and Performing the conversion in an intra block copy mode using the block vector, wherein the intra block copy mode is based on reconstructed blocks in the same video region as the current video block that include reference samples for deriving a predicted block of the current video block, and wherein during the conversion, a predicted sample having a position (A, B) from the reference samples in the buffer is determined at least according to the size of the buffer and / or the block vector (BVx, BVy); Wherein the block vector (BVx, BVy) is determined to be valid when all of the following conditions are met: (i) x + BVx >= 0, (ii) y + BVy >= floor(y / Hctu), and (iii) isRec(x + BVx + W - 1, y + BVy + H - 1) is true, where isRec(x, y) is true if the sample (x, y) is reconstructed by the intra block copy mode, W represents the width of the current video block, H represents the height of the current video block, and floor(a) is the largest integer not greater than a.

2. The method according to claim 1, further comprising: Determining, according to a rule, whether the block vector (BVx, BVy) corresponding to the current video block is valid for the conversion between the current video block of the current picture of the visual media data and the bitstream representation of the visual media data; and Performing the conversion using the block vector, based on a reference region from the current picture that includes reference samples for deriving a predicted block of the current video block, wherein the rule specifies that the block vector (BVx, BVy) is valid when (1) one or more samples from the sample block are outside the current picture and / or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and / or (3) one or more samples from the sample block fail to be reconstructed.

3. The method according to claim 2, wherein, When it is recognized that the block vector (BVx, BVy) is valid, the predicted sample having a position (A, B) from the reference samples in the buffer is determined at least according to the size of the buffer and / or the block vector (BVx, BVy).

4. The method according to claim 1, wherein The reference samples in the buffer correspond to reconstructed samples of a region of the current picture.

5. The method according to claim 4, wherein, The region includes a coding tree unit (CTU) row associated with the current video block.

6. The method according to any one of claims 1-5, wherein, The block vector (BVx, BVy) is determined to be valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside the boundaries of the picture.

7. The method according to claim 6, wherein The block vector (BVx, BVy) is valid regardless of whether x + BVx < 0 or x + BVx > 0.

8. The method according to claim 6, wherein The block vectors (BVx, BVy) are valid regardless of whether x+W+BVx>W pic or x+W+BVx<W pic , where W represents the width of the current video block, and W pic represents the width of the picture.

9. The method according to claim 6, wherein The block vector (BVx, BVy) is valid regardless of whether y + BVy < 0 or y + BVy > 0.

10. The method according to claim 6, wherein The block vectors (BVx, BVy) are valid regardless of whether x + H + BVx > H pic or x + H + BVx < H pic , where H represents the height of the current video block, and H pic represents the height of the picture.

11. The method according to any one of claims 1-5, wherein, The block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside the coding tree unit including the current video block.

12. The method according to claim 11, wherein, The block vectors (BVx, BVy) are valid regardless of whether y + BVy < floor(y / H ctu ) * H ctu or y + BVy > floor(y / H ctu ) * H ctu , where H ctu represents the height of the coding / decoding tree unit, and floor(a) is the largest integer not greater than a.

13. The method according to claim 11, wherein, The block vectors (BVx, BVy) are valid regardless of whether y + H + BVy < floor(y / H ctu ) * H ctu or y + H + BVy > floor(y / H ctu ) * H ctu , where H represents the height of the current video block, and H ctu represents the height of the codec tree unit, and floor(a) is the largest integer not greater than a.

14. The method according to any one of claims 1-5, wherein, The block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside the coding tree unit including the current video block and (n - 1) coding tree units along the left direction.

15. The method according to claim 14, wherein, The block vectors (BVx, BVy) are valid regardless of whether x + BVx < floor(x / W ctu ) * W ctu - (n - 1) * W ctu or x + BVx > floor(X / W ctu ) * W ctu - (n - 1) * W ctu , where W ctu represents the weight of the coding / decoding tree unit, and floor(a) is the largest integer not greater than a.

16. The method according to claim 14, wherein, The block vectors (BVx, BVy) are valid regardless of whether x + W + BVx > floor(X / W ctu )*W ctu +W ctu or x + W + BVx < floor(X / W ctu )*W ctu +W ctu where W represents the width of the current video block, and W ctu represents the weight of the codec tree unit, and floor(a) is the largest integer not greater than a.

17. The method according to any one of claims 1-5, wherein, The block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated based on the block vector (BVx, BVy) and the top-left position (x, y) of the current video block is outside the current CTU row including the current coding tree unit containing the current video block.

18. The method according to claim 17, wherein, The block vector (BVx, BVy) is valid regardless of whether Y + BVy < floor(Y / Hctu) * Hctu or Y + H + BVy >= floor(Y / Hctu) * Hctu + Hctu, where W ctu and H ctu represent the width and height of the CTU respectively, and floor(a) is the largest integer not greater than a.

19. The method according to any one of claims 1-5, wherein, The block vector (BVx, BVy) is determined to be valid regardless of whether the samples fail to be reconstructed.

20. The method according to claim 19, wherein, The block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx, y + BVy) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode.

21. The method according to claim 19, wherein, The block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx + W - 1, y + BVy) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode, and W represents the width of the current video block.

22. The method according to claim 19, wherein, The block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx, y + BVy + H - 1) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode, and H represents the height of the current video block.

23. The method according to claim 19, wherein The block vector (BVx, BVy) is valid regardless of whether isRec(x + BVx + W - 1, y + BVy + H - 1) is false, where isRec(x, y) is true if the pixel (x, y) is reconstructed by the intra block copy mode, W represents the width of the current video block, and H represents the height of the current video block.

24. The method according to any one of claims 1-5, wherein, The block vector (BVx, BVy) is determined to be valid regardless of whether the current video block is included in the first coding tree unit of the coding tree unit row.

25. The method according to claim 1, wherein The block vector is located in the first CTU in the CTU row.

26. The method according to claim 3, wherein, The prediction sample points with positions (A, B) are determined according to the size of the buffer, the block vectors (BVx, BVy), and the top-left position (x, y).

27. The method according to claim 26, wherein, The prediction sample points with positions (A, B) include prediction sample points with positions calculated according to ((X + BVx) % Wbuf, (Y + BVy) % Hbuf), where Wbuf and Hbuf represent the width and height of the buffer, respectively.

28. The method according to claim 1, wherein The transformation is performed in the intra-frame block copy mode.

29. The method according to claim 1, wherein The transformation includes generating the bitstream representation from the current video block.

30. The method according to claim 1, wherein, The transformation includes generating the pixel values of the current video block from the bitstream representation.

31. A video encoder device includes a processor configured to implement the method according to any one of claims 1-28.

32. A video decoder device includes a processor configured to implement the method according to any one of claims 1-28.

33. A computer-readable medium having stored thereon code embodying processor-executable instructions for implementing the method according to any one of claims 1-28.

Images