Size limit for intra block copy virtual buffer

Abstract

A method of video processing is described, comprising: for a conversion between a current video block of a video picture of a video and a coded representation of the video, making a determination regarding a size of a reference region of the video picture in which reference samples are used to predict the current video block based on a size of a virtual pipeline data unit (VPDU), a size of a coding tree block (CTB), or a size of a coding tree unit (CTU), and performing the conversion based on the determination.

Description

[Technical field]

[0001] This patent document relates to video coding techniques, devices and systems.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application is based on International Patent Application No. PCT / CN2019 / 097742, filed July 25, 2019, and International Patent Application No. PCT / CN2020 / 104081, filed July 24, 2020, which claims priority to and the benefit of International Patent Application No. PCT / CN2019 / 109849, filed October 7, 2019. The entirety of the above patent applications is incorporated by reference as part of the disclosure of this application. [Background technology]

[0003] Despite advances in video compression, digital video still accounts for the largest bandwidth usage in the Internet and other digital communications networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demands for digital video usage are expected to continue to increase. Summary of the Invention

[0004] The apparatus, systems, and methods relate to digital video coding, and in particular to a generic virtual buffer for intra block copy (IBC). The described methods may be applied to both existing video coding standards (e.g., High Efficiency Video Coding (HEVC)) and future video coding standards or video codecs.

[0005] In one exemplary aspect, the disclosed techniques may be used to provide a method for video processing that includes making a determination based on a size of a virtual pipeline data unit (VPDU), a size of a coding tree block (CTB), or a size of a coding tree unit (CTU) for conversion between a current video block of a video picture of a video and a coded representation of the video, regarding a size of a reference region of the video picture in which reference samples are used to predict a current video block, and performing the conversion based on the determination.

[0006] In yet another exemplary embodiment, the above-described methods are embodied in the form of processor executable code and stored on a computer readable program medium.

[0007] In yet another exemplary aspect, a device configured or operable to perform the above-described method is disclosed. The apparatus may include a processor programmed to implement the method.

[0008] In yet another representative aspect, a video decoder device may implement the methods described herein.

[0009] The above aspects and features of the disclosed technology are explained in more detail by the drawings, specification, and claims. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram showing an example of a current picture reference. [Diagram 2] Figure 2 shows an example of a dynamic reference area in JVET-M0407. [Diagram 3] FIG. 3 shows a flow chart of a decoding flow with reshaping. [Figure 4] 4 shows an example for the current CU (blue at 602), the red filled block (604) is the crossing VPDU column reference block, and the yellow filled block (606) is the crossing VPDU row reference block. Each large block represents a 64x64 VPDU, and the green areas (608) represent reconstructed pixels that can be used for IBC reference. [Diagram 5]FIG. 5 is a block diagram of an example hardware platform for implementing the visual media decoding or encoding techniques described in this document. [Figure 6] FIG. 6 is a block diagram of an example video processing system in which the disclosed techniques can be implemented. [Figure 7A] FIG. 7A illustrates a flow chart of an example method for video processing according to some implementations of the disclosed technology. [Figure 7B] FIG. 7B illustrates a flowchart of an example method for video processing according to some implementations of the disclosed technology. [Figure 7C] FIG. 7C illustrates a flowchart of an example method for video processing according to some implementations of the disclosed technology. [Figure 8] FIG. 8 shows a flow chart for one example video processing according to some implementations of the disclosed technology. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Embodiments of the disclosed technology may be applied to existing video coding standards (e.g., HEVC, H.265) and future standards to improve compression performance. Section headings are used in this document to improve readability of the description and are not intended to limit the description or embodiments (and / or implementations) to only each section.

[0012] 2. Video Coding Introduction Due to the increasing demand for higher resolution video, video coding methods and techniques are ubiquitous in modern technology. Video codecs typically include electronic circuits or software that compress or decompress digital video and are constantly being improved to provide higher coding efficiency. Video codecs convert uncompressed video into a compressed format. 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 delay (latency). Compression formats usually comply with standard video compression specifications, such as the High Efficiency Video Coding standard (also known as H.265 or MPEG-H Part 2), a general purpose video coding standard to be finalized, or other current and / or future video coding standards.

[0013] Video coding standards have evolved primarily through the development of well-known ITU-T and ISO / IEC standards: H.261 and H.263 from ITU-T, MPEG-1 and MPEG-4 Visual from ISO / IEC, and H.262 / MPEG-2 from both organizations. Video and MPEG jointly created the H.264 / MPEG-4 Advanced Video Coding (AVC) and H.265 / HEVC standards. Starting with H.262, video coding standards are based on a hybrid video coding structure in which temporal prediction and transform coding are utilized. To explore future video coding technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, many new methods have been adopted by JVET and put into reference software named JEM (Joint Exploration Model). In April 2018, VCEG (Q6 / 16) and ISO / IEC JTC1 SC29 / WG11 (MPEG) launched the Joint Video Experts Team (JVET) to work on the VVC standard, which aims for a 50% bitrate reduction over HEVC.

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

