RU2811460C2 - Virtual buffer for prediction when coding video in intra-frame block copying mode - Google Patents

Abstract

FIELD: image coding and decoding.

SUBSTANCE: invention is aimed at increasing the efficiency of image encoding/decoding. This result is achieved by performing a conversion between the current video block of the current visual media image and the representation of the visual media data as a stream of data bits. The transformation is based on a reference region from the current image containing reference samples to form a predicted block for the current video block. A virtual buffer of a given size is used to track the availability of reference samples to obtain a predicted block.

EFFECT: increasing the efficiency of image encoding/decoding.

13 cl, 22 dwg, 2 tbl

Description

This patent document relates to technologies, devices and systems for video encoding and decoding.

State of the art

Despite all the advances in video compression, digital video occupies the largest share of bandwidth on the Internet and other digital communications networks. As the number of connected user devices capable of receiving and presenting video on a display increases, bandwidth requirements for digital video use are expected to continue to grow.

Disclosure of the invention

This document describes various options and methods for buffer management and block vector encoding for intra-frame block copy mode in video and image decoding and encoding.

In one exemplary aspect, a method for processing visual media data is provided. The method comprises the steps of determining, for conversion between the current video block of the current visual media image and the data bit stream representation of the current video block, a block vector (BVx,BVy), wherein the validity of the block vector (BVx, BVy) is independent of (1) position (P, Q) of the sample block, and/or on (2) whether the sample is reconstructed at position (P,Q), and/or on (3) the position of the current video block, wherein the block vector (BVx, BVy) represents pixel displacement between the current video block and the specified block of samples; and performing, using the block vector, an intra-frame block copy transformation based on a reconstructed block located in the same video area as the current video block containing reference samples used to determine a predicted block for the current video block, wherein in the process of transformation the predicted sample at position (A, B) from the reference samples in the buffer is determined according to at least the buffer size and/or the block vector (BVx, BVy).

According to another exemplary aspect, another method for processing visual media data is provided. The method comprises determining, for conversion between a current video block of a current visual media image and a representation of the visual media data as a stream of data bits, whether a block vector (BVx, BVy) corresponding to the current video block is valid in accordance with some rule, wherein the block vector the vector (BVx, BVy) represents the pixel offset between the current video block and the sample block; and performing, using the block vector, a transformation based on a reference region from the current image containing reference samples used to determine a prediction block for the current video block, said rule specifying that the block vector (BVx, BVy) is valid when (1 ) one or more samples from the sample block are outside the current picture, and/or (2) one or more samples from the sample block are outside at least one coding tree unit (CTU) associated with the current video block, and/or (3) one or more samples from the block of samples could not be reconstructed

According to yet another exemplary aspect, another method for processing visual media data is provided. The method comprises performing a conversion between a current video block of a current visual media image and a representation of the visual media data as a stream of data bits, wherein the conversion is performed based on a reference region from the current image containing reference samples used to determine a predicted block for the current video block, and a virtual buffer of a given size is used to track the availability of reference samples to determine the prediction block.

According to yet another exemplary aspect, another video processing method is proposed. The method comprises maintaining, for conversion between a current video block of a current visual media image and a representation of the visual media data as a stream of data bits, a buffer storing reference samples from the current image to form a prediction block for the current video block, the one or more samples in the buffer , which are marked as unavailable for retrieval, have values outside the range of pixel values.

According to another exemplary aspect, another video processing method is provided. The method comprises performing a transformation between a current video block of a current visual media image and a representation of the visual media data as a stream of data bits, using a buffer containing reference samples from the current image to obtain a predicted block for the current video block, wherein the transformation is based on a rule defining , that in order for the data bitstream representation to satisfy the specified rule, the reference sample in the buffer must satisfy the data bitstream compliance constraint.

According to yet another exemplary aspect, a video encoding or decoding apparatus is provided, comprising a processor configured to perform the method described above.

In another exemplary aspect, a computer-readable program medium is provided. The medium stores code containing processor-executable commands to perform one of the described methods.

These and other aspects are described in more detail herein.

Brief description of drawings

Fig. 1 shows an example of linking the current image to a support or video with intra-frame block copying or an image encoding method.

Fig. 2 shows an example of a dynamic reference region.

Fig. 3 shows an example of encoding a block starting from point (x,y).

Fig. 4 shows examples of possible alternative methods for selecting previously encoded 64x64 blocks.

Fig. 5 shows an example of a possible alternative method for changing the encoding/decoding order of 64x64 blocks.

Fig. 6 is a logic diagram of an example of a video or image processing method.

Fig. 7 is a block diagram of a hardware platform for encoding or decoding video or images.

Fig. 8 shows another possible alternative method for selecting previously encoded 64x64 blocks when the decoding order for the 64x64 blocks is set from top to bottom, left to right.

Fig. 9 shows another possible alternative method for selecting previously encoded 64x64 blocks.

Fig. 10 shows an example of a logic diagram of a reshaping decoding procedure.

Fig. 11 shows another possible alternative method for selecting previously encoded 64x64 blocks when the decoding order for the 64x64 blocks is set from left to right, top to bottom.

Fig. 12 shows an illustration of the status of the reference buffer for the IBC copy mode, where a block denotes a 64x64 CTU.

Fig. 13 shows one arrangement of the reference area for the IBC copy mode.

Fig. 14 shows another arrangement of the reference area for the IBC copy mode.

Fig. 15 shows another reference region location for the IBC copy mode when the current virtual pipeline data unit (VPDU) is on the right side of the image boundary.

Fig. 16 shows an example of the virtual buffer status when VPDUs in a line of CTUs are decoded sequentially.

Fig. 17 is a block diagram of an example video processing system in which the described methods may be implemented.

Fig. 18 provides a logic diagram of an example method for processing visual media data.

Fig. 19 provides a logic diagram of an example method for processing visual media data.

Fig. 20 provides a logic diagram of an example method for processing visual media data.

Fig. 21 provides a logic diagram of an example method for processing visual media data.

Fig. 22 provides a logic diagram of an example method for processing visual media data.

Carrying out the invention

Section headings are used herein to aid understanding and do not limit the scope of the options described in each section to that section only. This document describes various options and methods for buffer management and block vector encoding in intra-frame block copy mode for decoding or encoding video or images.

1. Brief summary of the invention

This patent document relates to video encoding methods. In particular, it relates to intra-frame block copying during video encoding. This can be applied to standards under development, such as the Versatile Video Coding standard. This may also apply to video coding standards or future video codecs.

2. Brief discussion

Video coding standards have evolved primarily through the development of the well-known ITU-T and ISO/IEC standards. ITU-T has released H.261 and H.263, ISO/IEC has released MPEG-1 and MPEG-4 Visual, and the two have jointly released H.262/MPEG-2 Video and H.264/ MPEG-4 Advanced Video Coding (AVC) and H.265/HEVC. Since the H.262 standard, video coding standards have been based on a hybrid video coding structure using time prediction plus transformation coding. To research future video encoding technologies that will be developed after HEVC encoding technology, the Video Coding Experts Group (VCEG) and the Motion Picture Experts Group (MPEG) jointly founded the Joint Video Exploration Team in 2015 (JVET)). Since then, the JVET team has developed many new techniques and incorporated them into reference software called the Joint Exploration Model (JEM). In April 2018, VCEG (Q6/16) and ISO/IEC JTC1 SC29/WG11 (MPEG) formed the Joint Video Expert Team (JVET) to work on the VVC standard, with the goal of reducing 50% reduction in required data bit rate compared to HEVC encoding

2.1 Inter-frame prediction in HEVC/H.265 standard

Each PU prediction unit has motion parameters for one or two reference picture lists. The set of motion parameters contains a motion vector and a reference image index. The use of one or two reference picture lists may also be signaled using the inter_pred_idc parameter. Motion vectors can be explicitly encoded as increments relative to the predictors.

When a CU (coding unit) is encoded in the skip mode, there is one PU associated with this CU, and there are neither significant remainder coefficients nor coded increment of motion vector or reference picture index. The fusion mode is specified such that the motion parameters for the current PU are obtained from neighboring PUs, including spatial and temporal candidates. The combining mode can be applied to any inter-prediction PU, not just the skip mode. An alternative to the fusion mode is to pass the motion parameters explicitly, where the motion vectors (more precisely, the motion vector difference (MVD) relative to the motion vector predictor), the corresponding reference picture index for each reference picture list, and the reference list usage rate images are explicitly signaled for each PU. This type of mode is referred to in this document as advanced motion vector prediction (AMVP).

When signaling indicates that one of the two reference picture lists should be used, a PU is created from one block of samples. This is called 'uni-prediction'. Unidirectional prediction is available for both types of slices - P-slice or slice with reference to the previous slice (predicted slice) and B-slice or slice with reference to previous and subsequent slices (or bidirectionally interpolated slice ).

When signaling indicates that both reference picture lists should be used, a PU is created from two sample blocks. This is called 'bi-prediction'. Bidirectional interpolation is only available for B-slices.

The following text contains details regarding the inter-frame prediction modes specified in the HEVC coding standard. The description will begin with the merge mode.

2.2 Using the current image as a reference

Current Picture Referencing (CPR), or as it was once called Intra Block Copy (IBC), has been adopted by HEVC Screen Content Coding extensions (HEVC-SCC)) and in the test model of today's version of the VVC coding standard. The IBC copy principle extends the concept of motion compensation from inter-prediction coding to intra-prediction coding. As shown in FIG. 1, when the CPR mode is applied, the current block is predicted based on a reference block from the same image. The samples from the reference block must already be reconstructed before the current block is encoded or decoded. Although CPR mode is not that effective for most camera sequences, it does show significant gains in encoding screen content. The reason for this is the presence of large groups of repeating structures, such as icons and text characters, in the display of screen content. The CPR mode can effectively eliminate the redundancy between these repeating structures. In the HEVC-SCC standard, a coding unit (CU) using inter-picture prediction can apply the CPR mode if it selects the current picture as the reference picture. In this case, the motion vector (MV) is renamed a block vector (BV), and this BV is always accurate to an entire pixel. To ensure compatibility with the main HEVC encoding profile, the current picture is marked as a “long-term” reference picture in the Decoded Picture Buffer (DPB). It should be noted that similarly, in multi-view/3D video coding standards, an inter-view reference picture is also labeled as a “long-term” reference picture.

By following the BV vector to find the reference block, the prediction can be generated by copying the reference block. The remainder can be obtained by subtracting the reference pixels from the original signals. Transformation and quantization can then be applied, as in other encoding modes.

In fig. Figure 1 shows an example illustrating the use of the current image as a reference.

However, when the reference block is outside the image, or superimposed on the current block, or outside the reconstructed region, or outside the actual region limited by some limiting factors, some or all of the pixel values are undefined. There are basically two technical solutions to deal with this problem. One solution is to prevent this situation from happening, for example by matching data bit streams. Another solution is to apply padding to such undefined pixel values. The following subsections describe these technical solutions in detail.

2.3 CPR mode in HEVC Screen Content Coding extensions

In extensions with screen content encoding in the HEVC encoding standard, when any block uses the current image as a reference, it must ensure that the entire reference block is within the available reconstructed region, as indicated by the following special text (bold):

The offsetX and offsetY variables are output as follows:

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

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

One of the requirements for data bitstream matching is that when the reference image is the current image, the luminance motion vector mvLX must be subject to the following constraints:

- When the inference procedure for block availability in z-scan order, as specified in clause 6.4.1, is invoked with ( xCurr, yCurr ) set equal to ( xCb, yCb ), and the adjacent luminance component position ( xNbY, yNbY ) set equal to ( xPb + (mvLX[ 0 ] >> 2) − offsetX, yPb + ( mvLX[ 1 ] >> 2 ) − offsetY ) as input, the output must be TRUE.

- When the inference procedure for block availability in z-scan order, as specified in clause 6.4.1, is invoked with ( xCurr, yCurr ) set equal to ( xCb, yCb ), and the adjacent luminance component position ( xNbY, yNbY ) set equal to ( xPb + (mvLX[ 0 ] >> 2) + nPbW − 1 + offsetX, yPb + (mvLX[ 1 ] >> 2) + nPbH − 1 + offsetY), as input data, the output signal should have the value " True" (TRUE).

- One or both of the following conditions must be true:

- Value ( mvLX[ 0 ] >> 2 ) + nPbW + xB1 + offsetX is not greater than 0.

- Value ( mvLX[ 1 ] >> 2 ) + nPbH + yB1 + offsetY is not greater than 0.

- The following condition must be true:

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

Thus, the case where the reference block overlaps the current block or the reference block is outside the image will not occur. Therefore, there is no need to “fill in” the reference or forecast block.

2.4 Copying examples of CPR/IBC blocks

In today's VVC encoding test model, the entire reference block must be with the current coding tree unit (CTU) and must not overlap the current block. Thus, there is no need to "fill in" the reference or forecast block.

When dual tree is enabled, the partitioning structure may be different for luma CTUs and chrominance CTUs. Therefore, for a 4:2:0 color format, one chrominance block (eg, CU) may correspond to one colocated luminance region that has been divided into multiple luminance CUs.

A chrominance block can only be encoded in CPR mode when the following conditions must be true:

1. each luminance CU located within a luminance block located at the same location must be encoded in CPR mode

2. The BV vector for each of the 4x4 luma blocks is first converted into a BV vector for the chroma block, and this BV vector for the chrominance block is a real BV vector.

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

It should be noted that the definition of "real BV vector" has the following limitations:

1. all samples within the reference block identified by the BV vector must be within the limited search range (for example, must be within the same CTU in today's edition of the VVC coding standard).

2. all samples within the reference block identified by the BV vector have already been reconstructed by the current moment.

2.5 Copying examples of CPR/IBC blocks

In some examples, the reference area for CPR/IBC mode is limited to the current CTU, which is up to 128x128 in size. The reference area is modified dynamically to reuse memory to maintain reference samples for CPR/IBC mode, so that a block predicted in CPR/IBC mode may have more reference candidates, while the reference buffer for CPR/IBC mode may maintain the size or be reduced from one CTU unit.

In fig. 2 shows a method where the block size is 64x64 and the CTU contains 4 blocks of size 64x64. When encoding a 64x64 block, the previous 3 64x64 blocks can be used as a reference. With this approach, the decoder simply needs to store 4 64x64 blocks to support CPR/IBC mode.

Suppose that the position of the current luminance component CU unit relative to the top-left corner of the image has coordinates (x, y) and the block vector is equal to (BVx, BVy). In the current configuration, whether the BV vector is valid can be indicated by the fact that the position of the luminance component ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<< 6) was not reconstructed, and ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) is not equal to (x>>6<<6, y>>6<<6).

2.6. Intra-loop reformation (ILR)

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

The in-loop luminance reshaping device is implemented as a pair of look-up tables (LUTs), but only one of the two LUTs needs to be signaled, while the other table can be calculated based on the reported LUT. Each LUT is a one-dimensional, 10-bit, mapping table with 1024 input positions (1D-LUT). One LUT is a direct conversion LUT (direct LUT), FwdLUT, which converts the values input chrominance code into modified values : . The other LUT is the inverse LUT (inverse LUT), InvLUT, which converts the changed code values in meaning : . ( represents reconstructed values .).

2.6.1 Piecewise linear (PWL) model

Conceptually, the piece-wise linear (PWL) model is implemented as follows:

Let x1, x2 be two input anchor points and y1, y2 be the corresponding output anchor points for one line segment. The output value y for any input value x between x1 and x2 can be interpolated using the following equation:

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

In a fixed-point implementation, this equation can be rewritten as:

y = ((m * x + 2 ^FP_PREC-1 ) >> FP_PREC) + c

where m denotes a scalar, c denotes a shift, and FP_PREC is a constant for specifying precision.

In some examples, the PWL model is used to precompute the 1024-input forward FwdLUT and inverse InvLUT mapping tables; but the PWL model also allows implementations to be created to calculate identical display values in real time without first computing the LUTs.

2.6.2.1 Reshaping the brightness component

The method of in-loop reformation of the luminance component creates a pipeline of less complexity, which also eliminates the decoding delay for block-by-block intra-frame prediction during slice reconstruction during inter-frame prediction. Intra-frame prediction is carried out in a reshaped area for slices of both types - with intra-frame and inter-frame prediction.

Intra-frame prediction is always performed in the reshaped region, regardless of the slice type. In such a configuration, the intra-prediction process may begin immediately after the reconstruction of the previous TU is completed. Such a configuration may also offer a unified procedure for intra-frame prediction instead of a slice-specific procedure. In fig. 10 is a flowchart of a mode-based decoding procedure CE12-2.

16-element piecewise linear (PWL) models are tested to scale luma and chroma residuals instead of 32-element PWL models.

Reconstruction of a slice during intra-frame prediction using a device for intra-circuit reformation of the brightness component (blocks shaded in light green indicate the signal in the reformed area: the remainder of the brightness component; the brightness component during intra-frame prediction; the reconstructed luminance component during intra-frame prediction).

2.6.2.2 Luminance-dependent scaling of the remaining chrominance component

The luminance component-dependent scaling of the chroma residual is a multiplicative process implemented by a fixed-point integer operation. Scaling the remaining chrominance component compensates for the interaction of the luminance signal with the chrominance signal. Chroma residual scaling is applied at the TU level. More specifically, the following applies:

For intra-frame prediction, the reconstructed luminance component is averaged.

For interframe prediction, the predicted luminance component is averaged.

Averaging is used to identify the index in the PWL model. This index identifies the scale factor cScaleInv. The remainder of the color component is multiplied by this coefficient.

Note that the scale factor for the chrominance component is calculated based on the forward-mapped luminance component values instead of the reconstructed luminance component values.

2.6.2.3 Signaling additional information about ILR reconfiguration

These parameters are passed (currently) in the tile group header (similar to ALF filtering). These messages occupy 40 – 100 bits.

In some examples, added syntax is italicized.

B 7.3.2.1 RBSP Sequence Parameter Set Syntax

seq_parameter_set_rbsp() { Descriptor sps_seq_parameter_set_id ue(v) ... sps_triangle_enabled_flag u(1) sps_ladf_enabled_flag u(1) if ( sps_ladf_enabled_flag ) { sps_num_ladf_intervals_minus2 u(2) sps_ladf_lowest_interval_qp_offset se(v) for( i = 0; i < sps_num_ladf_intervals_minus2 + 1; i++ ) { sps_ladf_qp_offset[ i ] se(v) sps_ladf_delta_threshold_minus1[ i ] ue(v) } } sps_reshaper_enabled_flag u(1) rbsp_trailing_bits( ) }

B 7.3.3.1 Tile Group General Header Syntax

tile_group_header() { Descriptor ... if( num_tiles_in_tile_group_minus1 > 0 ) { offset_len_minus1 ue(v) for( i = 0; i < num_tiles_in_tile_group_minus1; i++ ) entry_point_offset_minus1[ i ] u(v) } if ( sps_reshaper_enabled_flag ) { tile_group_reshaper_model_present_flag u(1) if (tile_group_reshaper_model_present_flag) tile_group_reshaper_model ( ) tile_group_reshaper_enable_flag u(1) if ( tile_group_reshaper_enable_flag && (!( qtbtt_dual_tree_intra_flag && tile_group_type == I ) ) ) tile_group_reshaper_chr oma_residual_scale_flag u(1) } byte_alignment( ) }

Adding a new model of the tile group reformation device in the syntax table:

tile_group_reshaper_model() { Descriptor 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) } }

Adding the following semantics to the general semantics of the RBSP sequence parameter set:

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

In the tile group header syntax, adding the following semantics

The tile_group_reshaper_model_present_flag equal to 1 specifies that the tile_group_reshaper_model() parameter is present in the tile group header. The tile_group_reshaper_model_present_flag equal to 0 specifies that the tile_group_reshaper_model() parameter is not present in the tile group header. When the tile_group_reshaper_model_present_flag flag is not present, it is considered to be 0.

The tile_group_reshaper_enabled_flag equal to 1 specifies that the reshaper is enabled for the current tile group. The tile_group_reshaper_enabled_flag equal to 0 specifies that the reshaper is not enabled for the current tile group. When the tile_group_reshaper_enable_flag is not present, it is considered to be 0.

The tile_group_reshaper_chroma_residual_scale_flag flag equal to 1 specifies that chroma residual scaling is enabled for the current tile group. The tile_group_reshaper_chroma_residual_scale_flag equal to 0 specifies that chroma residual scaling is not enabled for the current tile group. When the tile_group_reshaper_chroma_residual_scale_flag is not present, it is treated as 0.

Adding tile_group_reshaper_model() syntax

The reshape_model_min_bin_idx index specifies the minimum bit (or bin) index to use during the reshaping device design process. The value of this index, reshape_model_min_bin_idx, must be in the range from 0 to the MaxBinIdx parameter, inclusive. The MaxBinIdx parameter value must be equal to 15.

The reshape_model_delta_max_bin_idx index specifies the maximum allowable bit (or slice) index MaxBinIdx minus the maximum bit index to use in the reshaping device design process. The reshape_model_max_bin_idx index value is set equal to MaxBinIdx – reshape_model_delta_max_bin_idx.

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

The reshape_model_bin_delta_abs_CW[ i ] parameter specifies the absolute value of the increment codeword (delta) for the i-th bit.

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

– If the reshape_model_bin_delta_sign_CW_flag[ i ] flag is 0, the corresponding RspDeltaCW[ i ] variable has a positive value.

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

When the reshape_model_bin_delta_sign_CW_flag[ i ] flag is not present, it is considered equal to 0.

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

The variable RspCW[ i ] is determined through the following steps:

The OrgCW variable is set to (1 << BitDepth _Y ) / ( MaxBinIdx + 1 ).

– If reshaper_model_min_bin_idx <= i <= reshaper_model_max_bin_idx

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

– Otherwise, RspCW[ i ] = 0.

The value of RspCW[i] must be in the range from 32 to 2 * OrgCW – 1 if the BitDepth _Y value is 10.

InputPivot[ i ] variables with i in the range from 0 to MaxBinIdx + 1, inclusive, are formed as follows

The ReshapePivot[ i ] variable for i in the range from 0 to MaxBinIdx + 1, inclusive, the ScaleCoef[ i ] variable and the InvScaleCoeff[ i ] variable for i in the range from 0 to MaxBinIdx, inclusive, are defined as follows:

InputPivot[ i ] = i * OrgCW

shiftY = 14
ReshapePivot[ 0 ] = 0;

for( i = 0; i <= MaxBinIdx ; i++) {
ReshapePivot[ i + 1 ] = ReshapePivot[ i ] + RspCW[ i ]

ScaleCoef[ i ] = ( RspCW[ i ] * (1 << shiftY) + (1 << (Log2(OrgCW) - 1))) >> (Log2(OrgCW))
if ( RspCW[ i ] == 0 )
InvScaleCoeff[ i ] = 0
else
InvScaleCoeff[ i ] = OrgCW * (1 << shiftY) / RspCW[ i ]
}

The variable ChromaScaleCoef[ i ] with i in the range from 0 to MaxBinIdx, inclusive, is defined as follows:

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

shiftC = 11

– if ( RspCW[ i ] == 0 )

ChromaScaleCoef [ i ] = (1 << shiftC)

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

2.6.2.4 Using ILR reframing

On the encoder side, each image (or group of tiles) is first converted into a reshaped region. And the entire coding procedure is carried out in the reformed area. For intra-frame prediction, the adjacent block is in the reshaped region; For inter-frame prediction, reference blocks (generated from the original region from the decoded image buffer) are first converted into a reshaped region. The remainder is then generated and encoded in the data bitstream.

