Mapping restrictions for intra block copy virtual buffers

Abstract

A method for video processing is described. The method includes: for a conversion between a current video block of a video picture of a video and a coded representation of the video, determining a number of reference samples in a reference region of the video picture for predicting the current video block based on a rule, wherein the rule specifies that the number of reference samples is limited to a specific range; and performing the conversion based on the determination.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] In accordance with the applicable Patent Law and / or Paris Convention, this application promptly claims priority to and benefits of International Patent Application No. PCT / CN2019 / 097742 filed on July 25, 2019, International Patent Application No. PCT / CN2019 / 109849 filed on October 7, 2019, and International Patent Application No. PCT / CN2019 / 122606 filed on December 3, 2019. For all purposes prescribed by law, the entire disclosure of the above-mentioned applications is incorporated by reference as part of the disclosure of this application. Technical Field

[0003] This patent document relates to video coding and decoding technology, equipment and systems. Background Art

[0004] Despite advances in video compression, digital video continues to be the largest bandwidth consumer on the Internet and other digital communications networks. As the number of connected user devices capable of receiving and displaying video increases, bandwidth requirements for digital video usage are expected to continue to grow. Summary of the invention

[0005] The present invention relates to a device, system and method for digital video coding and decoding, and in particular, to a universal virtual buffer for intra-frame block copy (IBC). The described method can be applied to existing video coding standards (e.g., High Efficiency Video Codec (HEVC)) and future video coding standards or video encoders.

[0006] In one representative aspect, the disclosed technology can be used to provide a method for video processing. The method includes: for a conversion between a current video block of a video picture of a video and a coded representation of the video, determining the number of reference samples in a reference area of ​​the video picture for predicting the current video block based on a rule, wherein the rule specifies that the number of reference samples is limited to a specific range; and performing the conversion based on the determining step.

[0007] In another exemplary aspect, a method for video processing is disclosed. The method includes: for a conversion between a current video block of a video picture of a video and a coded representation of the video, determining the availability of one or more reference samples of a reference block for predicting the current video block based on a rule, wherein the rule specifies using a granularity of a virtual pipeline data unit (VPDU) level in the determining step; and based on the determining step, performing the conversion between the current block and the coded representation of the current block.

[0008] In yet another aspect, another video processing method is disclosed. The method includes: performing a conversion between a current video block of a video picture of a video and a coded representation of the video according to a rule, wherein the current video block is represented in the coded representation using a residual of a prediction of a reference sample from a reference region in the video picture, and the rule specifies that during the conversion, sample values ​​in the reference region are reset at the beginning of processing each virtual pipeline data unit (VPDU) based on the position of a current VPDU of the current video block.

[0009] In yet another aspect, another video processing method is disclosed. The method includes: for a current video block of a video picture of a video and a coded representation of the video, because the size of the current video block is larger than the size of 64×64 luma samples, determining that samples from a current virtual pipeline data unit (VPDU) and samples from three other most recently processed VPDUs in the video picture can be used as reference samples for generating a prediction of the current video block; and based on the determination, performing the conversion.

[0010] In yet another aspect, another video processing method is disclosed. The method includes performing a conversion between a current video block of a video picture of a video and a coded representation of the video, wherein the conversion includes using a count of the number of available current virtual pipeline data units (VPDUs) mapped to a reference region of the video picture, wherein one or more reference samples from the reference region of the video picture are used to predict the current video block.

[0011] In yet another representative aspect, the above method is implemented in the form of processor executable code and stored in a computer readable program medium.

[0012] In yet another representative aspect, a device configured or operable to perform the above method is disclosed. The device may include a processor programmed to implement the method.

[0013] In yet another representative aspect, a video decoder device may implement a method as described herein.

[0014] The above and other aspects and features of the disclosed technology are described in more detail in the drawings, the description and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 An example of a current picture reference is shown.

[0016] Figure 2 An example of a dynamic reference region in JVET-M0407 is shown.

[0017] Figure 3 A flow chart of a decoding flow with shaping is shown.

[0018] Figure 4 An example of a current CU (blue 602) is shown, blocks filled in red (604) are cross-VPDU column reference blocks, and blocks filled in yellow (606) are cross-VPDU row reference blocks. Each large block indicates a 64×64 VPDU, and green areas (608) indicate pixels that can be reinterpreted for IBC reference.

[0019] Figure 5 is a block diagram of an example of a hardware platform for implementing the visual media decoding or visual media encoding techniques described in this document.

[0020] Figure 6 is a block diagram of an example video processing system in which the disclosed techniques may be implemented.

[0021] Fig. 7A , Figure 7B and Figure 7C A flow chart of an exemplary method for video processing based on some implementations of the disclosed technology is shown.

[0022] FIG. 8A to FIG. 8D A flow chart of an exemplary method for video processing based on some implementations of the disclosed technology is shown. DETAILED DESCRIPTION

[0023] Embodiments of the disclosed technology can be applied to existing video codec standards (e.g., HEVC, H.265) and future standards to improve compression performance. Section headings are used in this document to improve the readability of the specification and do not in any way limit the discussion or embodiments (and / or implementations) to the corresponding sections.

[0024] 2. Video Codec Introduction

[0025] Due to the growing demand for higher resolution video, video coding methods and techniques are ubiquitous in modern technology. Video encoders generally include electronic circuits or software that compress or decompress digital video and are constantly being improved to provide higher coding efficiency. Video encoders convert uncompressed video to a compressed format and vice versa. There is a complex relationship between video quality, the amount of data used to represent the video (determined by the bit rate), the complexity of the encoding and decoding algorithms, sensitivity to data loss and errors, ease of editing, random access, and end-to-end latency (delay). The compression format typically conforms to a standard video compression specification, such as the High Efficiency Video Codec (HEVC) standard (also known as H.265 or MPEG-H Part 2), the yet-to-be-finalized Versatile Video Codec (VVC) standard, or other current and / or future video codec standards.

[0026] Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T produced the H.261 and H.263 standards, ISO / IEC produced the MPEG-1 and MPEG-4 Visual standards, and the two organizations jointly produced the H.262 / MPEG-2 Video standard and the H.264 / MPEG-4 Advanced Video Coding (AVC) standard and the H.265 / HEVC standard. Starting with H.262, video codec standards are based on a hybrid video codec structure that utilizes temporal prediction plus transform coding. In order to explore future video codec technologies beyond HEVC, the Joint Video Exploration Team (JVET) was jointly established by VCEG and MPEG in 2015. Since then, JVET has adopted many new methods and incorporated them into reference software called the Joint Exploration Model (JEM). In April 2018, the Joint Video Experts Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1SC29 / WG11 (MPEG) was established to work on the VVC standard with the goal of reducing the bit rate by 50% compared to HEVC.

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

[0028] Each inter-predicted PU has motion parameters for one or two reference picture lists. The motion parameters include motion vectors and reference picture indices. The use of one of the two reference picture lists may also be signaled using inter_pred_idc. Motion vectors may be explicitly encoded as deltas relative to the predictor.

[0029] When a CU is encoded using skip mode, a PU is associated with the CU and there are no significant residual coefficients, no coded motion vector increments or reference picture indices. A Merge mode is specified, whereby the motion parameters of the current PU are obtained from neighboring PUs (including spatial and temporal candidates). Merge mode can be applied to any inter-predicted PU, not just to skip mode. An alternative to Merge mode is explicit transmission of motion parameters, where each PU explicitly signals: the motion vector (more precisely, the motion vector difference (MVD) compared to the motion vector predictor), the corresponding reference picture index for each reference picture list, and the reference picture list usage. Such a mode is named Advanced Motion Vector Prediction (AMVP) in this disclosure.

[0030] When signaling indicates that one of the two reference picture lists is to be used, the PU is generated from one block of samples. This is called "unidirectional prediction". Unidirectional prediction can be used for both P slices and B slices.

[0031] When signaling indicates that both of the reference picture lists are to be used, the PU is generated from two blocks of samples. This is called "bi-prediction". Bi-prediction is only available for B slices.

[0032] The following text provides the inter prediction modes specified in HEVC. The description starts with the Merge mode.

[0033] 2.2 Current Image Reference

[0034] HEVC Screen Content Codec Extension (HEVC-SCC) and the current VVC Test Model (VTM-3.0) have adopted Current Picture Reference (CPR), or once named Intra Block Copy (IBC). IBC extends the concept of motion compensation from inter-frame codecs to intra-frame codecs. Figure 1 As shown, when CPR is applied, the current block is predicted by a reference block in the same picture. Before encoding or decoding the current block, the samples in the reference block must have been reconstructed. Although CPR is not efficient for most camera-captured sequences, it shows significant codec gains for screen content. The reason is that there are many repeated patterns in screen content pictures, such as icons and text characters. CPR can effectively remove the redundancy between these repeated patterns. In HEVC-SCC, if the inter-frame codec codec unit (CU) selects the current picture as its reference picture, the inter-frame codec codec unit (CU) can apply CPR. In this case, MV is renamed as block vector (BV), and BV always has integer pixel precision. In order 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 the multi-view / 3D video codec standard, the inter-view reference picture is also marked as a "long-term" reference picture.

[0035] After the BV finds its reference block, a prediction can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixels from the original signal. Transformation and quantization can then be applied as in other codec modes.

[0036] 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 subject to some restrictions, some or all pixel values ​​are not defined. Basically, there are two solutions to deal with such problems. One is to disallow such cases, for example in bitstream conformance. The other is to apply padding to those undefined pixel values. The following subsections describe the solutions in detail.

[0037] 2.3 CPR in HEVC Screen Content Codec Extension