[0015] If a CU is coded in skip mode, one PU is associated with the CU and there are no significant residual coefficients, coded motion vector deltas, or reference pictures. Merge mode is specified such that the motion parameters for the current PU are obtained from neighboring PUs, including spatial and temporal candidates. Merge mode can be applied to any intra-predicted PU, not just skip mode. An alternative to merge mode is explicit transmission of motion parameters, where the motion vectors (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 are explicitly signaled for each PU. Such a mode is referred to as Advanced motion vector prediction (AMVP) in this disclosure.

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

[0017] If the signaling indicates that both reference picture lists should be used, the PU is generated from two sample blocks. This is called "bi-prediction." Bi-prediction is available only for B-slice.

[0018] The text below gives details on the intra prediction modes specified in HEVC. The description starts with merge mode.

[0019] 2.2 Current Picture Reference The HEVC Screen Content Coding Extension (HEVC-SCC) and the current VVC Test Model (VTM-3.0) employ Current Picture Referencing (CPR), or what was once named Intra-Block Copy (IBC). IBC extends the concept of motion compensation from inter-frame coding to intra-frame coding. As shown in Figure 1, the current block is predicted by a reference block in the same picture when CPR is applied. The samples in the reference block must already be reconstructed before the current block is coded or decoded. Although CPR is not very efficient in most camera-captured sequences, it has great advantages for coding screen content. The reason is that there are many repeating patterns, such as icons and text characters, in screen content pictures. CPR can effectively remove the redundancy between these repeating patterns. In HEVC-SCC, an inter-coded coding unit (CU) can apply CPR if it selects the current picture as a reference picture. In this case, MV is renamed as block vector (BV), and BV always has integer-pixel precision. It should be noted that for compatibility with Main Profile HEVC, the current picture is marked as a “long-term” reference picture in the decoded picture buffer (DPB), and similarly, in multiview / 3D video coding standards, inter-view reference pictures are also marked as “long-term” reference pictures.

[0020] After the BV finds its reference block, it can generate a prediction by copying the reference block. The residual can be obtained by subtracting the reference pixel from the original signal. Then, transformation and quantization can be applied similarly to other coding modes.

[0021] However, if the reference block is outside the picture, overlaps with the current block, is outside the reshaped area, or is outside the valid area limited by some constraints, some or all pixel values ​​are undefined. To deal with such problems, there are basically two solutions: one is to not allow such situations, for example in bitstream adaptation; the other is to apply padding to the undefined pixel values. The following sub-sections explain the solutions in detail.

[0022] 2.3 CPR in HEVC Screen Content Coding Extension In the HEVC Screen Content Coding Extension, if a block uses the current picture as a reference, it should ensure that the entire reference block is within the available reconstruction region, as indicated in the following specification text. [Table 1]

[0023] Therefore, cases where the reference block overlaps with the current block or is outside the picture do not occur. There is no need to pad the reference block or the prediction block.

[0024] 2.4 CPR / IBC in the VVC Test Model In the current VVC test model, i.e., VTM-3.0 design, the entire reference block should be a current coding tree unit (CTU) and does not overlap with the current block, so there is no need to pad the reference block or the predicted block.

[0025] When enabling dual trees, the partition structure may be different from luma CTU to chroma CTU. Thus, for a 4:2:0 color format, one chroma block (e.g., CU) may correspond to one collocated luma region that is divided into multiple luma CUs.

[0026] A chroma block can be coded in CPR mode if and only if the following conditions are true:

[0027] (1) Each luma CU in a co-located luma block is coded in CPR mode.

[0028] (2) Each BV of a luma 4x4 block is first converted to a BV of a chroma block, and the BV of the chroma block is a valid BV.

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

[0030] Please note that the definition of a “valid BV” is subject to the following constraints:

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

[0032] (2) All samples in the reference block identified by BV are reconstructed.

[0033] 2.5 CPR / IBC in JVET-L0297 / JVET-M0407 / JVET-M0408 In VTM3.0, the reference region of CPR / IBC is currently limited to a CTU,128×128.,In JVET-L0297 / JVET-M0407 / JVET-M0408, we present a method to dynamically,change the reference region to reuse memory to store,CPR / IBC reference samples, so that a CPR / IBC block,has more reference candidates while the reference buffer of CPR / IBC,can be maintained or reduced from one CTU.

[0034] Figure 2 shows how the blocks are 64x64 and the CTU contains four 64x64 blocks. When coding a 64x64 block, the previous three 64x64 blocks can be used as references. By doing so, the decoder only needs to store four 64x64 blocks to support CPR / IBC. The above method was adopted in VTM4.0.

[0035] Assume the position of the current luma CU relative to the top-left corner of the picture is (x,y) and the block vector is (BVx,BVy). In the current design, BV is valid if the luma position ((x+BVx)>6<6+(1<7),(y+BVy)>>6<6) is not reshaped and ((x+BVx)>6<6+(1<7),(y+BVy)>>6<6) is within the range of (x>6<6, <y>This can be seen by the fact that it is not equal to 6<6).

[0036] 2.6 Virtual IBC buffer proposed in JVET-O1170 A virtual buffer concept is introduced to help describe the reference region for IBC prediction mode. If the CTU size is ctbSize, then we say wIbcBuf=128*128 / ctbSize, and define a virtual IBC buffer, ibcBuf, whose width is wIbcBuf and whose height is ctbSize. Thus:

[0037] -If the CTU size is 128x128, the size of ibcBuf is also 128x128.

[0038] -If CTU size is 64x64, then ibcBuf size is 256x64.

[0039] -If CTU size is 32x32, then ibcBuf size is 512x32.

[0040] Note that the width and height of a VPDU is min(ctbSize,64). We imply Wv=min(ctbSize,64).

[0041] The virtual IBC buffer ibcBuf is maintained as follows:

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

[0043] (2) At the start of decoding the VPDU (xVPDU, yVPDU) for the top-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.

[0044] (3) After decoding, the CU contains (x,y) relative to the top left of the picture and sets the following:

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

[0046] Therefore, the bitstream constraint can be simply written as:

[0047] [Table 2]

[0048] The IBC reference buffer concept also simplifies the text of the decoding process by avoiding reference to the interpolation and motion compensation processes, including sub-block processes.

[0049] 2.7 VPDU A virtual pipeline data unit (VPDU) is defined as a non-overlapping unit within a picture. In a hardware decoder, consecutive VPDUs are processed simultaneously by multiple pipeline stages. It is important to keep the VPDU size small because it is roughly proportional to the buffer size in most pipeline stages. 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) partitions can lead to an increase in the VPDU size.

[0050] In order to maintain the VPDU size as 64x64 luma samples, the following standard partition restrictions (including syntax signaling modifications) apply in VTM5:

[0051] - For CUs whose width or height or both width and height are equal to 128, TT splits are not allowed.

[0052] - For 128xN CUs with N <= 64 (i.e. width equals 128 and height less than 128), horizontal BT is not allowed.

[0053] - For Nx128 CUs with N <= 64 (i.e. width equals 128 and height less than 128), vertical BT is not allowed.

[0054] In VVC, it is generally agreed that the VPDU width and height in luma samples is min(64,CtbSizeY). So if the CTB / CTU size is 64x64, 128x128, 256x256, the VPDU size is 64x64. If the CTB / CTU size is 32x32, the VPDU size is 32x32.