After encoding/decoding of the entire image (or group of tiles) is completed, the samples in the reshaped region are converted to the original region and then the deblocking filter and other filters are applied.

The procedure for direct conversion to a predicted signal is not activated in the following cases:

The current block is encoded using intra-frame prediction

The current block is encoded using the current picture as a reference (CPR (current picture referencing)) (also called intra-block copying, IBC)

The current block is encoded using a combined inter-intra mode (CIIP) and direct reframing is not enabled for the intra-prediction block

3. Examples of problems solved by various options

There are several problems with today's CPR/IBC coding.

1. The reference areas change dynamically, which makes the encoding/decoding procedure complicated.

2. Invalid block vectors are easily generated and are difficult to verify, which complicates both the encoder and the decoder.

3. Irregular reference region leads to inefficient block vector encoding.

4. It is unclear how to handle CTUs smaller than 128x128.

5. In the process of determining whether the BV vector is valid or invalid for chrominance blocks, the decision is made based on the availability of the luminance component sample, which may lead to incorrect decisions due to the splitting structure of the double tree.

4. Examples of options

In some embodiments, a regular buffer may be used to support a block in CPR/IBC mode.

The isRec(x,y) function is defined to indicate whether a pixel at (x,y) coordinates has been reconstructed for use as a reference in IBC copy mode. When point (x,y) is outside the image, another slice/tile/block, isRec(x,y) is false; when the pixel at (x,y) has not yet been reconstructed, isRec(x,y) is false. In another example, when the sample at point (x,y) has already been reconstructed but some other conditions are met, it may also be marked as unavailable, for example as being outside the reference region/in another VPDU, and the function isRec(x, y) has the value "false".

The function isRec(c, x,y) is defined to indicate whether the sample at point (x,y) for the c component is available. For example, if the sample at point (x, y) has not yet been reconstructed, it is marked as unavailable. In another example, when the sample at point (x,y) has already been reconstructed but some other conditions are met, it may also be marked as unavailable, for example, as being outside the image/in another slice/tile/block/in another VPDU , outside the permissible support area. The isRec(c, x,y) function evaluates to false when a sample at (x, y) is not available, otherwise it evaluates to true.

In the following discussion, the reference samples may be reconstructed samples. Note that the term “pixel buffer” can mean “single color component buffer” or “multiple color component buffer.”

Reference buffer for CPR/IBC mode

1. It is proposed to use a pixel buffer of M×N size to save reference samples of the chrominance component for the CPR/IBC mode.

- In one example, the buffer size is 64x64.

- In one example, the buffer size is 128x128.

- In one example, the buffer size is 64x128.

- In one example, the buffer size is 128x64.

- In one example, N is equal to the height of the CTU unit.

- In one example, N=nH, where H is the height of the CTU unit, n is a positive integer.

- In one example, M is equal to the width of the CTU unit.

- In one example, M=mW, where W is the width of the CTU unit, m is a positive integer.

- In one example, the buffer size, such as 96x128 or 128x96, is not equal to the CTU size.

- In one example, the buffer size is equal to the size of the CTU unit

- In one example, M=mW and N=H, where W and H represent the width and height of the CTU, m is a positive integer.

- In one example, M=W and N=nH, where W and H represent the width and height of the CTU, n is a positive integer.

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

- In the above example, m and n may depend on the size of the CTU unit.

- In one example, when the CTU size is 128x128, m=1 and n=1.

- In one example, when the CTU size is 64x64, m=4 and n=1.

- In one example, when the CTU size is 32x32, m=16 and n=1.

- In one example, when the CTU size is 16x16, m=64 and n=1.

- Alternatively, the buffer size corresponds to the CTU size.

- Alternatively, the buffer size corresponds to the size of the virtual pipeline data unit (VPDU).

- The M and/or N values may be signaled from an encoder to a decoder, for example as part of a VPS set/SPS set/PPS set/picture header/slice header/tile group header.

23. The values of M and/or N may be different in different profiles/levels/tiers defined by the standard. It is proposed to use another pixel buffer of size Mc×Nc to save reference samples of the chrominance component for the CPR/IBC mode.

- In one example, Mc = M/2 and Nc = N/2 for 4:2:0 video

- In one example, Mc = M and Nc = N for 4:4:4 video

- In one example, Mc = M and Nc = N/2 for 4:2:2 video

- Alternatively, Mc and Nc may be independent of M and N.

- In one example, the chrominance buffer contains two channels corresponding to the Cb and Cr components.

- In one example, Mc=M and Nc=N.

30. It is proposed to use a sample buffer of M×N size to save reference samples in RGB format for CPR/IBC mode

- In one example, the buffer size is 64x64.

- In one example, the buffer size is 128x128.

- In one example, the buffer size is 64x128.

- In one example, the buffer size is 128x64.

- Alternatively, the buffer size corresponds to the CTU size.

- Alternatively, the buffer size corresponds to the size of the virtual pipeline data unit (VPDU).

37. It is proposed that the buffer can store the reconstructed pixels before contour filtering. Loop filtering can refer to the use of a deblocking filter, an adaptive loop filter (ALF), a sample adaptive offset (SAO) filter, a cross-component ALF filter, or some other filter.

- In one example, the buffer may store samples of the current CTU.

- In one example, the buffer may store samples outside the current CTU.

- In one example, the buffer can store samples from any part of the current image.

- In one example, the buffer can store samples from other images.

42. It is proposed that the buffer can store the reconstructed pixels after contour filtering. Loop filtering may refer to the use of a deblocking filter, an adaptive loop filter (ALF), a nonlinear adaptive offset filter (SAO), a cross-component ALF filter, or some other filters.

- In one example, the buffer may store samples of the current CTU.

- In one example, the buffer may store samples outside the current CTU.

- In one example, the buffer can store samples from any part of the current image.

- In one example, the buffer can store samples from other images.

47. It is proposed that the buffer can store reconstructed pixels both before and after contour filtering. Loop filtering may refer to the use of a deblocking filter, an adaptive loop filter (ALF), a nonlinear adaptive offset filter (SAO), a cross-component ALF filter, or some other filters.

- In one example, the buffer may store both samples from the current image and samples from other images, depending on the availability of those samples.

- In one example, the reference samples from other images are samples from a pool of reconstructed samples after contour filtering.

- In one example, the reference samples from other images are samples from a pool of reconstructed samples before contour filtering.

51. It is proposed that the buffer can store samples at a given bit depth, which may be different from the bit depth of the encoded video data.

- In one example, the bit depth of the reconstruction buffer/encoded video data is greater than the bit depth of the IBC copy mode reference samples stored in the buffer.

- In one example, even if the internal bit depth is different from the input bit depth for the video sequence, for example, (10 bits vs. 8 bits), the reference samples for the IBC copy mode are stored to be aligned with the input bit depth.

- In one example, the bit depth is identical to the bit depth of the reconstruction buffer.

- In one example, the bit depth is identical to the bit depth of the input image/video.

- In one example, the bit depth is identical to the given number.

- In one example, the bit depth depends on the standard profile.

- In one example, the bit depth or difference of bit depths compared to the output bit depth/input bit depth/internal bit depth may be signaled in the SPS set/PPS set/sequence header/picture header/slice header/group header tiles/tile title or in other types of video inputs.

- The proposed methods can be applied using the proposed buffer definitions noted in other sections, alternatively, it can also be applied to the existing IBC copy mode variant.

- The bit depth of each color component in the buffer may be different from other components.

Buffer initialization

61. It is suggested to initialize the buffer using a given value

- In one example, the buffer is initialized using a given value.

- In one example, said target value may depend on the input bit depth and/or the internal bit depth.

- In one example, the buffer is initialized using an average gray level, for example, 128 for an 8-bit signal or 512 for a 10-bit signal.

- In one example, the buffer is initialized using the value forwardLUT(m) when ILR reshaping is used. For example, m= 1<<(Bitdepth-1).

- Alternatively, the buffer is initialized using the value reported as signaling in the SPS set/VPS set/APS set/PPS set/sequence header/tile group header/picture header/tile/unit/CTU/coding unit/VPDU unit/ areas.

- In one example, said target value may be derived from samples of previously decoded pictures or slices, or strings of CTUs or CTUs or CUs.

- The specified target value may be different for different color components.

69. As an alternative, it is proposed to initialize the buffer using decoded pixels from previously decoded blocks.

- In one example, pixels before in-loop filtering are used as decoded pixels.

- In one example, when the buffer size is equal to the size of the CTU, the buffer is initialized using decoded pixels from a previously decoded CTU, if available.

- In one example, when the buffer size is 64x64, the buffer of that size is initialized using decoded pixels from a previously decoded 64x64 block, if available.

- Alternatively, if there are no previously encoded blocks available, the method from paragraph 8 can be applied.

Buffer links

74. A block that needs to use a buffer as a support can use the position (x,y), x=0,1,2,…,M-1;y=0,1,2,…,N-1, in buffer to indicate where to get the support from.

75. Alternatively, the reference position can be denoted as l = y*M+x, l=0,1,…,M*N-1.

76. When the top-left position of a block related to the current CTU is designated (x0,y0), the block vector (BVx,BVy)=(x-x0,y-y0) can be passed to the decoder to indicate where to take the support in the buffer.

77. Alternatively, the block vector (BVx,BVy) can be defined as (x-x0+Tx,y-y0+Ty), where Tx and Ty represent the specified offsets.

78. For any pixel at point (x0, y0) and vector (BVx, BVy), the corresponding support in the buffer can be found at point (x0+BVx, y0+BVy)

- In one example, when the point (x0+BVx, y0+BVy) is outside the buffer, it should be truncated to the boundary.

- Alternatively, when the point (x0+BVx, y0+BVy) is outside the buffer, its reference value is predetermined to be a specified value, for example, the average gray level.

- Alternatively, the reference position is defined as ((x0+BVx) mod M, (y0+BVy) mod N), so that it is always in the buffer.

82. For any pixel (x0, y0) and (BVx, BVy), when the point (x0+BVx, y0+BVy) is outside the buffer, its reference value can be inferred from the values in the buffer.

- In one example, this value is derived from the sample ((x0+BVx) mod M, (y0+BVy) mod N) in the buffer.

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

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

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

87. Certain coordinates outside the buffer range may not be allowed

- In one example, for any pixel at point (x0, y0) relative to the top-left corner of the CTU unit and the block vector (BVx, BVy), there is a constraint on the data bit stream that point y0+BVy must be in the range [0 ,…,N-1].

- In one example, for any pixel at point (x0, y0) relative to the top-left corner of the CTU unit and the block vector (BVx, BVy), there is a constraint on the data bit stream that point x0+BVx must be in the range [0 ,…,M-1].

- In one example, for any pixel at point (x0, y0) relative to the top-left corner of the CTU unit and the block vector (BVx, BVy), there is a constraint on the data bit stream that point y0+BVy must be in the range [0 ,…,N-1] and point x0+BVx must be in the range [0,…,M-1].

91. When a signaled or inferred block vector for one block points to some location outside the buffer, appropriate buffer padding may be applied.

- In one example, the value of any sample outside the buffer is determined using a given value.

- In one example, this value could be 1<<(Bitdepth-1), such as 128 for 8-bit signals and 512 for 10-bit signals.

- In one example, this value could be forwardLUT(m) when ILR reshaping is used. For example m= 1<<(Bitdepth-1).

- Alternatively, the indication of the specified set value may be signaled or indicated in the SPS set/PPS set/sequence header/picture header/slice header/tile header/CTU unit/CU unit level.

- In one example, any sample outside the buffer is defined as the value of the nearest sample in the buffer.

97. The way the support is processed from the buffer may differ in the horizontal direction and the vertical direction, or may differ according to the position of the current block (for example, close to the image border or not).

- In one example, when the point y0+BVy is outside the interval [0, N-1], the sample value at the point (x0+BVx, y0+BVy) is assigned a specified value.

- In one example, when the point x0+BVx is outside the interval [0, M-1], the sample value at the point (x0+BVx, y0+BVy) is assigned a specified value.

- Alternatively, the sample value at point (x0+BVx, y0+BVy) is assigned the value ((x0+BVx)mod M, y0+BVy), which may involve another method for further inference if ((x0+BVx) mod M, y0+BVy) is still outside the buffer.

- Alternatively, the sample value at point (x0+BVx, y0+BVy) is assigned the value (x0+BVx, (y0+BVy) mod N), which may involve another method for further inference if (x0+BVx, ( y0+BVy) mod N) is still outside the buffer.

Block vector representation

102. Each component of a block vector (BVx, BVy) or one of these components can be normalized to some range.

- In one example, the BVx component can be replaced by the (BVx mod M) component.

- Alternatively, the BVx component can be replaced by the ((BVx+X) mod M)-X component, where X is the specified value.

- In one example, X is equal to 64.

- In one example, X is equal to M/2;

- In one example, X is equal to the horizontal coordinate of the block relative to the current CTU.

- In one example, the component BVy can be replaced by the component (BVy mod N).

- Alternatively, the BVy component can be replaced by the ((BVy+Y) mod N)-Y component, where Y is the specified value.

- In one example, Y is 64.

- In one example, Y is equal to N/2;

- In one example, Y is equal to the vertical coordinate of the block relative to the current CTU.

113. Components BVx and BVy may have different normalized ranges.

114. The difference of block vectors (BVDx, BVDy) can be normalized to a certain range.

- In one example, the component BVDx can be replaced by the component (BVDx mod M), where the result of the modulo function (mod) is the remainder.

- Alternatively, the BVDx component can be replaced by the ((BVDx+X) mod M)-X component, where X is the specified value.

- In one example, X is equal to 64.

- In one example, X is equal to M/2;

- In one example, the component BVy can be replaced by the component (BVDy mod N).

- Alternatively, the BVy component can be replaced by the ((BVDy+Y) mod N)-Y component, where Y is the specified value.

- In one example, Y is 64.

- In one example, Y is equal to N/2;

123. The components BVDx and BVDy may have different normalized ranges.

Validity check for block vector

Let's denote the width and height of the buffer for the IBC copy mode as W _buf and H _buf . For a WxH block (this could be a luma block, a chroma block, a CU unit, a TU unit, a 4x4 sub-block, 2x2 or other sub-blocks) starting from a point (X,Y) relative to the top left corner of the image, the following can be applied to report whether the block vector (BVx, BVy) is valid or not. Let W _pic and H _pic denote the width and height of the image and; W _ctu and H _ctu denote the width and height of the CTU unit. The result of the function floor(x) is the largest integer not greater than x. The function isRec(x, y) determines whether the sample at point (x, y) has been reconstructed.

124. A block vector (BVx, BVy) can be set valid even if any reference position is outside the image boundaries.

- In one example, a block vector can be set to real even if X+BVx < 0.

- In one example, a block vector can be set to real even if X+W+BVx > W _pic .

- In one example, a block vector can be set to real even if Y+BVy < 0.

- In one example, a block vector can be set to real even if Y+H+BVy > H _pic .

129. A block vector (BVx, BVy) can be set as valid even if any reference position is outside the current line of CTU units.

- In one example, a block vector can be set to real even if Y+BVy<floor(Y/ H _ctu )* H _ctu .

- In one example, a block vector can be set to real even if Y+H+BVy>=floor(Y/ H _ctu )*H _ctu + H _ctu .

132. A block vector (BVx, BVy) can be set as valid even if any reference position is outside the current and (n-1) left CTUs, where n denotes the number of CTUs (including or excluding the current CTU), which can be used as a reference area for the IBC copy mode.

- In one example, a block vector can be set to real even if X+BVx<floor(X/W _ctu )* W _ctu - (n-1)* W _ctu .

- In one example, a block vector can be set to real even if X+W+BVx > floor(X/W _ctu )* W _ctu + W _ctu

135. A block vector (BVx, BVy) can be set to be valid even if a particular sample has not yet been reconstructed.

- In one example, a block vector can be set to real even if the function isRec(X+BVx, Y+ BVy) is false.

- In one example, a block vector can be set to real even if the function isRec(X+BVx +W-1, Y+BVy) is false.

- In one example, a block vector can be set to real even if the function isRec(X+BVx, Y+BVy +H-1) is false.

- In one example, a block vector can be set to real even if the function isRec(X+BVx +W-1, Y+BVy +H-1) is false.

140. A block vector (BVx, BVy) can always be set to valid when the block is not the 1st CTU in a row of CTUs.

- Alternatively, the block vector can be set to always real.

142. A block vector (BVx, BVy) can always be set as valid when the following 3 conditions are satisfied

- X + BVx >= 0

- Y + BVy >= floor(Y / H _ctu )

- isRec(X + BVx + W - 1, Y + BVy + H - 1) == true (true)

- Alternatively, when all three conditions are satisfied for the 1st CTU block in a row of CTUs, the block vector can be set to always be valid.

144. When a block vector (BVx, BVy) is valid, copying samples for the corresponding block can be based on this block vector.

- In one example, the prediction of the sample (X, Y) can be carried out from ((X+BVx)%W _buf , (Y+BVy)%H _buf )

Buffer update

146. When encoding a new image or tile, the buffer may be reset.

- The term "reset" can mean that the buffer is being initialized.

- The term "reset" can mean that all samples/pixels in the buffer are assigned a given value (eg 0 or -1).

149. Upon completion of encoding of a VPDU, the buffer may be updated with the reconstructed values of that VPDU.

150 When encoding of a CTU is completed, the buffer may be updated with the reconstructed values of that CTU.

- In one example, when the buffer is not completely full, this buffer can be updated sequentially one CTU unit after another.

- In one example, when the buffer is completely full, the buffer area corresponding to the oldest CTU will be updated.

- In one example, when M=mW and N=H (W and H denote CTU unit sizes; M and N denote buffer sizes) and the previously updated area starts at (kW, 0), the next starting position for update will be (( k+1)W mod M, 0).

154. A buffer flush can occur at the beginning of each line of CTUs.

- Alternatively, a buffer flush may occur at the start of decoding of each CTU.

- Alternatively, a buffer flush can be performed at the start of decoding one tile.

- Alternatively, a buffer flush can be performed at the start of decoding one group of tiles/image.

158. When encoding of a block starting at point (x,y) is completed, the corresponding buffer region starting at that point (x,y) will be updated with the reconstructed data of that block.

- In one example, the (x,y) coordinates indicate a position relative to the top-left corner of the CTU.

160. When encoding of a block relative to an image is completed, the corresponding buffer area will be updated with the reconstructed data of that block.

- In one example, the value at position (x mod M, y mod N) in the buffer can be updated with the reconstructed pixel value at position (x, y) relative to the top-left corner of the image.

- In one example, the value at position (x mod M, y mod N) in the buffer can be updated with the reconstructed pixel value at position (x, y) relative to the top-left corner of the current tile.

- In one example, the value at position (x mod M, y mod N) in the buffer can be updated with the reconstructed pixel value at position (x, y) relative to the top-left corner of the current string of CTUs.

- In one example, the value in the buffer may be updated with the reconstructed pixel values after bit depth alignment.

165. When encoding of a block starting at point (x,y) is completed, the corresponding buffer region starting at point (xb,yb) will be updated with the reconstructed data of that block, where (xb, yb) and (x, y) are different coordinates

- In one example, the coordinates (x,y) represent the position relative to the top-left corner of the CTU, and the coordinates (xb, yb) are equal to (x+update_x, y+update_y), where the increments update_x and update_y indicate the position being updated in buffer.

167. In the above examples, the reconstructed block values may indicate the reconstructed values before applying filters (eg, a deblocking filter).

- Alternatively, the reconstructed block values may indicate the reconstructed values after applying filters (eg, a deblocking filter).

169. When updating a buffer using reconstructed samples, these reconstructed samples may be first modified before being stored so that the bit depth of the samples may be changed.

- In one example, the buffer is updated with the value of the reconstructed sample after aligning the bit depth of the sample with the bit depth of the buffer.

- In one example, the value in the buffer is updated according to the value {p+[1<<(b-1)]}>>b, where p denotes the value of the reconstructed sample, b denotes the specified bit shift value.

- In one example, the value in the buffer is updated according to the value of clip({p+[1<<(b-1)]}>>b, 0, (1<<bitdepth)-1), where p denotes the value of the reconstructed count, b denotes the specified bit shift value, bitdepth denotes the bit depth of the buffer.

- In one example, the value in the buffer is updated according to the value {p+[1<<(b-1)-1]}>>b, where p denotes the value of the reconstructed sample, b denotes the specified bit shift value.

- In one example, the value in the buffer is updated according to the value of clip({p+[1<<(b-1)-1]}>>b, 0, (1<<bitdepth)-1), where p denotes the value of the reconstructed sample, b denotes the specified bit shift value, bitdepth denotes the bit depth of the buffer.

- In one example, the value in the buffer is updated according to the value of p>>b.

- In one example, the value in the buffer is updated according to the value clip(p>>b, 0, (1<<bitdepth)-1), where bitdepth denotes the bit depth of the buffer.

- In the above examples, the number b may be equal to the bit depth of the reconstructed samples minus the bit depth of the input sample.

178. When using samples from a buffer to generate a prediction, preprocessing may be applied.

- In one example, the predicted value corresponds to p<<b, where p denotes the sample value in the buffer, and b denotes the target value.

- In one example, the predicted value corresponds to clip(p<<b, 0, 1<<bitdepth), where bitdepth denotes the bit value for the reconstructed samples.

- In one example, the predicted value corresponds to (p<<b)+(1<<(bitdepth-1)), where p denotes the value of the sample in the buffer, and b denotes the target value, bitdepth denotes the bit depth for the reconstructed samples.

- In the above examples, the number b may be equal to the bit depth of the reconstructed samples minus the bit depth of the input sample.

183. The buffer may be updated in some specific order.

- In one example, the buffer can be updated sequentially.

- In one example, the buffer may be updated according to the order of the reconstructed blocks.

186. When the buffer is completely full, the samples in the buffer can be replaced with the most recently reconstructed samples.

- In one example, updating of readings can occur on a first-in, first-out basis.

- In one example, the oldest samples may be replaced.

- In one example, samples may be assigned a priority, and replacement may be carried out according to priority.

- In one example, samples can be marked as “long-term”, so that other samples will be replaced first.

- In one example, a flag may be sent along with the block to indicate high priority.

- In one example, a number may be transmitted along with the block to indicate priority.

- In one example, samples from a reconstructed block with some characteristic may be given higher priority so that other samples are replaced first.

- In one example, when the proportion of samples encoded in IBC copy mode is greater than a certain threshold, all samples in that block can be assigned high priority.

- In one example, when the proportion of samples encoded in palette mode is greater than some threshold value, all samples of such a block can be assigned high priority.

- In one example, when the proportion of samples encoded in IBC copy mode or palette mode is greater than a certain threshold, all samples in that block can be assigned high priority.

- In one example, when the proportion of samples encoded in skip-transform mode is greater than a certain threshold value, all samples of such a block can be assigned high priority.

- The specified threshold value may vary according to block size, color component, CTU size.

- The threshold value can be reported as an alarm in the SPS set/PPS set/sequence header/slice header/tile group/tile level/area.

- In one example, the fact that the buffer is completely full may mean that the number of available samples in the buffer is not less than a particular threshold.

- In one example, when the number of available samples in the buffer is not less than 64x64x3 samples of the luminance component, the buffer can be considered completely filled.

Alternative Buffer Combination