[0038] In the screen content codec extension of HEVC, when a block uses the current picture as a reference, it should be ensured that the entire reference block is within the available reconstruction area, as indicated in the following normative text:

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

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

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

[0042] The bitstream conformance requirement is that when the reference picture is the current picture, the luma motion vector mvLX shall obey the following constraints:

[0043] - When the derivation process for z-scan order block availability specified in Section 6.4.1 is called with (xCurr, yCurr) set equal to (xCb, yCb) and the adjacent luminance position (xNbY, yNbY) set equal to (xPb+(mvLX[0]>>2)-offsetX, yPb+(mvLX[1]>>2)-offsetY) as input, the output shall be equal to TRUE.

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

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

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

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

[0048] - The following conditions should be true:

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

[0050] Therefore, it will not happen that the reference block overlaps with the current block or is outside the picture. No padding of the reference or prediction blocks is required.

[0051] 2.4 CPR / IBC in the VVC test model

[0052] In the current VVC test model (i.e., VTM-3.0 design), the entire reference block should use the current codec tree unit (CTU) and not overlap with the current block. Therefore, no padding of the reference or prediction block is required.

[0053] When dual-tree is enabled, the partitioning structure can be different from luma CTU to chroma CTU. Thus, for a 4:2:0 color format, one chroma block (eg, CU) can correspond to a co-located luma region that has been partitioned into multiple luma CUs.

[0054] Chroma blocks can be coded using CPR mode only if the following conditions are true:

[0055] (1) Each luma CU in a co-located luma block should be coded and decoded using CPR mode

[0056] (2) Each of the BVs of the luma 4×4 block is first converted into the BV of the chroma block, and the BV of the chroma block is a valid BV.

[0057] If either of the two conditions is false, the chroma block shall not be coded using CPR mode.

[0058] Note that the definition of "Effective BV" has the following restrictions:

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

[0060] (2) All samples in the reference block identified by BV have been reconstructed.

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

[0062] In VTM3.0, the reference area of ​​CPR / IBC is limited to the current CTU, with a maximum of 128x128. JVET-L0297 / JVET-M0407 / JVET-M0408 proposed the following method: dynamically change the reference area to reuse the memory for storing reference samples of CPR / IBC, so that CPR / IBC blocks can have more reference candidates, and the reference buffer of CPR / IBC can be retained or reduced from one CTU.

[0063] Figure 2 A method is shown where the block is 64x64 and the CTU contains 4 64x64 blocks. When encoding or decoding a 64x64 block, the previous 3 64x64 blocks can be used as references. In this way, the decoder only needs to store 4 64x64 blocks to support CPR / IBC. The above method is used in VTM4.0.

[0064] Assume that the position of the current luma CU relative to the upper left corner of the picture is (x, y) and the block vector is (BVx, BVy). In the current design, it can be determined whether the BV is valid by the following: the luma 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).

[0065] 2.6 Virtual IBC Buffer Proposed in JVET-O1170

[0066] The virtual buffer concept is introduced to help describe the reference area for IBC prediction mode. For a CTU size of ctbSize, we express wIbcBuf = 128*128 / ctbSize, and define a virtual IBC buffer ibcBuf, where the width is wIbcBuf, and the height is ctbSize. Therefore,

[0067] - For CTU size of 128x128, the size of ibcBuf is also 128x128.

[0068] - For CTU size 64x64, the size of ibcBuf is 256x64.

[0069] - For CTU size 32x32, ibcBuf size is 512x32.

[0070] Note that the width and height of VPDU are both min(ctbSize, 64). We denote Wv = min(ctbSize, 64).

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

[0072] (1) At the start of decoding each CTU row, flush the entire ibcBuf with the value (-1).

[0073] (2) When starting to decode the VPDU (xVPDU, yVPDU) relative to the upper left corner of the picture, set ibcBuf[x][y] = -1, where x = xVPDU% wIbcBuf, ..., xVPDU% wIbcBuf + Wv-1; y = yVPDU% ctbSize, ..., yVPDU% ctbSize + Wv-1.

[0074] (3) After decoding, the CU contains (x, y) relative to the upper left corner of the picture. Set

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

[0076] Therefore, the bitrate limit can be simply described as

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

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

[0079] 2.7 VPDU

[0080] A virtual pipeline data unit (VPDU) is defined as a non-overlapping unit in a picture. In a hardware decoder, consecutive VPDUs are processed by multiple pipeline stages simultaneously. In most pipeline stages, the VPDU size is roughly proportional to the buffer size, so it is important to keep the VPDU size small. In most hardware decoders, the VPDU size can be set to the maximum transform block (TB) size. However, in VVC, ternary tree (TT) and binary tree (BT) segmentation may cause the VPDU size to increase.

[0081] To keep the VPDU size to 64x64 luma samples, the following normative segmentation restrictions are applied in VTM5 (with syntax signalling modifications):

[0082] - For CUs with width or height equal to 128 or both width and height equal to 128, TT partitioning is not allowed.

[0083] - For 128xN CUs with N≤64 (i.e., width equal to 128 and height less than 128), horizontal BT is not allowed.

[0084] - For Nx128 CUs with N≤64 (i.e., height equal to 128 and width less than 128), vertical BT is not allowed.

[0085] In VVC, the width and height of VPDU are usually agreed to be min(64, CtbSizeY) in luma samples. Therefore, for CTB / CTU size of 64x64, 128x128 or 256x256, the VPDU size is 64x64. For CTB / CTU size of 32x32, the VPDU size is 32x32.

[0086] 2.8 Buffer Management and Block Vector Encoding and Decoding for Intra-frame Block Copy

[0087] Details of various IBC buffer functions and their corresponding management are described in PCT / CN2019 / 093552, which is incorporated by reference.

[0088] 2.9 In-Loop Reshaping (ILR) in JVET-M0427

[0089] The basic idea of ​​in-loop reshaping (ILR) is to transform the original (in the first domain) signal (prediction / reconstruction signal) into the second domain (shaping domain).

[0090] The loop brightness shaper is implemented as a pair of lookup tables (LUTs), but only one of the two LUTs needs to be signaled, as the other can be calculated from the signaled LUT. Each LUT is a one-dimensional, 10-bit, 1024-entry mapping table (1D-LUT). One LUT is the forward LUT FwdLUT, which converts the input brightness code value Y i Mapped to the changed value Y r : Y r =FwdLUT[Y i ]. The other LUT is the inverse LUT InvLUT, which changes the codec value Y r Map to ( The reconstruction value represented by Y i ).

[0091] 2.9.1 PWL Model

[0092] Conceptually, piecewise linear (PWL) is implemented as follows:

[0093] Let x1, x2 be two input pivot points, and y1, y2 be their corresponding overall output pivot points. The output value y for any input value x between x1 and x2 can be interpolated by the following equation:

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

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

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

[0097] Here, m is a scalar, c is an offset, and FP_PREC is a constant value used to specify the precision.

[0098] Note that in CE-12 software, the PWL model is used to pre-compute the 1024-entry FwdLUT and InvLUT mapping tables; however, the PWL model also allows implementations to compute the same mapping values ​​on-the-fly without pre-computing the LUTs.

[0099] 2.9.2 Test CE12-2

[0100] 2.9.2.1 Brightness Shaping

[0101] Test 2 of in-loop luma shaping (ie CE12-2 in the proposal) provides a lower complexity pipeline that also eliminates the decoding latency of block-by-block intra prediction in inter slice reconstruction. For both inter and intra slices, intra prediction is performed in the shaped domain.

[0102] Intra prediction is always performed in the shaped domain regardless of the slice type. With such an 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 without depending on the slice. Figure 3 A block diagram of the mode-based CE12-2 decoding process is shown.

[0103] CE12-2 also tests a 16-segment piecewise linear (PWL) model for luma and chroma residual scaling, instead of the 32-segment PWL model of CE12-1.

[0104] Inter-frame strip reconstruction using the loop luma shaper in CE12-2 (lighter shaded blocks represent signals in the shaping domain: luma residual; predicted intra-frame luma; and reconstructed intra-frame luma)

[0105] 2.9.2.2 Luma-Dependent Chroma Residual Scaling

[0106] Luma-dependent chroma residual scaling is a multiplication process implemented using fixed-point integer arithmetic. Chroma residual scaling compensates for the interaction of luma and chroma signals. Chroma residual scaling is applied at the TU level. More specifically, the following applies:

[0107] - For intra frames, the reconstructed brightness is averaged.

[0108] -For inter frames, the predicted brightness is averaged.

[0109] The average value is used to identify the index in the PWL model. This index identifies the scaling factor cScaleInv. The chroma residual is multiplied by this number.

[0110] Note that the chroma scaling factors are computed from the predicted luma values ​​of the forward map rather than the reconstructed luma values.

[0111] 2.9.2.3 Signaling of ILR assistance information

[0112] The parameters are (currently) sent in a slice-group header (similar to ALF). These are reported to require 40-100 bits.

[0113] The following specification is based on version 9 of JVET-L1001. Added syntax is prefixed with "++".

[0114] In 7.3.2.1 Sequence Parameter Set RBSP Syntax

[0115]

[0116] In 7.3.3.1 Generic slice group header syntax

[0117]

[0118]

[0119] Add new syntax slice group shaper model:

[0120] ++reshaper_model_min_bin_idx ue(v) ++reshaper_model_delta_max_bin_idx ue(v) ++reshaper_model_bin_delta_abs_cw_prec_minus1 ue(v) ++for(i=reshaper_model_min_bin_idx;i<=reshaper_model_max_bin_idx;i++){ ++reshape_model_bin_delta_abs_CW[i] u(v) ++if(reshaper_model_bin_delta_abs_CW[i])>0) ++reshaper_model_bin_delta_sign_CW_flag[i] u(1) ++} ++}

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