[0055] 2.8 Buffer Management and Block Vector Coding for Intra Block Copy Details of the characteristics of various IBC buffers and the corresponding management are described in PCT / CN2019 / 093552, which is incorporated by reference.

[0056] 2.9 In-Loop Remodeling (ILR) in JVET-M0427 The basic idea of ​​in-loop reshaping (ILR) is to transform the original (first domain) signal (the predicted / reshaped signal) into a second domain (the reshaped domain).

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

[0058] 2.9.1 PWL model Conceptually, piece-wise linear (PWL) is implemented as follows:

[0059] Let x1, x2 be two input pivot points and y1, y2 be the corresponding output pivot points of a piece. The output value y for any input value x between x1 and x2 can be interpolated by the following formula:

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

[0061] In a fixed-point implementation, the equation can be rewritten as follows:

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

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

[0064] Note that in the CE-12 software, the PWL model is used to pre-calculate the 1024-entry FwdLUT and InvLUT mapping tables, but the PWL model also allows an implementation to calculate the same mapping values ​​on-the-fly without pre-calculating the LUTs.

[0065] 2.9.2 CE12-2 Test 2.9.2.1 Luma reformation Test 2 of the in-loop luma reconstruction (i.e., proposed CE12-2) provides a low-complexity pipeline and also eliminates the decoding latency for block-by-block intra prediction in inter-slice reconstruction. Intra prediction is performed in the reconstruction domain for both inter-slice and intra-slice.

[0066] Intra prediction is always performed in the reconstruction domain, regardless of the slice type. In such a configuration, intra prediction can start immediately after the previous TU reconstruction. Such an arrangement can also provide a unified process for intra modes instead of being slice-dependent. Figure 3 shows a block diagram of the CE12-2 decoding process based on the mode.

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

[0068] Interslice remodeling is accompanied by in-loop luma remodeling in CE12-2 (lighter shaded blocks indicate signal within the remodeled domain: luma residues, intraluma predictions, and intraluma remodeling).

[0069] 2.9.2.2 Luma-Dependent Chroma Residual Scaling Luma-dependent chroma residue scaling is a multiplicative process implemented in fixed-point integer arithmetic. Chroma residual scaling compensates for the interaction of the chroma and luma signals. Chroma residual scaling is applied at the TU level. More specifically, the following applies:

[0070] -For intra, the reconstructed luma is averaged.

[0071] -For inter, the predicted lumas are averaged.

[0072] The average value is used to identify an index into the PWL model, which in turn identifies the scaling factor cScaleInv by which the chroma residual is multiplied.

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

[0074] 2.9.2.3 Signaling of ILR side information The parameters are (currently) transmitted in the tile group header (similar to ALF). These are said to take up 40-100 bits. [Table 3] TIFF0007670680000004.tif234167TIFF0007670680000005.tif234158TIFF0007670680000006.tif179156

[0075] 2.9.2.4 Using ILR At the encoder side, each picture (or tile group) is first transformed into the reconstructed domain, and all coding processes are performed in the reconstructed domain. For intra prediction, the neighboring blocks are in the reconstructed domain, and for intra prediction, the reference block (generated from the original domain from the decoded picture buffer) is first transformed into the reconstructed domain. Then, the residual is generated and coded into the bitstream.

[0076] After the encoding / decoding of an entire picture (or a group of tiles) is completed, the samples in the reconstructed domain are transformed back to the original domain, and then a deblocking filter and other filters are applied.

[0077] Forward reshaping on the predicted signal is disabled for the following cases:

[0078] The current block is intra-coded.

[0079] ○ The current block is coded as CPR (current picture referencing, aka intra block copy, IBC).

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

[0081] 3 Shortcomings of existing implementations There are several problems with the current design of the IBC virtual buffer.

[0082] (1) The method for maintaining the IBC virtual buffer when the CTU size is larger than 128 x 128 is not defined.

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

[0084] (3) Line buffers for IBC mode and BV for CTU can be reduced.

[0085] (4) Subpictures may be too restrictive.

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

[0087] 4. Exemplary method for a generic virtual buffer for IBC The width and height of the VPDU is indicated by vSize, e.g., vSize=min(64,ctbSizeY), where ctbSizeY is the width / height of the luma CTB / CTU.