202. Instead of always using three previously encoded blocks of size 64x64 each as a reference area, it is proposed to adaptively change this configuration based on the location of the current block (or VPDU).

- In one example, when encoding/decoding a block of size 64x64, the previous 3 blocks of size 64x64 can be used as a reference. Compared to FIG. 2, more kinds of combinations of previous 64×64 blocks can be applied. In fig. Figure 2 shows an example of various combinations of previous 64x64 blocks.

204. Instead of using a z-scan scan order, a vertical scan order may be used.

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

- In one example, when encoding/decoding blocks of size 64x64, the previous 3 blocks of size 64x64 each can be used as a reference. Compared to FIG. 2, more types of encoding/decoding orders of 64x64 blocks can be applied. In fig. Figure 4 shows an example of a different encoding/decoding order for 64x64 blocks.

- Alternatively, the methods above can only be applied to encode screen content

- Alternatively, the methods above can only be applied when CPR mode is activated for a single tile/group/tiles/image.

- Alternatively, the methods above can only be applied when CPR mode is enabled for one CTU or one row of CTUs.

Virtual buffer for IBC copy mode

In the following, the width and height of the VPDU unit are designated as W _VPDU (eg, 64) and H _VPDU (eg, 64), respectively, in luminance component counts. Alternatively, the W _VPDU and/or H _VPDU symbols may indicate the width and/or height of another video unit (eg, a CTU).

210. A virtual buffer may be maintained to monitor the status of the reference area for IBC copy mode.

- In one example, the virtual buffer has a size of m W _VPDU xn H _VPDU .

- In one example, m is 3 and n is 2.

- In one example, the parameters m and/or n may depend on the image resolution, CTU sizes.

- In one example, parameters m and/or n may be signaled or preset.

- In one example, the techniques described in the sections and subsections above can be applied to a virtual buffer.

- In one example, the reading at point (x, y) relative to the top-left corner of the image/slice/tile/brick can be mapped to (x%(mW _VPDU ), y%(nH _VPDU ))

214. An array can be used to track the availability of each sample associated with a virtual buffer.

- In one example, a flag may be associated with a sample in the virtual buffer to specify whether the sample in the buffer can be used as a reference for IBC copy mode or not.

- In one example, each 4x4 block containing luma and chrominance samples may share a flag to indicate whether any samples associated with the block in question can be used as a reference for IBC copy mode or not .

- In one example, an array corresponding to 3x2 VPDUs (eg, each 4x4 block can share the same availability flag) is maintained to track the availability of reference samples for the IBC copy mode.

- In one example, an array corresponding to 4x2 VPDUs (eg, each 4x4 block can share the same availability flag) is maintained to track the availability of reference samples for the IBC copy mode.

219. After decoding of a VPDU or video unit has completed, some samples associated with the virtual buffer may be marked as unavailable for reference in IBC copy mode.

- In one example, which samples may be marked as unavailable depends on the location of the most recently decoded VPDU.

- When one sample is marked as unavailable, prediction from that sample is not allowed.

- Alternatively, other methods (eg using default values) can be further applied to output a predictor to replace the unavailable sample.

223. The position of the most recently decoded VPDU may be recorded to help identify which samples associated with the virtual buffer may be marked as unavailable.

- In one example, at the beginning of decoding a VPDU, some samples associated with the virtual buffer may be marked as unavailable according to the location of the most recently decoded VPDU.

- In one example, if we designate (xPrevVPDU, yPrevVPDU) as the top-left position relative to the top-left corner of the image/slice/tile/brick/other video processing unit from the most recently decoded VPDU, and if yPrevVPDU%(n H _VPDU ) is 0, some positions (x, y) may be marked as unavailable.

- In one example, x may be in the range such that [xPrevVPDU - 2W _VPDU + 2mW _VPDU )% mW _VPDU , ((xPrevVPDU – 2 W _VPDU + 2m W _VPDU )% mW _VPDU )-1+W _VPDU ];

- In one example, y may be in the range such that [yPrevVPDU%(n H _VPDU ), (yPrevVPDU%(n H _VPDU ))-1+H _VPDU ];

- In one example, x may be in the range such that [xPrevVPDU - 2W _VPDU + 2mW _VPDU )% mW _VPDU , ((xPrevVPDU - 2W _VPDU + 2mW _VPDU )% mW _VPDU )-1+W _VPDU ], and y may be in the range such that [yPrevVPDU%(n H _VPDU ), (yPrevVPDU%(n H _VPDU ))-1+H _VPDU ].

- In one example, if we designate (xPrevVPDU, yPrevVPDU) as the top-left position relative to the top-left corner of the image/slice/tile/brick/other video processing unit from the most recently decoded VPDU, and if yPrevVPDU%(n H _VPDU ) is not equal to 0, some positions (x, y) may be marked as unavailable.

- In one example, x may be in the range such that [xPrevVPDU - W _VPDU + 2mW _VPDU )% mW _VPDU , ((xPrevVPDU - W _VPDU + 2mW _VPDU )% mW _VPDU )-1+W _VPDU ];

- In one example, y may be in the range such that [yPrevVPDU%(n H _VPDU ), (yPrevVPDU%(n H _VPDU ))-1+H _VPDU ]

- In one example, x may be in the range such that [xPrevVPDU - W _VPDU + 2mW _VPDU )% mW _VPDU , ((xPrevVPDU - W _VPDU + 2mW _VPDU )% mW _VPDU )-1+W _VPDU ], and y may be in the range such that [yPrevVPDU%(n H _VPDU ), (yPrevVPDU%(n H _VPDU ))-1+H _VPDU ].

233. When a CU contains multiple VPDUs, instead of applying a support availability marking procedure for IBC copy mode according to the VPDU, a support availability marking procedure for IBC copy mode may be performed according to the CU.

- In one example, at the beginning of decoding a CU containing multiple VPDUs, a support availability marking procedure for IBC copy mode may be applied to each VPDU before a VPDU within the CU is decoded.

- In this case, 128x64 and 64x128 blocks may not be valid in IBC copy mode.

- In one example, the pred_mode_ibc_flag for CUs of size 128x64 and 64x128 may not be transmitted and may be set to 0.

237. For a reference block or sub-block, it may not be necessary to check the support availability status for the top-left corner to indicate whether the block vector associated with the reference block is valid or not.

- In one example, only the top-left, bottom-left and bottom-right corners of a block/sub-block need to be checked to report whether the corresponding block vector is valid or not.

239. The buffer size for IBC copy mode may depend on the VPDU unit size (where the width/height ratio is denoted as vSize) and/or the CTB/CTU size (where the width/height ratio is denoted as ctbSize)

- In one example, the buffer height could be equal to ctbSize.

- In one example, the buffer width may depend on min(ctbSize, 64)

- In one example, the buffer width could be (128*128/vSize, min(ctbSize, 64 ))

243. The IBC copy mode buffer may contain values outside the pixel range, indicating that this position may not be available for reference for the IBC copy mode, for example, may not be used to predict other samples.

- The count value can be set to a value indicating that the count is not available.

- In one example, this value could be -1.

- In one example, the specified value may be equal to any value outside the range [0, 1<<(internal_bit_depth) – 1], where internal_bit_depth is a positive integer. For example, the internal_bit_depth parameter denotes the internal bit depth used for encoding/decoding the color component sample.

- In one example, the specified value may be equal to any value outside the range [0, 1<<(input_bit_depth) – 1] where input_bit_depth is a positive integer. For example, input_bit_depth denotes the input bit depth used for encoding/decoding the sample for the color component.

248. The availability marking for samples in the buffer for IBC copy mode may depend on the current block position, current block size, CTU/CTB unit/block size, and VPDU unit size. In one example, let (xCb, yCb) denote the position of the block relative to the top-left corner of the image; the ctbSize parameter represents the size (i.e. width and/or height) of the CTU/CTB unit/block; vSize= min(ctbSize, 64); wIbcBuf and hIbcBuf indicate the width and height of the buffer for IBC copy mode.

- In one example, if parameter (xCb%vSize) is 0 and parameter (yCb%vSize) is 0, a certain set of buffer positions for IBC copy mode may be marked as unavailable.

- In one example, when the current block size is less than the VPDU unit size, i.e. min(ctbSize, 64), the area marked as unreachable can be determined according to the size of the VPDU unit.

- In one example, when the current block size is larger than the VPDU unit size, i.e. min(ctbSize, 64), the area marked as unreachable can be determined according to the size of the CU unit.

252. At the start of decoding of a video unit (eg, VPDU (xV, yV)), the top-left image position corresponding to the positions in the buffer for the IBC copy mode may be assigned a value out of the pixel range.

- In one example, samples in the buffer located at position (x%wIbcBuf, y%hIbcBuf) in the buffer, with x = xV, …,xV+ctbSize-1 and y=yV,…,yV+ctbSize-1, will be assigned the value -1. Here parameters wIbcBuf and hIbcBuf represent the width and height of the buffer for IBC copy mode, parameter ctbSize represents the width of the CTU/CTB unit/block.

- In one example, the hIbcBuf parameter may be equal to the ctbSize parameter.

255. The data bit stream compliance limit can be set according to the sample value in the IBC copy mode buffer

- In one example, if a reference block associated with a block vector in an IBC copy mode buffer contains a value out of the pixel range, the data bit stream may be invalid.

257. The data bit stream compliance limit may be set in accordance with the availability indication in the IBC copy mode buffer.

- In one example, if any of the luminance reference samples mapped to the IBC copy mode buffer for block encoding/decoding is marked as unavailable, the data bit stream may be invalid.

- In one example, when a single tree is used, if any of the luminance reference samples mapped to the IBC copy mode buffer for block encoding/decoding is marked as unavailable, the data bit stream may be invalid.

- The corresponding data bitstream may be such that, for a block encoded in the IBC copy mode, the associated block vector may point to a reference block mapped to the IBC copy mode buffer and each of the luminance reference samples located in the IBC copy mode buffer. copying the IBC for block encoding/decoding must be marked as unavailable, (e.g. sample values are within the range [K0, K1], where, for example, K0 is set to 0 and K1 is set to (1<<BitDepth-1) where BitDepth stands for internal bit depth or input bit depth).

261. Data bitstream compliance constraints may depend on the types of partitioning tree and the type of encoding tree for the current unit

- In one example, if a dual tree is allowed at a high level (eg slice/image/brick/tile) and the current video block (eg CU unit/PU unit/CB unit/PB unit) is encoded using a single tree, Data bit stream constraints may need to check whether all component positions mapped to the IBC copy mode buffer are marked as unavailable or not.

- In one example, if a dual tree is allowed at a high level (e.g., slice/image/brick/tile), and the current video luminance block (e.g., CU/PU/CB/PB) is encoded using dual tree, data bitstream constraints may override the positions of chrominance components mapped to the IBC copy mode buffer, whether they are marked as unavailable or not.

- Alternatively, in such a case, the data bit stream constraints may still check all component positions mapped to the IBC copy mode buffer to see if they are marked as unavailable or not.

- In one example, if a single tree is used, the data bitstream constraints may override the positions of chrominance components mapped to the IBC copy mode buffer, whether they are marked as unavailable or not.

Improvements to today's VTM standard

266. Prediction for IBC copy mode may have lower accuracy than reconstruction.

- In one example, the predicted value is determined according to the value clip{{p+[1<<(b-1)]}>>b,0,(1<<bitdepth)-1}<<b, where p denotes the value of the reconstructed sample, b denotes the specified bit shift value, bitdepth denotes the bit depth of the predicted sample.

- In one example, the predicted value is determined according to the value clip{{p+[1<<(b-1)-1]}>>b,0,(1<<bitdepth)-1}<<b, where p denotes the reconstructed sample value, b denotes the specified bit shift value.

- In one example, the predicted value is determined according to the value ((p>>b)+(1<<(bitdepth-1)))<<b, where bitdepth denotes the bit depth of the predicted sample.

- In one example, the predicted value is determined according to the value of (clip((p>>b),0,(1<<(bitdepth-b)))+(1<<(bitdepth-1)))<< b, where bitdepth denotes the bit depth of the predicted sample.

- In one example, the forecast value is truncated in different ways depending on whether ILR reformation is applied or not.

- In the examples above, b may be equal to the bit depth of the reconstructed samples minus the bit depth of the input samples.

- In one example, the bit depth or difference of bit depths compared to the output bit depth/input bit depth/internal bit depth may be signaled in the SPS set/PPS set/sequence header/picture header/slice header/group header tiles/tile title or other types of video data units.

267. Part of the IBC copy mode prediction may have lower accuracy, while another part has the same accuracy as reconstruction.

- In one example, the valid reference region may contain samples with different accuracies (eg, bit depth).

- In one example, a support from 64x64 blocks other than the 64x64 block currently being decoded has low accuracy, but a support from the current 64x64 block has the same accuracy as the reconstruction.

- In one example, a reference from CTUs other than the currently decoded CTU has low accuracy, and a reference from the current CTU has the same accuracy as the reconstruction.

- In one example, a support from a certain group of color components has low accuracy, and a support from other color components has the same accuracy as the reconstruction.

268. When the CTU is of size MxM and the size of the reference area is nMxnM, the reference area is the nearest available nxn CTU in the string of CTUs.

- In one example, when the reference area size is 128x128 and the CTU size is 64x64, the nearest available 4 CTUs in the CTU row can be used as the reference for IBC copy mode.

- In one example, when the reference area size is 128x128 and the CTU size is 32x32, the nearest available 16 CTUs in the CTU row can be used as the reference for IBC copy mode.

269. When the CTU size is M and the size of the reference region is nM, the reference region is the nearest available n-1 CTUs in the CTU string/tile.

- In one example, when the reference area size is 128x128 or 256x64 and the CTU size is 64x64, the nearest available 3 CTUs in the CTU row can be used as the reference for IBC copy mode.

- In one example, when the reference area size is 128x128 or 512x32 and the CTU size is 32x32, the nearest available 15 CTUs in the CTU row can be used as the reference for IBC copy mode.

270. When the CTU size is M, the VPDU size is kM and the size of the reference area is nM, and the reference area is the nearest available n-k CTUs in the CTU string/tile.

- In one example, the CTU size is 64x64, the VPDU size is also 64x64, the reference area size is 128x128, the nearest 3 CTUs in a row of CTUs can be used as a reference for IBC copy mode.

- In one example, the CTU size is 32x32, the VPDU size is 64x64, the reference area size is 128x128, the nearest (16-4)=12 CTUs in a string of CTUs can be used as a reference for IBC copy mode.

271. For a block of size w x h and top-left corner at (x, y) using IBC copy mode, there are constraints that keep the reference block out of some region for memory reuse, where w and h denote the width and height of the current block.

- In one example, when the CTU size is 128x128 and (x, y)=(m x 64,n x 64), the reference block cannot overlap a 64x64 area starting from ((m-2)x64, n x 64) .

- In one example, when the CTU size is 128x128, the reference block cannot overlap a w x h block with a top-left corner at (x-128, y).

- In one example, when the CTU size is 128x128, the point (x+BVx, y+BVy) cannot be within a block of size w*h with the top-left corner at the point (x-128, y) where BVx and BVy denote the block vector for the current block.

- In one example, when the CTU size is M x M and the IBC copy mode buffer size is k x M x M, the reference block cannot overlap a block of size w x h with the top-left corner at (x-k x M, y ), where BVx and BVy denote the block vector for the current block.

- In one example, when the CTU size is M x M and the IBC copy mode buffer size is k x M x M, the point (x+BVx, y+BVy) cannot be within a block of size w x h with top-left angle at (x-k x M, y), where BVx and BVy denote the block vector for the current block.

272. When the CTU size is not M x M and the size of the reference area is nM x nM, the reference area is the nearest available nxn-1 CTUs in the string of CTUs.

- In one example, when the reference area size is 128x128 and the CTU size is 64x64, the nearest available 3 CTUs in the CTU row can be used as the reference for IBC copy mode.

- In one example, when the reference area size is 128x128 and the CTU size is 32x32, the nearest available 15 CTUs in the CTU row can be used as the reference for IBC copy mode.

273. For a CU unit within a block of size 64x64, starting from (2m*64, 2n*64), i.e. top-left 64x64 block in a 128x128 CTU, the predicted region in IBC copy mode can be composed of reconstructed samples in a 64x64 block starting from ((2m-2)*64, 2n*64), a 64x64 block starting from ((2m-1)*64, 2n*64), a 64x64 block starting from ((2m-1)*64, (2n+1)*64), and in the current 64x64 block.

274. For a CU within a 64x64 block, starting from ((2m+1)*64, (2n+1)*64), i.e. lower-right 64x64 block in a 128x128 CTU, the forecast area in IBC copy mode can be composed of the current 128x128 CTU.

275. For a CU within a 64x64 block, starting from ((2m+1)*64, 2n*64), i.e. top-right 64x64 block in a 128x128 CTU, the predicted region in IBC copy mode can be composed of reconstructed samples in a 64x64 block starting from ((2m-1)*64, 2n*64), a 64x64 block starting from ((2m-1)*64, (2n+1)*64), a 64x64 block starting from (2m*64, 2n*64), and in the current 64x64 block.

- Alternatively, if the current 64x64 block starting from (2m*64, (2n+1)*64) was reconstructed, the predicted region in IBC copy mode can be composed of the reconstructed samples in the 64x64 block starting from ( (2m-1)*64, 2n*64), a 64x64 block starting from (2m*64, 2n*64), a 64x64 block starting from (2m*64, (2n+1)*64), and in the current block size 64x64.

276. For a CU unit within a block of size 64x64, starting from (2m*64, (2n+1)*64), i.e. bottom-left 64x64 block in a 128x128 CTU, the predicted region in IBC copy mode can be composed of reconstructed samples in a 64x64 block starting from ((2m-1)*64, (2n+1)*64), block size 64x64, starting from (2m*64, 2n*64); block of size 64x64, starting from ((2m+1)*64, 2n*64), and in the current block of size 64x64.

- Alternatively, if the current 64x64 block starting from ((2m+1)*64, 2n*64) has not been reconstructed, the predicted region in IBC copy mode can be composed of the reconstructed samples in the 64x64 block starting from ((2m-1)*64, 2n*64), block size 64x64, starting from ((2m-1)*64, (2n+1)*64), block size 64x64, starting from (2m*64, 2n *64), and in the current block size 64x64.

277. It is proposed to adjust the reference area based on which 64x64 blocks the current CU belongs to.

- In one example, for a CU unit starting from (x,y), when (y>>6)&1 == 0, two or up to two preceding 64x64 blocks starting from ((x>>6<<6 )-128, y>>6<<6) and ((x>>6<<6)-64, y>>6<<6), can be reference in IBC copy mode.

- In one example, for a CU unit starting from (x,y) when (y>>6)&1 == 1, one preceding block of size 64x64 starting from ((x>>6<<6)-64 , y>>6<<6), can be a reference in IBC copy mode.

278. For a block starting from a point (x,y), and with a block vector (BVx, BVy), if isRec(((x+BVx)>>6<<6)+128-(((y+BVy) >>6)&1)*64+(x%64), ((y+BVy)>>6<<6) +(y%64)) is true, this block vector is invalid.

- In one example, the block in question is a luminance component block.

- In one example, the block in question is a chrominance block in 4:4:4 format.

- In one example, the block in question contains both luma and chrominance components.

279. For a chroma block in 4:2:0 format, starting from (x,y), and with a block vector (BVx, BVy), if isRec(((x+BVx)>>5<<5)+64 -(((y+BVy)>>5)&1)*32+(x%32), ((y+BVy)>>5<<5) +(y%32)) is true, this block vector is invalid .

280. Determining whether the BV vector is invalid or not for a component block c may rely on the availability of X component samples, instead of checking only the luminance component sample.

- For a block of component c, starting at point (x,y), and with a block vector (BVx, BVy), if isRec(c, ((x+BVx)>>6<<6)+128-(((y +BVy)>>6)&1)*64+(x%64), ((y+BVy)>>6<<6) +(y%64)) is true, this block vector can be considered invalid.

- In one example, the block in question is a luminance component block (eg, c is the luminance component or green (G) component for RGB encoding).

- In one example, the block in question is a 4:4:4 chrominance block (eg, c is the cb or cr component, or the blue/red (B/R) component in RGB encoding).

- In one example, you can check the availability of samples for both luminance and chrominance components, for example, the block in question contains both luminance and chrominance components

- For a chroma block in 4:2:0 format, starting from the point (x,y) of the c component, and with a block vector (BVx, BVy), if isRec(c, ((x+BVx)>>5<< 5)+64-(((y+BVy)>>5)&1)*32+(x%32), ((y+BVy)>>5<<5) +(y%32)) is true, this block vector can be considered invalid.

- For a block or sub-block of a chroma component, starting from the point (x, y) of the component c, and with a block vector (BVx, BVy), if isRec(c, x+BVx+Chroma_CTU_size, y) for the chroma component is true, that block the vector can be considered invalid, where the Chroma_CTU_size parameter is the CTU unit size for the chroma component.

- In one example, for a 4:2:0 format, the Chroma_CTU_size parameter can be equal to 64.

- In one example, the chrominance subblock may be a 2x2 block in a 4:2:0 format.

- In one example, the chrominance subblock may be a 4x4 block in a 4:4:4 format.

- In one example, a chrominance subblock may correspond to a minimum size CU in the luma component.

- Alternatively, the chrominance subblock may correspond to a minimum size CU for the chrominance component.

281. For all sections above, it is assumed that the reference buffer contains several blocks of size MxM (M=64). However, this can be extended to other cases, such as when the reference buffer contains multiple NxM blocks (e.g. N=128, M=64).

282. For all sections above, additional restrictions may apply that the reference buffer must be within the same brick/tile/group of tiles/slice as the current block.

- In one example, if part of the reference buffer is outside the current brick/tile/tile group/slice, the IBC copy mode may not be activated. Signaling of syntax elements related to IBC copy mode may be skipped.

- Alternatively, if part of the reference buffer is outside the current brick/tile/tilegroup/slice, IBC copy mode can still be enabled for one block, however the block vector associated with that one block can only point to the remaining reference buffer.

283. It is proposed to have K1 of the most recently encoded VPDUs, if available, in the 1st VPDU line from the CTU/CTB line and K2 of the most recently encoded VPDUs, if available, in the 2nd VPDU line from the units line. /CTU/CTB as the reference area for IBC copy mode excluding the current VPDU.

- In one example, K1 is 2 and K2 is 1.

- In one example, the above methods can be applied when the CTU/CTB unit/block size is 128x128 and the VPDU unit size is 64x64.

- In one example, the above methods can be applied when the CTU/CTB unit size is 64x64 and the VPDU unit size is 64x64 and/or 32x32.

- In one example, the above methods can be applied when the CTU/CTB unit size is 32x32 and the VPDU unit size is 32x32 or less.

49. The above methods can be applied at different stages.

- In one example, a modulo operation (eg, a mod b) of block vectors (BVs) may be invoked in a BV availability test procedure to decide whether such a BV is valid or not.

- In one example, a modulo operation (eg, a mod b) of block vectors (BV) can be used to identify the location of a reference sample (eg, in accordance with the modulo operation of the results of determining the position of the current sample and the BV vector) in in the virtual buffer for the IBC copy mode or in the buffer for the reconstructed image (for example, before the in-loop filtering procedure).

5. Options

5.1 Option #1

Below is a description of the buffer implementation for IBC copy mode:

The buffer size is 128x128. The CTU unit size is also 128x128. To encode the 1st CTU in a line of CTUs, the buffer is initialized to 128 (for an 8-bit video signal). To encode the kth CTU in a string of CTUs, the buffer is initialized with the reconstructed data before loop filtering the (k-1)th CTU.