[0122] sps_reshaper_enabled_flag equal to 1 specifies that the reshaper is used in the Coded Video Sequence (CVS). sps_reshaper_enabled_flag equal to 0 indicates that the reshaper is not used in the CVS.

[0123] ++In the slice group header syntax, add the following semantics

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

[0125] tile_group_reshaper_enabled_flag equal to 1 specifies that the reshaper is enabled for the current slice group. tile_group_reshaper_enabled_flag equal to 0 specifies that the reshaper is not enabled for the current slice group. When tile_group_reshaper_enable_flag is not present, it is inferred to be equal to 0.

[0126] tile_group_reshaper_chroma_residual_scale_flag equal to 1 specifies that chroma residual scaling is enabled for the current slice group. tile_group_reshaper_chroma_residual_scale_flag equal to 0 specifies that chroma residual scaling is not enabled for the current slice group. When tile_group_reshaper_chroma_residual_scale_flag is not present, it is inferred to be equal to 0.

[0127] ++Add tile_group_reshaper_model() syntax

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

[0129] 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 equal to MaxBinIdx - reshape_model_delta_max_bin_idx.

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

[0131] reshape_model_bin_delta_abs_CW[i] specifies the absolute difference codeword value of the i-th binary number.

[0132] reshaper_model_bin_delta_sign_CW_flag[i] specifies the sign of reshape_model_bin_delta_abs_CW[i] as follows:

[0133] -If reshape_model_bin_delta_sign_CW_flag[i] is equal to 0, the corresponding variable RspDeltaCW[i] is positive.

[0134] - Otherwise (reshape_model_bin_delta_sign_CW_flag[i] is not equal to 0), the corresponding variable RspDeltaCW[i] is a negative value.

[0135] When reshape_model_bin_delta_sign_CW_flag[i] is not present, it is inferred to be equal to 0.

[0136] Variable RspDeltaCW[i]=(1 2*reshape_model_bin_delta_sign_CW[i])*reshape_model_bin_delta_abs_CW[i];

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

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

[0139] -If reshaper_model_min_bin_idx<=i<=reshaper_model_max_bin_idx

[0140] Then RspCW[i]=OrgCW+RspDeltaCW[i].

[0141] -Otherwise, RspCW[i]=0.

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

[0143] The variable InputPivot[i] where i ranges from 0 to MaxBinIdx+1 (inclusive) is derived as follows:

[0144] InputPivot[i]=i*OrgCW

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

[0146]

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

[0148] ChromaResidualScaleLut

[64] ={16384,16384,16384,16384,16384,16384,16384,8192,8192,8192,8192 ,5461,5461,5461,5461,4096,4096,4096,4096,3277,3277,3277,3277,2731,2731,2731,2731,2341,234 1,2341,2048,2048,2048,1820,1820,1820,1638,1638,1638,1489,1489,1489,1489,1365,1365,1365,1260,1260,1260,1170,1170,1170,1092,1092,1092,1024,1024,1024,1024};

[0149] shiftC=11

[0150] if (RspCW[i] == 0)

[0151] Then ChromaScaleCoef[i]=(1< <shiftC)

[0152] - Otherwise (RspCW[i]!=0), then ChromaScaleCoef[i]=ChromaResidualScaleLut[RspCW[i]>>1]

[0153] 2.9.2.4 Use of ILR

[0154] On the encoder side, each picture (or slice group) is first converted to the shaped domain. And all encoding and decoding processes are performed in the shaped domain. For intra prediction, the neighborhood blocks are in the shaped domain; for inter prediction, the reference blocks (generated from the original domain of the decoded picture buffer) are first converted to the shaped domain. Then the residual is generated and encoded and decoded to the bitstream.

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

[0156] Forward shaping of the prediction signal is disabled in the following cases:

[0157] o The current block is intra-coded

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

[0159] o The current block is coded in combined inter-intra mode (CIIP) and forward shaping is disabled for intra-predicted blocks

[0160] 3 Disadvantages of existing implementations

[0161] There are some problems in the current IBC virtual buffer design.

[0162] (1) How to keep the IBC virtual buffer undefined when the CTU size is larger than 128×128.

[0163] (2) The relationship between the virtual buffer size and the reference sample size is unclear.

[0164] (3) The row buffer for IBC mode and the BV for CTU rows can be reduced.

[0165] (4) The sub-images may be too restricted.

[0166] (5) The chroma QP table may not be designed in the correct way.

[0167] 4 Exemplary Method for Generic Virtual Buffer for IBC

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

[0169] Embodiments of the technology disclosed herein overcome the shortcomings of existing implementations, thereby providing video codecs with higher codec efficiency. The method of a general virtual buffer for IBC based on the disclosed technology can improve both existing video codec standards and future video codec standards, and is explained below as examples described in various implementations. The examples of the technology disclosed herein provided below explain the overall concept and are not meant to be interpreted as limitations. In the examples, the various features described in these examples may be combined unless clearly indicated to the contrary.

[0170] Related to IBC buffer

[0171] 1. The size of the IBC virtual buffer (eg, which is used to decide the validity of a block vector or a map sample) may depend on the VPDU size, CTB / CTU size.

[0172] a. In one example, the width multiplied by the height of the virtual buffer may be fixed, however, the width and / or height of the virtual buffer may depend on the VPDU size and / or the CTB / CTU size.

[0173] b. In one example, the height of the virtual buffer may be equal to the height of the CTB / CTU.

[0174] i. Alternatively, the width of the virtual buffer may be set to (IBC virtual buffer size / CTB height).

[0175] c. In one example, the width of the virtual buffer may be equal to the width of the CTB / CTU.

[0176] d. In one example, the width of the virtual buffer can be one or more times the width of the VPDU

[0177] e. In one example, the height of the virtual buffer can be one or more times the height of the VPDU

[0178] 2. It is recommended to allocate a larger IBC virtual buffer size compared to the memory size required for the IBC BV search area.

[0179] a. In one example, the IBC virtual buffer size may be larger than the total size of the VPDU memory used for IBC.

[0180] i. In one example, one or more CTUs may be allocated to an IBC virtual buffer.

[0181] b. In one example, the width of the IBC virtual buffer size may be (128*128 / ctbSizeY+ctbSizeY).

[0182] c. In one example, the width of the IBC virtual buffer size may be (128*128 / ctbSizeY+ctbSizeY), and the height of the IBC virtual buffer size may be ctbSizeY.

[0183] d. In one example, the width of the IBC virtual buffer may be (256*128 / ctbSizeY). Alternatively, the height of the IBC virtual buffer may be ctbSizeY.

[0184] e. In one example, a larger IBC virtual buffer may be allocated for a larger CTU / CTB.

[0185] i. In one example, when the CTU size is not less than K (eg, K=128), the width of the IBC virtual buffer may be (128*128 / ctbSizeY+ctbSizeY). Alternatively, the height of the IBC virtual buffer may be ctbSizeY.

[0186] ii. In one example, when the CTU size is less than K (eg, K=128), the width of the IBC virtual buffer may be (128*128 / ctbSizeY). Alternatively, the height of the IBC virtual buffer may be ctbSizeY.

[0187] 3. The reference block for an IBC block can be restricted to be completely within a certain VPDU row or VPDU column

[0188] a. In one example, reference blocks may be prohibited from crossing different VPDU rows.

[0189] b. In one example, reference blocks may be prohibited from crossing different VPDU columns.

[0190] c. In one example, the VPDU row or column may be associated with a picture.

[0191] d. In one example, the VPDU row or column mentioned above may be associated with an IBC virtual buffer.

[0192] e. Furthermore, alternatively, when the reference block pointed to by the BV spans two or more CTUs / CTBs, the above method may be called.

[0193] 4. The reference block for an IBC block can span multiple VPDUs / span different VPDU rows / VPDU columns. However, additional operations may be required to fill in some prediction values ​​in the reference block.

[0194] a. In one example, some predicted values ​​may be populated with some default values.

[0195] 5. Range limitations may be applied to the block vectors (BV) and / or block vector differences (BVD) used in IBC mode.

[0196] a. In one example, the allowed range of BV / BVD may depend on the location of the current IBC encoded block, such as the coordinates relative to the CTU / CTB covering the current block.

[0197] b. In one example, the block vector can be limited to [-2 m , 2 m -1].

[0198] c. In one example, the block vector difference after precision conversion can be limited to [-2 n , 2 n -1].

[0199] d. In one example, the block vector difference after precision conversion can be limited to [-2 n +1,2 n -1].

[0200] e. In one example, the block vector difference signaled in the bitstream can be limited to [-2 n , 2 n -1].

[0201] f. In one example, the block vector difference signaled in the bitstream can be limited to [-2 n +1,2 n -1].

[0202] g. In one example, m is set to 18 or 17 or 15.

[0203] h. In one example, n is set to 17 or 16 or 14.

[0204] i. In one example, m and / or may depend on the precision of the BV / motion vector storage and / or the precision associated with the block vector differences.

[0205] j. In one example, the block vector may be restricted to the same range as the motion vector used for inter prediction mode.

[0206] k. In one example, the block vector difference may be constrained to be within the same range as the motion vector used for inter prediction mode.

[0207] 1. In one example, a conforming bitstream should satisfy the above sub-items are satisfied.

[0208] i. Alternatively, before encoding / decoding a block using a BV / BVD, a clipping process for the BV / BVD may be applied to the decoded BV / BVD.

[0209] 6. The number of available samples mapped to the IBC virtual buffer can be limited.