[0088] The embodiments of the disclosed technology overcome the shortcomings of existing embodiments, thereby providing video coding with higher coding efficiency. Based on the disclosed technology, a method for a general virtual buffer for IBC may improve both existing and future video coding standards, as elucidated in the following examples in which various implementations are described. The examples of the disclosed technology provided below are illustrative of the general concept and are not intended to be construed as limiting. In the examples, various features described in these examples can be combined, unless explicitly indicated to the contrary. IBC Buffer Related 1. The size of the IBC virtual buffer (eg, the one used to determine whether a block vector or a mapped sample is valid or not) may depend on the VPDU size, the CTB / CTU size. In one example, the width x 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. b. In one example, the height of the virtual buffer may be equal to the height of the CTB / CTU. i. Alternatively, the width of the virtual buffer may also be set to (size of IBC virtual buffer / height of CTB). c. In one example, the width of the virtual buffer may be equal to the width of the CTB / CTU. d. In one example, the width of the virtual buffer may be one or more times the VPDU width. e. In one example, the virtual buffer height may be one or more times the VPDU height. 2. It is proposed to allocate a larger IBC virtual buffer size compared to the memory size required for the IBC BV search area. In one example, the IBC virtual buffer size may be larger than the total size of the VPDU memory used for the IBC. i. In one example, one or more CTUs may be allocated to an IBC virtual buffer. b. In one example, the width of the IBC virtual buffer size may be (128*128 / ctbSizeY+ctbSizeY). 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. 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. e. In one example, a larger IBC virtual buffer can be allocated to a larger CTU / CTB. In one example, if the CTU size is not less than K (e.g., 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. In one example, if the CTU size is less than K (e.g., 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. 3. The reference block of an IBC block may be constrained to lie entirely within a particular VPDU row or VPDU column. In one example, reference blocks may be prohibited from crossing different VPDU rows. b. In one example, reference blocks may be prohibited from crossing different VPDU sequences. c. In one example, the above VPDU rows or columns may be relative to the picture. d. In one example, the above VPDU rows or columns may be relative to the IBC virtual buffer. e. Alternatively, if the reference block pointed to by the BV crosses two or more CTUs / CTBs, the above method may be invoked. 4. The reference block for an IBC block can span multiple VPDUs and different VPDU rows / columns. However, additional operations may be required to fill in some of the predicted values ​​of the reference block. In one example, some default values ​​may be used to fill in some of the predicted values. 5. Range constraints may be applied to the block vectors (BV) and / or block vector differences (BVD) used in IBC mode. In one example, the tolerance of BV / BVD may depend on the position of the current IBC coding block, such as the coordinator relative to the CTU / CTB that covers the current block. b. In one example, the block vector is [-2 m ,2 m -1]. c. In one example, the block vector difference after precision conversion is [-2 n ,2 n -1]. d. In one example, the block vector difference after precision conversion is [-2 n +1,2 n -1]. e. In one example, the block vector difference signaled in the bitstream is [-2 n ,2 n -1]. f. In one example, the block vector difference signaled in the bitstream is [-2 n +1,2 n -1]. In one example, m is set to 18, or 17, or 15. In one example, n is set to 17, or 16, or 14. i. In one example, m and / or n may depend on the precision of the BV / motion vector storage and / or the precision associated with block vector differences. j. In one example, the block vectors may be constrained to be within the same ranges as the motion vectors used for intra prediction modes. k. In one example, the block vector differences may be constrained to be within the same range as the vectors of motion vectors used for intra prediction modes. l. In one example, a conformance bitstream satisfies that the above sub-bullets are met. i. Alternatively, a clipping process to the BV / BVD may be applied to the decoded BV / BVD before the BV / BVD is utilized for encoding / decoding a block. 6. The number of available samples mapped into the IBC virtual buffer may be limited. In one example, the maximum number of available samples mapped to the buffer may be less than the IBC virtual buffer size. b. In one example, if the CTB / CTU size is greater than 64x64, the maximum number of available samples mapped into the IBC virtual buffer may be fixed. c. In one example, the number of available samples mapped to an IBC virtual buffer may be limited to be less than one or more times the number of samples in a VPDU. i. In one example, the number of available samples mapped to an IBC virtual buffer may be limited to be no more than 3 times the number of samples in a VPDU when the CTU / CTB size is greater than 64x64. 7. Unavailability marking of IBC reference samples mapped to IBC virtual buffers can be performed with VPDU granularity. In one example, if a sample needs to be marked as unusable, samples within the same VPDU may also be marked as unusable. b. In one example, one or more VPDUs may be marked as unavailable at the same time. c. In one example, which VPDU samples are marked as unusable may depend on the position of the current VPDU. d. In one example, which VPDU samples are marked as unusable may depend on the position of the previous or most recently decoded VPDU. 8. If the CTU / CTB size is greater than 64x64, the IBC reference can be the current VPDU and the three most recently decoded VPDUs. In one example, an index may be maintained for each VPDU mapped into the virtual IBC buffer to track the decoding order of each VPDU. 9. A counter may be maintained to track the number of available VPDUs mapped into the buffer. In one example, the counter is reset to 0 at the beginning of decoding each CTU row and is incremented by 1 when one VPDU mapped into the buffer is decoded. b. In one example, if the counter is greater than a predefined value, e.g., 3, then a sample of one VPDU mapped into the buffer may be marked as unusable, and the counter may be decremented by 1. 10. If the CTU / CTB size is 128x128, the corresponding IBC virtual buffer may be of size 256x128. Alternatively, the IBC virtual buffer may be of size (k*64)×128, where k>2. 11. If the CTU / CTB size is 256x256, the corresponding IBC virtual buffer may be of size 64x256 to track the availability of reference samples, i.e., ibcBufW=64, ibcBufH=256. 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. 12. If the CTU / CTB size is 256x256, the corresponding IBC virtual buffer may be of size 128x256 to track the availability of reference samples, i.e., ibcBufW=128, ibcBufH=256. In one example, except for a given VPDU row, only one VPDU can be held for each VPDU row in the buffer (excluding the current VPDU). i. In one example, only one VPDU can be held for each VPDU row in the buffer, except for the last VPDU row (excluding the current VPDU). 13.The IBC buffer may not be reset at the beginning of a CTU line. 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. b. Alternatively, the IBC virtual buffer may be partially reset at the beginning of a CTU row. i. In one example, the VPDUs of the CTU row are inherited into the current IBC buffer, while other buffer areas can be reset. ii. In one example, the bottom left most VPDU of the CTU row is inherited into the current IBC buffer, while other buffer areas may be reset. 14. Whether and / or how a sample in a buffer is marked as unusable may be independent of the location of the chroma block. In one example, only if a luma block is the first block in a VPDU, the corresponding samples in the IBC buffer may be marked as unavailable. b. In one example, when decoding a chroma coding unit, it may not be permissible to reset samples in the buffer or mark them as unavailable. 15. It is proposed that at the start of decoding of each VPDU, the corresponding IBC virtual buffer area may be reset based on the position of the current VPDU. In one example, the IBC virtual buffer area corresponding to (xVPDU+ctbSizeY, yVPDU) is reset, where (xVPDU, yVPDU) indicates the position of the current VPDU relative to the top-left corner of the picture. 16. Whether and / or how to mark a sample in the IBC virtual buffer may depend on the position of the most recently decoded VPDU and the VPDU size. In one example, whether and / or how to mark a sample in the IBC virtual buffer as unusable may depend on the location of the nearest decoded VPDU in a brick / slice / tile / picture. b. In one example, whether and / or how to mark a sample in the IBC virtual buffer as unusable may depend on the position of the most recently decoded VPDU within a CTU row of a brick / slice / tile / picture. c. In one example, which samples in the IBC virtual buffer are marked as unavailable may be independent of the position of the current block. IBC Line Buffer Related 17. Block vector prediction across a CTU row may not be allowed. In one example, if a block vector prediction is from a different CTU row compared to the current CTU row, it may be considered unusable. 18. The deblocking decision for the current IBC block across a CTU row may be independent of the block vectors or motion vectors of other blocks. a. In one example, if two blocks are different CTU rows and one block is coded in IBC mode and the other is coded in IBC or inter mode, the deblocking boundary strength may always be set equal to 1. b. In one example, if two blocks are different CTU rows and one block is coded in IBC mode and the other is coded in IBC or inter mode, the deblocking boundary strength may always be set equal to 0. 19. The deblocking decision for the current IBC block across a CTU row does not have to depend on whether other blocks are coded in IBC mode or in inter mode. a. In one example, if two blocks are different CTU rows and one block is coded in IBC mode and the other is not coded in intra mode, the deblocking boundary strength may always be set equal to 1. Related Subpictures 20. It has been proposed to allow prediction (eg, motion / sample prediction) between two sub-pictures under certain conditions. In one example, if the boundary of the first sub-picture coincides with the picture boundary (or the compatibility window boundary), it may be permissible to use information from the second sub-picture. i. Alternatively, in addition, the sub-picture border is a left or right sub-picture border. ii. Alternatively, the picture boundary is the left or right picture boundary. iii. In one example, the left (or right) border of the second sub-picture may coincide with the left (or right) border of the picture. b. The condition is true if and only if picture wrapping is enabled (e.g., sps_ref_wraparound_enabled_flag is equal to 1). 21. Picture wrapping excludes subpictures. In one example, picture wrapping is enabled when sub-pictures are used. b. In one example, if picture wrapping is enabled, sub-pictures cannot be used. c. Alternatively, picture wrapping can be enabled when sub-pictures are used. iv. In one example, picture wrapping may be enabled for sub-pictures that have boundaries that coincide with picture boundaries. Related Chroma QP Tables 22. The minimum index of the chroma QP table may be independent of the bit depth of the chroma components. In one example, the minimum index of a chroma QP table may depend on the bit depth of the luma component. b. In one example, the minimum index of the chroma QP table is QpBdOffset Y , i.e. 6*bit_depth_luma_minus8.

[0089] 5. Examples of the Disclosed Technology 5.1 Embodiment #1 If the CTU size is 256x256, then a 64x256 IBC virtual buffer ibcBuf is maintained, i.e. ibcBufW=64, ibcBufH=256. The VPDU size is 64x64, and in addition to the VPDU, an on-chip memory of 3 VPDUs is currently used to store IBC reference samples.

[0090] The buffer ibcBuf is reset to -1 at the start of decoding a CTU line.

[0091] At the start of decoding of a new VPDU with top-left position (x0,y0) relative to the top-left corner of the picture, the following applies:

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

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

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

[0095] The bitstream constraints are that the following two conditions are true:

[0096] 1) Given a WxH block with position (x,y) relative to the top-left of the picture, (y%ibcBufH)+H<=ibcBufH.

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

[0098] 5.2 Embodiment #2 If the CTU size is 256x256, then a 128x256 IBC virtual buffer ibcBuf is maintained, i.e. ibcBufW=128, ibcBufH=256. The VPDU size is 64x64, and currently, in addition to the VPDU, 3 VPDUs of on-chip memory are used to store IBC reference samples.

[0099] The buffer ibcBuf is reset to -1 at the start of decoding a CTU row. xPrevVPDU=0 and yPrevVPDU=0.

[0100] At the start of decoding of a new VPDU with top-left position (x0,y0) relative to the top-left corner of the picture, the following applies:

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

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

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

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

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

[0106] The bitstream constraints are that the following two conditions are true:

[0107] 1) Given a WxH block with position (x,y) relative to the top left of the picture, (y%ibcBufH)+H<=ibcBufH.