Fig. 3 shows an example of encoding a block starting from a point with coordinates (x,y).

When encoding a block starting at point (x,y) associated with the current CTU, a block vector (BVx, BVy) = (x-x0, y-y0) is sent to the decoder to indicate that the reference block starts at point (x0, y0) in the buffer for IBC copy mode. Let's assume that the width and height of the block are w and h, respectively. After block encoding is completed, the wxh region starting at point (x,y) in the IBC copy mode buffer will be updated with the reconstructed block data before loop filtering.

5.2 Option #2

In fig. Figure 4 shows examples of possible alternative methods for selecting previously encoded 64x64 blocks.

5.3 Option #3

In fig. 5 shows an example of a possible alternative method for changing the encoding/decoding order of 64x64 blocks.

5.4 Option #4

In fig. 8 shows another possible alternative method for selecting previously encoded 64x64 blocks when the decoding order of the 64x64 blocks is set from top to bottom, left to right.

5.5 Option #5

In fig. 9 shows another possible alternative method for selecting previously encoded 64x64 blocks.

5.6 Option #6

In fig. 11 shows another possible alternative method for selecting previously encoded 64x64 blocks when the decoding order of the 64x64 blocks is set from left to right, top to bottom.

5.7 Option #7

Assuming that the size of the CTU is WxW, then the implementation of a copy mode IBC buffer of size mWxW and bit depth B in the decoder is described below.

At the start of decoding, the CTU strings initialize the buffer using the value (1<<(B-1)) and set the starting point for updating (xb, yb) to (0,0).

When a CU starting at the point (x, y) belonging to the upper-left corner of the CTU and having size wxh is decoded, the area starting at point (xb+x, yb+y) and having size wxh will be updated using the reconstructed pixel values of the CU unit, after aligning the bit depth with B bits.

After decoding the CTU, the starting point for updating (xb, yb) is set to ((xb+W) mod mW, 0).

When decoding a CU encoded in copy-mode IBC with a block vector (BVx, BVy), for any pixel (x, y) belonging to the top-left corner of the CTU, the predicted pixels are extracted from the buffer at position ((x+ BVx) mod mW, (y+BVy) mode W) after matching the bit depth with the bit depth of the predicted signals.

In one example, parameter B is set to 7 or 8, while the block I/O bit depth may be 10.

5.8 Option #8

For a luma CU unit or a combined luma/chrominance CU unit, starting from a point (x,y) related to the top-left corner of the image and a block vector (BVx, BVy), this block vector is invalid when the isRec( function ((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+(x%64), ((y+BVy)>>6<<6 ) +(y%64)) is true.

For a CU unit of chrominance component starting from a point (x,y) related to the top-left corner of the image and a block vector (BVx, BVy), this block vector is invalid when the function isRec(((x+BVx)>> 5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32), ((y+BVy)>>5<<5) +(y%32)) is true.

5.9 Option #9

For a block or subblock of chrominance starting at a 4:2:0 point (x,y) at the top-left corner of the image and a block vector (BVx, BVy), that block vector is invalid when the isRec( function c, (x+BVx+64, y+BVy) is true, where c denotes the chrominance component.

For a block or subblock of chrominance starting from a 4:4:4 point (x,y) at the top-left corner of the image and a block vector (BVx, BVy), that block vector is invalid when the isRec( function c, (x+BVx+128, y+BVy) is true, where c denotes the chrominance component.

5.10 Option #10

For a luma CU unit or a combined luma/chrominance CU unit, starting from a point (x,y) related to the top-left corner of the image and a block vector (BVx, BVy), this block vector is invalid when the isRec( function ((x+BVx)>>6<<6)+128-(((y+BVy)>>6)&1)*64+(x%64), ((y+BVy)>>6<<6 ) +(y%64)) is true.

For a block or subblock of chrominance starting from a 4:2:0 point (x,y) at the top-left corner of the image and a block vector (BVx, BVy), that block vector is invalid when the isRec( function c, ((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32), ((y+BVy)>>5< <5) +(y%32)) is true, where c denotes the chrominance component.

5.11 Option #11

This option focuses on an implementation supporting the two most recently encoded VPDUs in the 1st VPDU row and one of the most recently encoded VPDUs in the 2nd VPDU row from the CTU/CTB row, excluding the current VPDU.

When VPDUs are encoded in top-to-bottom and left-to-right order, the reference region is illustrated in FIG. 13.

When VPDUs are encoded in left-to-right and top-to-bottom order, and the current VPDU is not located to the right of the image boundary, the corresponding reference region is illustrated in FIG. 14.

When VPDUs are encoded in left-to-right and top-to-bottom order, and the current VPDU is to the right of the image boundary, the corresponding reference region is illustrated in FIG. 15.

Given a luminance component block (x, y) of size wxh, one can tell whether the block vector (BVx, BVy) is valid or not by checking the following condition:

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

If the result of the above function is true, the block vector is invalid (BVx, BVy), otherwise the block vector can be valid.

5.12 Option #12

If the CTU is 192x128 in size, a 192x128 virtual buffer is maintained to track reference samples for IBC copy mode.

The reference (x, y) relative to the top-left corner of the image is associated with the position (x%192, y%128) relative to the top-left corner of the buffer. The following steps show how to mark the availability of samples associated with the virtual buffer for the reference region for IBC copy mode.

The position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the image is recorded as the top-left sample from the most recently decoded VPDU.

1. At the start of decoding a string of VPDUs, all buffer positions are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0,0).

2. At the start of decoding the 1st CU from the VPDU, position (x, y) with x = (xPrevVPDU - 2WVPDU+ 2mWVPDU)%(mWVPDU), .., ((xPrevVPDU - 2WVPDU+ 2mWVPDU)% (mWVPDU))- 1+WVPDU; and y = yPrevVPDU%(nHVPDU), .., (yPrevVPDU%(nHVPDU))-1+HVPDU can be marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), i.e. the top left position of the specified CU relative to the image.

3. After decoding the CU unit, position (x, y) with x = xCU%(mWVPDU), ..., (xCU+CU_width-1)%(mWVPDU) and y = yCU%(nHVPDU),…,(yCU +CU_height-1)%(nHVPDU) is marked as unavailable.

4. For a CU unit encoded in IBC copy mode, with a block vector (xBV, yBV), if any position (x, y) with x = (xCU+xBV)%(mWVPDU), ..., ( xCU+xBV+CU_width-1)%(mWVPDU) and y = (yCU+yBV)%(nHVPDU),…,(yCU+yBV+CU_height-1)%(nHVPDU) are marked as unavailable, the block vector is considered invalid.

In fig. 16 shows the buffer status along with the decoding status of VPDUs in a picture.

5.13 Option #13

If the CTU size is 128x128 or the CTU size is larger than the specified VPDU size (eg, 64x64 in the current embodiment) or the CTU size is larger than the VPDU size (eg, 64x64 in the current embodiment), maintain a 192x128 virtual buffer to track reference samples for IBC copy mode. Subsequently, when a < 0, (a % b) is defined as the function floor(a/b)*b, where the result of the function floor(c) is the largest integer not greater than c.

The reference (x, y) relative to the top-left corner of the image is associated with the position (x%192, y%128) relative to the top-left corner of the buffer. The following steps show how to mark the availability of samples associated with a virtual buffer for the IBC copy mode reference region.

The position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the image is recorded as the top-left sample from the most recently decoded VPDU.

1. At the start of decoding a string of VPDUs, all positions in the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0,0).

2. At the start of decoding the 1st CU from the VPDU,

- If parameter yPrevVPDU%64 is 0, positions (x, y) with x = (xPrevVPDU – 128)%192, .., ((xPrevVPDU – 128)%192) + 63; and y = yPrevVPDU%128, .., (yPrevVPDU%128)+63, are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), i.e. top-left position of the CU unit relative to the image.

- Otherwise, positions (x, y) with x = (xPrevVPDU – 64)%192, .., ((xPrevVPDU – 64)%192) + 63; and y = yPrevVPDU%128, .., (yPrevVPDU%128)+63, are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), i.e. top-left position of the CU unit relative to the image.

5. After decoding the CU unit, position (x, y) with x = xCU%192, ..., (xCU+CU_width-1)%192 and y = yCU%128,…,(yCU+CU_height-1)% 128 are marked as unavailable.

6. For a CU unit encoded in IBC copy mode, with a block vector (xBV, yBV), if any position (x, y) with x = (xCU+xBV)%192, ..., (xCU+ xBV+CU_width-1)%192 and y = (yCU+yBV)%128,…,(yCU+yBV+CU_height-1)%128 are marked as unavailable, the block vector is considered invalid.

If the CTU size is SxS, S is not equal to 128, let Wbuf be equal to 128*128/S. A virtual buffer of size WbufxS is then maintained to track reference samples for IBC copy mode. The size of the VPDU unit in this case is equal to the size of the CTU unit.

The position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the image is recorded as the top-left sample from the most recently decoded VPDU.

1. At the start of decoding a string of VPDUs, all positions in the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0,0).

2. At the start of decoding the 1st CU from the VPDU, position (x, y) with x = (xPrevVPDU – W _buf *S)%S, .., ((xPrevVPDU – W _buf *S)%S) + S - 1; and y = yPrevVPDU%S, .., (yPrevVPDU%S) + S -1; marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), i.e. top-left position of the CU unit relative to the image.

3. After decoding the CU unit, position (x, y) with x = xCU%(W _buf ), ..., (xCU+CU_width-1)%(W _buf ) and y = yCU%S,…,(yCU +CU_height-1)%S is marked as accessible.

4. For a CU unit encoded in IBC copy mode, with a block vector (xBV, yBV), if any position (x, y) with x = (xCU+xBV)%(Wbuf), ..., ( xCU+xBV+CU_width-1)%(Wbuf) and y = (yCU+yBV)%S,…,(yCU+yBV+CU_height-1)%S are marked as unavailable, the block vector is considered invalid.

5.14 Option #14

If the CTU size is 128x128 or the CTU size is larger than the VPDU size (for example, 64x64 in today's release) or the CTU size is larger than the VPDU size (for example, 64x64 in today's release), then maintain a 256x128 virtual buffer to track the reference samples for mode with IBC copying. Subsequently, when a < 0, (a % b) is defined as the function floor(a/b)*b, where the result of the function floor(c) is the largest integer not greater than c.

The reference (x, y) relative to the top-left corner of the image is associated with the position (x%256, y%128) relative to the top-left corner of the buffer. The following steps show how to mark the availability of samples associated with a virtual buffer for the IBC copy mode reference region.

The position (xPrevVPDU, yPrevVPDU) relative to the top-left corner of the image is recorded as the top-left sample from the most recently decoded VPDU.

1. At the start of decoding a string of VPDUs, all positions in the buffer are marked as unavailable. (xPrevVPDU, yPrevVPDU) is set to (0,0).

2. At the start of decoding the 1st CU from the VPDU,

- If yPrevVPDU%64 is 0, positions (x, y) with x = (xPrevVPDU – 128)%256, .., ((xPrevVPDU – 128)% 256) + 63; and y = yPrevVPDU%128, .., (yPrevVPDU%128)+63, are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), i.e. top-left position of the CU unit relative to the image.

- Otherwise, positions (x, y) with x = (xPrevVPDU – 64)% 256, .., ((xPrevVPDU – 64)% 256) + 63; and y = yPrevVPDU%128, .., (yPrevVPDU%128)+63, are marked as unavailable. Then (xPrevVPDU, yPrevVPDU) is set as (xCU, yCU), i.e. top-left position of the CU unit relative to the image.

5. After decoding the CU unit, position (x, y) with x = xCU%256, ..., (xCU+CU_width-1)%256 and y = yCU%128,…,(yCU+CU_height-1)% 128 are marked as available.

6. For a CU unit encoded in IBC copy mode, with a block vector (xBV, yBV), if any position (x, y) with x = (xCU+xBV)%256, ..., (xCU+ xBV+CU_width-1)%256 and y = (yCU+yBV)%128,…,(yCU+yBV+CU_height-1)%128 are marked as unavailable, the block vector is considered invalid.

When the CTU size is not 128x128 or less than 64x64 or less than 64x64, the same procedure as in the previous embodiment is applied, i.e. option #14.

5.15 Option #15

The procedure for marking the availability of a reference region for IBC copy mode is described as follows. In this document, changes are indicated in bold italics with underlining.

7.3.7.1 General data slice syntax