[0210] a. In one example, the maximum number of available samples mapped to the buffer may be less than the IBC virtual buffer size.

[0211] b. In one example, when the CTB / CTU size is larger than 64×64, the maximum number of available samples mapped to the IBC virtual buffer may be fixed.

[0212] c. In one example, the number of available samples mapped to the IBC virtual buffer may be limited to be less than or equal to one or more times the number of samples in a VPDU.

[0213] i. In one example, when the CTU / CTB size is larger than 64×64, the number of available samples mapped to the IBC virtual buffer may be limited to be less than or equal to three times the number of samples in the VPDU.

[0214] 7. Unavailability marking of IBC reference samples mapped to IBC virtual buffers can be performed at the granularity of VPDU

[0215] a. In one example, when samples need to be marked as unavailable, samples within the same VPDU may also be marked as unavailable.

[0216] b. In one example, one or more VPDUs may be marked as unavailable at the same time.

[0217] c. In one example, which VPDU's samples are marked as unavailable may depend on the location of the current VPDU.

[0218] d. In one example, which VPDU's samples are marked as unavailable may depend on the location of the previously or most recently decoded VPDU.

[0219] 8. Unavailability marking of IBC reference samples mapped to an IBC virtual buffer may be performed just before encoding / decoding a video unit (e.g., CU / PU / TU). In one example, for a WxH video unit with an upper left position (X, Y) relative to the upper left of the slice / slice / brick / sub-picture / picture containing the video unit, the following may apply.

[0220] a. In one example, before encoding / decoding a video unit, the corresponding area in the virtual buffer may be marked as unavailable.

[0221] b. In the above example, the corresponding IBC virtual buffer may be the luminance region of x=(X%IBC_buf_width)..(X%IBC_buf_width)+W-1 and y=(Y%IBC_buf_height)..(Y%IBC_buf_height)+H-1.

[0222] c. In the above example, the corresponding IBC virtual buffer can be the chroma area of ​​x=(X%IBC_buf_width) / SubWidthC..((X%IBC_buf_width)+W-1) / SubWidthC and y=(Y%IBC_buf_height) / SubHeightC..((Y%IBC_buf_height)+H-1) / SubHeightC.

[0223] d. In the above example, IBC_buf_width refers to the IBC virtual buffer width; IBC_buf_height refers to the IBC virtual buffer height.

[0224] e. Alternatively, unavailability marking of IBC reference samples mapped to the IBC virtual buffer may be performed before encoding / decoding the K*L samples / pixels in the video unit.

[0225] i. In one example, K and / or L are both equal to 1.

[0226] ii. In one example, K and / or L are set to the sub-block size used in the CU / PU.

[0227] 9. When the CTU / CTB size is larger than 64×64, the IBC reference can be the current VPDU and the three most recently decoded VPDUs.

[0228] a. In one example, an index may be maintained for each VPDU mapped to the virtual IBC buffer to track the decoding order of each VPDU.

[0229] 10. A counter may be maintained to track the number of available VPDUs mapped to the buffer.

[0230] a. In one example, the counter is reset to 0 at the start of decoding each CTU row, and is incremented by 1 when one VPDU mapped to the buffer has been decoded.

[0231] b. In one example, when the counter is greater than a certain value (eg, 3), samples of one VPDU mapped to the buffer may be marked as unavailable, and the counter may be decreased by 1.

[0232] 11. When the CTU / CTB size is 128×128, the size of the corresponding IBC virtual buffer can be 256×128.

[0233] a. Alternatively, the IBC virtual buffer may have size (k*64)×128, where k>2.

[0234] 12. When the CTU / CTB size is 256×256, the corresponding IBC virtual buffer may have a size of 64×256 to track the availability of reference samples, i.e., ibcBufW=64, ibcBufH=256.

[0235] a. In one example, before decoding a VPDU with top left position (x0, y0), the corresponding VPDU row (0, y0%256) in the IBC buffer is set to -1.

[0236] 13. When the CTU / CTB size is 256×256, the corresponding IBC virtual buffer may have a size of 128×256 to track the availability of reference samples, i.e., ibcBufW=128, ibcBufH=256.

[0237] a. In one example, except for a certain VPDU row, only one VPDU (excluding the current VPDU) may be reserved for each VPDU row in the buffer.

[0238] i. In one example, except for the last VPDU row, only one VPDU (excluding the current VPDU) may be retained for each VPDU row in the buffer.

[0239] 14. The IBC buffer may not be reset at the beginning of a CTU row.

[0240] a. In one example, the IBC virtual buffer inherited from the above CTU row can be used as the initial state of the current CTU row.

[0241] b. Alternatively, the IBC virtual buffer may be partially reset at the beginning of a CTU row.

[0242] i. In one example, the VPDU in the above CTU row may be inherited into the current IBC buffer, and other buffer areas may be reset.

[0243] ii. In one example, the bottom left VPDU of the above CTU row may be inherited into the current IBC buffer, and other buffer areas may be reset.

[0244] 15. Whether and / or how samples in a buffer are marked as unavailable can be independent of the chroma block position.

[0245] a. In one example, only when the luma block is the first block in the VPDU, the corresponding samples in the IBC buffer may be marked as unavailable.

[0246] b. In one example, when decoding a chroma codec unit, resetting or marking samples in the buffer as unavailable may not be allowed.

[0247] 16. It is proposed that when starting to decode each VPDU, the corresponding IBC virtual buffer can be reset based on the current VPDU position.

[0248] a. In one example, the IBC virtual buffer corresponding to (xVPDU+ctbSizeY, yVPDU) will be reset, where (xVPDU, yVPDU) represents the position of the current VPDU relative to the upper left corner of the picture.

[0249] 17. Whether and / or how to mark samples in the IBC virtual buffer may depend on the position of the most recently decoded VPDU and the VPDU size.

[0250] a. In one example, whether and / or how samples in the IBC virtual buffer are marked as unavailable may depend on the location of the most recently decoded VPDU, ie, brick / slice / slice / picture.

[0251] b. In one example, whether and / or how samples in the IBC virtual buffer are marked as unavailable may depend on the position of the most recently decoded VPDU in the CTU row of the brick / slice / slice / picture.

[0252] c. In one example, the samples in the IBC virtual buffer that will be marked as unavailable may be independent of the location of the current block.

[0253] Related to IBC line buffer

[0254] 18. Block vector prediction across CTU rows can be disabled

[0255] a. In one example, a block vector prediction may be considered unavailable when it is from a different CTU row than the current CTU row.

[0256] 19. The deblocking decision for the current IBC block that spans CTU rows can be independent of the block vectors or motion vectors of other blocks.

[0257] a. In one example, when two blocks have different CTU rows and one block is coded in IBC mode and the other block is coded in IBC or inter mode, the deblocking boundary strength may always be set equal to 1.

[0258] b. In one example, when two blocks have different CTU rows and one block is coded in IBC mode and the other block is coded in IBC or inter mode, the deblocking boundary strength may always be set equal to 0.

[0259] 20. The deblocking decision for the current IBC block that spans CTU rows can be independent of whether the other block is coded in IBC mode or in inter mode.

[0260] a. In one example, when two blocks have different CTU rows and one block is coded in IBC mode and the other block is not coded in intra mode, the deblocking boundary strength may always be set equal to 1.

[0261] Related to sub-image

[0262] 21. It is proposed to allow prediction between two sub-pictures (e.g., motion / sample prediction) under certain conditions.

[0263] a. In one example, if the boundary of the first sub-picture coincides with the picture boundary (or consistency window boundary), it may be allowed to use information from the second sub-picture.

[0264] i. Furthermore, alternatively, the sub-picture boundary is a left sub-picture boundary or a right sub-picture boundary.

[0265] ii. Furthermore, alternatively, the picture boundary is a left picture boundary or a right picture boundary.

[0266] iii. In one example, the left (or right) boundary of the second sub-picture may coincide with the left (or right) boundary of the picture.

[0267] b. The condition is true only if picture wrapping is enabled (eg, sps_ref_wraparound_enabled_flag is equal to 1).

[0268] 22. Image wrapping excludes sub-images.

[0269] a. In one example, if sub-pictures are used, picture wrapping is enabled.

[0270] b. In one example, if picture wrapping is enabled, subpictures cannot be used.

[0271] c. Alternatively, when sub-pictures are used, picture wrapping can be enabled.

[0272] iv. In one example, picture wrapping may be enabled for sub-pictures having borders that coincide with picture borders.

[0273] Related to the chroma QP table

[0274] 23. The minimum index of the chroma QP table can be independent of the bit depth used for the chroma components.

[0275] a. In one example, the minimum index of the chroma QP table may depend on the bit depth used for the luma component.

[0276] b. In one example, the minimum index in the chroma QP table may be QpBdOffset Y , that is 6*bit_depth_luma_minus8.

[0277] 5. Exemplary Implementation of the Disclosed Technology

[0278] 5.1 Example #1

[0279] When the CTU size is 256×256, a 64×256 IBC virtual buffer ibcBuf is maintained, i.e., ibcBufW=64, ibcBufH=256. The VPDU size is 64×64, and in addition to the current VPDU, the on-chip memory of 3 additional VPDUs is used to store IBC reference samples.

[0280] The buffer ibcBuf is reset to -1 when starting to decode a CTU line.

[0281] When starting to decode a new VPDU at the top left position (x0, y0) relative to the top left corner of the picture, the following applies

[0282] 1) For x=x0..x0+63, y=y0..y0+63, ibcBuf[x%ibcBufW][y%ibcBufH]=-1

[0283] 2) After decoding a CU, for (x, y) in the CU relative to the upper left corner of the picture, set ibcBuf[x%ibcBufW][y%ibcBufH] to the reconstructed value of the sample (x, y) before loop filtering (e.g., SAO, deblocking, ALF).