[0108] 2) ibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH] does not contain invalid pixel values, e.g. -1 for x=0..W-1, y=0..H-1. [Table 4] TIFF0007670680000008.tif234160TIFF0007670680000009.tif236161TIFF00076706800 00010.tif234161TIFF0007670680000011.tif240159TIFF0007670680000012.tif158158

[0109] Figure 4 shows an example of a reference block crossing a VPDU column and a VPDU row. As shown in Figure 4, for the current CU (blue 602), the block filled with red (604) is the crossing VPDU column reference block, and the block filled with yellow (606) is the crossing VPDU row reference block. Each large block represents a 64x64 VPDU, and the green area (608) represents the reconstructed pixels that can be used for IBC reference.

[0110] FIG. 5 is a block diagram of a video processing device 500. The device 500 may be used to implement one or more methods described herein. The device 500 may be embodied in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 500 may include one or more processors 502, one or more memories 504, and video processing hardware 506. The processor 502 may be configured to implement one or more methods described herein (including, but not limited to, the method 400). The memory(s) 504 may be used to store data and codes used to implement the methods and techniques described herein. The video processing hardware 506 may be used to implement some techniques described herein in hardware circuits.

[0111] 6 is a block diagram illustrating an example video processing system 1900 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 1900. System 1900 may include an input 1902 for receiving video content. The video content may be received in a raw or uncompressed format, e.g., 8 or 10 bit multi-component 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, passive optical network (PON), etc., and wireless interfaces such as Wi-Fi or cellular interfaces.

[0112] The system 1900 may include an encoding component 1904 that may implement various coding or encoding methods described herein. The encoding component 1904 may reduce the average bit rate of the video from the input 1902 to the output of the encoding component 1904 to generate a coded representation of the video. Thus, the coding techniques are sometimes referred to as video compression or video transcoding techniques. The output of the encoding component 1904 may be stored or transmitted via a communication link, as represented by component 1906. The stored or communicated bitstream (or coded) representation of the video received at the input 1902 may be used by component 1908 to generate pixel values ​​or displayable video that are sent to the display interface 1910. The process of generating a user-viewable video from the bitstream representation is sometimes referred to as video decompression. Furthermore, although certain video processing operations may be referred to as “coding” operations or tools, it will be understood that the coding tools or operations are used in an encoder and that a corresponding decoding tool or operation, which reverses the result of the coding, is performed in a decoder.

[0113] 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 embodied in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.

[0114] In some embodiments, the video coding method may be performed using an apparatus implemented on a hardware platform such as those described with respect to FIG. 5 or FIG.

[0115] The above examples may be incorporated into the context of the methods described below, for example methods 710, 720, 730, 810, which may be implemented in a video decoder or video encoder.