slice_data() { Descriptor for( i = 0; i < NumBricksInCurrSlice; i++ ) { CtbAddrInBs = FirstCtbAddrBs[ SliceBrickIdx[ i ] ] for( j = 0; j < NumCtusInBrick[ SliceBrickIdx[ i ] ]; j++, CtbAddrInBs++ ) { if( ( j % BrickWidth[ SliceBrickIdx[ i ] ] ) = = 0 ) { NumHmvpCand = 0 NumHmvpIbcCand = 0 xPrevVPDU = 0 yPrevVPDU = 0 if( CtbSizeY == 128 ) reset_ibc_isDecoded(0, 0, 256, CtbSizeY, BufWidth, BufHeight) else reset_ibc_isDecoded(0, 0, 128*128/CtbSizeY, CtbSizeY, BufWidth, BufHeight) } CtbAddrInRs = CtbAddrBsToRs[ CtbAddrInBs ] …… reset_ibc_isDecoded(x0, y0, w, h, BufWidth, BufHeight) { Descriptor if( x0 >= 0) for (x = x0 % BufWidth; x < x0 + w; x+=4) for (y = y0 % BufHeight; y < y0 + h; y+=4) isDecoded[ x >> 2 ][ y >> 2 ] = 0 }

The BufWidth parameter is equal to (CtbSizeY==128)?256:(128*128/CtbSizeY) and the BufHeight parameter is equal to CtbSizeY.

7.3.7.5 Coding unit syntax

coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descriptor if( treeType != DUAL_TREE_CHROMA && ( CtbSizeY = = 128 ) && (x0 % 64) = = 0 && (y0 % 64) = = 0 ) { for( x = x0; x < x0 + cbWidth; x += 64 ) for( y = y0; y < y0 + cbHeight; y += 64 ) if( ( yPrevVPDU % 64 ) = = 0 ) reset_ibc_isDecoded(xPrevVPDU – 128, yPrevVPDU, 64, 64, BufWidth, BufHeight) else reset_ibc_isDecoded(xPrevVPDU – 64, yPrevVPDU, 64, 64, BufWidth, BufHeight) xPrevVPDU = x0 yPrevVPDU = y0 } if( treeType != DUAL_TREE_CHROMA && ( CtbSizeY < 128 ) && (x0 % CtbSizeY) = = 0 && (y0 % CtbSizeY) = = 0 ) { reset_ibc_isDecoded(xPrevVPDU – (128*128/CtbSizeY – CtbSizeY), yPrevVPDU, 64, 64, BufWidth, BufHeight) xPrevVPDU = x0 yPrevVPDU = y0 } if( slice_type != I | | sps_ibc_enabled_flag ) { if( treeType != DUAL_TREE_CHROMA &&
!( cbWidth = = 4 && cbHeight = = 4 && !sps_ibc_enabled_flag ) ) cu_skip_flag[ x0 ][ y0 ] ae(v) if( cu_skip_flag[ x0 ][ y0 ] = = 0 && slice_type != I
&& !( cbWidth = = 4 && cbHeight = = 4 ) ) pred_mode_flag ae(v) if( ( ( slice_type = = I && cu_skip_flag[ x0 ][ y0 ] = =0 ) | |
( slice_type != I && ( CuPredMode[ x0 ][ y0 ] != MODE_INTRA | |
( cbWidth = = 4 && cbHeight = = 4 && cu_skip_flag[ x0 ][ y0 ] = = 0 ) ) ) &&
sps_ibc_enabled_flag && ( cbWidth != 128 && cbHeight != 128 ) ) pred_mode_ibc_flag ae(v) } ...

8.6.2 Procedure for obtaining motion vector components for blocks in IBC copy mode

8.6.2.1 General

...

The data bitstream compliance requirement is that when the block vector validity procedure of clause 8.6.3.2 is invoked for a block vector mvL, the parameter isBVvalid shall be true.

...

8.6.3 Decoding procedure for blocks encoded in ibc copy mode

8.6.3.1 General

This procedure is used when decoding coding units that have been encoded in block copy prediction (ibc) mode.

The input data for the procedure is:

- position of the luminance component (xCb, yCb), specifying the top-left sample of the current coding block relative to the top-left sample of the luminance component in the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples,

- variables numSbX and numSbY, specifying the number of subblocks for encoding the luminance component in the horizontal and vertical directions,

- motion vectors mv[ xSbIdx ][ ySbIdx ] for xSbIdx = 0 .. numSbX − 1, and ySbIdx = 0 .. numSbY − 1,

- variable cIdx, which specifies the index of the color component for the current block.

- array ibcBuf size (nIbcBufW)x(ctbSize)

...

For each encoding subblock with subblock index ( xSbIdx, ySbIdx ) with xSbIdx = 0 .. numSbX − 1, and ySbIdx = 0 .. numSbY − 1, the following applies:

- The luminance component position (xSb, ySb), specifying the top-left sample of the current encoding subblock relative to the top-left sample of the luminance component in the current image, is determined as follows:

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

If the cIdx parameter is 0, the nIbcBufW parameter is set to ibcBufferWidth, otherwise the nIbcBufW parameter is set to ( ibcBufferWidth / SubWidthC ). The following applies:

predSamples[ xSb + x ][ ySb + y ] = ibcBuf [ ( xSb + x + (mv[ xSb ][ ySb ][ 0 ] >> 4 )) % nIbcRefW ][ ySb + y + (mv[ xSb ][ ySb ][ 1 ] >> 4) ]

for x = 0..sbWidth − 1 and y = 0..sbHeight – 1.

...

8.6.3.2 Procedure for checking the validity of a block vector

The inputs to this procedure are:

- position of the luminance component (xCb, yCb), specifying the top-left sample of the current coding block relative to the top-left sample of the luminance component of the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples,

- variables numSbX and numSbY, specifying the number of subblocks for encoding the luminance component in the horizontal and vertical directions,

- block vectors mv[ xSbIdx ][ ySbIdx ] with xSbIdx = 0 .. numSbX − 1, and ySbIdx = 0 .. numSbY − 1,

- variable cIdx, which specifies the index of the color component for the current block.

- ibcBuf array of size (nIbcBufW)x(ctbSize)

The output of this procedure is the isBVvalid flag to indicate whether the block vector is valid or not.

The following applies

1. The isBVvalid flag is set to true.

2. If ( ( yCb & ( ctbSize – 1 ) ) + mv[ 0 ][ 0 ][ 1 ] + cbHeight ) > ctbSize, the isBVvalid flag is set to false.

3. Otherwise, for each index xSbIdx, ySbIdx of the subblock with xSbIdx = 0 .. numSbX − 1, and ySbIdx = 0 .. numSbY – 1, determine the position of this subblock relative to the upper-left reading of the luminance component of the ibcBuf block:

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

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

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

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

if (isDecoded[ xTL>>2 ][ yTL>>2 ] == 0) or (isDecoded[ xBR>>2 ][ yTL>>2 ] == 0) or (isDecoded[ xBR>>2 ][ yBR> >2 ] == 0), the isBVvalid flag is set to false.

8.7.5 Image reconstruction procedure

8.7.5.1 General

The inputs for this procedure are:

- position ( xCurr, yCurr ), specifying the top-left sample of the current block relative to the top-left component of the current image,

- variables nCurrSw and nCurrSh, specifying the width and height, respectively, of the current block,

- variable cIdx, which specifies the color component of the current block,

- an array of predSamples of size (nCurrSw) x (nCurrSh), specifying the predicted samples of the current block,

- resSamples array of size (nCurrSw) x (nCurrSh), specifying samples of the remainder of the current block.

The output of this procedure is

- recSamples array of reconstructed image samples.

- ibcBuf array of support for IBC copy mode.

...

By denoting nIbcBufW as the width of the ibcBuf array, the following applies:

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

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

5.16 Option #16

This is identical to the previous version except for the following changes

slice_data() { Descriptor for( i = 0; i < NumBricksInCurrSlice; i++ ) { CtbAddrInBs = FirstCtbAddrBs[ SliceBrickIdx[ i ] ] for( j = 0; j < NumCtusInBrick[ SliceBrickIdx[ i ] ]; j++, CtbAddrInBs++ ) { if( ( j % BrickWidth[ SliceBrickIdx[ i ] ] ) = = 0 ) { NumHmvpCand = 0 NumHmvpIbcCand = 0 xPrevVPDU = 0 yPrevVPDU = 0 if( CtbSizeY == 128 ) reset_ibc_isDecoded(0, 0, 192, CtbSizeY, BufWidth, BufHeight) else reset_ibc_isDecoded(0, 0, 128*128/CtbSizeY, CtbSizeY, BufWidth, BufHeight) } CtbAddrInRs = CtbAddrBsToRs[ CtbAddrInBs ] …… reset_ibc_isDecoded(x0, y0, w, h, BufWidth, BufHeight) { Descriptor if( x0 >= 0) for (x = x0 % BufWidth; x < x0 + w; x+=4) for (y = y0 % BufHeight; y < y0 + h; y+=4) isDecoded[ x >> 2 ][ y >> 2 ] = 0 }

The BufWidth parameter is equal to (CtbSizeY==128)?192:(128*128/CtbSizeY) and the BufHeight parameter is equal to CtbSizeY.

5.17 Option #17

Changes in some examples are indicated herein in bold and underlined text.

7.3.7 Data slice syntax

7.3.7.1 General data slice syntax

slice_data() { Descriptor for( i = 0; i < NumBricksInCurrSlice; i++ ) { CtbAddrInBs = FirstCtbAddrBs[ SliceBrickIdx[ i ] ] for( j = 0; j < NumCtusInBrick[ SliceBrickIdx[ i ] ]; j++, CtbAddrInBs++ ) { if( ( j % BrickWidth[ SliceBrickIdx[ i ] ] ) = = 0 ) { NumHmvpCand = 0 NumHmvpIbcCand = 0 resetIbcBuf = 1 } CtbAddrInRs = CtbAddrBsToRs[ CtbAddrInBs ] coding_tree_unit( ) if( entropy_coding_sync_enabled_flag &&
( ( j + 1 ) % BrickWidth[ SliceBrickIdx[ i ] ] = = 0 ) ) { end_of_subset_one_bit /* equal to 1 */ ae(v) if( j < NumCtusInBrick[ SliceBrickIdx[ i ] ] − 1 ) byte_alignment( ) } } if( !entropy_coding_sync_enabled_flag ) { end_of_brick_one_bit /* equal to 1 */ ae(v) if( i < NumBricksInCurrSlice − 1 ) byte_alignment( ) } } }

7.4.8.5 Coding unit semantics

When all the following conditions are true, the list of predictors of traffic vectors based on the background of the predictors of the jointly used list of united candidates is updated by establishing the NumHmvpsmibCCAND parameter equal to the NumHmvpibCCAND parameter, and the establishment of the HMVPSMIBCANDLIST [I] parameter. i] for i = 0..numhmvpibccand − 1:

- IsInSmr[ x0 ][ y0 ] is equal to “TRUE”.

- SmrX[ x0 ][ y0 ] is equal to x0.

- SmrY[ x0 ][ y0 ] is equal to y0.

The following assignments are made for x = x0..x0 + cbWidth − 1 and y = y0..y0 + cbHeight − 1:

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

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

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

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

Setting the vSize parameter to min( ctbSize, 64 ) and the wIbcBuf parameter to (128*128/ctbSize). The width and height of the ibcBuf array are equal to wIbcBuf and ctbSize, respectively.

If refreshIbcBuf is 1, the following applies

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

- resetIbcBuf = 0

When ( x0 % vSize ) is 0 and ( y0 % vSize ) is 0, for x = x0..x0 + vSize − 1 and y = y0..y0 + vSize – 1, the following applies

ibcBuf[ x % wIbcBuf ][ y % ctbSize ] = − 1

8.6.2 Procedure for determining motion vector components for blocks in IBC copy mode

8.6.2.1 General

The inputs to this procedure are:

- position of the brightness component ( xCb, yCb ) of the upper-left sample of the current luminance component encoding block relative to the upper-left sample of the luminance component of the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples.

The output of this procedure is:

- vector mvL of the movement of the brightness component with an accuracy of 1/16 of the count.

This luminance component motion vector mvL is obtained as follows:

- The IBC copy mode luminance motion vector prediction procedure, as specified in clause 8.6.2.2, is invoked using the luminance component position (xCb, yCb), the variables cbWidth and cbHeight as input, and the output is the motion vector mvL brightness component.

- When the general_merge_flag[ xCb ][ yCb ] is 0, the following applies:

1. The mvd variable is defined as follows:

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

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

2. The rounding procedure for motion vectors, as specified in clause 8.5.2.14, is invoked with mvX set equal to mvL, rightShift set equal to MvShift + 2, and leftShift set equal to MvShift + 2 as input, and the rounded vector mvL as output data.

3. The motion vector mvL of the brightness component is modified as follows:

u[ 0 ] = ( mvL[ 0 ] + mvd[ 0 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-885)

mvL[ 0 ] = ( u[ 0 ] >= 2 ¹⁷ ) ? ( u[ 0 ] − 2 ¹⁸ ) : u[ 0 ] (8-886)

u[ 1 ] = ( mvL[ 1 ] + mvd[ 1 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-887)

mvL[ 1 ] = ( u[ 1 ] >= 2 ¹⁷ ) ? ( u[ 1 ] − 2 ¹⁸ ) : u[ 1 ] (8-888)

NOTE 1 – The resulting values of the vectors mvL[ 0 ] and mvL[ 1 ], as specified above, will always be in the range −2 ¹⁷ to 2 ¹⁷ − 1, inclusive.

The procedure for updating the history-based list of motion vector predictors, as specified in clause 8.6.2.6, is applied to the luminance component motion vector mvL.

The data bitstream compliance requirement is that the luma block vector mvL must satisfy the following constraints:

- ((yCb + ( mvL[ 1 ] >> 4 ) ) % wIbcBuf ) + cbHeight not greater than ctbSize

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

8.7.5 Image reconstruction procedure

8.7.5.1 General

The inputs to this procedure are:

- position ( xCurr, yCurr ), specifying the top-left sample of the current block relative to the top-left sample of the current image component,

- variables nCurrSw and nCurrSh, specifying the width and height, respectively, of the current block,

- variable cIdx, which specifies the color component of the current block,

- an array of predSamples of size (nCurrSw) x (nCurrSh), specifying the predicted samples of the current block,

- resSamples array of size (nCurrSw) x (nCurrSh), specifying the remainder samples for the current block.

The output of this procedure is a recSamples array of reconstructed samples and an ibcBuf array in the IBC copy mode buffer.

Depending on the cIdx value for the color component, the following assignments are made:

- If cIdx is 0, the recSamples array corresponds to the S _L array of reconstructed image samples and the function clipCidx1 corresponds to Clip1 _Y .

- Otherwise, if the cIdx parameter is equal to 1, the tuCbfChroma parameter is set to tu_cbf_cb[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cb array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

- Otherwise (parameter cIdx is equal to 2), the parameter tuCbfChroma is set equal to tu_cbf_cr[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cr array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

Depending on the value of the slice_lmcs_enabled_flag, the following applies

- If the slice_lmcs_enabled_flag is 0, a recSamples block of reconstructed samples of size (nCurrSw)x(nCurrSh) at position ( xCurr, yCurr ) is defined as follows

for i = 0..nCurrSw − 1, j = 0..nCurrSh − 1:

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

- Otherwise (slice_lmcs_enabled_flag is 1), the following applies:

- If cIdx is 0, the following applies:

- The procedure for image reconstruction with display of luminance component samples, as specified in article 8.7.5.2, is attracted to the position ( xCurr, yCurr ) of the luminance component, the input data is the width nCurrSw and height nCurrSh of the block, the predSamples array of predicted luminance component samples and the resSamples array of samples the remainder of the brightness component, and the output data is an array of resSamples of reconstructed samples of the brightness component.

- Otherwise (parameter cIdx greater than 0), the image reconstruction procedure with the luminance component-dependent scaling procedure of the chrominance component residual in relation to the chrominance component samples, as specified in clause 8.7.5.3, is involved in the position ( xCurr, yCurr ) of the chrominance component, the input data is the width nCurrSw and the height nCurrSh of the transformation block, the coded block flag for the current chrominance component transformation block tuCbfChroma, the predSamples array of predicted chrominance component samples and the resSamples array of samples of the remainder of the chrominance component, and the output data is the recSamples array of reconstructed chrominance component samples.

After decoding the current encoding unit, the following applies:

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

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

5.18 Option #18

Changes in some examples are indicated herein in bold italics with underlining.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

slice_data() { Descriptor for( i = 0; i < NumBricksInCurrSlice; i++ ) { CtbAddrInBs = FirstCtbAddrBs[ SliceBrickIdx[ i ] ] for( j = 0; j < NumCtusInBrick[ SliceBrickIdx[ i ] ]; j++, CtbAddrInBs++ ) { if( ( j % BrickWidth[ SliceBrickIdx[ i ] ] ) = = 0 ) { NumHmvpCand = 0 NumHmvpIbcCand = 0 resetIbcBuf = 1 } CtbAddrInRs = CtbAddrBsToRs[ CtbAddrInBs ] coding_tree_unit( ) if( entropy_coding_sync_enabled_flag &&
( ( j + 1 ) % BrickWidth[ SliceBrickIdx[ i ] ] = = 0 ) ) { end_of_subset_one_bit /* equal to 1 */ ae(v) if( j < NumCtusInBrick[ SliceBrickIdx[ i ] ] − 1 ) byte_alignment( ) } } if( !entropy_coding_sync_enabled_flag ) { end_of_brick_one_bit /* equal to 1 */ ae(v) if( i < NumBricksInCurrSlice − 1 ) byte_alignment( ) } } }

7.4.8.5 Coding unit semantics

When all the following conditions are true, the list of predictors of traffic vectors based on the background of the predictors of the jointly used list of united candidates is updated by establishing the NumHmvpsmibCCAND parameter equal to the NumHmvpibCCAND parameter, and the establishment of the HMVPSMIBCANDLIST [I] parameter. i] for i = 0..numhmvpibccand − 1:

- IsInSmr[ x0 ][ y0 ] is equal to “TRUE”.

- SmrX[ x0 ][ y0 ] is equal to x0.

- SmrY[ x0 ][ y0 ] equals y0.

The following assignments are made for x = x0..x0 + cbWidth − 1 and y = y0..y0 + cbHeight − 1:

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

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

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

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

Setting the vSize parameter to min( ctbSize, 64 ) and the wIbcBufY parameter to (128*128/CtbSizeY).

ibcBuf _L is an array of width wIbcBufY and height CtbSizeY.

ibcBuf _Cb and ibcBuf _Cr are arrays with width wIbcBufC =(wIbcBufY/SubWidthC) and height (CtbSizeY/SubHeightC), i.e. CtbSizeC.

If resetIbcBuf is 1, the following applies

- ibcBuf _L [ x % wIbcBufY ][ y % CtbSizeY ] = − 1, for x = x0..x0 + wIbcBufY − 1 and y = y0..y0 + CtbSizeY – 1

- ibcBuf _Cb [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0..x0 + wIbcBufC − 1 and y = y0..y0 + CtbSizeC – 1

- ibcBuf _Cr [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0..x0 + wIbcBufC − 1 and y = y0..y0 + CtbSizeC – 1

- resetIbcBuf = 0

When ( x0 % vSizeY ) is 0 and ( y0 % vSizeY ) is 0, the following applies

- ibcBuf _L [ x % wIbcBufY ][ y % CtbSizeY ] = − 1, for x = x0..x0 + vSize − 1 and y = y0..y0 + vSize – 1

- ibcBuf _Cb [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0/SubWidthC..x0/ SubWidthC + vSize/ SubWidthC − 1 and y = y0/SubHeightC..y0/SubHeightC + vSize/SubHeightC – 1

- ibcBuf _Cr [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0/SubWidthC..x0/ SubWidthC + vSize/ SubWidthC − 1 and y = y0/SubHeightC..y0/SubHeightC + vSize/SubHeightC – 1

8.6.2 Procedure for obtaining motion vector components for blocks in IBC copy mode

8.6.2.1 General

The inputs to this procedure are:

- position ( xCb, yCb ) of the upper-left sample of the luminance component of the current luminance component encoding block relative to the upper-left sample of the luminance component of the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples.

The output of this procedure is:

- vector mvL of the movement of the brightness component with an accuracy of 1/16 of the count.

The motion vector mvL of the brightness component is determined as follows:

- The procedure for predicting the motion vector of the luminance component in the IBC copy mode, as specified in clause 8.6.2.2, is drawn from the position ( xCb, yCb ) of the luminance component, the input data for this are the variables cbWidth and cbHeight, and the output data is the motion vector mvL brightness component.

- When the general_merge_flag[ xCb ][ yCb ] is 0, the following applies:

1. The mvd variable is defined as follows:

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

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

2. The rounding procedure for motion vectors, as specified in clause 8.5.2.14, is invoked with mvX set equal to mvL, rightShift set equal to MvShift + 2, and leftShift set equal to MvShift + 2 as input, and the rounded vector mvL as output data.

3. The motion vector mvL of the brightness component is modified as follows:

u[ 0 ] = ( mvL[ 0 ] + mvd[ 0 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-885)

mvL[ 0 ] = ( u[ 0 ] >= 2 ¹⁷ ) ? ( u[ 0 ] − 2 ¹⁸ ) : u[ 0 ] (8-886)

u[ 1 ] = ( mvL[ 1 ] + mvd[ 1 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-887)

mvL[ 1 ] = ( u[ 1 ] >= 2 ¹⁷ ) ? ( u[ 1 ] − 2 ¹⁸ ) : u[ 1 ] (8-888)

NOTE 1 – The resulting values of the vectors mvL[ 0 ] and mvL[ 1 ], as specified above, will always be in the range −2 ¹⁷ to 2 ¹⁷ − 1, inclusive.

The procedure for updating the history-based list of motion vector predictors, as specified in clause 8.6.2.6, is applied to the luminance component motion vector mvL.

Article 8.6.2.5 is invoked with the vector mvL as input and mvC as output.

The data bitstream compliance requirement is that the luma block vector mvL must satisfy the following constraints:

- ((yCb + ( mvL[ 1 ] >> 4 ) ) % CtbSizeY ) + cbHeight is not less than CtbSizeY

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

- If the treeType parameter is SINGLE_TREE, for x = xCb..xCb + cbWidth − 1 and y = yCb..yCb + cbHeight – 1, ibcBuf _Cb [ (x + (mvC[0]>>5)) % wIbcBufC ][ ( y +(mvC[1]>>5)) % CtbSizeC] ] must not be equal to −1.

8.6.3 Decoding procedure for blocks encoded in ibc copy mode

8.6.3.1 General

This procedure is used when decoding coding units that have been encoded in block copy prediction (ibc) mode.

The inputs for this procedure are:

- position ( xCb, yCb ) of the luminance component, specifying the top-left sample of the current coding block relative to the top-left sample of the luminance component in the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples,

- index of the color component for the current block.

- motion vector mv,

- array ibcBuf _L of size (wIbcBufY)x(CtbSizeY), array ibcBuf _Cb of size (wIbcBufC)x(CtbSizeC), array ibcBuf _Cr of size (wIbcBufC)x(CtbSizeC).

The output of this procedure is:

- array of predSamples of predicted samples.

For x = xCb.. xCb+ Width − 1 and y = yCb..yCb + Height − 1, the following applies

If cIdx is 0

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

if cIdx is 1

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

if cIdx is 2

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

8.7.5 Image reconstruction procedure

8.7.5.1 General

The inputs to this procedure are:

- position ( xCurr, yCurr ) specifying the top-left reference of the current block relative to the top-left reference of the current image component,

- variables nCurrSw and nCurrSh, specifying the width and height, respectively, of the current block,

- variable cIdx, which specifies the color component of the current block,

- an array of predSamples of size (nCurrSw) x (nCurrSh), specifying the predicted samples for the current block,

- resSamples array of size (nCurrSw) x (nCurrSh), specifying the remainder samples for the current block.

The output of this procedure is the recSamples array of reconstructed samples and the ibcBuf _L , ibcBuf _Cb , ibcBuf _Cr arrays in the IBC copy mode buffer.

Depending on the cIdx value for the color component, the following assignments are made:

- If cIdx is 0, the recSamples array corresponds to the S _L array of reconstructed image samples and the function clipCidx1 corresponds to Clip1 _Y .

- Otherwise, if the cIdx parameter is equal to 1, the tuCbfChroma parameter is set to tu_cbf_cb[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cb array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

- Otherwise (parameter cIdx is equal to 2), the parameter tuCbfChroma is set equal to tu_cbf_cr[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cr array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

Depending on the value of the slice_lmcs_enabled_flag, the following applies:

- If the slice_lmcs_enabled_flag is 0, a recSamples block of reconstructed samples of size (nCurrSw)x(nCurrSh) at position ( xCurr, yCurr ) is defined as follows

for i = 0..nCurrSw − 1, j = 0..nCurrSh − 1:

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

- Otherwise (slice_lmcs_enabled_flag is 1), the following applies:

- If cIdx is 0, the following applies:

- The procedure for image reconstruction with display of luminance component samples, as specified in article 8.7.5.2, is attracted to the position ( xCurr, yCurr ) of the luminance component, the input data is the width nCurrSw and height nCurrSh of the block, the predSamples array of predicted luminance component samples and the resSamples array of samples the remainder of the brightness component, and the output data is an array of resSamples of reconstructed samples of the brightness component.

- Otherwise (parameter cIdx greater than 0), the image reconstruction procedure with the luminance component-dependent scaling procedure of the chrominance component residual in relation to the chrominance component samples, as specified in clause 8.7.5.3, is involved in the position ( xCurr, yCurr ) of the chrominance component, the input data is the width nCurrSw and the height nCurrSh of the transformation block, the encoded block flag for the current chrominance component transformation block tuCbfChroma, the predSamples array of predicted chrominance component samples and the resSamples array of samples of the remainder of the chrominance component, and the output data is the recSamples array of reconstructed chrominance component samples.

After decoding the current encoding unit, the following may apply:

If cIdx is 0, and if treeType is SINGLE_TREE or DUAL_TREE_LUMA, the following applies

ibcBuf _L [ ( xCurr + i ) % wIbcBufY ][ ( yCurr + j ) % CtbSizeY ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

If cIdx is 1, and if treeType is SINGLE_TREE or DUAL_TREE_CHROMA, the following applies

ibcBuf _Cb [ ( xCurr + i ) % wIbcBufC ][ ( yCurr + j ) % CtbSizeC ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

If cIdx is 2, and if treeType is SINGLE_TREE or DUAL_TREE_CHROMA, the following applies

ibcBuf _Cr [ ( xCurr + i ) % wIbcBufC ][ ( yCurr + j ) % CtbSizeC ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

5.19 Option #19

Changes in some examples are indicated in bold and underlined text throughout this document.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

slice_data() { Descriptor for( i = 0; i < NumBricksInCurrSlice; i++ ) { CtbAddrInBs = FirstCtbAddrBs[ SliceBrickIdx[ i ] ] for( j = 0; j < NumCtusInBrick[ SliceBrickIdx[ i ] ]; j++, CtbAddrInBs++ ) { if( ( j % BrickWidth[ SliceBrickIdx[ i ] ] ) = = 0 ) { NumHmvpCand = 0 NumHmvpIbcCand = 0 resetIbcBuf = 1 } CtbAddrInRs = CtbAddrBsToRs[ CtbAddrInBs ] coding_tree_unit( ) if( entropy_coding_sync_enabled_flag &&
( ( j + 1 ) % BrickWidth[ SliceBrickIdx[ i ] ] = = 0 ) ) { end_of_subset_one_bit /* equal to 1 */ ae(v) if( j < NumCtusInBrick[ SliceBrickIdx[ i ] ] − 1 ) byte_alignment( ) } } if( !entropy_coding_sync_enabled_flag ) { end_of_brick_one_bit /* equal to 1 */ ae(v) if( i < NumBricksInCurrSlice − 1 ) byte_alignment( ) } } }

7.4.8.5 Coding unit semantics

When all the following conditions are true, the list of predictors of traffic vectors based on the background of the predictors of the jointly used list of united candidates is updated by establishing the NumHmvpsmibCCAND parameter equal to the NumHmvpibCCAND parameter, and the establishment of the HMVPSMIBCANDLIST [I] parameter. i] for i = 0..numhmvpibccand − 1:

- IsInSmr[ x0 ][ y0 ] is equal to “TRUE”.

- SmrX[ x0 ][ y0 ] is equal to x0.

- SmrY[ x0 ][ y0 ] is equal to y0.

The following assignments are made for x = x0..x0 + cbWidth − 1 and y = y0..y0 + cbHeight − 1:

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

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

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

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

Setting the vSize parameter to min( ctbSize, 64 ) and the wIbcBufY parameter to (128*128/CtbSizeY).

ibcBuf _L is an array with width wIbcBufY and height CtbSizeY.

ibcBuf _Cb and ibcBuf _Cr are arrays with width wIbcBufC =(wIbcBufY/SubWidthC) and height (CtbSizeY/SubHeightC), i.e. CtbSizeC.

If resetIbcBuf is 1, the following applies

- ibcBuf _L [ x % wIbcBufY ][ y % CtbSizeY ] = − 1, for x = x0..x0 + wIbcBufY − 1 and y = y0..y0 + CtbSizeY – 1

- ibcBuf _Cb [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0..x0 + wIbcBufC − 1 and y = y0..y0 + CtbSizeC – 1

- ibcBuf _Cr [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0..x0 + wIbcBufC − 1 and y = y0..y0 + CtbSizeC – 1

- resetIbcBuf = 0

When ( x0 % vSizeY ) is 0 and ( y0 % vSizeY ) is 0, the following applies

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

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

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

8.6.2 Procedure for obtaining motion vector components for blocks in IBC copy mode

8.6.2.1 General

The inputs to this procedure are:

- position ( xCb, yCb ) of the luminance component of the upper-left sample of the current luminance component encoding block relative to the upper-left sample of the luminance component of the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples.

The output of this procedure is:

- vector mvL of the movement of the brightness component with an accuracy of 1/16 of the count.

The motion vector mvL of the brightness component is determined as follows:

- The procedure for predicting the motion vector of the luminance component in the IBC copy mode, as specified in clause 8.6.2.2, is drawn from the position ( xCb, yCb ) of the luminance component, the input data for this are the variables cbWidth and cbHeight, and the output data is the motion vector mvL brightness component.

- When the general_merge_flag[ xCb ][ yCb ] is 0, the following applies:

1. The mvd variable is defined as follows:

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

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

2. The rounding procedure for motion vectors, as specified in clause 8.5.2.14, is invoked with mvX set equal to mvL, rightShift set equal to MvShift + 2, and leftShift set equal to MvShift + 2 as input, and the rounded vector mvL as output data.

3. The motion vector mvL of the brightness component is modified as follows:

u[ 0 ] = ( mvL[ 0 ] + mvd[ 0 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-885)

mvL[ 0 ] = ( u[ 0 ] >= 2 ¹⁷ ) ? ( u[ 0 ] − 2 ¹⁸ ) : u[ 0 ] (8-886)

u[ 1 ] = ( mvL[ 1 ] + mvd[ 1 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-887)

mvL[ 1 ] = ( u[ 1 ] >= 2 ¹⁷ ) ? ( u[ 1 ] − 2 ¹⁸ ) : u[ 1 ] (8-888)

NOTE 1 – The resulting values of the vectors mvL[ 0 ] and mvL[ 1 ], as specified above, will always be in the range −2 ¹⁷ to 2 ¹⁷ − 1, inclusive.

The procedure for updating the history-based list of motion vector predictors, as specified in clause 8.6.2.6, is applied to the luminance component motion vector mvL.

Article 8.6.2.5 is invoked with the vector mvL as input and mvC as output.

The data bitstream compliance requirement is that the luma block vector mvL must satisfy the following constraints:

- ((yCb + ( mvL[ 1 ] >> 4 ) ) % CtbSizeY ) + cbHeight is not greater than CtbSizeY

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

- If the treeType parameter is SINGLE_TREE, for x = xCb..xCb + cbWidth − 1 and y = yCb..yCb + cbHeight – 1, ibcBuf _Cb [ (x + (mvC[0]>>5)) % wIbcBufC ][ ( y +(mvC[1]>>5)) % CtbSizeC] ] must not be equal to −1.

8.6.3 Decoding procedure for blocks encoded in ibc copy mode

8.6.3.1 General

This procedure is used when decoding coding units that have been encoded in block copy prediction (ibc) mode.

The inputs to this procedure are:

- position ( xCb, yCb ) of the luminance component, specifying the top-left sample of the current coding block relative to the top-left sample of the luminance component in the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples,

- variable cIdx, which specifies the index of the color component for the current block.

- motion vector mv,

- array ibcBuf _L of size (wIbcBufY)x(CtbSizeY), array ibcBuf _Cb of size (wIbcBufC)x(CtbSizeC), array ibcBuf _Cr of size (wIbcBufC)x(CtbSizeC).

The output of this procedure is:

- array of predSamples of predicted samples.

For x = xCb.. xCb+ Width − 1 and y = yCb..yCb + Height − 1, the following applies

if cIdx is 0

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

if cIdx is 1

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

if cIdx is 2

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

8.7.5 Image reconstruction procedure

8.7.5.1 General

The inputs to this procedure are:

- position ( xCurr, yCurr ) specifying the top-left reference of the current block relative to the top-left reference of the current image component,

- variables nCurrSw and nCurrSh, specifying the width and height, respectively, of the current block,

- variable cIdx, which specifies the color component of the current block,

- an array of predSamples of size (nCurrSw) x (nCurrSh), specifying the predicted samples for the current block,

- resSamples array of size (nCurrSw) x (nCurrSh), specifying the remainder samples for the current block.

The output of this procedure is the recSamples array of reconstructed samples and the ibcBuf _L , ibcBuf _Cb , ibcBuf _Cr arrays in the IBC copy mode buffer.

Depending on the cIdx value for the color component, the following assignments are made:

- If cIdx is 0, the recSamples array corresponds to the S _L array of reconstructed image samples and the function clipCidx1 corresponds to Clip1 _Y .

- Otherwise, if the cIdx parameter is equal to 1, the tuCbfChroma parameter is set to tu_cbf_cb[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cb array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

- Otherwise (parameter cIdx is equal to 2), the parameter tuCbfChroma is set equal to tu_cbf_cr[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cr array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

Depending on the value of the slice_lmcs_enabled_flag, the following applies:

- If the slice_lmcs_enabled_flag is 0, a recSamples block of reconstructed samples of size (nCurrSw)x(nCurrSh) at position ( xCurr, yCurr ) is defined as follows

for i = 0..nCurrSw − 1, j = 0..nCurrSh − 1:

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

- Otherwise (slice_lmcs_enabled_flag is 1), the following applies:

- If cIdx is 0, the following applies:

- The procedure for image reconstruction with display of luminance component samples, as specified in article 8.7.5.2, is attracted to the position ( xCurr, yCurr ) of the luminance component, the input data is the width nCurrSw and height nCurrSh of the block, the predSamples array of predicted luminance component samples and the resSamples array of samples the remainder of the brightness component, and the output data is an array of resSamples of reconstructed samples of the brightness component.

- Otherwise (parameter cIdx greater than 0), the image reconstruction procedure with the luminance component-dependent scaling procedure of the chrominance component residual in relation to the chrominance component samples, as specified in clause 8.7.5.3, is involved in the position ( xCurr, yCurr ) of the chrominance component, the input data is the width nCurrSw and the height nCurrSh of the transformation block, the encoded block flag for the current chrominance component transformation block tuCbfChroma, the predSamples array of predicted chrominance component samples and the resSamples array of samples of the remainder of the chrominance component, and the output data is the recSamples array of reconstructed chrominance component samples.

After decoding the current encoding unit, the following may apply:

If cIdx is 0, and if treeType is SINGLE_TREE or DUAL_TREE_LUMA, the following applies

ibcBuf _L [ ( xCurr + i ) % wIbcBufY ][ ( yCurr + j ) % CtbSizeY ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

If cIdx is 1, and if treeType is SINGLE_TREE or DUAL_TREE_CHROMA, the following applies

ibcBuf _Cb [ ( xCurr + i ) % wIbcBufC ][ ( yCurr + j ) % CtbSizeC ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

If cIdx is 2, and if treeType is SINGLE_TREE or DUAL_TREE_CHROMA, the following applies

ibcBuf _Cr [ ( xCurr + i ) % wIbcBufC ][ ( yCurr + j ) % CtbSizeC ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

5.20 Option #20

Changes in some examples are indicated herein in bold italics with underlining.

7.3.7 Slice data syntax

7.3.7.1 General slice data syntax

slice_data() { Descriptor for( i = 0; i < NumBricksInCurrSlice; i++ ) { CtbAddrInBs = FirstCtbAddrBs[ SliceBrickIdx[ i ] ] for( j = 0; j < NumCtusInBrick[ SliceBrickIdx[ i ] ]; j++, CtbAddrInBs++ ) { if( ( j % BrickWidth[ SliceBrickIdx[ i ] ] ) = = 0 ) { NumHmvpCand = 0 NumHmvpIbcCand = 0 resetIbcBuf = 1 } CtbAddrInRs = CtbAddrBsToRs[ CtbAddrInBs ] coding_tree_unit( ) if( entropy_coding_sync_enabled_flag &&
( ( j + 1 ) % BrickWidth[ SliceBrickIdx[ i ] ] = = 0 ) ) { end_of_subset_one_bit /* equal to 1 */ ae(v) if( j < NumCtusInBrick[ SliceBrickIdx[ i ] ] − 1 ) byte_alignment( ) } } if( !entropy_coding_sync_enabled_flag ) { end_of_brick_one_bit /* equal to 1 */ ae(v) if( i < NumBricksInCurrSlice − 1 ) byte_alignment( ) } } }

7.4.8.5 Coding unit semantics

When all the following conditions are true, the list of predictors of traffic vectors based on the background of the predictors of the jointly used list of united candidates is updated by establishing the NumHmvpsmibCCAND parameter equal to the NumHmvpibCCAND parameter, and the establishment of the HMVPSMIBCANDLIST [I] parameter. i] for i = 0..numhmvpibccand − 1:

- IsInSmr[ x0 ][ y0 ] is equal to “TRUE”.

- SmrX[ x0 ][ y0 ] is equal to x0.

- SmrY[ x0 ][ y0 ] is equal to y0.

The following assignments are made for x = x0..x0 + cbWidth − 1 and y = y0..y0 + cbHeight − 1:

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

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

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

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

Setting the vSize parameter to min( ctbSize, 64 ) and the wIbcBufY parameter to (128*128/CtbSizeY).

ibcBuf _L is an array with width wIbcBufY and height CtbSizeY.

ibcBuf _Cb and ibcBuf _Cr are arrays with width wIbcBufC =(wIbcBufY/SubWidthC) and height (CtbSizeY/SubHeightC), i.e. CtbSizeC.

If resetIbcBuf is 1, the following applies

- ibcBuf _L [ x % wIbcBufY ][ y % CtbSizeY ] = − 1, for x = x0..x0 + wIbcBufY − 1 and y = y0..y0 + CtbSizeY – 1

- ibcBuf _Cb [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0..x0 + wIbcBufC − 1 and y = y0..y0 + CtbSizeC – 1

- ibcBuf _Cr [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0..x0 + wIbcBufC − 1 and y = y0..y0 + CtbSizeC – 1

- resetIbcBuf = 0

When ( x0 % vSizeY ) is 0 and ( y0 % vSizeY ) is 0, the following applies

- ibcBuf _L [ x % wIbcBufY ][ y % CtbSizeY ] = − 1, for x = x0..x0 + max(vSize, cbWidth) − 1 and y = y0..y0 + max(vSize, cbHeight)– 1

- ibcBuf _Cb [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0/SubWidthC..x0/ SubWidthC + max(vSize/ SubWidthC, cbWidth) − 1 and y = y0/SubHeightC..y0/SubHeightC + max(vSize/SubHeightC, cbHeight) – 1

- ibcBuf _Cr [ x % wIbcBufC ][ y % CtbSizeC ] = − 1, for x = x0/SubWidthC..x0/ SubWidthC + max(vSize/ SubWidthC, cbWidth) − 1 and y = y0/SubHeightC..y0/SubHeightC + max(vSize/SubHeightC, cbHeight) – 1

8.6.2 Procedure for obtaining motion vector components for blocks in IBC copy mode

8.6.2.1 General

The inputs to this procedure are:

- position ( xCb, yCb ) of the luminance component of the upper-left sample of the current luminance component encoding block relative to the upper-left sample of the luminance component of the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples.

The output of this procedure is:

- vector mvL of the movement of the brightness component with an accuracy of 1/16 of the count.

The motion vector mvL of the brightness component is determined as follows:

- The procedure for predicting the motion vector of the luminance component in the IBC copy mode, as specified in clause 8.6.2.2, is drawn from the position ( xCb, yCb ) of the luminance component, the input data for this are the variables cbWidth and cbHeight, and the output data is the motion vector mvL brightness component.

- When the general_merge_flag[ xCb ][ yCb ] is 0, the following applies:

1. The mvd variable is defined as follows:

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

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

2. The rounding procedure for motion vectors, as specified in clause 8.5.2.14, is invoked with mvX set equal to mvL, rightShift set equal to MvShift + 2, and leftShift set equal to MvShift + 2 as input, and the rounded vector mvL as output.

3. The motion vector mvL of the brightness component is modified as follows:

u[ 0 ] = ( mvL[ 0 ] + mvd[ 0 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-885)

mvL[ 0 ] = ( u[ 0 ] >= 2 ¹⁷ ) ? ( u[ 0 ] − 2 ¹⁸ ) : u[ 0 ] (8-886)

u[ 1 ] = ( mvL[ 1 ] + mvd[ 1 ] + 2 ¹⁸ ) % 2 ¹⁸ (8-887)

mvL[ 1 ] = ( u[ 1 ] >= 2 ¹⁷ ) ? ( u[ 1 ] − 2 ¹⁸ ) : u[ 1 ] (8-888)

NOTE 1 – The resulting values of the vectors mvL[ 0 ] and mvL[ 1 ], as specified above, will always be in the range −2 ¹⁷ to 2 ¹⁷ − 1, inclusive.

The procedure for updating the history-based list of motion vector predictors, as specified in clause 8.6.2.6, is applied to the luminance component motion vector mvL.

Article 8.6.2.5 is invoked with the vector mvL as input and mvC as output.

The data bitstream compliance requirement is that the luma block vector mvL must satisfy the following constraints:

- ((yCb + ( mvL[ 1 ] >> 4 ) ) % CtbSizeY ) + cbHeight is not greater than CtbSizeY

- For x = xCb..xCb + cbWidth − 1 and y = yCb..yCb + cbHeight – 1, ibcBuf _L [ (x + (mvL[0]>>4)) % wIbcBufY ][ ( y +(mvL[ 1]>>4)) % CtbSizeY ] is not more than −1.

8.6.3 Decoding procedure for blocks encoded in ibc copy mode

8.6.3.1 General

This procedure is used when decoding coding units that have been encoded in block copy prediction (ibc) mode.

The inputs to this procedure are:

- position ( xCb, yCb ) of the luminance component, specifying the top-left sample of the current coding block relative to the top-left sample of the luminance component in the current image,

- variable cbWidth, which specifies the width of the current coding block in luminance component samples,

- variable cbHeight, which specifies the height of the current coding block in luminance component samples,

- variable cIdx, which specifies the index of the color component for the current block.

- motion vector mv,

- array ibcBuf _L of size (wIbcBufY)x(CtbSizeY), array ibcBuf _Cb of size (wIbcBufC)x(CtbSizeC), array ibcBuf _Cr of size (wIbcBufC)x(CtbSizeC).

The output of this procedure is:

- array of predSamples of predicted samples.

For x = xCb.. xCb+ Width − 1 and y = yCb..yCb + Height − 1, the following applies

If cIdx is 0

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

if cIdx is 1

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

if cIdx is 2

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

8.7.5 Image reconstruction procedure

8.7.5.1 General

The inputs to this procedure are:

- position ( xCurr, yCurr ) specifying the top-left sample of the current block relative to the top-left sample of the current image component,

- variables nCurrSw and nCurrSh, specifying the width and height, respectively, of the current block,

- variable cIdx, which specifies the color component of the current block,

- an array of predSamples of size (nCurrSw) x (nCurrSh), specifying the predicted samples for the current block,

- resSamples array of size (nCurrSw) x (nCurrSh), specifying the remainder samples for the current block.

The output of this procedure is the recSamples array of reconstructed samples and the ibcBuf _L , ibcBuf _Cb , ibcBuf _Cr arrays in the IBC copy mode buffer.

Depending on the cIdx value for the color component, the following assignments are made:

- If cIdx is 0, the recSamples array corresponds to the S _L array of reconstructed image samples and the function clipCidx1 corresponds to Clip1 _Y .

- Otherwise, if the cIdx parameter is equal to 1, the tuCbfChroma parameter is set to tu_cbf_cb[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cb array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

- Otherwise (parameter cIdx is equal to 2), the parameter tuCbfChroma is set equal to tu_cbf_cr[ xCurr ][ yCurr ], the recSamples array corresponds to the S _Cr array of reconstructed chrominance samples, and the function clipCidx1 corresponds to Clip1 _C .

Depending on the value of the slice_lmcs_enabled_flag, the following applies:

- If the slice_lmcs_enabled_flag is 0, a recSamples block of reconstructed samples of size (nCurrSw)x(nCurrSh) at position ( xCurr, yCurr ) is defined as follows

for i = 0..nCurrSw − 1, j = 0..nCurrSh − 1:

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

- Otherwise (slice_lmcs_enabled_flag is 1), the following applies:

- If cIdx is 0, the following applies:

- The procedure for image reconstruction with display of luminance component samples, as specified in article 8.7.5.2, is attracted to the position ( xCurr, yCurr ) of the luminance component, the input data is the width nCurrSw and height nCurrSh of the block, the predSamples array of predicted luminance component samples and the resSamples array of samples the remainder of the brightness component, and the output data is an array of resSamples of reconstructed samples of the brightness component.

- Otherwise (parameter cIdx greater than 0), the image reconstruction procedure with the luminance component-dependent scaling procedure of the chrominance component residual in relation to the chrominance component samples, as specified in clause 8.7.5.3, is involved in the position ( xCurr, yCurr ) of the chrominance component, the input data is the width nCurrSw and the height nCurrSh of the transformation block, the coded block flag for the current chrominance component transformation block tuCbfChroma, the predSamples array of predicted chrominance component samples and the resSamples array of samples of the remainder of the chrominance component, and the output data is the recSamples array of reconstructed chrominance component samples.

After decoding the current encoding unit, the following may apply:

If cIdx is 0, and if treeType is SINGLE_TREE or DUAL_TREE_LUMA, the following applies

ibcBuf _L [ ( xCurr + i ) % wIbcBufY ][ ( yCurr + j ) % CtbSizeY ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

If cIdx is 1, and if treeType is SINGLE_TREE or DUAL_TREE_CHROMA, the following applies

ibcBuf _Cb [ ( xCurr + i ) % wIbcBufC ][ ( yCurr + j ) % CtbSizeC ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

If cIdx is 2, and if treeType is SINGLE_TREE or DUAL_TREE_CHROMA, the following applies

ibcBuf _Cr [ ( xCurr + i ) % wIbcBufC ][ ( yCurr + j ) % CtbSizeC ] = recSamples[ xCurr + i ][ yCurr + j ]

for i = 0..nCurrSw − 1, j = 0..nCurrSh – 1.

In fig. 6 is a logic diagram of an example method 600 for processing visual media (video or image) signals. Method 600 comprises determining (602) to convert between a current video block and a data bit stream representation of that current video block, the size of a buffer for storing reference samples for that current video block using an intra-block copy encoding mode, and performing (604) the conversion with using reference samples stored in a buffer.

The following articles describe some examples of preferred features implemented by variants of method 600 and other methods. Additional examples are provided in Section 4 of this document.

1. A video processing method, comprising: determining, for conversion between a current video block and a representation of that current video block as a stream of data bits, the size of a buffer for storing reference samples of the current video block using an intra-frame block copy encoding mode; and performing the conversion using the reference samples stored in the buffer.

2. The method according to article 1, characterized in that the buffer size has a given constant value.

3. The method according to any of articles 1 – 2, characterized in that the specified size is MxN, where M and N are integers.

4. The method according to Article 3, characterized in that MxN is 64x64 or 128x128 or 64x128.

5. The method according to article 1, characterized in that the buffer size is equal to the size of the coding tree unit for the current video block.

6. The method according to article 1, characterized in that the buffer size is equal to the size of the virtual pipeline data unit used during the conversion.

7. The method according to article 1, characterized in that the size of the buffer corresponds to the field in the form of a stream of data bits.

8. The method of Clause 7, wherein the field is included in a data bit stream representation in a video parameter set or in a sequence parameter set or in an image parameter set or in an image header or in a slice header or at the tile group header level.

9. A method according to any of articles 1 - 8, characterized in that the buffer size is different for the reference samples of the luminance component on the one hand and the reference samples of the chrominance components on the other hand.

10. A method according to any of articles 1 – 8, characterized in that the buffer size depends on the color component subsampling format for the current video block.

11. The method according to any of articles 1 - 8, characterized in that the reference samples are saved in RGB format.

12. A method according to any of articles 1 - 11, characterized in that the specified buffer is used to save reconstructed samples before and after contour filtering.

13. The method of Clause 12, wherein the loop filtering is deblocking filtering or adaptive loop filtering (ALF) or nonlinear adaptive offset filtering (SAO).

14. A video processing method comprising: initialization to convert between a current video block and a representation of that current video block as a stream of data bits, a buffer to store reference samples for the current video block using an intra-frame block copy encoding mode applying initial (initialized) values for reference readings; and performing the conversion using the reference samples stored in the buffer.

15. The method according to Article 14, characterized in that the specified initial values correspond to a certain constant.

16. The method according to any of articles 14 - 15, characterized in that the specified initial values are a function of the bit depth of the current video block.

17. The method according to Article 15, characterized in that the specified constant corresponds to the average gray level.

18. The method according to Article 14, characterized in that the specified initial (initializing) values correspond to the pixel values of the previous decoded video block.

19. The method according to article 18, characterized in that the specified previous decoded video block corresponds to the decoded block before the in-loop filtering.

20. A method according to any of Articles 14 - 19, characterized in that the buffer has the size as specified in one of Articles 1 - 13.

21. The method according to any of articles 1 - 20, characterized in that the pixel positions in the buffer are addressed using numbers x and y.

22. A method according to any of Articles 1 to 20, characterized in that the pixel positions in the buffer are addressed using a single number ranging from 0 to M*N-1, where M and N denote the width expressed in pixels and buffer height.

23. The method according to any of articles 1 to 20, characterized in that the current representation in the form of a stream of data bits contains a block vector for transformation, where the block vector, denoted as (BVx,BVy), is equal to (x-x0,y- y0), where (x0, y0) corresponds to the top-left position of the coding tree unit of the current video block.

24. The method according to any of articles 1 - 20, characterized in that the current representation in the form of a stream of data bits contains a block vector for transformation, where this block vector, denoted as (BVx,BVy), is equal to (x-x0+ Tx,y-y0+Ty), where (x0, y0) corresponds to the top-left unit position of the coding tree of the current video block, and where Tx and Ty are the offset values.

25. The method according to article 24, characterized in that Tx and Ty are predetermined shift values.

26. A method according to any of articles 1 – 20, characterized in that during the transformation process, for a pixel located at position (x0, y0) and having a block vector (BVx, BVy), the corresponding support in the buffer is located in the reference positions (x0+BVx, y0+BVy).

27. The method according to Article 26, characterized in that in the case where the reference position is outside the buffer, the support in the buffer is determined by truncation along the boundary of the buffer.

28. The method according to Article 26, characterized in that in the case where the reference position is outside the buffer, the support in the buffer is determined to have a given value.

29. A method according to any of articles 1 – 20, characterized in that during the transformation process, for a pixel located at position (x0, y0) and having a block vector (BVx, BVy), the corresponding support in the buffer is located at the reference position ((x0+BVx) mod M, (y0+BVy) mod N), where “mod” denotes the modulo operation, and M and N are integers representing the x and y sizes of the buffer.

30. A method of video processing, comprising: an initial setting (reset), in the process of conversion between video and a representation of the current video block in the form of a stream of data bits, a buffer storing reference samples for encoding in a mode with intra-frame copying of blocks at the video boundary; and performing the conversion using the reference samples stored in the buffer.

31. The method according to Article 30, characterized in that the video border corresponds to a new image or a new tile.

32. The method of Clause 30, wherein the conversion is performed by updating, after a reset, the buffer using the reconstructed values from the Virtual Pipeline Data Unit (VPDU).

33. The method according to Article 30, characterized in that the transformation is carried out by updating, after resetting, the buffer using the reconstructed values from the coding tree unit.

34. The method according to Article 30, characterized in that the reset is carried out at the beginning of each line of units in the coding tree.

35. The method according to Article 1, characterized in that the buffer size corresponds to L previously decoded blocks of size 64x64 each, where L is an integer.

36. A method according to any of articles 1 to 35, characterized in that the vertical scanning order is used to read or store samples in a buffer during the conversion process.

37. A method of processing video, comprising: using, to convert between a current video block and a representation of that current video block as a stream of data bits, a buffer for storing reference samples for the current video block using an intra-block copy encoding mode where the first bit depth is different from the second bit depth of encoded data; and performing the conversion using the reference samples stored in the buffer.

38. The method according to Article 37, characterized in that the first bit depth is greater than the second bit depth.

39. The method according to any of Articles 37 - 38, characterized in that the first bit depth is identical to the bit depth of the reconstructed data buffer used in the conversion process.

40. A method according to any one of clauses 37 to 39, characterized in that the first bit depth is signaled in a data bit stream representation as a value or as a difference value.

41. A method according to any of Articles 37 – 40, characterized in that the specified conversion uses different bit depths for the chrominance component and for the luminance component.

Additional variations and examples of Articles 37 to 41 are described in Item 7 in Section 4.

42. A method of video processing, comprising: performing a transformation between a current video block and a representation of that current video block as a stream of data bits using an intra-frame copy mode, in which the first precision used in computing the predicted data in the conversion process is lower than the second precision used in computing the reconstructed data in the process of transformation.

43. The method according to Article 43, characterized in that the calculations of the predicted data include determining the value of the predicted sample based on the value of the reconstructed sample using the function clip{{p+[1<<(b-1)}>>b,0,(1 <<bitdepth)-1}<<b, where p is the value of the reconstructed sample, b is the specified bit shift value, and bitdepth is the accuracy of the predicted sample.

Additional variations and examples of Articles 42 – 43 are described in Item 28 in Section 4.

44. A video processing method comprising: performing a conversion between a current video block and a representation of that current video block as a stream of data bits using an intra-frame copy mode in which a reference region of size nM x nM is used for a coding tree unit of size MxM, where n and M denote integers, and where the current video block is located in a coding tree unit, and where the reference region is the nearest available nxn coding tree unit in the row of coding tree units corresponding to the current video block.

Additional variations and examples of Article 4 are described in Item 35 in Section 4.

45. A video processing method comprising: performing a conversion between a current video block and a representation of that current video block as a stream of data bits using an intra-frame copy mode in which a reference region of size nM x nM is used for a coding tree unit of size other than MxM size, where n and M denote integers, and where the current video block is located in a coding tree unit, and where the reference region is the nearest available coding tree unit of size nxn-1 in the row of coding tree units corresponding to the current video block.

Additional variations and examples of Clause 4 are described in Clause 36 in Section 4. FIG. 8 and 9 show additional examples of options.

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

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

48. The method according to claim 3, characterized in that M=mW and N=nH, where W and H represent the width and height of a coding tree unit (CTU), m and n are positive integers.

49. Method according to any of paragraphs 46 – 48, characterized in that n and m depend on CTU.

50. A video processing method, comprising: determining, for transforming between a current video block of a video and a data bit stream representation of that current video block, the validity of a block vector corresponding to the current video block of a video component c using an X component of that video, where the X component is different from the luminance component video component; and performing a transformation using the block vector after determining that the block vector is valid for the current video block. Here, the block vector denoted as (BVx,BVy) is equal to (x-x0,y-y0), where (x0, y0) corresponds to the top-left position in the coding tree unit of the current video block.

51. The method according to Article 50, characterized in that the c component corresponds to the brightness component of the video in question.

52. The method according to Article 50, characterized in that the current video block is a chroma component block, and the video has a 4:4:4 format.

53. The method according to Article 50, characterized in that the video has a 4:2:0 format and in that the current video block is a block of the chrominance component, starting at position (x, y), and in that the determination procedure contains a determination that the block the vector is invalid for the case in which isRec(c, ((x+BVx)>>5<<5)+64-(((y+BVy)>>5)&1)*32+(x%32), ((y+BVy)>>5<<5) +(y%32)) is true.

54. The method of Article 50, characterized in that the video is in 4:2:0 format, and that the current video block is a chrominance block starting at position (x, y), and that the determination procedure includes a determination that the block vector is invalid for the case in which isRec(c, x+BVx+Chroma_CTU_size, y) is true.

55. A method of video processing, comprising: determining, selectively for conversion between a current video block of a current virtual pipeline data unit (VPDU) of a video area and a representation of that current video block as a stream of data bits, that K1 pre-processed VPDUs from the first row of the video area and K2 should be used pre-processed VPDUs from the second line of the video area; and performing a transformation, where the transformation eliminates the use of the rest of the current VPDU.

56. Method according to Article 55, characterized in that K1 = 1 and K2 = 2.

57. The method as set forth in any one of Clauses 55 to 56, wherein the current video block is selectively processed based on the size of the video area or the size of the current VPDU.

58. A method for processing video, comprising: performing a block vector validity check for conversion between a current video block and a data bitstream representation of that current video block, where the block vector is used for intra-block copy mode; and using the result of the validity check to selectively apply this block vector in the transformation process.

59. The method according to Article 58, characterized in that the conversion process uses a buffer for the intra-block copy mode (IBC), where the width and height of the buffer for the IBC copy mode are equal to Wbuf and Hbuf, the dimensions of the current video block are equal to WxH and where the block vector is represented by as (BVx, BVy), and where the current video block is in the current image having dimensions Wpic and Hpic, and in the coding tree unit having Wctu and Hctu as width and height, and where the validity check uses a predefined rule.

60. A method according to any of Articles 58 - 59, characterized in that the current video block is a luma block, a chrominance block, a coding unit (CU), a transform unit (TU), a 4x4 block, a 2x2 block or a subblock mother block, starting from the pixel with coordinates (X, Y).

61. A method according to any of Articles 58 – 60, characterized in that when checking validity, a block vector falling outside the boundaries of the current image is considered as valid.

62. A method according to any of Articles 58 – 60, characterized in that when checking validity, a block vector falling outside the boundaries of a coding tree unit is considered as valid.

Paragraphs 23 – 30 in the previous section offer additional examples and variations of clauses 58 – 62 above.

63. The method according to any of Articles 1 – 62, characterized in that the conversion procedure contains the generation of a representation in the form of a stream of data bits from the current video block.

64. The method according to any of Articles 1 – 62, characterized in that the conversion procedure contains the generation of pixel values of the current video block based on its representation as a stream of data bits.

65. A video encoder comprising a processor configured to implement the method set forth in any one or more of Clauses 1 through 62.

66. A video decoding device comprising a processor configured to implement the method set forth in any one or more of Clauses 1 through 62.

67. A computer-readable medium having code written on it, this code containing computer-executable commands to implement the method described in any one or more Articles 1 to 62.

In fig. 7 is a block diagram of the hardware platform of the video/image processing device 700. Apparatus 700 may be used to implement one or more of the methods described herein. The device 700 may be embedded in a smartphone, tablet, computer, Internet of Things (IoT) receiver, etc. Device 700 may include one or more processors 702, one or more storage devices 704, and video processing hardware 706. Processor(s) 702 may be configured to implement one or more methods (including, but not limited to, method 600) described herein. Storage device(s) 704 may be used to store data and code used to implement the methods and technologies described herein. Video processing hardware 706 may be used to implement, in circuit hardware form, some of the methods described herein.

The bit stream representation of the data corresponding to the current video block does not need to be a set of adjacent bits, but may be distributed across headers, parameter sets, and Network Abstraction Layer (NAL) packets.

Section A: Other Additional Example Options

In Section A, we present another example of an option in which the current version of the VVC coding standard could be modified to implement some of the technologies described in this document.

This section analyzes a number of problems in today's IBC copy-mode reference data buffer configuration and proposes another configuration option to address these problems. This proposes an independent buffer for the reference data in IBC copy mode instead of "mixing" such a buffer with storage for decoding. Compared to today's baseline, the proposed design achieves -0.99%/-0.71%/-0.79% AI/RA/LD-B luminance component BD-rate for class F and -2.57%/-1.81%/-1.36% for 4:2:0 TGM, with 6.7% memory reduction; or -1.31%/-1.01%/-0.81% for class F and -3.23%/-2.33%/-1.71% for 4:2:0 TGM with a 6.7% increase in memory capacity.

A1. Introduction

The encoding mode with intra-frame copying of blocks has been adopted, i.e. IBC mode (or using the current image as a reference, i.e. CPR mode earlier). It is clear that the reference samples for the IBC copy mode must be stored in the on-chip memory, and that this fact only limits the size of the reference area for a single CTU. To limit additional on-chip storage requirements, today's configuration reuses a 64x64 memory region to decode VPDUs, so that only 3 additional 64x64 storage regions are required to support IBC copy mode. When the CTU size is 128x128, the reference area currently used is shown in FIG. 2.

In today's project (VVC standard project 4), the area is determined as follows

– The following conditions must be true: ( yCb + ( mvL[ 1 ] >> 4 ) ) >> CtbLog2SizeY = yCb >> CtbLog2SizeY (8-972) ( yCb + ( mvL[ 1 ] >> 4 ) + cbHeight – 1) >> CtbLog2SizeY = yCb >> CtbLog2SizeY (8-973) ( xCb + ( mvL[ 0 ] >> 4 ) ) >> CtbLog2SizeY >= ( xCb >> CtbLog2SizeY ) – 1 (8-974) ( xCb + ( mvL[ 0 ] >> 4 ) + cbWidth – 1) >> CtbLog2SizeY <= ( xCb >> CtbLog2SizeY ) (8-975) [Ed. (SL): Conditions (8-218) and (8-216) could be checked under 6.4.X.] – When ( xCb + ( mvL[ 0 ] >> 4 ) ) >> CtbLog2SizeY equals ( xCb >> CtbLog2SizeY ) – 1, the block availability determination procedure as specified in clause 6.4.X [Ed. (BB): The procedure for checking the availability of neighboring blocks has yet to be formulated] are attracted using the current position ( xCurr, yCurr ) of the luminance component set to ( xCb, yCb ) and the neighboring position of the luminance component ( ( ( xCb + ( mvL[ 0 ] >> 4 ) + CtbSizeY ) >> ( CtbLog2SizeY – 1 ) ) << ( CtbLog2SizeY – 1 ), ( ( yCb + ( mvL[ 1 ] >> 4 ) ) >> ( CtbLog2SizeY – 1 ) ) << ( CtbLog2SizeY – 1 ) ) as input, and the output must be FALSE.

Thus, the total volume of reference data is equal to one CTU.

A2. Potential problems with today's configuration

Today's configuration involves reusing a 64x64 memory area to decode the current VPDU, and the reference area for IBC copy mode is aligned with the memory reuse area of the VPDU, respectively. This configuration combines a memory area for decoding a VPDU unit with a buffer for IBC copy mode. There could be a number of problems here:

1. Dealing with smaller CTUs can be a challenge. Assuming the CTU size is 32x32, then it is not clear whether today's 64x64 memory design for decoding the current VPDU can effectively support 32x32 memory reuse in other architectures.

2. The reference area varies significantly. Accordingly, too many restrictions on the correspondence of data bit streams are introduced. This places additional load on the encoder so that it can efficiently use the reference region and avoid generating legal data bit streams. This also increases the likelihood of invalid BVs appearing in various modules, such as the union list. Additional logic or additional matching constraints may be introduced to deal with invalid BV vectors. This not only introduces additional overhead for the encoder or decoder, it may also create a discrepancy between the encoding of the BV vectors and the encoding of the MV vectors.

3. This configuration does not scale well. Because the VPDU decoding is mixed with the IBC copy mode buffer, it is not easy to increase or decrease the reference area relative to today's single 128x128 CTU configuration. This may limit the flexibility to exploit the best trade-off between encoding efficiency and on-chip memory size in later designs, such as lower or higher profile ones.

4. The buffer bit depth for IBC copy mode is related to the decode buffer. Even though the screen content typically has a smaller bit depth than the internal decoding bit depth, the buffer still needs to waste memory to store bits that primarily represent rounding or quantization noise. The problem becomes even more serious when considering a configuration with a higher decoding bit depth.

A3. Clear buffer configuration for IBC copy mode

To solve the problems listed in the subsection above, we propose to have a separate, dedicated buffer for IBC copy mode that is not mixed with decode memory.

For a 128x128 CTU, the buffer is defined to be 128x128 of 8-bit samples, when a CU(x,y) of size wxh has been decoded, its reconstructed version before in-loop filtering is converted to an 8-bit format and written in the wxh block area starting from position (x%128, y%128). Here the % modulo operator results in a positive number, i.e. For , for example, -3%128=125.

Assuming that the pixel at address (x,y) is encoded in IBC copy mode with vector BV=(BVx, BVy), the predicted sample for that pixel in the reference buffer for IBC copy mode is located at address ((x+BVx)% 128, (y+BVy)%128), and the value of this pixel will be converted to 10-bit format before prediction.

When the buffer is considered to be of size (W, H), after decoding a CTU unit or a CU unit starting from point (x, y), the reconstructed pixels before edge filtering will be stored in the buffer starting from position (x%W, y%H) . Thus, after decoding a CTU, the corresponding buffer for the reference data in IBC copy mode will be updated accordingly. This setting may occur when the CTU size is not 128x128. For example, for a CTU unit of size 64x64, the CTU, at the current buffer size, could be considered a 256x64 buffer. For a 64x64 CTU unit, FIG. 2 shows the buffer status.

In fig. 12 is an illustration of the reference data buffer status for IBC copy mode, where a block denotes a 64x64 CTU.

In such a configuration, since the IBC copy mode buffer is different from the decoding memory for the VPDU, the IBC copy mode reference data buffer can be used as a reference here.

If the buffer bit depth for IBC copy mode is 8-bits, then compared to the current configuration where 3 additional 64x64 10-bit buffers are needed, the on-chip storage capacity increase value is (8*4)/(10*3 )-100%=6.7%.

If we reduce the bit depth further, the memory requirements can be further reduced. For example, for a 7-bit buffer, the on-chip storage capacity savings will be 100% - (7*4)/(10*3)=6.7%.

In such a configuration, the only constraint for matching the data bit stream is that the reference block must be within the reconstructed region in the current row of CTUs of the current tile.

When initialization to 512 is allowed at the beginning of each line of CTUs, all data bitstream compliance restrictions can be removed.

A4. Experimental results

In some embodiments, the described methods may be implemented using VTM-4.0 software.

For the 10-bit buffer and CTC implementation, the decoder is fully compatible with today's VTM4.0 encoder, which means that the proposed decoder can accurately decode data bit streams according to the VTM-4.0 CTC method.

For the 7-bit buffer implementation, the results are shown in Table I.

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

Table I. Performance with 7-bit buffer.

The base level is the result of the VTM-4.0 method with IBC copy mode for all sequences.

All with intra-frame prediction According to VTM-4.0 with IBC enabled Y U V Code.T Decode.T Class A1 -0.01% -0.09% -0.10% 132% 101% Class A2 0.05% 0.00% 0.06% 135% 100% Class B 0.00% -0.02% 0.01% 135% 100% Class C -0.02% 0.01% 0.03% 130% 98% Class E -0.13% -0.16% -0.04% 135% 99% Total -0.02% -0.05% 0.00% 133% 100% Class D 0.04% 0.04% 0.12% 127% 107% Class F -0.99% -1.14% -1.18% 115% 99% 4:2:0 TGM -2.57% -2.73% -2.67% 104% 102% Random access According to VTM-4.0 with IBC enabled Y U V Code.T Decode.T Class A1 0.02% -0.01% 0.01% 109% 100% Class A2 0.00% -0.04% 0.03% 111% 100% Class B -0.01% -0.10% -0.22% 113% 101% Class C -0.01% 0.17% 0.12% 115% 100% Class E Total 0.00% 0.00% -0.04% 112% 100% Class D 0.05% 0.16% 0.20% 117% 101% Class F -0.71% -0.77% -0.77% 109% 99% 4:2:0 TGM -1.81% -1.65% -1.64% 107% 101% Small delay B According to VTM-4.0 with IBC enabled Y U V Code.T Decode.T Class A1 Class A2 Class B 0.01% 0.36% 0.30% 114% 95% Class C -0.01% -0.12% -0.10% 120% 98% Class E 0.10% 0.20% 0.18% 107% 99% Total 0.03% 0.16% 0.13% 114% 97% Class D -0.01% 1.07% 0.18% 123% 104% Class F -0.79% -0.89% -1.01% 110% 100% 4:2:0 TGM -1.36% -1.30% -1.26% 109% 102%

Table II. Characteristics with 8-bit buffer.

The base level is the result of the VTM-4.0 method with IBC copy mode for all sequences.

All with intra-frame prediction According to VTM-4.0 with IBC enabled Y U V Code.T Decode.T Class A1 -0.01% 0.02% -0.10% 129% 102% Class A2 0.02% -0.06% -0.02% 134% 102% Class B -0.04% -0.02% -0.07% 135% 101% Class C -0.03% 0.04% 0.00% 130% 98% Class E -0.16% -0.14% -0.08% 134% 100% Total -0.04% -0.03% -0.05% 133% 100% Class D 0.00% 0.04% 0.02% 126% 101% Class F -1.31% -1.27% -1.29% 114% 98% 4:2:0 TGM -3.23% -3.27% -3.24% 101% 100% Random access According to VTM-4.0 with IBC enabled Y U V Code.T Decode.T Class A1 -0.01% -0.08% 0.04% 107% 99% Class A2 -0.03% -0.16% 0.06% 110% 99% Class B -0.01% -0.14% -0.22% 111% 99% Class C -0.01% 0.15% 0.09% 115% 100% Class E Total -0.01% -0.05% -0.03% 111% 99% Class D 0.01% 0.19% 0.22% 116% 101% Class F -1.01% -0.99% -1.01% 108% 99% 4:2:0 TGM -2.33% -2.14% -2.19% 105% 100% Small delay B According to VTM-4.0 with IBC enabled Y U V Code.T Decode.T Class A1 Class A2 Class B 0.00% 0.04% -0.14% 113% #NUM! Class C -0.05% -0.28% -0.15% 119% 98% Class E 0.04% -0.16% 0.43% 107% #NUM! Total 0.00% -0.11% 0.00% 113% #NUM! Class D -0.07% 1.14% 0.13% 122% 99% Class F -0.81% -0.92% -0.96% 111% 99% 4:2:0 TGM -1.71% -1.67% -1.71% 106% 95%

In fig. 17 is a block diagram showing an example of a video processing system 1700 in which the various methods described herein may be implemented. Various implementations may include some or all of the components of the system 1700. The system 1700 may include an input 1702 for receiving video content. This video content may be received in a raw or uncompressed format, such as 8 or 10-bit multi-pixel values, or may be in a compressed or encoded format. Input 1702 may be a network interface, a peripheral bus interface, or a storage device interface. Examples of a network interface include wired interfaces such as Ethernet, passive optical network (PON), etc., and wireless interfaces such as Wi-Fi or cellular interfaces.

System 1700 may include an encoding component 1704 that may implement various encoding techniques described herein. The encoding component 1704 may reduce the average transmission rate of video data bits as they pass from the input 1702 to the output of the encoding component 1704 to create an encoded representation of the video. Therefore, encoding technologies are sometimes called video compression technologies or video transcoding technologies. The output of encoding component 1704 may be either stored or transmitted via attached communications media, represented here by component 1706. The stored or transmitted (or encoded) representation of the video as a stream of data bits received as input 1702 may be used by component 1708 to generate values pixels or display video transmitted to display interface 1710. The procedure of generating user-viewable video from its representation as a stream of data bits is sometimes called video decompression (expansion). In addition, although some video processing operations are referred to as "encoding" operations or tools, it should be understood that the encoding tools or operations are used in the encoding devices and the corresponding decoding tools or operations that reverse the encoding results will be performed by the decoding device.

Examples of a peripheral bus interface or display interface may be a universal serial bus (USB) or a high definition multimedia interface (HDMI) or Displayport, etc. Examples of storage interfaces include the serial advanced technology attachment (SATA) interface, the peripheral device interface (PCI), the IDE interface, and other similar interfaces. The methods described herein may be implemented in a variety of electronic devices, such as mobile phones, laptop computers, smartphones, or other devices capable of digital processing and/or displaying video.

In fig. 18 is a logic diagram of an example of a visual data processing method. The steps of this logic circuit are discussed in conjunction with Example 23 discussed in Section 4 of that document. At step 1802, the method determines, to transform between the current video block of the current visual media image and the data bitstream representation of that current video block, a block vector (BVx,BVy), where the validity of this block vector (BVx, BVy) is independent of (1 ) the position (P, Q) of the sample block, and/or (2) whether the sample located at position (P,Q) is reconstructed, and/or (3) the position of the current video block, where the block vector (BVx, BVy) represents the offset pixels between the current video block and the specified sample block. At step 1804, the procedure performs, using the specified block vector, an intra-block copy mode transformation based on a reconstructed block located in the same video area as the current video block containing the reference samples used to generate a predicted block for the current video block, where, during conversion, the predicted sample located at position (A, B) from the plurality of reference samples located in the buffer is determined according to at least the buffer size and/or the block vector (BVx, BVy).

In fig. 19 is a logic diagram of an example of a visual data processing method. The steps of this logic circuit are discussed in conjunction with Example 23 discussed in Section 4 of that document. At step 1902, the method determines, for the conversion between the current video block of the current visual media image and the data bit stream representation of that visual media, whether the block vector (BVx, BVy) corresponding to the current video block is valid, in accordance with some rule, where this block vector (BVx, BVy) represents the pixel offset between the current video block and the sample block. At step 1904, the procedure performs, using the specified block vector, a transformation based on a reference region from the current image containing the reference samples used to form a predicted block for the current video block, where the specified rule specifies that the block vector (BVx, BVy) is valid in the case where (1) one or more samples from the sample block in question are outside the current image, and/or (2) one or more samples from this sample block are outside at least one coding tree unit (CTU) associated with the current video block, and/or (3) one or more samples from this block of samples could not be reconstructed.

In fig. 20 is a logic diagram of an example of a visual data processing method. The steps of this logic circuit are discussed in conjunction with Example 44 discussed in Section 4 of that document. At step 2002, the method performs a transformation between the current video block of the current visual media image and a representation of that visual media data as a stream of data bits, where this transformation is performed based on a reference region from the current image containing reference samples used to generate a predicted block for the current video block. and where a virtual buffer of a given size is used to track the availability of reference samples to form a prediction block.

In fig. 21 is a logic diagram of an example of a visual data processing method. The steps of this logic circuit are discussed in conjunction with Example 51 discussed in Section 4 of that document. At step 2102, the method supports, for converting between the current video block of the current image of the visual media data and the representation of that visual media data as a stream of data bits, a buffer containing reference samples from the current image to form a predicted block for the current video block, where one or more reference samples in the buffer that are marked as unavailable for generation have values outside the range of pixel values.

In fig. 22 is a logic diagram of an example of a visual data processing method. The steps of this logic circuit are discussed in conjunction with Example 54 discussed in Section 4 of that document. At step 2202, the method performs a conversion between the current video block of visual media data and a representation of that visual media data as a stream of data bits using a buffer containing reference samples from the current image to form a predicted block for the current video block, where this conversion is performed in accordance with a rule specifying that in order for a data bitstream representation to comply with this rule, the reference samples in the buffer must satisfy the data bitstream compliance constraint.

Some versions of this document will now be presented in article format.

L1. A method for processing visual media data, comprising:

definition, to transform between the current video block of the current visual media image and the data bitstream representation of that current video block, a block vector (BVx,BVy), where the validity of that block vector (BVx, BVy) is independent of (1) position (P, Q) block of samples, and/or (2) whether the sample located at position (P,Q), and/or (3) position of the current video block, where the specified block vector (BVx, BVy) represents the pixel offset between the current video block and the specified block of readings; And

performing, using this block vector, an intra-block copy mode transformation which is based on the fact that the reconstructed block, located in the same video area as the current video block, contains reference samples used to form a predicted block for the current video block, where, during the transformation process, the predicted sample at position (A, B) from the set of reference samples located in the buffer is determined in accordance with at least the buffer size and/or the block vector (BVx, BVy).

L2. A method for processing visual media data, comprising:

determining, for the conversion between the current video block of the current visual media image and the representation of that visual media as a stream of data bits, whether the block vector (BVx, BVy) corresponding to the current video block is valid, in accordance with some rule, where this block vector (BVx , BVy) represents the pixel offset between the current video block and the sample block; And

performing, using said block vector, said transformation based on a reference region from the current image containing reference samples used to form a predicted block for the current video block, wherein said rule specifies that the block vector (BVx, BVy) is valid when ( 1) one or more samples from the sample block in question are outside the current image, and/or (2) one or more samples from the sample block in question are outside at least one coding tree unit (CTU) associated with the current video block, and/or (3) one or more samples from the considered block of samples could not be reconstructed.

L3. The method of Article L2, characterized in that, after identifying that the block vector (BVx, BVy) is valid, the predicted sample at position (A, B) from the plurality of reference samples in the buffer is determined at least in accordance with the size of the buffer and/ or block vector (BVx, BVy).

L4. The method according to any one or more of articles L1 or L3, characterized in that the reference samples in the buffer correspond to reconstructed samples from any area of the current invention.

L5. The method of Article L4, wherein said area contains a string of coding tree units (CTUs) associated with the current video block.

L6. The method according to any one or more of clauses L1 to L5, characterized in that the block vector (BVx, BVy) is determined to be valid regardless of whether the position (P, Q) calculated in accordance with the block vector (BVx, BVy) and the top left position (x, y) of the current video block, outside the image boundaries.

L7. The method according to Article L6, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities x+BVx<0 or x+BVx>0 is valid.

L8. The method according to article L6, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid x+W+BVx > W _pic or x+W+BVx < W _pic , where W denotes the width of the current video block and W _pic denotes the width of the image.

L9. The method according to article L6, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid y+BVy<0 or y+BVy>0.

L10. Method according to article L6, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid x+H+BVx > H _pic or x+H+BVx < H _pic , where H denotes the height of the current video block and H _pic denotes the height of the image.

L11. The method according to any one or more of clauses L1 to L5, characterized in that the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated in accordance with the block vector (BVx, BVy) is ) and the top left position (x, y) of the current video block, outside the coding tree unit containing the current video block.

L12. Method according to Article L11, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid y+BVy<floor(y/H _ctu )* H _ctu or y+BVy>floor(y/ H _ctu )* H _ctu , where H _ctu denotes the unit height of the coding tree, and the function floor(a) is equal to the largest integer not greater than a.

L13. Method according to Article L11, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid y+H+BVy<floor(y/H _ctu )*H _ctu or y+H+BVy> floor(y/H _ctu )*H _ctu , where H denotes the height of the current video block, and H _ctu denotes the height of the coding tree unit, and the function floor(a) is equal to the largest integer not greater than a.

L14. The method according to any one or more of clauses L1 to L5, characterized in that the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated in accordance with the block vector (BVx, BVy) is ) and the top left position (x, y) of the current video block, outside the coding tree unit containing the current video block, and (n-1) coding tree units in the direction to the left.

L15. Method according to Article L14, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid x+BVx<floor(x/W _ctu )*W _ctu -(n-1)*W _ctu or x+BVx>floor(X/W _ctu )*W _ctu -(n-1)*W _ctu , where W _ctu denotes the unit weight of the coding tree, and the function floor(a) is equal to the largest integer not greater than a.

L16. Method according to Article L14, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid x+W+BVx>floor(X/W _ctu )*W _ctu +W _ctu or x+W +BVx<floor(X/W _ctu )*W _ctu +W _ctu , where W denotes the width of the current video block, W _ctu denotes the unit weight of the coding tree, and the function floor(a) is equal to the largest integer not greater than a.

L17. The method according to any one or more of clauses L1 to L5, characterized in that the block vector (BVx, BVy) is valid regardless of whether the position (P, Q) calculated in accordance with the block vector (BVx, BVy) is ) and the top left position (x, y) of the current video block, beyond the current string of CTUs, including the current coding tree unit containing the current video block.

L18. Method according to Article L17, characterized in that the block vector (BVx, BVy) is valid regardless of which of the inequalities is valid Y+BVy<floor(Y/ Hctu)* Hctu or Y+H+BVy>=floor(Y / Hctu)*Hctu+ Hctu, where, W _ctu and H _ctu denote the width and height of the CTU unit, respectively, and the function floor(a) is equal to the largest integer not greater than a.

L19. The method according to any one or more of articles L1 - L5, characterized in that the block vector (BVx, BVy) is determined as valid regardless of whether it was possible or not to reconstruct the sample.

L20. Method according to Article L19, characterized in that the block vector (BVx, BVy) is valid regardless of whether the function isRec(x+BVx, y+ BVy) is false, where the function isRec(x,y) is true if the pixel at position (x,y) is reconstructed using intra-frame block copy mode.

L21. Method according to Article L19, characterized in that the block vector (BVx, BVy) is valid regardless of whether the function isRec(x+BVx+W-1, y+BVy) is false, where isRec(x,y ) is true if the pixel at position (x,y) is reconstructed in intra-frame block copy mode, and W denotes the width of the current video block.

L22. Method according to Article L19, characterized in that the block vector (BVx, BVy) is valid regardless of whether the function isRec(x+BVx, y+BVy+H-1) is false, where isRec(x,y ) is true if the pixel at position (x,y) is reconstructed in intra-frame block copy mode, and H denotes the height of the current video block.

L23. Method according to Article L19, characterized in that the block vector (BVx, BVy) is valid regardless of whether the function isRec(x+BVx+W-1, y+BVy+H-1) is false, where isRec (x, y) is true if the pixel at position (x,y) is reconstructed in intra-frame block copy mode, W denotes the width of the current video block, and H denotes the height of the current video block.

L24. The method according to any one or more of clauses L1 to L5, characterized in that the block vector (BVx, BVy) is determined to be valid regardless of whether the current video block is included in the first coding tree unit of a row of coding tree units.

L25. The method according to any one or more of clauses L1 - L5, characterized in that the block vector (BVx, BVy) is determined to be valid when all of the following conditions are satisfied: (i) x + BVx >= 0, (ii) y + BVy >= floor(y / Hctu), and (iii) the function isRec(x + BVx + W - 1, y + BVy + H - 1) is true, where the function isRec(x, y) is "true" if the sample at point (x, y) is reconstructed in intra-frame block coding mode, W denotes the width of the current video block, H denotes the height of the current video block, where the function floor(a) is equal to the largest integer not greater than a.

L26. Method according to Article L25, characterized in that the block vector is located in the first CTU in the row of CTUs.

L27. The method according to article L3, characterized in that the predicted sample located at position (A, B) is determined in accordance with the buffer size, the block vector (BVx, BVy) and the top left position (x, y).

L28. Method according to Article L27, characterized in that the predicted sample located in position (A, B) is the predicted sample located in the position calculated according to ((X+BVx)%Wbuf, (Y+BVy)%Hbuf) , where Wbuf and Hbuf denote the buffer width and buffer height, respectively.

L29. A method according to any one or more of articles L1 - L28, characterized in that the specified conversion is carried out in the mode of intra-frame block copying.

M1. A method for processing visual media data, comprising:

performing a conversion between the current video block of the current image of the visual media data and a representation of that visual media data as a stream of data bits,

where, this transformation is performed based on a reference region from the current image containing reference samples used to generate a predicted block for the current video block, and

where a virtual buffer of a given size is used to track the availability of reference samples to form a prediction block.

M2. The method of Article M1, characterized in that the virtual buffer is maintained using a virtual pipeline data unit (VPDU), and characterized in that the size of the virtual buffer is m*W _VPDU xn*H _VPDU , where W _VPDU and H _VPDU denote width and height VPDU units.

M3. The method according to article M2, characterized in that m=4 and n=2.

M4. The method of Article M2, wherein m and/or n are determined at least in part based on the resolution of an image associated with the current video block or the size of a coding tree unit containing the current video block.

M5. Method according to article M2, characterized in that m and/or n are predefined values.

M6. Method according to article M2, characterized in that m and/or n are signaled in the form of fields in a data bit stream representation.

M7. The method according to article M1, characterized in that the sample in the current video block is mapped to a point (x%(m*W _VPDU ), y%(n*H _VPDU )) in the virtual buffer, where this sample in the current video block is located at the point with coordinates (x, y) relative to the top left corner of the image; “x%y” is defined as y = x – y*floor(x/y), where the function floor(a) is equal to the largest integer not greater than a, and W _VPDU and H _VPDU denote the width and height of the VPDU unit.

M8. The method according to article M1, additionally containing:

using an array to track the availability of samples stored in a virtual buffer.

M9. The method according to article M8, characterized in that the specified array contains a flag for indicating whether one or more samples stored in the buffer are used for prediction in intra-frame block copy mode.

M10. The method according to article M8, characterized in that the specified array corresponds to one or more VPDU units of size 3x2 each.

M11. Method according to article M8, characterized in that the specified array corresponds to one or more VPDU units of size 4x2 each.

M12. The method according to article M1, characterized in that a subset of samples stored in the virtual buffer is flagged as unavailable for prediction.

M13. The method of clause M12, wherein said subset of samples flagged as unavailable for prediction is based on the position of the most recently processed VPDU.

M14. Method according to article M13, characterized in that the samples are flagged as unavailable at the beginning of VPDU processing.

M15. The method of article M14, characterized in that if yPrevVPDU%(n*H _VPDU ) is 0, then a subset of samples located at positions (x, y) are flagged as unavailable, where x is in the first specified range and y is in the second specified range, where (xPrevVPDU, yPrevVPDU) denotes the upper left corner of the coding tree unit of the most recently processed VPDU, and W _VPDU and H _VPDU denote the unit width and height of that VPDU.

M16. The method according to article M15, characterized in that the first range is expressed as [xPrevVPDU - 2W _VPDU + 2mW _VPDU )% mW _VPDU , ((xPrevVPDU - 2*W _VPDU + 2*m*W _VPDU )% (m*W _VPDU )) -1+W _VPDU ], and the second range is expressed as [yPrevVPDU%(n*H _VPDU ), (yPrevVPDU%(n*H _VPDU ))-1+H _VPDU ].

M17. The method according to Article M15, characterized in that the first range is expressed as [xPrevVPDU - 2*W _VPDU + 2*m*W _VPDU )% mW _VPDU , ((xPrevVPDU - 2*W _VPDU + 2*m*W _VPDU )% ( m*W _VPDU ))-1+W _VPDU ], and the second range is expressed as [yPrevVPDU%(n*H _VPDU ), (yPrevVPDU%(n*H _VPDU ))-1+ H _VPDU ].

M18. The method according to article M14, characterized in that if yPrevVPDU%(n*H _VPDU ) is not equal to 0, then a subset of samples located at positions (x, y) is flagged as unavailable, where x lies in the first specified range and y lies in the second specified range, where (xPrevVPDU, yPrevVPDU) denotes the upper left corner of the coding tree unit for the most recently processed VPDU, and W _VPDU and H _VPDU denote the width and height of the specified VPDU.

M19. The method according to Article M18, characterized in that the first range is expressed as [xPrevVPDU - W _VPDU + 2*m*W _VPDU )% (m*W _VPDU ), ((xPrevVPDU - W _VPDU + 2*m*W _VPDU )% ( m*W _VPDU ))-1+W _VPDU ], and the second range is expressed as [yPrevVPDU%(n*H _VPDU ), (yPrevVPDU%(n*H _VPDU ))-1+ H _VPDU ].

M20. Method according to Article M18, characterized in that the first range is expressed as [xPrevVPDU - W _VPDU + 2*m*W _VPDU )% mW _VPDU , ((xPrevVPDU - W _VPDU + 2*m*W _VPDU )% (m*W _VPDU ))-1+W _VPDU ], and the second range is expressed as [yPrevVPDU%(n*H _VPDU ), (yPrevVPDU%(n*H _VPDU ))-1+ H _VPDU ].

M21. The method of clause M12, wherein when a coding tree unit contains VPDUs, the subset of samples flagged as not available for prediction is based on the position of the most recently processed coding tree unit.

M22. The method according to article M21, characterized in that the samples are marked with flags as unavailable at the beginning of processing of the coding tree unit.

M23. The method according to any one or more of articles M1-M22, additionally containing:

determining the availability of a block vector corresponding to the current video block based on the top left position of the current video block, the bottom left position of the current video block, and the bottom right position of the current video block, where the determination procedure excludes the use of the top right position of the current video block.

M24. A method according to one or more of articles M1 - M23, characterized in that the specified conversion is carried out in the mode of intra-frame block copying.

N1. A method for processing visual media data, comprising:

maintaining, for conversion between the current video block of the current image of the visual media data and a representation of that visual media data as a stream of data bits, a buffer containing reference samples from the current image to form a predicted block for the current video block,

where one or more reference samples in the buffer that are marked as unavailable for generation have values outside the range of pixel values.

N2. The method of Article N1, characterized in that the specified range of pixel values is expressed as [0, 1<<(bit_depth) – 1], where bit_depth is a positive integer.

N3. The method according to article N2, characterized in that the bit_depth parameter indicates the level of accuracy used to process the samples.

N4. The method according to Article N1, characterized in that the method further contains:

initializing a plurality of samples in the buffer with a specified value indicating that the plurality of samples is unavailable.

N5. The method according to article N4, characterized in that the specified set value is equal to -1.

N6. The method according to any one or more of articles N4 - N5, characterized in that the position of the specified set of samples and/or whether this set should be initialized with a given value is based on one or more of the following factors: the position of the current video block, the size of the current video block , the size of the VPDU containing the current video block, and/or the size of the coding tree unit containing the current video block.

N7. The method according to article N6, characterized in that if (xCb%vSize) is equal to 0 and (yCb%vSize) is equal to 0, the specified set of samples is marked as unavailable, where xCb, yCb denotes the position of the current video block relative to the specified sample and vSize= min( ctbSize, 64), where ctbSize denotes the width or height of the coding tree unit.

N8. The method according to article N1, characterized in that if the size of the current block is less than min(ctbSize, 64), the specified set of samples in the buffer is marked as unavailable, where ctbSize denotes the width or height of a coding tree unit.

N9. The method according to article N8, characterized in that the positions of these several samples are associated with the size of the VPDU unit.

N10. The method according to article N8, characterized in that the positions of these several samples are associated with the size of the coding tree unit containing the current video block.

N11. The method according to article N4, characterized in that the specified set of samples in the buffer have positions expressed as (x%wIbcBuf, y%hIbcBuf), where x = xV, ..., xV+ctbSize-1 and y = yV, ..., yV+ ctbSize-1, and xV, yV denote the top left position of the VPDU unit relative to the top left position of the image, where ctbSize denotes the size of the coding tree unit, and wIbcBuf and hIbcBuf denote the buffer width and buffer height.

N12. The method according to article N11, characterized in that the specified set of samples in the buffer is initialized with the value -1.

N13. The method according to article N4, characterized in that the specified set of samples is initialized at the beginning of decoding the video unit.

N14. The method according to any one or more of articles N1 - N13, characterized in that the specified conversion is carried out in the mode of intra-frame block copying.

O1. A method for processing visual media data, comprising:

performing a conversion between the current video block of the current visual media image and a representation of that visual media data as a stream of data bits using a buffer containing reference samples from the current image to form a predicted block for the current video block,

where this conversion is performed based on a rule that specifies that, in order for a data bitstream representation to conform to this rule, a reference sample in the buffer must satisfy a data bitstream compliance constraint.

O2. The method of Clause O1, wherein said constraint on matching the data bit stream is based on at least one of the factors (1) the value of the reference sample in question in the buffer, and/or (2) information about the availability of that sample in the buffer.

O3. The method of any one or more of clauses O1 to O2, wherein said bitstream compliance constraint specifies that the data bitstream representation is non-compliant if the sample in the buffer in question has a value outside the pixel range.

O4. The method according to Article O3, characterized in that the specified range is of the form [K0, K1], where K0 is set equal to 0 and K1 is set equal to (1<<BitDepth-1), where BitDepth represents the level of accuracy of the predicted sample.

O5. A method according to any one or more of clauses O1 to O2, wherein said data bit stream compliance constraint specifies that the data bit stream representation is non-compliant if information about the availability of the sample in question in the buffer indicates that the sample is not available for the current video block.

O6. A method according to any one or more of clauses O1 to O2, characterized in that the sample in question is a luminance component sample, and characterized in that said data bitstream compliance constraint specifies that the data bitstream representation is inconsistent if the information The availability of the sample in question in the buffer indicates that the sample is not available for the current video block, and a split in a single tree structure is used for the current video block.

O7. A method according to any one or more of articles O1 – O6, additionally containing:

marking information about the availability of a sample in accordance with the value of this sample in the buffer.

O8. The method according to Article O7, characterized in that if the value of the sample in question lies in the interval designated as [K0, K1], information about the availability of this sample is marked as available.

O9. The method according to Article O8, characterized in that K0 is set equal to 0 and K1 is set equal to (1<<BitDepth-1), where BitDepth represents the level of accuracy of the predicted sample.

O10. The method of any one or more of clauses O1 to O8, wherein said data bitstream matching constraint is further based on a partitioning type and a tree type for a coding unit associated with the current video block.

O11. The method of Clause O10, wherein if the partition type corresponds to a double tree and the tree type is a single tree, then the data bitstream matching constraint specifies a check to see whether all color components of the sample in question are marked as unavailable.

O12. The method of Clause O10, wherein if the partition type corresponds to a binary tree and the tree type is a binary tree, then the data bitstream matching constraint specifies an exception to check whether the chrominance component of the sample in question is marked as unavailable.

O13. A method according to any one or more of articles O1 - O12, characterized in that the specified conversion is carried out in the mode of intra-frame block copying.

XX. The method according to any of the articles L1 - XX, characterized in that the conversion procedure contains the generation of a representation in the form of a stream of data bits from the current video block.

XX. The method according to any of the articles L1 - XX, characterized in that the conversion procedure contains the generation of pixel values of the current video block from a representation in the form of a stream of data bits.

XX. The video encoder comprises a processor configured to implement a method in accordance with any one or more of clauses L1 through XX.

XX. The video decoding device includes a processor configured to implement a method in accordance with any one or more of clauses L1 to XX.

XX. A computer-readable medium having code written on it, where this code contains instructions executable by a processor to implement a method in accordance with any one or more clauses L1 - XX.

As used herein, the term "video processing" may refer to video encoding, video decoding, video compression, or video expansion (decompression). For example, video compression algorithms may be applied in the process of converting from a pixel representation of a video to a corresponding bitstream representation or vice versa. The representation of the current video block as a data bitstream may, for example, correspond to bits that are either located in one location or distributed in different locations in the data bitstream, as defined in the syntax. For example, a macroblock may be encoded in terms of transformed and encoded error residuals, as well as the use of bits in headers and other fields in the data bitstream.

From the foregoing, it will be understood that specific embodiments of the presently contemplated technology have been described herein for purposes of illustration, but various modifications may be made without departing from the scope of the present invention. Accordingly, the technology proposed herein is not limited in any way except by the appended Claims.

Implementation of the subject matter of the present invention and the functional operations described in this patent document may be implemented in various systems, digital electronic circuits, or computer downloadable software, firmware or hardware, including the structures discussed herein and their structural equivalents, or in combinations of one or more of the listed components. The implementation of the subject matter of the present invention, discussed in this description, can be carried out in the form of one or more computer program products, i.e. one or more modules of computer program instructions encoded on a tangible and non-volatile computer-readable storage medium for execution by or to control the operation of a data processing device. The computer-readable storage medium may be a computer-readable storage device, a computer-readable storage substrate, a storage device, a collection of objects that create a computer-readable propagated signal, or a combination of one or more of these components. The term "data processing unit" or "data processing device" or "data processing apparatus" covers all data processing equipment, devices and machines, including, for example, a programmable processor, a computer, or multiple processors or computers. Hardware and devices may contain, in addition to hardware, code that provides an environment for executing the computer programs 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 these.

A computer program (also known as a program, software, software application, script or code) may be written in any programming language, including compiled or interpreted languages, and may be deployed in any form, including a stand-alone program or in form of a module, component, subroutine, or other unit suitable for use in a computer environment. A computer program does not necessarily correspond to a file on a file system. A program may be stored in a portion of a file that also contains other programs or data (for example, one or more scripts are stored in a markup language document), in a single file specifically dedicated only to the program in question, or in multiple coordinated files (for example, files that save one or more modules, subroutines or code fragments). A computer program may be deployed for execution on a single computer or on multiple computers located at a single location or distributed over multiple locations and connected through a communications network.

The procedures and logic described herein may be implemented by one or more programmable processors executing one or more computer programs to implement functions by operating on input data and generating output data. These procedures and logic circuits may also be implemented by, and the hardware may also be implemented in, the form of special-purpose logic circuitry, such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC). circuit)).

Processors suitable for executing a computer program include, for example, general purpose and special purpose microprocessors and any one or more digital computer processors of any type. In general, the processor will receive instructions and data from read only memory and/or random access memory. The main elements of a computer are a processor for executing commands and one or more storage devices for storing commands and data. In general, a computer will also comprise or be operatively coupled to receive data and/or transmit data with one or more mass storage devices for storing data, such as magnetic devices, magneto-optical disks, or optical disks. However, the computer does not need to have such devices. Computer-readable media for storing computer program instructions and data includes all forms of non-volatile storage devices and storage media, including, for example, semiconductor storage devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable memory (EPROM). EEPROM) and flash memory devices. The processor and storage device may be complemented by or integrated into special purpose logic circuitry.

This description, together with the accompanying drawings, should be considered as examples only. As used here, the application of the conjunction "or" must also include "and/or" unless the context clearly indicates otherwise.

Although this patent document contains many specific details, they should not be construed as any limitation on the scope of any innovation or what may be claimed as an invention, but merely as descriptions of features that may be specific to particular embodiments of particular innovations . Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of one embodiment may also be implemented in multiple embodiments individually or in some suitable subcombination. Moreover, although features may be described above as operating in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excluded from that claimed combination such that the claimed combination may be converted into a subcombination or variations of such a subcombination.

Likewise, while operations are depicted in the drawings in a particular order, this should not be construed as a requirement that such operations must be performed in the specific order shown or in a sequential order or that all operations shown must be performed to achieve the desired results. Moreover, the separation of the various system components described in this patent document should not be understood as requiring such separation in all embodiments.

Only a few embodiments and examples are described herein, however, other embodiments, improvements and variations may be created based on what is described and illustrated herein.

Claims (46)

1. A method for processing video data, comprising the steps of: determining, for conversion between the current video block of the current video image and the video data bitstream, that a first prediction mode is applied to the current video block; maintain, for the first prediction mode, a virtual buffer of a given size containing reference samples obtained from the reference region of the current image; obtaining, for the current video block, a predicted block defined by a block vector in the virtual buffer; And perform a transformation based on at least the predicted block, in this case, a subset of reference samples in the virtual buffer is not available to obtain the predicted block, the locations of a subset of reference samples are determined based on the size of the virtual unit, when the current video block contains one or more virtual units, the locations of a subset of reference samples are further determined based on the size of the current video block, the reference sample subset locations are determined based on (x0, y0), where y0 % Vsize = 0, (x0, y0) specifies a location in the current image, where Vsize denotes the size of the virtual unit, and the reference sample subset locations are further determined based on the x0 % value Vsize, where % represents the modulo operation. 2. The method of claim 1, wherein the size of the virtual buffer is mxW x nxH, where W denotes the width of the virtual unit, H denotes the height of the virtual unit, and m and n are integers. 3. The method according to claim 2, wherein the values of m and n depend on the block size of the coding tree. 4. The method according to claim 3, in which m=4 and n=2. 5. The method of claim 1, wherein the subset of reference samples is located at positions (x, y) in the virtual buffer, wherein x is in a first specified range in the virtual buffer determined based on x0, and y is in a second specified range in the virtual buffer defined based on y0, where (x0, y0) denotes the upper left corner of the virtual unit. 6. The method of claim 5, wherein the first predetermined range and the second predetermined range are further determined based on Vsize. 7. The method of claim 1, wherein the virtual buffer is reset before encoding the image or slice. 8. The method according to claim 1, wherein the conversion step encodes the current video block into a stream of data bits. 9. The method according to claim 1, wherein the conversion step decodes the current video block from the data bit stream. 10. The method of claim 1, wherein the size of the virtual unit is 64 or equal to the block size of the coding tree including the current video block. 11. A video data processing device containing a processor and non-volatile memory with instructions, wherein the instructions, when executed by the processor, cause the processor to execute: determining, for conversion between the current video block of the current video image and the video data bitstream, that a first prediction mode is applied to the current video block; maintaining, for the first prediction mode, a virtual buffer of a given size containing reference samples obtained from the reference region of the current image; obtaining, for the current video block, a predicted block defined by a block vector in the virtual buffer; And performing a transformation based on at least a predicted block, in this case, a subset of reference samples in the virtual buffer is not available to obtain the predicted block, the locations of a subset of reference samples are determined based on the size of the virtual unit, when the current video block contains one or more virtual units, the locations of a subset of reference samples are further determined based on the size of the current video block, the reference sample subset locations are determined based on (x0, y0), where y0 % Vsize = 0, (x0, y0) specifies a location in the current image, where Vsize denotes the size of the virtual unit, and the reference sample subset locations are further determined based on the x0 % value Vsize, where % represents the modulo operation. 12. A non-volatile computer-readable recording medium that stores instructions that cause the processor to execute: determining, for conversion between the current video block of the current video image and the video data bit stream, that a first prediction mode is applied to the current video block; maintaining, for the first prediction mode, a virtual buffer of a given size containing reference samples obtained from the reference region of the current image; obtaining, for the current video block, a predicted block defined by a block vector in the virtual buffer; And performing a transformation based on at least a predicted block, in this case, a subset of reference samples in the virtual buffer is not available to obtain the predicted block, the locations of a subset of reference samples are determined based on the size of the virtual unit, when the current video block contains one or more virtual units, the locations of a subset of reference samples are further determined based on the size of the current video block, the reference sample subset locations are determined based on (x0, y0), where y0 % Vsize = 0, (x0, y0) specifies a location in the current image, where Vsize denotes the size of the virtual unit, and the reference sample subset locations are further determined based on the x0 % value Vsize, where % represents the modulo operation. 13. A method for storing a video data bit stream, comprising the steps of: determining that a first prediction mode is applied to the current video block of the current video image; maintain, for the first prediction mode, a virtual buffer of a given size containing reference samples obtained from the reference region of the current image; obtaining, for the current video block, a predicted block defined by a block vector in the virtual buffer; generating a stream of data bits from the current video block at least based on the predicted block; And storing a stream of data bits on a non-volatile computer-readable medium for recording information, in this case, a subset of reference samples in the virtual buffer is not available to obtain the predicted block, the locations of a subset of reference samples are determined based on the size of the virtual unit, when the current video block contains one or more virtual units, the locations of a subset of reference samples are further determined based on the size of the current video block, the reference sample subset locations are determined based on (x0, y0), where y0 % Vsize = 0, (x0, y0) specifies a location in the current image, where Vsize denotes the size of the virtual unit, and the reference sample subset locations are further determined based on the x0 % value Vsize, where % represents the modulo operation.