[0284] 3) Given bv, the reference for (x, y) is ibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH]

[0285] The bitstream is restricted to the following two conditions should be true

[0286] 1) For a WxH block at the upper left position (x, y) relative to the upper left corner of the picture, (y%ibcBufH)+H<=ibcBufH

[0287] 2) For x=0..W-1, y=0..,H-1, ibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH] should not contain invalid pixel values, e.g., -1.

[0288] 5.2 Example #2

[0289] When the CTU size is 256×256, a 128×256 IBC virtual buffer ibcBuf is maintained, i.e., ibcBufW = 128, ibcBufH = 256. The VPDU size is 64×64, and in addition to the current VPDU, the on-chip memory of 3 additional VPDUs is used to store IBC reference samples.

[0290] The buffer ibcBuf is reset to -1 when starting to decode a CTU row. xPrevVPDU=0 and yPrevVPDU=0.

[0291] When starting to decode a new VPDU at the top left position (x0, y0) relative to the top left corner of the picture, the following applies

[0292] 1) If (yPrevVPDU+64)%ibcBufH is not equal to 0,

[0293] For x=x0..x0+63, y=y0..y0+63, ibcBuf[(x+xPrevVPDU-64)%ibcBufW][(y+yPrevVPDU)%ibcBufH]=-1

[0294] 2) Otherwise ((yPrevVPDU+64)%ibcBufH is equal to 0),

[0295] For x=x0…x0+63,y=y0…y0+63,

[0296] ibcBuf[(x+xPrevVPDU)%ibcBufW][(y+yPrevVPDU)%ibcBufH]=-1

[0297] 3) xPrevVPDU = x0 and yPrevVPDU = y0

[0298] The bitstream is restricted to the following two conditions should be true

[0299] 1) For a WxH block at the upper left position (x, y) relative to the upper left corner of the picture, (y%ibcBufH)+H<=ibcBufH

[0300] 2) For x=0..W-1, y=0..,H-1, ibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH] should not contain invalid pixel values, e.g., -1.

[0301] 5.3 Example #3

[0302] This embodiment reflects item 2. Changes marked in bold italics are based on VVC Draft 6 document JVET-O2001-vE.

[0303] Add 2 to specify the minimum luma codec block size.

[0304] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows:

[0305] CtbLog2SizeY=log2_ctu_size_minus5+5 (7-15)

[0306] CtbSizeY=1< <CtbLog2SizeY (7-16)

[0307] MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2(7-17)

[0308] MinCbSizeY=1< <MinCbLog2SizeY (7-18)

[0309]

[0310] IbcBufWidthC=IbcBufWidthY / SubWidthC (7-20)

[0311] Vsize=min(64,CtbSizeY) (7-21)

[0312] 5.4 Example #4

[0313] This embodiment reflects item 3.

[0314] Let (xCb, yCb) be the top left position of the current block relative to the top left corner of the picture. The block width and height are W and H respectively. The block vector of the block is (xBv, yBv)

[0315] Restrictions on VPDU lines relative to images:

[0316] The bitstream constraint is that (xCb+xBv) / vSize should be equal to (xCb+xBv+W-1 / vSize).

[0317] VPDU column restrictions relative to the picture:

[0318] The bitstream constraint is that (yCB+yBv) / vSize should be equal to (yCB+yBv+H-1 / vSize).

[0319] VPDU line limit relative to IBC buffer:

[0320] The bitstream constraint is that ((xCb+xBv)%IbcBufWidthY) / vSize should be equal to (((xCb+xBv+W-1)%IbcBufWidthY) / vSize).

[0321] VPDU queue limits relative to the IBC buffer:

[0322] The bitstream constraint is that ((yCb+yBv)%IbcBufHeightY) / vSize should be equal to (((yCb+yBv+H-1)%IbcBufHeightY) / vSize).

[0323] 5.5 Example #5

[0324] This embodiment reflects that marking samples in the IBC virtual buffer as unavailable should be independent of chroma blocks.

[0325] Changes marked in bold and italics are based on JVET-O2001-vE. Deleted text is marked with double brackets (e.g., [[a]] indicates the character "a" has been deleted).

[0326] 7.4.9.5 Codec unit semantics

[0327] When ResetIbcBuf is equal to 1, the following applies:

[0328] - For x=0..IbcBufWidthY-1 and y=0..CtbSizeY-1, make the following assignments:

[0329] IbcVirBuf[0][x][y]=-1 (7-153)

[0330] -The variable ResetIbcBuf is set equal to 0.

[0331] When x0%VSize equals 0 and y0%VSize equals 0 When , the following assignments are made to x = x0..x0+VSize-1 and y = y0..y0+VSize-1:

[0332] IbcVirBuf[0][x%IbcBufWidthY][y%CtbSizeY]=-1(7-154)

[0333] 5.6 Example #6

[0334] 7.4.9.5 Codec unit semantics ...

[0336] When ResetIbcBuf is equal to 1, the following applies:

[0337] - For x=0..IbcBufWidthY-1 and y=0..CtbSizeY-1, make the following assignments:

[0338] IbcVirBuf[0][x][y]=-1 (7-153)

[0339]

[0340] -The variable ResetIbcBuf is set equal to 0.

[0341] When x0%VSize equals 0 and y0%VSize equals 0 and

[0342]

[0343] IbcVirBuf[0][x%IbcBufWidthY][y%CtbSizeY]=-1 (7-154)

[0344]

[0345] 5.7 Example #7

[0346] This embodiment gives an example that allows sub-picture prediction. Changes compared to JVET-O2001-vE are highlighted in bold and italics.

[0347] 8.5.6.3.3 Luma integer sample acquisition process

[0348] The input to this process is:

[0349] -Full sample unit (xInt L ,yInt L ),

[0350] - Luminance reference sample array refPicLX L .

[0351] The output of this process is the predicted brightness sample value predSampleLXL

[0352] The variable shift is set equal to Max(2,14-BitDepth Y ).

[0353] The variable picW is set equal to pic_width_in_luma_samples, and the variable picH is set equal to pic_height_in_luma_samples.

[0354] The brightness position in full sample units (xInt, yInt) is derived as follows:

[0355]

[0356] xInt=Clip3(0,picW-1,sps_ref_wraparound_enabled_flag? (8-782)

[0357] ClipH((sps_ref_wraparound_offset_minus1+1)*MinCbSizeY,picW,xInt L ):xInt L )

[0358] yInt=Clip3(0,picH-1,yInt L ) (8-783)

[0359] The predicted brightness sample value predSampleLXL is derived as follows:

[0360] PredSampleLXL=refPicLXL[Xint][Yint]< <shift3(8-784)

[0361] 5.8 Example #8

[0362] This embodiment shows an exemplary design of a chroma QP table. Changes marked in bold and italics are based on JVET-O2001-vE. Deleted text is marked with double brackets (eg, [[a]] indicates that the character "a" has been deleted).

[0363] 7.4.3.3 Sequence parameter set RBSP semantics ...

[0365] For i=0..same_qp_table_for_chroma?0:2, the i-th chroma QP mapping table ChromaQpTable[i] is derived as follows:

[0366]