[0116] 7A shows a flow chart of an example method 710 for video processing. The method 710 includes, at step 712, determining the validity of a block vector or one or more samples mapped to a virtual buffer based on a size of a virtual buffer associated with a current block coded based on pixels in a reference block, where the current picture includes the current block and the reference block, and the size of the virtual buffer is based on a size of a virtual pipeline data unit, a size of a coding tree block, or a size of a coding tree unit. The method 700 includes, at step 714, performing a conversion between the current block and a bitstream representation of the current block based on the determination.

[0117] 7B shows a flowchart of an example method 720 for video processing. The method 720 includes, at step 722, designating one or more reference samples of the reference block as unavailable for a current block coded based on pixels in the reference block, 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 a current picture including the current block and the reference block. The method 720 includes, at step 724, performing a conversion between the current block and a bitstream representation of the current block based on the designation.

[0118] 7C shows a flow chart of an example method 730 for video processing. The method 730 includes, at step 732, determining a size of a virtual buffer associated with the reference block based on a size of a coding tree block (CTB) or a size of a coding tree unit (CTU) of the current block for a current block coded based on pixels in the reference block, the current picture including the current block and the reference block. The method 730 includes, at step 734, performing a conversion between the current block and a bitstream representation of the current block based on the determination.

[0119] 8 shows a flow chart of an example method 810 for video processing. The method 810 includes, at step 812, making a determination based on a size of a virtual pipeline data unit (VPDU), a size of a coding tree block (CTB), or a size of a coding tree unit (CYU) regarding a size of a reference region of the video picture from which reference samples are used to predict a current video block for conversion between a current video block of a video picture of the video and a coded representation of the video. The method 810 further includes, at step 814, performing the conversion based on the determination.

[0120] Some embodiments of the disclosed techniques include making a decision or determination to enable a video processing tool or mode. In one example, if a video processing tool or mode is enabled, an encoder uses or implements the tool or mode in processing blocks of video, but may not necessarily modify the resulting bitstream based on the use of the tool or mode. That is, conversion of blocks of video to a bitstream representation of video uses the video processing tool or mode when enabled based on the decision or determination. In another example, if a video processing tool or mode is enabled, a decoder processes the bitstream knowing that the bitstream has been modified based on the video processing tool or mode. That is, conversion of a bitstream representation of video to blocks of video is performed using the video processing tool or mode enabled based on the decision or determination.

[0121] Some embodiments of the disclosed techniques include making a decision or determination to disable a video processing tool or mode. In one example, when a video processing tool or mode is disabled, an encoder does not use the tool or mode in converting blocks of video into a bitstream representation of the video. In another example, when a video processing tool or mode is disabled, a decoder processes the bitstream knowing that the bitstream has not been modified using the disabled video processing tool or mode based on the decision or determination.

[0122] In this document, the term "video processing" may refer to video coding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during conversion of a pixel representation of a video to a corresponding bitstream representation, or vice versa. The bitstream representation of a current video block may correspond to bits that are co-located or spread to different locations within the bitstream, e.g., as defined by a syntax. For example, a macroblock may be transformed and encoded in terms of a coded error residual value and using bits in the header and other fields in the bitstream.

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

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

[0125] 2. The method of claim 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.

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

[0127] 4. The method of claim 1, wherein the width or height of the virtual buffer is N times the width or height of the VPDU, respectively, where N is an integer number greater than or equal to 1.

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

[0129] 6. The method of clause 1, wherein the maximum number of the one or more samples is fixed based on a determination that the size of the CTB or the size of the CTU is greater than 64x64.

[0130] 7. The method of claim 1, wherein the number of one or more samples is less than or equal to N times the number of samples in a VPDU, where N is an integer number, N≧1.

[0131] 8. The method of claim 7, wherein N=3 if the size of the CTB or the size of the CTU is determined to be greater than 64×64.

[0132] 9. A method for video processing, comprising: for a current block coded based on pixels in the reference block, designating 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 a current picture including the current block and the reference block; and performing a conversion between the current block and a bitstream representation of the current block based on the designation.

[0133] 10. The method of claim 9, further comprising the step of designating corresponding samples in the current VPDU as unusable.

[0134] 11. The method of claim 10, wherein the step of specifying the corresponding sample is based on a position of a current VPDU.

[0135] 12. The method of claim 10, wherein the step of specifying the corresponding sample is based on a position of a previous VPDU or a recently decoded VPDU.

[0136] 13. The method of claim 9, wherein each of the one or more reference samples comprises a sample corresponding to each of the three most recently decoded VPDUs.

[0137] 14. A method for video processing, comprising: for a current block that is coded 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 coding tree block or a size of a coding tree unit of the current block, where a current picture includes the current block and the reference block; and performing a conversion between the current block and a bitstream representation of the current block based on the determination.

[0138] 15. The method according to clause 14, wherein if the size of the CTB or CTU is determined to be 128x128, the size of the virtual buffer is 256x128.

[0139] 16. The method according to clause 14, wherein if the size of the CTB or CTU is determined to be 256x256, the size of the virtual buffer is 64x256.

[0140] 17. The method according to clause 14, wherein if the size of the CTB or CTU is determined to be 256x256, the size of the virtual buffer is 128x256.

[0141] 18. The method of any of clauses 1-17, wherein coding the current block based on pixels in a reference block in the current picture that constitutes the current block is an intra block copy (IBC) operation, and wherein the virtual buffer is an IBC virtual buffer.

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

[0143] 20. The method of claim 19, wherein the IBC buffer size is greater than a total size of a virtual pipeline data unit memory used for the transformation.

[0144] 21. The method of claim 19 or 20, wherein the width of the IBC virtual buffer size is (128*128 / ctbSizeY+ctbSizeY).

[0145] 22. A method of video processing, comprising: for a conversion between a bitstream representation of a current block of video and the current block, determining a size of a reference block for the conversion based on rule-based intra-block predictive coding; and performing the conversion based on the determination, the rule constraining the reference block to be within a virtual pipeline data unit (VPUD) column or a virtual pipeline data unit row.

[0146] 23. The method of claim 22, wherein the rule prohibits the reference block from spanning different VPDU rows.

[0147] 24. The method of claim 22, wherein the rule prohibits the reference block from spanning different VPDU sequences.

[0148] 25. The method according to any of clauses 22-24, wherein the VPDU column or VPDU row is for the picture that contains the current block.

[0149] 26. The method of any of clauses 22-24, wherein the VPDU column or the VPDU row is for an intra block copy virtual buffer.

[0150] 27. The method of any of clauses 1-26, wherein the transformation includes video coding to generate a bitstream representation from the current block.

[0151] 28. The method of any of clauses 1-26, wherein the transforming includes video decoding to generate the current block from the bitstream representation.

[0152] 29. An apparatus in a video system comprising a processor and a non-transitory memory having instructions thereon, the instructions, when executed by the processor, causing the processor to perform a method according to any of clauses 1-28.

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

[0154] 31. Any method, apparatus, or system described herein.

[0155] The second set of clauses describes certain features and aspects of the technology disclosed in the previous sections, e.g., Examples 1, 2, 6-8.

[0156] 1. A method for video processing, comprising: for conversion between a current video block of a video picture of a video and a coded representation of the video, making a decision regarding a size of a reference region of the video picture in which reference samples are used to predict the current video block based on a size of a virtual pipeline data unit (VPDU), a size of a coding tree block (CTB), or a size of a coding tree unit (CTU), and performing the conversion based on the decision.

[0157] 2. The method of claim 1, wherein the current video block is coded using an intra block copy (IBC) mode that generates a predictive block using at least one block vector pointing to a video frame containing the current video block, and the reference region is an IBC virtual buffer.

[0158] 3. The method of claim 1 or 2, further comprising determining the validity of a block vector or one or more samples mapped to the reference region based on the size of the reference region.

[0159] 4. The method of claim 1 or 2, wherein the product of the height and width of the reference area 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.

[0160] 5. The method of claim 1 or 2, wherein the height of the reference area is equal to the height of the CTB or the height of the CTU.

[0161] 6. The method of claim 1 or 2, wherein the width of the reference area is set to a value obtained by dividing the size of the reference area by the height of the CTB.

[0162] 7. The method of claim 1 or 2, wherein the width of the reference area is equal to the width of the CTB or the width of the CTU.

[0163] 8. The method of claim 1 or 2, wherein the width of the reference area is N times the width of the VPDU, and N is an integer number greater than or equal to 1.

[0164] 9. The method of claim 1 or 2, wherein the height of the reference area is N times the height of the VPDU, respectively, where N is an integer number greater than or equal to 1.

[0165] 10. The method according to clause 1 or 2, wherein the width of the reference area is 256*128 / ctbSizeY, where ctbSizeY indicates the width or height of the luma CTB or CTU.

[0166] 11. The method according to clause 1 or 2, wherein the height of the reference area is ctbSizeY, where ctbSizeY indicates the width or height of the luma CTB or CTU.

[0167] 12. The method according to clause 1 or 2, wherein the size of the reference region is determined such that a larger reference region is assigned to a larger CTU or a larger CTB.

[0168] 13. The method according to clause 1 or 2, wherein the width of the reference area is (128*128 / ctbSizeY+ctbSizeY), where ctbSizeY indicates the width or height of the luma CTB or CTU.

[0169] 14. The method of claim 1 or 2, wherein when the size of the CTB or the size of the CTU has a size of 128x128 luma samples, the size of the reference region corresponds to a size of 256x128 luma samples.

[0170] 15. The method according to clause 1 or 2, wherein the size of the reference region corresponds to a size of (k×64)×128 luma samples, where K is greater than 2.

[0171] 16. The method of claim 1 or 2, wherein when the size of the CTB or the size of the CTU corresponds to a size of 256x256 luma samples, the size of the reference region corresponds to a size of 64x256 luma samples.

[0172] 17. The method according to clause 16, wherein before decoding the VPDU at the top left position (x0, y0), the corresponding VPDU row in the reference area is set to -1.

[0173] 18. The method of claim 1 or 2, wherein when the size of the CTB or the size of the CTU has a size of 256x256 luma samples, the size of the reference region corresponds to a size of 128x256 luma samples.

[0174] 19. The method according to clause 18, wherein only one VPDU other than the current VPDU is maintained for each VPDU row in the reference area, except for a given VPDU row.

[0175] 20. The method of any of clauses 1-19, wherein the converting includes encoding the current video block into the coded representation.

[0176] 21. The method of any of clauses 1-19, wherein the transforming includes decoding the coded representation from the current video block.

[0177] 22. A video processing device comprising a processor configured to carry out the method according to any of clauses 1-21.

[0178] 23. A computer readable medium having stored thereon program code which, when executed, causes a processor to implement the method according to any of clauses 1-21.

[0179] From the foregoing, it will be understood that, although specific embodiments of the disclosed technology have been described herein for purposes of illustration, various modifications can be made without departing from the scope of the invention. Accordingly, the presently disclosed technology is not to be limited except as by the appended claims.

[0180] The implementation and functional operation of the subject matter described in this patent document can be embodied in various systems, digital electronic circuits, or computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in one or more combinations thereof. The implementation of the subject matter described herein can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible and non-transitory computer-readable medium for controlling the operation of a data processing apparatus by or on a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or one or more combinations thereof. The term "data processing unit" or "data processing apparatus" encompasses all apparatuses, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. An apparatus may include, in addition to hardware, code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these.

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

[0182] The processes and logic flows described herein 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 special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit), and apparatus may also be implemented.

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

[0184] The specification, together with the drawings, where illustrative means by way of example, is considered to be illustrative only. As used herein, the use of "or" is intended to include "and / or" unless the context clearly indicates otherwise.

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

[0186] Similarly, although the figures show acts in a particular order, this should not be understood as requiring that such acts be performed in the particular order shown, or in sequential order, or that all of the acts described be performed, in order to achieve 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.

[0187] Only a few embodiments and examples have been described, and other embodiments, extensions, and variations can be made based on what is described and illustrated in this patent document.< / y>

Claims