[0367] When same_qp_table_for_chroma is equal to 1, for k = [[ 63. Set ChromaQpTable[1][k] and ChromaQpTable[2][k] to be equal to ChromaQpTable[0][k].

[0368] The bitstream conformance requirement is that for i = 0..same_qp_table_for_chroma? 0:2 and j = 0..num_points_in_qp_table_minus1[i], the value of qpInVal[i][j] And qpOutVal[i][j] should be within -QpBdOffset C to 63 (inclusive). ...

[0370] 5.9 Example #9

[0371] This example shows an exemplary design of an enlarged IBC virtual buffer. Changes marked in italics and bold are based on JVET-O2001-vE. Deleted text is marked with double brackets (eg, [[a]] indicates that the character "a" is deleted).

[0372] 7.4.3.3 Sequence parameter set RBSP semantics ...

[0374] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows:

[0375] CtbLog2SizeY=

[0376] log2_ctu_size_minus5+5

[0377] (7-15)

[0378] CtbSizeY=

[0379] 1< <CtbLog2SizeY

[0380] (7-16)

[0381] MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2(7-17)

[0382] MinCbSizeY=

[0383] 1< <MinCbLog2SizeY

[0384] (7-18)

[0385]

[0386] IbcBufWidthC=IbcBufWidthY / SubWidthC (7-20)

[0387] Vsize = min(64, CtbSizeY)

[0388] (7-21) ...

[0390] 7.4.9.5 Codec unit semantics ...

[0392] When x0%VSize is equal to 0 and y0%VSize is equal to 0, the following assignments are made to x=x0..x0+VSize-1 and y=y0..y0+VSize-1:

[0393]

[0394] 5.10 Example #10

[0395] This example shows an exemplary design of an enlarged IBC virtual buffer. Changes marked in italics and bold are based on JVET-O2001-vE. Deleted text is marked with double brackets (eg, [[a]] indicates that the character "a" is deleted).

[0396] 7.4.3.3 Sequence parameter set RBSP semantics ...

[0398] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows:

[0399] CtbLog2SizeY=

[0400] log2_ctu_size_minus5+5

[0401] (7-15)

[0402] CtbSizeY=

[0403] 1< <CtbLog2SizeY

[0404] (7-16)

[0405] MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2(7-17)

[0406] MinCbSizeY=

[0407] 1< <MinCbLog2SizeY

[0408] (7-18)

[0409]

[0410]

[0411] IbcBufWidthC=IbcBufWidthY / SubWidthC (7-20)

[0412] Vsize = min(64, CtbSizeY)

[0413] (7-21) ...

[0415] 7.4.9.5 Codec unit semantics ...

[0417] When x0%VSize is equal to 0 and y0%VSize is equal to 0, the following assignments are made to x=x0..x0+VSize-1 and y=y0..y0+VSize-1:

[0418]

[0419] 5.11 Example #11

[0420] Changes marked in bold and italics are based on JVET-O2001-vE. Deleted text is marked with double brackets (e.g., [[a]] indicates the character "a" has been deleted).

[0421] 7.4.3.3 Sequence parameter set RBSP semantics ...

[0423] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows:

[0424] CtbLog2SizeY=

[0425] log2_ctu_size_minus5+5

[0426] (7-15)

[0427] CtbSizeY=

[0428] 1< <CtbLog2SizeY

[0429] (7-16)

[0430] MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2(7-17)

[0431] MinCbSizeY=

[0432] 1< <MinCbLog2SizeY

[0433] (7-18)

[0434]

[0435] IbcBufWidthC=IbcBufWidthY / SubWidthC (7-20)

[0436] Vsize = min(64, CtbSizeY)

[0437] (7-21) ...

[0439] 7.4.9.5 Codec unit semantics ...

[0441] When x0%VSize is equal to 0 and y0%VSize is equal to 0, the following assignments are made to x=x0..x0+VSize-1 and y=y0..y0+VSize-1:

[0442]

[0443] Figure 4 An example of a reference block spanning VPDU columns and VPDU rows is shown. Figure 4 As shown, for the current CU (in blue 602), the blocks filled in red (604) are cross-VPDU column reference blocks, while the blocks filled in yellow (606) are cross-VPDU row reference blocks. Each large block indicates a 64×64 VPDU, and the green area (608) indicates the reconstructed pixels that can be used for IBC reference.

[0444] Figure 5 5 is a block diagram of a video processing apparatus 500. Apparatus 500 may be used to implement one or more methods described herein. Apparatus 500 may be implemented in a smart phone, a tablet computer, a computer, an Internet of Things (IoT) receiver, etc. Apparatus 500 may include one or more processors 502, one or more memories 504, and video processing hardware 506. Processor 502 may be configured to implement one or more methods described in this document (including but not limited to method 400). One or more memories 504 may be used to store data and code for implementing the methods and techniques described herein. Video processing hardware 506 may be used to implement some of the techniques described in this document in hardware circuits.

[0445] Figure 6 1 is a block diagram illustrating an exemplary video processing system 1900 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 1900. System 1900 may include an input 1902 for receiving video content. The video content may be received in a raw or uncompressed format (e.g., 8 or 10 bit multi-component pixel values), or may be received in a compressed or encoded format. Input 1902 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, a passive optical network (PON), and the like, and wireless interfaces such as Wi-Fi or cellular interfaces.

[0446] System 1900 may include a codec component 1904, which may implement various coding or encoding methods described in this document. Codec component 1904 may reduce the average bit rate of the video from input 1902 to the output of codec component 1904 to generate a coded representation of the video. Therefore, codec technology is sometimes referred to as video compression or video code conversion technology. The output of codec component 1904 may be stored or transmitted by a connected communication component (as shown in component 1906). The stored or transmitted bitstream (or coded) representation of the video received at input 1902 may be used by component 1908 to generate pixel values ​​or displayable video sent to display interface 1910. The process of generating user-visible video from bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it should be understood that codec tools or operations are used at encoders, and the corresponding decoding tools or operations of the inverse codec results will be performed by decoders.

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

[0448] In some embodiments, the reference Figure 5 or a device implemented on the hardware platform described in 6 to implement the video encoding and decoding method.

[0449] The examples described above may be incorporated into the context of the methods described below (eg, methods 710 to [ ] that may be implemented at a video decoder or a video encoder).

[0450] Fig. 7A A flow chart of an exemplary method 710 for video processing is shown. The method 710 includes: at step 712, based on the size of a virtual buffer associated with a current block, making a decision on the validity of one or more samples or block vectors mapped to the virtual buffer, wherein the current block is coded based on pixels in a reference block, the current picture includes the current block and the reference block, and the size of the virtual buffer is based on the size of a virtual pipeline data unit (VPDU), the size of a codec tree block (CTB), or the size of a codec tree unit (CTU). The method 700 includes: at step 714, based on the decision, performing a conversion between the current block and a bitstream representation of the current block.

[0451] Figure 7B A flow chart of an exemplary method 720 for video processing is shown. The method 720 includes: at step 722, for a current block that is encoded and decoded based on pixels in a reference block, specifying one or more reference samples of the reference block as unavailable, each of the one or more reference samples being mapped to a virtual buffer and having a corresponding sample in at least a current virtual pipeline data unit (VPDU) associated with the reference block, and the current picture including the current block and the reference block. The method 720 includes: at step 724, based on the specification, performing conversion between the current block and a bitstream representation of the current block.

[0452] Figure 7C A flow chart of an exemplary method 730 for video processing is shown. The method 730 includes: at step 732, for a current block that is coded and decoded based on pixels in a reference block, determining a size of a virtual buffer associated with the reference block based on a size of a codec tree unit (CTU) or a size of a codec tree block (CTB) of the current block, wherein the current picture includes the current block and the reference block. The method 730 includes: at step 734, based on the determination, performing a conversion between the current block and a bitstream representation of the current block.

[0453] Fig. 8A A flow chart of an exemplary method 810 for video processing is shown. The method 810 includes: at step 812, for a conversion between a current video block of a video picture of a video and a coded representation of the video, determining a number of reference samples in a reference area of ​​a video picture used to predict the current video block based on a rule, wherein the rule specifies that the number of reference samples is limited to a certain range. The method 810 includes: at step 814, based on the determination, performing the conversion.

[0454] Figure 8B A flow chart of an exemplary method 820 for video processing is shown. The method 820 includes: at step 822, for a conversion between a current video block of a video picture of a video and a coded representation of the video, determining the availability of one or more reference samples for predicting a reference block of the current video block based on a rule, wherein the rule specifies using a granularity of a virtual pipeline data unit (VPDU) level in the determination. The method 820 includes: at step 824, based on the determination, performing a conversion between the current block and the coded representation of the current block.

[0455] Figure 8CA flow chart of an exemplary method 830 for video processing is shown. The method 830 includes: at step 832, performing a conversion between a current video block of a video picture of a video and a coded representation of the video. In some implementations, the conversion is performed according to a rule, wherein the current video block is represented in the coded representation using prediction residuals of reference samples from a reference region in the video picture, and wherein the rule specifies that during the conversion, sample values ​​in the reference region are reset at the beginning of processing each virtual pipeline data unit (VPDU) based on the position of the current VPDU of the current video block. In some implementations, the conversion includes using a count of the number of available current virtual pipeline data units (VPDUs) mapped to the reference region of the video picture, wherein one or more reference samples from the reference region of the video picture are used to predict the current video block.

[0456] Fig.8D A flow chart of an exemplary method 840 for video processing is shown. The method 840 includes: at step 842, for a current video block of a video picture of a video and a coded representation of the video, because the size of the current video block is greater than the size of 64×64 luma samples, determining that samples from a current virtual pipeline data unit (VPDU) and samples of three other most recently processed VPDUs in the video picture can be used as reference samples for generating a prediction of the current video block. The method 840 includes: at step 844, based on the determination, performing a conversion.

[0457] Some embodiments of the disclosed technology include deciding or determining to enable a video processing tool or pattern. In one example, when a video processing tool or pattern is enabled, the encoder will use or implement the tool or pattern in the processing of a video block, but may not need to modify the resulting bitstream based on the use of the tool or pattern. That is, the conversion from a block of video to a bitstream representation of a video will use the video processing tool or pattern when deciding or determining to enable a video processing tool or pattern. In another example, when a video processing tool or pattern is enabled, the decoder will process the bitstream based on the knowledge that the bitstream has been modified by the video processing tool or pattern. That is, the conversion from the bitstream representation of a video to a block of the video will be performed using the video processing tool or pattern enabled by deciding or determining.

[0458] Some embodiments of the disclosed technology include deciding or determining to disable a video processing tool or mode. In one example, when a video processing tool or mode is disabled, the encoder will not use the tool or mode in converting blocks of video to a bitstream representation of the video. In another example, when a video processing tool or mode is disabled, the decoder will process the bitstream with the knowledge that the bitstream is not modified using the video processing tool or mode that was decided or determined to be disabled.

[0459] 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 in the conversion process from a pixel representation of a video to a corresponding bitstream representation, or vice versa. As defined by the syntax, the bitstream representation of the current video block may correspond to bits that are concatenated within the bitstream or distributed at different locations within the bitstream. For example, a macroblock may be encoded or decoded according to a transformed and encoded error residual value, and bits in the header and other fields of the bitstream may also be used for encoding and decoding.

[0460] The various technical solutions and embodiments described in this document are further described using a list of terms. The first set of terms describes certain features and aspects of the technology disclosed in the previous sections.

[0461] 1. A method for video processing, comprising: making a decision regarding the validity of one or more samples or block vectors mapped to a virtual buffer associated with a current block that is encoded and decoded based on pixels in a reference block, wherein a current picture includes the current block and the reference block, and wherein the size of the virtual buffer is based on a size of a virtual pipeline data unit (VPDU), a size of a codec tree block (CTB), or a size of a codec tree unit (CTU); and performing a conversion between the current block and a bitstream representation of the current block based on the decision.

[0462] 2. The method of clause 1, wherein the product of the height and width of the virtual buffer is fixed, and the height or the width is based on the size of the VPDU, the size of the CTB, or the size of the CTU.

[0463] 3. The method of clause 1, wherein the width of the virtual buffer is equal to the width of the CTB or the width of the CTU.

[0464] 4. The method of clause 1, wherein the width or height of the virtual buffer is N times the width or height of the VPDU, respectively, and wherein N ≥ 1 and is an integer.

[0465] 5. The method of clause 1, wherein the maximum number of one or more samples is less than a size of the virtual buffer.

[0466] 6. The method of clause 1, wherein when determining that a size of a CTB or a size of a CTU is greater than 64x64, a maximum number of one or more samples is fixed.

[0467] 7. The method of clause 1, wherein the number of the one or more samples is less than or equal to N times the number of samples in the VPDU, and wherein N ≥ 1 and is an integer.

[0468] 8. The method of clause 7, wherein when determining that the size of a CTB or the size of a CTU is greater than 64×64, N=3.

[0469] 9. A method for video processing, comprising: for a current block encoded and decoded based on pixels in a reference block, specifying one or more reference samples of the reference block as unavailable, wherein each of the one or more reference samples is mapped to a virtual buffer and has a corresponding sample in at least a current virtual pipeline data unit (VPDU) associated with the reference block, and wherein a current picture includes the current block and the reference block; and based on the specification, performing conversion between the current block and a bitstream representation of the current block.

[0470] 10. The method of clause 9, further comprising: designating corresponding samples in a current VPDU as unavailable.

[0471] 11. The method of clause 10, wherein corresponding samples in the current VPDU are designated as unavailable based on the location of the current VPDU.

[0472] 12. The method of clause 10, wherein corresponding samples in the current VPDU are designated as unavailable based on a location of a previous VPDU or a most recently decoded VPDU.

[0473] 13. The method of clause 9, wherein each of the one or more reference samples has a corresponding sample in each of the three most recently decoded VPDUs.

[0474] 14. A method for video processing, comprising: for a current block that is encoded and decoded based on pixels in a reference block, determining the size of a virtual buffer associated with the reference block based on the size of a codec tree block (CTB) or a size of a codec tree unit (CTU) of the current block, wherein a current picture includes the current block and the reference block; and based on the determination, performing conversion between the current block and a bitstream representation of the current block.

[0475] 15. The method of clause 14, wherein when the size of the CTB or CTU is determined to be 128×128, the size of the virtual buffer is 256×128.

[0476] 16. The method of clause 14, wherein when the size of the CTB or CTU is determined to be 256×256, the size of the virtual buffer is 64×256.

[0477] 17. The method of clause 14, wherein when the size of the CTB or CTU is determined to be 256×256, the size of the virtual buffer is 128×256.

[0478] 18. A method as described in any of clauses 1 to 17, wherein encoding and decoding the current block based on pixels in a reference block in a current picture including the current block is an intra block copy (IBC) operation, and the virtual buffer is an IBC virtual buffer.

[0479] 19. A video processing method, comprising: allocating an intra-block codec (IBC) virtual buffer size for a conversion between a bitstream representation of a current video block and a current block, wherein the IBC virtual buffer size is larger than a minimum size of a block vector search area used for the conversion; and performing the conversion based on the allocation.

[0480] 20. The method of clause 19, wherein the IBC buffer size is larger than a total size of the virtual pipeline data unit memory used for conversion.

[0481] 21. The method of any of clauses 19-20, wherein the width of the IBC virtual buffer size is (128*128 / ctbSizeY+ctbSizeY).

[0482] 22. A video processing method, comprising: for conversion between a bitstream representation of a current video block and the current block, determining a size of a reference block for conversion based on intra-block prediction coding according to a rule; and performing conversion based on the determination, wherein the rule restricts the reference block to a virtual pipeline data unit (VPDU) column or a virtual pipeline data unit row.

[0483] 23. The method of clause 22, wherein the rule does not allow reference blocks to span different VPDU rows.

[0484] 24. The method of clause 22, wherein the rule does not allow reference blocks to span different VPDU columns.

[0485] 25. A method as described in any of clauses 22-24, wherein the VPDU column or VPDU row relates to a picture including the current block.

[0486] 26. The method of any of clauses 22-24, wherein a VPDU column or a VPDU row is associated with an intra block copy virtual buffer.

[0487] 27. A method as described in any of clauses 1-26, wherein converting includes video encoding and decoding to generate a bitstream representation from the current block.

[0488] 28. A method as described in any of clauses 1-26, wherein converting includes video decoding to generate the current block through a bitstream representation.

[0489] 29. An apparatus in a video system, comprising a processor and a non-volatile memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to implement the method of any one of clauses 1 to 28.

[0490] 30. A computer program product stored on a non-transitory computer readable medium and comprising program code for performing the method of any of clauses 1 to 28.

[0491] 31. A method, apparatus or system as herein described.

[0492] The second group of items describes certain features and aspects of the technology disclosed in the previous sections, for example, example items 2-5, 8 and 16.

[0493] 1. A method for video processing, comprising:

[0494] For conversion between a current video block of a video picture of a video and a coded representation of the video, determining a number of reference samples in a reference area of ​​the video picture for predicting the current video block based on a rule, wherein the rule specifies that the number of reference samples is limited to a specific range; and based on the determination, performing the conversion.

[0495] 2. The method of clause 1, wherein the rule specifies that the maximum number of reference samples is smaller than the size of the reference region.

[0496] 3. The method of clause 1, wherein the rule specifies that the maximum number of reference samples is fixed when the size of a codec tree block (CTB) or the size of a codec tree unit (CTU) is greater than 64×64.

[0497] 4. The method of clause 1, wherein the rule specifies that the number of reference samples is less than or equal to N times the number of samples in a virtual pipeline data unit (VPDU), and wherein N ≥ 1 and is an integer.

[0498] 5. The method of clause 4, wherein N=3 in the case where the size of a codec tree block (CTB) or the size of a codec tree unit (CTU) is determined to be larger than the size of 64×64 luma samples.

[0499] 6. A method for video processing, comprising: for a conversion between a current video block of a video picture of a video and a coded representation of the video, determining the availability of one or more reference samples of a reference block for predicting the current video block based on a rule, wherein the rule specifies using a granularity of a virtual pipeline data unit (VPDU) level in the determination; and based on the determination, performing the conversion between the current block and the coded representation of the current block.

[0500] 7. The method of clause 6, wherein the determining determines one or more reference samples as unavailable, and the method further comprises determining one or more corresponding samples in the current VPDU as unavailable.

[0501] 8. The method of clause 6, further comprising: determining the availability of one or more VPDUs as unavailable.

[0502] 9. The method of clause 7, wherein the determination of the one or more corresponding samples is based on a location of a current VPDU.

[0503] 10. The method of clause 7, wherein the determination of the one or more corresponding samples is based on a location of a previous VPDU or a most recently decoded VPDU.

[0504] 11. The method of clause 6, wherein the determining is performed prior to encoding or decoding a video unit comprising the current video block, and wherein the one or more reference samples correspond to a reference region of a video picture.

[0505] 12. The method of clause 11, wherein prior to encoding or decoding the video unit, the corresponding area in the reference area is marked as unavailable.

[0506] 13. A method as described in clause 11, wherein the corresponding area in the reference area corresponds to a brightness area of ​​x = (X% IBC_buf_width)..(X% IBC_buf_width)+W-1 and y = (Y% IBC_buf_height)..(Y% IBC_buf_height)+H-1, wherein the size of the video unit is W×H, IBC_buf_width and IBC_buf_height indicate the width and height of the virtual buffer respectively, and the upper left position of the video unit is (X, Y).

[0507] 14. A method as described in clause 11, wherein the corresponding area in the reference area corresponds to a chroma area of ​​x = (X% IBC_buf_width) / SubWidthC..((X% IBC_buf_width)+W-1) / SubWidthC and y = (Y% IBC_buf_height) / SubHeightC..((Y% IBC_buf_height)+H-1) / SubHeightC, where the size of the video unit is W x H, IBC_buf_width and IBC_buf_height indicate the width and height of the virtual buffer respectively, and the upper left corner position of the video unit is (X, Y).

[0508] 15. The method of clause 6, wherein the determining is performed prior to encoding or decoding KxL samples or KxL pixels included in a video unit including the current video block.

[0509] 16. The method of clause 15, wherein at least one of K and L is equal to 1.

[0510] 17. The method of clause 15, wherein at least one of K and L is set to a sub-block size used in the video unit.

[0511] 18. A method for video processing, comprising: performing a conversion between a current video block of a video picture of a video and a coded representation of the video according to a rule, wherein the current video block is represented in the coded representation using a residual of a prediction of a reference sample from a reference area in the video picture, and wherein the rule specifies that during the conversion, sample values ​​in the reference area are reset at the beginning of processing each virtual pipeline data unit (VPDU) based on the position of a current VPDU of the current video block.

[0512] 19. A method as described in clause 18, wherein the reference area is located at a position of (xVPDU+ctbSizeY, yVPDU), wherein (xVPDU, yVPDU) represents the position of the current VPDU relative to the upper left corner of the picture including the current video block, and ctbSizeY is the width or height of a luma codec tree block (CTB) or a luma codec tree unit (CTU).

[0513] 20. A method for processing a video, comprising: for a current video block of a video picture of the video and a coded representation of the video, because the size of the current video block is larger than the size of 64×64 luma samples, determining that samples from a current virtual pipeline data unit (VPDU) and samples of three other most recently processed VPDUs in the video picture can be used as reference samples for generating a prediction of the current video block; and based on the determination, performing the conversion.

[0514] 21. The method of clause 20, wherein the current video block corresponds to a codec tree block (CTB) or a codec tree unit (CTU).

[0515] 22. The method of clause 20, wherein an index is maintained for each VPDU mapped to a reference region of a video picture.

[0516] 23. A method for video processing, comprising: performing a conversion between a current video block of a video picture of a video and a coded representation of the video, wherein the conversion includes counting the number of available current virtual pipeline data units (VPDUs) mapped to a reference region of the video picture, wherein one or more reference samples from the reference region of the video picture are used to predict the current video block.

[0517] 24. A method as described in clause 23, wherein the counter is reset to zero at the beginning of decoding each CTU row and the counter is incremented by one when decoding a VPDU mapped to the reference region.

[0518] 25. The method of clause 23, wherein the counter is greater than a certain value, and wherein samples in the VPDU mapped to the reference region are marked as unusable and the counter is decremented by 1.

[0519] 26. A method as described in any of clauses 1 to 25, wherein the conversion includes encoding the current video block into a coded representation.

[0520] 27. A method as described in any of clauses 1 to 25, wherein the conversion comprises decoding the encoded representation from the current video block.

[0521] 28. A video processing device, wherein the video processing device comprises a processor configured to implement the method of any one or more of clauses 1 to 27.

[0522] 29. A computer readable medium storing program code which, when executed, causes a processor to implement the method of any one or more of clauses 1 to 27.

[0523] It will be appreciated from the foregoing that specific embodiments of the presently disclosed technology have been described herein for purposes of illustration, but that various modifications may be made without departing from the scope of the invention. Accordingly, the technology of the present disclosure is not to be limited, except as in the appended claims.

[0524] The implementation of the subject matter and functional operations described in this patent document can be implemented in various systems, digital electronic circuits, or computer software, firmware or hardware, including the structures disclosed in this specification and their equivalents, or a combination of one or more of the above. The implementation of the subject matter described in this specification can be implemented as one or more computer program products, that is, one or more modules of computer program instructions encoded on a tangible non-transitory computer-readable medium for execution by a data processing device or controlling the operation of the data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a material composition that affects a machine-readable propagation signal, or a combination of one or more of the above. The term "data processing unit" or "data processing device" includes all devices, devices and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, such as code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of the above.

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

[0526] The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and the apparatus may be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0527] For example, processors suitable for executing computer programs include general and special microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or a read-only memory and a random access memory. The necessary elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include or be operably coupled to receive data from or transmit data to one or more mass storage devices, which are used to store data, such as magnetic disks, magneto-optical disks, or optical disks. However, the computer does not need to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices. The processor and memory can be supplemented by or combined in a dedicated logic circuit.

[0528] This specification and drawings are intended to be regarded as exemplary only, where exemplary means example.As used herein, the use of "or" is intended to include "and / or" unless the context clearly dictates otherwise.

[0529] Although this patent document includes many details, these should not be interpreted as limitations on the scope of any invention or the scope of what is claimed, but rather as descriptions of features that may be specific to a specific embodiment of a specific invention. Certain features described in this patent document in the context of separate embodiments 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 in multiple embodiments individually or in any suitable sub-combination. In addition, although features may be described above as working in certain combinations, and even initially claimed as such, in some cases one or more features in the claimed combination may be removed from the combination, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0530] Similarly, while operations are described in a particular order in the drawings, this should not be understood as requiring that the operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed to achieve the desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0531] Only a few implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and shown in this patent document.

Claims

1. A method for processing video data, comprising: For a conversion between a current video block of a video picture of a video and a bitstream of the video, determining a number of reference samples in a virtual buffer including reference samples derived from the video picture based on a rule, wherein the rule specifies that a maximum number of available reference samples in the virtual buffer is less than a size of the virtual buffer; and performing said converting based on said determining, wherein the current video block is encoded in a prediction mode, wherein prediction samples are derived from blocks of available reference samples in the virtual buffer based on block vectors, in, The rule specifies that the position of the reference sample marked as unavailable in the virtual buffer is (m, n), Where m=(x+(IbcBufWidthY>>1))%IbcBufWidthY, and n=y%CtbSizeY, Where (x, y) represents the position of the sample in the video picture and is determined based on the size of the virtual unit, Where IbcBufWidthY represents the width of the virtual buffer, Where CtbSizeY represents the size of the luma CTB comprising the current video block, and Where >> represents the right shift operator and % represents the modulus operator.

2. The method of claim 1, wherein: The prediction mode is an intra block copy (IBC) mode and the virtual buffer is an IBC virtual buffer.

3. The method of claim 1, wherein: The height of the virtual unit is min(CtbSize, 64), where CtbSize represents the size of the CTB including the current video block.

4. The method of claim 1, wherein IbcVirBuf[0][(x+(IbcBufWidthY>>1))%IbcBufWidthY][y%CtbSizeY]=-1, Wherein, IbcVirBuf[0][m][n] represents the reference samples in the virtual buffer that are marked as unavailable.