1. 1. A method for processing video data, comprising the steps of: determining, for conversion between a current video block of a video picture of a video and a bitstream of the video, a prediction mode to be applied to the current video block; maintaining a virtual buffer containing reference samples derived from the video picture for the prediction mode; in the prediction mode, deriving a prediction sample for the current video block based on a block vector that points to available reference samples in the virtual buffer; performing the transformation based on the prediction samples; Including, The size of the virtual buffer is determined based on the size of a coding tree block (CTB) constituting the current video block, and the size of the virtual buffer is a width of the virtual buffer or a height of the virtual buffer; the width of the virtual buffer is greater than or equal to 1 times the width of the virtual unit, and the width of the virtual unit is the minimum of (ctbSizeY, 64), where ctbSizeY indicates the size of the luma CTB that constitutes the current video block; the height of the virtual buffer is greater than or equal to one time the height of the virtual unit, and the height of the virtual unit is the minimum (min) of (ctbSizeY, 64); the area of ​​the virtual buffer is fixed and equal to 256x128, the height of the virtual buffer is equal to ctbSizeY, and the width of the virtual buffer is 256x128 / ctbSizeY; a location of one or more unavailable samples in the virtual buffer for deriving the prediction sample is determined based on a width of the virtual unit and a height of the virtual unit. method.

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

3. samples of blocks in the virtual buffer corresponding to the virtual unit are set to −1 and are unavailable for deriving the predicted samples; The method according to claim 1 or 2.

4. The bitstream conformance constraints satisfied by the bitstream include that no reference block determined by a block vector pointing to a reference sample in the virtual buffer has a value equal to -1.

4. The method according to claim 1 .

5. the virtual buffer is refreshed with the value -1 at the beginning of each coding tree unit row; 5. The method according to any one of claims 1 to 4.

6. If the ctbSizeY is greater than 64, the maximum number of samples available in the virtual buffer is fixed.

6. The method according to any one of claims 1 to 5.

7. the number of available samples mapped to the virtual buffer is limited to no more than a multiple of the number of samples in the virtual unit; 7. The method according to any one of claims 1 to 6.

8. a location of the one or more unavailable samples within the virtual buffer is determined based on a maximum between a width of the virtual unit and a width of the current video block, and a maximum between a height of the virtual unit and a height of the current video block.

8. The method according to any one of claims 1 to 7.

9. the converting includes encoding the current video block into the bitstream.

9. The method according to any one of claims 1 to 8.

10. the converting includes decoding the current video block from the bitstream.

9. The method according to any one of claims 1 to 8.

11. 16. An apparatus for processing video data, comprising: a processor; and a non-transitory memory containing instructions that, when executed by the processor, The processor, determining, for a conversion between a current video block of a video picture of a video and a bitstream of the video, a prediction mode to be applied to the current video block; maintain a virtual buffer containing reference samples derived from the video picture for the prediction mode; in the prediction mode, deriving a prediction sample for the current video block based on a block vector that points to available reference samples in the virtual buffer; and performing said transformation based on said prediction samples; Let them do so, The size of the virtual buffer is determined based on the size of a coding tree block (CTB) constituting the current video block, and the size of the virtual buffer is a width of the virtual buffer or a height of the virtual buffer; the width of the virtual buffer is greater than or equal to 1 times the width of the virtual unit, and the width of the virtual unit is the minimum of (ctbSizeY, 64), where ctbSizeY indicates the size of the luma CTB that constitutes the current video block; the height of the virtual buffer is greater than or equal to one time the height of the virtual unit, and the height of the virtual unit is the minimum (min) of (ctbSizeY, 64); the area of ​​the virtual buffer is fixed and equal to 256x128, the height of the virtual buffer is equal to ctbSizeY, and the width of the virtual buffer is 256x128 / ctbSizeY; a location of one or more unavailable samples in the virtual buffer for deriving the prediction sample is determined based on a width of the virtual unit and a height of the virtual unit. Device.

12. A non-transitory computer-readable storage medium having instructions stored thereon, The instructions cause a processor to: determining, for a conversion between a current video block of a video picture of a video and a bitstream of the video, a prediction mode to be applied to the current video block; maintain a virtual buffer containing reference samples derived from the video picture for the prediction mode; in the prediction mode, deriving a prediction sample for the current video block based on a block vector that points to a reference sample in the virtual buffer; and performing said transformation based on said prediction samples; Let them do so, The size of the virtual buffer is determined based on the size of a coding tree block (CTB) constituting the current video block, and the size of the virtual buffer is a width of the virtual buffer or a height of the virtual buffer; the width of the virtual buffer is greater than or equal to 1 times the width of the virtual unit, and the width of the virtual unit is the minimum of (ctbSizeY, 64), where ctbSizeY indicates the size of the luma CTB that constitutes the current video block; the height of the virtual buffer is greater than or equal to one time the height of the virtual unit, and the height of the virtual unit is the minimum (min) of (ctbSizeY, 64); the area of ​​the virtual buffer is fixed and equal to 256x128, the height of the virtual buffer is equal to ctbSizeY, and the width of the virtual buffer is 256x128 / ctbSizeY; a location of one or more unavailable samples in the virtual buffer for deriving the prediction sample is determined based on a width of the virtual unit and a height of the virtual unit. A non-transitory computer-readable storage medium.

13. A method for storing a video bitstream on a non-transitory computer-readable recording medium, comprising: The method comprises: determining, for conversion between a current video block of a video picture of a video and a bitstream of the video, a prediction mode to be applied to the current video block; maintaining a virtual buffer containing reference samples derived from the video picture for the prediction mode; in the prediction mode, deriving a prediction sample for the current video block based on a block vector that points to available reference samples in the virtual buffer; generating the bitstream based on the predicted samples; storing the video bitstream on a non-transitory computer readable recording medium; Including, The size of the virtual buffer is determined based on the size of a coding tree block (CTB) constituting the current video block, and the size of the virtual buffer is a width of the virtual buffer or a height of the virtual buffer; the width of the virtual buffer is greater than or equal to 1 times the width of the virtual unit, and the width of the virtual unit is the minimum of (ctbSizeY, 64), where ctbSizeY indicates the size of the luma CTB that constitutes the current video block; the height of the virtual buffer is greater than or equal to one time the height of the virtual unit, and the height of the virtual unit is the minimum (min) of (ctbSizeY, 64); the area of ​​the virtual buffer is fixed and equal to 256x128, the height of the virtual buffer is equal to ctbSizeY, and the width of the virtual buffer is 256x128 / ctbSizeY; a location of one or more unavailable samples in the virtual buffer for deriving the prediction sample is determined based on a width of the virtual unit and a height of the virtual unit. method.

Images