5. The method of claim 1, wherein: At the beginning of decoding each CTU row, the values ​​of the reference samples in the virtual buffer are reset to -1.

6. The method of claim 1, wherein: A product of a height and a width of the virtual buffer is fixed, and the width of the virtual buffer is determined based on the CTB size.

7. The method of claim 6, wherein: The height of the virtual buffer is equal to the height of the CTB, and the width of the virtual buffer is set to a value obtained by dividing the area of ​​the virtual buffer by the height of the CTB.

8. The method of claim 7, wherein an area of ​​the virtual buffer is 256*128, a height of the virtual buffer is equal to ctbSizeY, and a width of the virtual buffer is 256*128 / ctbSizeY, wherein ctbSizeY represents a size of a luma CTB including the current video block.

9. The method of claim 1, wherein: The converting includes encoding the current video block into the bitstream.

10. The method of claim 1, wherein: The converting includes decoding the current video block from the bitstream.

11. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein: When the instructions are executed by the processor, the processor: for a conversion between a current video block of a video picture of a video and a bitstream of the video, determining a number of reference samples in a virtual buffer including reference samples derived from the video picture based on a rule, wherein the rule specifies that a maximum number of available reference samples in the virtual buffer is less than a size of the virtual buffer; as well as performing said converting based on said determining, wherein the current video block is encoded in a prediction mode, wherein prediction samples are derived from blocks of available reference samples in the virtual buffer based on block vectors, The rule specifies that the position of the reference sample marked as unavailable in the virtual buffer is (m, n), Where m=(x+(IbcBufWidthY>>1))%IbcBufWidthY, and n=y%CtbSizeY, Where (x, y) represents the position of the sample in the video picture and is determined based on the size of the virtual unit, Where IbcBufWidthY represents the width of the virtual buffer, Where CtbSizeY represents the size of the luma CTB comprising the current video block, and Where >> represents the right shift operator and % represents the modulus operator.

12. The apparatus of claim 11, wherein the prediction mode is an intra block copy (IBC) mode and the virtual buffer is an IBC virtual buffer.

13. The apparatus of claim 11, wherein the height of the virtual unit is min(CtbSize, 64), where CtbSize represents a size of a CTB including the current video block.

14. The apparatus of claim 11, wherein IbcVirBuf[0][(x0+(IbcBufWidthY>>1))%IbcBufWidthY][y0%CtbSizeY]=-1, Wherein, IbcVirBuf[0][x][y] represents the reference sample in the virtual buffer that is marked as unavailable.

15. A non-transitory computer-readable storage medium storing instructions for causing a processor to: For a conversion between a current video block of a video picture of a video and a bitstream of the video, determining a number of reference samples in a virtual buffer including reference samples derived from the video picture based on a rule, wherein the rule specifies that a maximum number of available reference samples in the virtual buffer is less than a size of the virtual buffer; and performing said converting based on said determining, wherein the current video block is encoded in a prediction mode, wherein prediction samples are derived from blocks of available reference samples in the virtual buffer based on block vectors, in, The rule specifies that the position of the reference sample marked as unavailable in the virtual buffer is (m, n), Where m=(x+(IbcBufWidthY>>1))%IbcBufWidthY, and n=y%CtbSizeY, Where (x, y) represents the position of the sample in the video picture and is determined based on the size of the virtual unit, Where IbcBufWidthY represents the width of the virtual buffer, Where CtbSizeY represents the size of the luma CTB comprising the current video block, and Where >> represents the right shift operator and % represents the modulus operator.

16. A method for storing a bit stream of a video, comprising: determining, for a current video block of a video picture of a video, a number of reference samples in a virtual buffer including reference samples derived from the video picture based on a rule, wherein the rule specifies that a maximum number of available reference samples in the virtual buffer is less than a size of the virtual buffer; and generating the bitstream based on the determination, storing the bit stream in a non-transitory computer-readable recording medium, wherein the current video block is encoded in a prediction mode, wherein prediction samples are derived from blocks of available reference samples in the virtual buffer based on block vectors, The rule specifies that the position of the reference sample marked as unavailable in the virtual buffer is (m, n), Where m=(x+(IbcBufWidthY>>1))%IbcBufWidthY, and n=y%CtbSizeY, Where (x, y) represents the position of the sample in the video picture and is determined based on the size of the virtual unit, Where IbcBufWidthY represents the width of the virtual buffer, Where CtbSizeY represents the size of the luma CTB comprising the current video block, and Where >> represents the right shift operator and % represents the modulus operator.

17. A video processing device, wherein: The video processing device comprises a processor configured to implement the method of any one of claims 5 to 10.

18. A computer readable medium, wherein: The computer readable medium stores program code which, when executed, causes a processor to implement the method as claimed in any one of claims 2 to 10.

Images