Video decoding method, video decoding device and computer program

Abstract

Aspects of the present disclosure include methods and apparatus for video coding. One of the apparatuses includes a processing circuit that receives a bitstream for a current region in a picture. The current region includes a luma coding region and a chroma coding region. The luma coding region and the chroma coding region are partitioned using separate coding tree structures. The processing circuit determines a chroma block vector (BV) for a current chroma block in the chroma coding region. The chroma BV indicates a chroma reference block in the picture. The processing circuit determines whether the chroma BV is valid based on whether collocated luma samples of the chroma reference block are within a permitted range of the luma region that includes the collocated luma samples of the current chroma block. If the chroma BV is valid, the processing circuit reconstructs the current chroma block based on the chroma reference block.

Description

[Technical Field]

[0001] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 434,398, entitled "IBC Chroma Block Vector Search Range Validation," filed December 21, 2022, which claims the benefit of priority to U.S. Patent Application No. 18 / 376,352, entitled "IBC Chroma Block Vector Search Range Validation," filed October 3, 2023. The disclosures of the prior applications are incorporated herein by reference in their entireties.

[0002] This disclosure describes embodiments generally related to video coding. [Background technology]

[0003] The "Background" discussion provided herein is intended to generally provide a context for the present disclosure. To the extent described in this Background section, the work of the current inventors, as well as aspects of the disclosure that may not otherwise be admitted as prior art at the time of filing, are not admitted expressly or implicitly as prior art to the present disclosure.

[0004] Image / video compression can help transmit image / video data across different devices, storage, and networks with minimal quality loss. In some examples, video codec techniques can compress video based on spatial and temporal redundancy. In one example, a video codec can use a technique called intra-prediction, which can compress images based on spatial redundancy. For example, intra-prediction can use reference data from a current picture during reconstruction for sample prediction. In another example, a video codec can use a technique called inter-prediction, which can compress images based on temporal redundancy. For example, inter-prediction can predict samples in a current picture from previously reconstructed pictures using motion compensation. Motion compensation can be indicated by a motion vector ("MV"). Summary of the Invention [Problem to be solved by the invention]

[0005] [Means for solving the problem]

[0006] Aspects of the present disclosure include methods and apparatus for video encoding / decoding. In some examples, the video decoding device includes a processing circuit. The processing circuit receives a bitstream for a current region in a picture. The current region includes a luma-coding region and a chroma-coding region. Coding information in the bitstream indicates that the luma-coding region and the chroma-coding region are partitioned using separate coding tree structures. The processing circuit determines a chroma block vector (BV) for a current chroma block in the chroma-coding region. The chroma BV indicates a chroma reference block in the picture. The processing circuit determines whether the chroma BV is valid based on collocated luma samples of the current chroma block and collocated luma samples of the chroma reference block. In response to determining that the chroma BV is valid, the processing circuit reconstructs the current chroma block based on the chroma reference block indicated by the chroma BV. In one example, the processing circuit determines whether the chroma BV is valid based on whether collocated luma samples of the chroma reference block are within a permitted range of the luma region that includes the collocated luma samples of the current chroma block.

[0007] In one embodiment, the current chroma block is predicted in one of: (i) intra block copy (IBC) mode, (ii) intra template matching prediction (IntraTMP) mode, and (iii) direct block vector (DBV) mode.

[0008] In one embodiment, the processing circuit determines that the chroma BV is valid responsive to (i) the collocated luma samples of the chroma reference block being within the allowed IBC reference range of the luma region that includes the collocated luma samples of the current chroma block, and (ii) the chroma samples in the chroma reference block being already reconstructed. The allowed range may be the allowed IBC reference range.

[0009] In one example, in response to determining that the current chroma BV is not valid, the processing circuit corrects the chroma BV to obtain a valid chroma BV and reconstructs the current chroma block based on another chroma reference block indicated by the valid chroma BV, where (i) the collocated luma samples of the other chroma reference block are within the allowed IBC reference range of the luma domain, and (ii) the chroma samples in the other chroma reference block have already been reconstructed.

[0010] In one example, the processing circuitry either (i) explicitly decodes the chroma BV from the coding information, or (ii) derives the chroma BV using IntraTMP mode or DBV mode.

[0011] In one example, the current region is a current coding tree unit (CTU), the luma coding region is a luma coding tree block (CTB) within the current CTU, and the chroma coding region is a chroma CTB within the current CTU.

[0012] In one example, the current CTU in the picture is divided into four coding units using quadtree partitioning, and the current region is one coding unit of the four coding units.

[0013] In one example, the allowed IBC reference range includes at least one of the reconstructed luma samples in the current coding tree unit (CTU) or one or more previously reconstructed CTUs, where the current CTU includes the current region.

[0014] In one example, the coding information in the bitstream includes a flag that indicates that the luma and chroma coding regions are split using two separate coding tree structures.

[0015] In one embodiment, the processing circuit determines whether the saturation BV is valid based on whether (i) the saturation samples in the saturation reference block have already been reconstructed, and (ii) the saturation reference block is within an allowed intra block copy (IBC) reference range of the current saturation block scaled from an allowed IBC reference range of the luma domain containing the collocated luma samples of the current saturation block. In response to determining that the saturation BV is valid, the processing circuit reconstructs the current saturation block based on the saturation reference block indicated by the saturation BV.

[0016] In one embodiment, the processing circuitry determines the allowed IBC reference range of the current chroma block by scaling the allowed IBC reference range of the luma region that includes the collocated luma samples of the current chroma block.

[0017] In one embodiment, the scaling factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma domain depends on the chroma sampling format.

[0018] In one example, the scaling factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma domain is different in different dimensions.

[0019] In one example, the magnification includes a horizontal magnification and a vertical magnification. If the chroma sampling format is 4:2:0, the horizontal magnification is 2 and the vertical magnification is 2. If the chroma sampling format is 4:2:2, the horizontal magnification is 2 and the vertical magnification is 1. If the chroma sampling format is 4:4:4, the horizontal magnification is 1 and the vertical magnification is 1.

[0020] In one embodiment, the processing circuit determines whether the chroma BV is valid depending on (i) the chroma samples in the chroma reference block have already been reconstructed, and (ii) the chroma reference block is within the allowed IBC reference range of the current chroma block.

[0021] In one example, in response to determining that the saturation BV is not valid, the processing circuit corrects the saturation BV to obtain a valid saturation BV and reconstructs the current saturation block based on another saturation reference block indicated by the valid saturation BV, where (i) the saturation samples in the saturation reference block have already been reconstructed, and (ii) the other saturation reference block is within the allowed IBC reference range of the current saturation block.

[0022] Aspects of the present disclosure also provide a non-transitory computer-readable medium storing instructions that, when executed by a computer, cause the computer to perform a method for video encoding / decoding. [Brief explanation of the drawings]

[0023] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings.

[0024] [Figure 1] FIG. 1 is a schematic diagram illustrating an example block diagram of a video processing system (100).

[0025] [Figure 2] FIG. 2 is a schematic diagram illustrating an exemplary block diagram of a decoder.

[0026] [Figure 3] FIG. 3 is a schematic diagram illustrating an exemplary block diagram of an encoder.

[0027] [Figure 4] FIG. 4 illustrates a BV associated with a current CU (401) according to some embodiments of the present disclosure.

[0028] [Figure 5] FIG. 5 illustrates a reference sample memory ("RSM") update process at four intermediate points during the reconstruction process, according to an embodiment of the present disclosure.

[0029] [Figure 6] FIG. 6 illustrates a left neighbor CTU and a current CTU, showing the valid reference area, according to an embodiment of the present disclosure.

[0030] [Figure 7] FIG. 7 illustrates an example of a prediction area for an Intra Block Copy ("IntraBC") mode in a super-block prediction according to an embodiment of the present disclosure.

[0031] [Figure 8] FIG. 8 illustrates an example of a memory reclamation mechanism or memory update process in an RSM during decoding of a CTU or SB in a current picture according to an embodiment of the present disclosure.

[0032] [Figure 9] 9A-B show examples of memory update processes in the RSM during decoding of the current SB (or CTU) according to an embodiment of the present disclosure, performed in either (a) horizontal splitting at the SB root (FIG. 9A) or (b) vertical splitting at the SB root (FIG. 9B).

[0033] [Figure 10] FIG. 10 illustrates an example of an intra template matching prediction ("IntraTMP") mode, according to an embodiment of the present disclosure.

[0034] [Figure 11] FIG. 11 illustrates an example allowed reference range for the current chroma block according to some embodiments of the present disclosure.

[0035] [Figure 12] FIG. 12 is a flowchart outlining a decoding process according to some embodiments of the present disclosure.

[0036] [Figure 13] FIG. 13 is a flowchart outlining an encoding process according to some embodiments of the present disclosure.

[0037] [Figure 14] FIG. 14 is a flowchart outlining a decoding process according to some embodiments of the present disclosure.

[0038] [Figure 15] FIG. 15 is a flowchart outlining an encoding process according to some embodiments of the present disclosure.

[0039] [Figure 16] FIG. 16 is a schematic diagram of a computer system according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0040] 1 illustrates a block diagram of a video processing system 100 in some examples. The video processing system 100 is an example of an application of the disclosed subject matter, a video encoder and video decoder in a streaming environment. The disclosed subject matter is equally applicable to other video-enabled applications, including, for example, video conferencing, digital TV, streaming services, and storing compressed video on digital media such as CDs, DVDs, memory sticks, etc.

[0041] The video processing system 100 includes a capture subsystem 113, which may include a video source 101, such as a digital camera, that creates a stream of uncompressed video pictures 102. In one example, the stream of video pictures 102 includes samples captured by the digital camera. The stream of video pictures 102, shown in bold to emphasize its high data volume compared to the encoded video data 104 (or coded video bitstream), can be processed by an electronic device 120 that includes a video encoder 103 coupled to the video source 101. The video encoder 103 can include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter, as described in more detail below. The encoded video data 104 (or coded video bitstream), shown in thin to emphasize its low data volume compared to the stream of video pictures 102, can be stored on a streaming server 105 for future use. One or more streaming client subsystems, such as the client subsystems 106 and 108 of FIG. 1, can access the streaming server 105 to retrieve copies 107 and 109 of the encoded video data 104. The client subsystem 106 may include, for example, a video decoder 110 in an electronic device 130. The video decoder 110 decodes the incoming copy 107 of the encoded video data and creates an outgoing stream of video pictures 111 that can be rendered on a display 112 (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data 104, 107, and 109 (e.g., a video bitstream) may be encoded according to a particular video coding / compression standard. Examples of these standards include ITU-T Recommendation H.265.In one example, an evolving video coding standard is informally known as Versatile Video Coding (VVC), and the disclosed subject matter may be used in the context of VVC.

[0042] It should be noted that the electronic devices 120 and 130 may include other components (not shown). For example, the electronic device 120 may include a video decoder (not shown), and the electronic device 130 may include a video encoder (not shown).

[0043] 2 shows an exemplary block diagram of a video decoder (210). The video decoder (210) may be included in an electronic device (230). The electronic device (230) may include a receiver (231) (e.g., a receiving circuit). The video decoder (210) may be used in place of the video decoder (110) in the example of FIG. 1.

[0044] The receiver (231) may receive one or more coded video sequences to be decoded, for example, by the video decoder (210). In one embodiment, one coded video sequence is received at a time, with the decoding of each coded video sequence being independent of the decoding of the other coded video sequences. The coded video sequences may be received from a channel (201), which may be a hardware / software link to a storage device that stores the encoded video data. The receiver (231) may receive the encoded video data along with other data, such as coded audio data and / or auxiliary data streams, that may be forwarded to a respective using entity (not shown). The receiver (231) may separate the coded video sequences from other data. To prevent network jitter, a buffer memory (215) may be coupled between the receiver (231) and the entropy decoder / parser (220) (hereinafter, "parser (220)"). In certain applications, the buffer memory (215) is part of the video decoder (210). In other cases, the buffer memory (215) may be external to the video decoder (210) (not shown). In still other cases, there may be a buffer memory (not shown) external to the video decoder (210), for example, to prevent network jitter, and another buffer memory (215) internal to the video decoder (210), for example, to handle playback timing. When the receiver (231) receives data from a store-and-forward device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (215) may not be necessary and may be small. For use with best-effort packet networks such as the Internet, the buffer memory (215) may be necessary, may be relatively large, may advantageously be adaptively sized, and may be implemented at least in part in an operating system or similar element (not shown) external to the video decoder (210).

[0045] The video decoder (210) may include a parser (220) that reconstructs symbols (221) from the coded video sequence. These symbol categories include information used to manage the operation of the video decoder (210) and potentially include information to control a rendering device, such as a rendering device (212) (e.g., a display screen) that is not an integral part of the electronic device (230) but can be coupled to the electronic device (230) as shown in FIG. 2. Control information for the rendering device may be in the form of a Supplementary Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). The parser (220) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence can be aligned with a video coding technique or standard and can follow various principles, including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The parser (220) may extract a set of subgroup parameters for at least one subgroup of pixels in a video decoder from the coded video sequence based on at least one parameter corresponding to the group. The subgroup may include a group of pictures (GOP), a picture, a tile, a slice, a macroblock, a coding unit (CU), a block, a transform unit (TU), a prediction unit (PU), etc. The parser (220) may also extract information such as transform coefficients, quantization parameter values, motion vectors, etc. from the coded video sequence.

[0046] The parser (220) may perform entropy decoding / parsing operations on the video sequence received from the buffer memory (215) to create symbols (221).

[0047] The reconstruction of the symbols (221) can involve several different units, depending on the type of coded video picture or portion thereof (e.g., inter-picture and intra-picture, inter-block and intra-block) and other factors. Which units are involved and how can be controlled by subgroup control information parsed from the coded video sequence by the parser (220). The flow of such subgroup control information between the parser (220) and the following units is not shown for clarity.

[0048] In addition to the functional blocks already mentioned, the video decoder (210) may be conceptually subdivided into several functional units, as described below. In an actual implementation operating within commercial constraints, many of these units may interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the following conceptual subdivision into functional units is appropriate.

[0049] The first unit is a scalar / inverse transform unit (251), which receives control information from the parser (220) including the transform to be used, block size, quantization factor, quantization scaling matrix, etc., as well as quantized transform coefficients as symbols (221). The scalar / inverse transform unit (251) can output blocks containing sample values ​​that can be input to the aggregator (255).

[0050] In some cases, the output samples of the scaler / inverse transform unit (251) may relate to intra-coded blocks. Intra-coded blocks do not use prediction information from a previously reconstructed picture, but can use prediction information from a previously reconstructed portion of the current picture. Such prediction information may be provided by the intra-picture prediction unit (252). In some cases, the intra-picture prediction unit (252) generates a block of the same size and shape as the block being reconstructed using surrounding, already reconstructed information retrieved from the current picture buffer (258). The current picture buffer (258), for example, buffers the partially reconstructed and / or fully reconstructed current picture. The aggregator (255) may add, on a sample-by-sample basis, the prediction information generated by the intra-prediction unit (252) to the output sample information provided by the scaler / inverse transform unit (251).

[0051] In other cases, the output samples of the scalar / inverse transform unit (251) may relate to an inter-coded, potentially motion-compensated block. In such cases, the motion-compensated prediction unit (253) may access the reference picture memory (257) to retrieve samples used for prediction. After motion-compensating the retrieved samples according to the symbols (221) related to the block, these samples may be added to the output of the scalar / inverse transform unit (251) by the aggregator (255) to generate output sample information (in this case, referred to as residual samples or residual signals). The addresses in the reference picture memory (257) from which the motion-compensated prediction unit (253) retrieves prediction samples may be controlled by motion vectors available to the motion-compensated prediction unit (253), for example, in the form of symbols (221) that may have X, Y, and reference picture components. Motion compensation may also include interpolation of sample values ​​retrieved from the reference picture memory (257) when sub-sample accurate motion vectors are in use, motion vector prediction mechanisms, etc.

[0052] The output samples of the aggregator (255) may be applied to various loop filtering techniques in a loop filter unit (256). Video compression techniques can include in-loop filtering techniques controlled by parameters contained in the coded video sequence (also called a coded video bitstream) and made available to the loop filter unit (256) as symbols (221) from the parser (220). Video compression can also depend on meta-information obtained during decoding of previous portions (in decoding order) of the coded picture or coded video sequence, as well as on previously reconstructed, loop-filtered sample values.

[0053] The output of the loop filter unit (256) may be a sample stream that can be output to a rendering device (212) and stored in a reference picture memory (257) for use in future inter-picture prediction.

[0054] Once a particular coded picture is fully reconstructed, it can be used as a reference picture for future prediction. For example, once the coded picture corresponding to the current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (220)), the current picture buffer (258) can become part of the reference picture memory (257), and a new current picture buffer can be reallocated before beginning reconstruction of the following coded picture.

[0055] The video decoder (210) can perform decoding operations according to a given video compression technology or standard, such as ITU-T Recommendation H.265. A coded video sequence may comply with the syntax specified by the video compression technology or standard being used, in the sense that the coded video sequence conforms to both the syntax of the video compression technology or standard and the profile documented in the video compression technology or standard. Specifically, a profile may select specific tools from all tools available in the video compression technology or standard as the only tools available in that profile. Compliance also requires that the complexity of the coded video sequence be within the range limited by the level of the video compression technology or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. In some cases, the limits set by the level may be further limited by the specification of a hypothetical reference decoder (HRD) and metadata for HRD buffer management signaled in the coded video sequence.

[0056] In one embodiment, the receiver (231) can receive additional (redundant) data along with the encoded video. The additional data may be included as part of the coded video sequence. The additional data may be used by the video decoder (210) to properly decode the data and / or more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0057] 3 shows an example block diagram of a video encoder (303). The video encoder (303) is included in an electronic device (320). The electronic device (320) includes a transmitter (340) (e.g., a transmission circuit). The video encoder (303) can be used in place of the video encoder (103) in the example of FIG. 1.

[0058] The video encoder (303) can receive video samples from a video source (301) (not part of the electronic device (320) in the example of FIG. 3) that can capture video images to be encoded by the video encoder (303). In another example, the video source (301) is part of the electronic device (320).

[0059] The video source (301) may provide a source video sequence to be coded by the video encoder (303) in the form of a digital video sample stream, which may be of any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, etc.), any color space (e.g., BT.601 Y CrCB, RGB, etc.), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media delivery system, the video source (301) may be a storage device that stores prepared video. In a video conferencing system, the video source (301) may be a camera that captures local image information as a video sequence. The video data may be provided as multiple individual pictures that, when viewed in sequence, give the appearance of motion. The pictures themselves may be organized as a spatial array of pixels, each of which may contain one or more samples, depending on the sampling structure, color space, etc., in use. The following discussion focuses on samples.

[0060] According to one embodiment, the video encoder (303) can encode and compress pictures of a source video sequence into a coded video sequence (343) in real time or under any other required time constraints. Enforcing the appropriate coding rate is one of the functions of the controller (350). In some embodiments, the controller (350) controls and is operatively coupled to other functional units as described below. For clarity, coupling is not shown. Parameters set by the controller (350) can include rate control-related parameters (picture skip, quantization, lambda value for rate-distortion optimization techniques, etc.), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. The controller (350) can be configured with other appropriate functions related to the video encoder (303) optimized for a particular system design.

[0061] In some embodiments, the video encoder (303) is configured to operate in a coding loop. As an overly simplified explanation, in one example, the coding loop can include a source coder (330) (e.g., responsible for creating symbols, such as a symbol stream, based on an input picture to be coded and a reference picture) and a (local) decoder (333) embedded in the video encoder (303). The decoder (333) reconstructs the symbols to create sample data in a manner similar to that created by the (remote) decoder. The reconstructed sample stream (sample data) is input to a reference picture memory (334). Because decoding the symbol stream produces bit-exact results regardless of the location of the (local or remote) decoder, the contents of the reference picture memory (334) are also bit-exact between the local and remote encoders. In other words, the predictive portion of the encoder "sees" the exact same sample values ​​as the decoder "sees" when using prediction during decoding. This basic principle of reference picture synchrony (and the drift that occurs when synchrony cannot be maintained due to, for example, channel errors) is also used in several related technologies.

[0062] The operation of the "local" decoder (333) may be similar to the operation of a "remote" decoder, such as the video decoder (210), already described in detail above in connection with Figure 2. However, and with brief reference also to Figure 2, because symbols are available and the encoding / decoding of symbols into a coded video sequence by the entropy coder (345) and parser (220) may be lossless, the entropy decoding portion of the video decoder (210), including the buffer memory (215) and parser (220), may not be fully implemented in the local decoder (333).

[0063] In one embodiment, decoder technology other than parsing / entropy decoding present in the decoder is present in the corresponding encoder in the same or substantially the same functional form. Therefore, the disclosed subject matter focuses on the operation of the decoder. A description of the encoder technology can be omitted, as it is the reverse of the decoder technology described generically. In certain areas, more detailed descriptions are provided below.

[0064] In operation, in some examples, the source coder (330) may perform motion-compensated predictive coding, which predictively codes an input picture with reference to one or more previously coded pictures from a video sequence designated as “reference pictures.” In this manner, the coding engine (332) codes differences between pixel blocks of the input picture and pixel blocks of reference pictures that may be selected as prediction references for the input picture.

[0065] The local video decoder (333) can decode coded video data for pictures that may be designated as reference pictures based on symbols created by the source coder (330). The operation of the coding engine (332) can advantageously be a lossy process. When the coded video data is decoded by a video decoder (not shown in FIG. 3), the reconstructed video sequence may typically be a replica of the source video sequence, with some errors. The local video decoder (333) can replicate the decoding process that may be performed on the reference pictures by the video decoder and store the reconstructed reference pictures in the reference picture memory (334). In this way, the video encoder (303) can locally store copies of reconstructed reference pictures that have content in common (without transmission errors) with the reconstructed reference pictures obtained by the far-end video decoder.

[0066] The predictor (335) can perform the prediction search for the coding engine (332). That is, for a new picture to be coded, the predictor (335) can search the reference picture memory (334) for sample data (as candidate reference pixel blocks) or specific metadata that can serve as suitable prediction criteria for the new picture, such as the reference picture's motion vectors, block shapes, etc. The predictor (335) can operate on a sample block / pixel block basis to find a suitable prediction criteria. In some cases, as determined by the search results obtained by the predictor (335), the input picture may have prediction criteria drawn from multiple reference pictures stored in the reference picture memory (334).

[0067] The controller (350) may manage the coding operations of the source coder (330), including, for example, setting the parameters and subgroup parameters used to encode the video data.

[0068] The output of all of the aforementioned functional units may be entropy coded by an entropy coder (345), which converts the symbols produced by the various functional units into a coded video sequence by applying lossless compression to the symbols according to techniques such as Huffman coding, variable length coding, or arithmetic coding.

[0069] The transmitter (340) can buffer the coded video sequence created by the entropy coder (345) in preparation for transmission over a communication channel (360), which can be a hardware / software link to a storage device that stores the encoded video data. The transmitter (340) can also merge the coded video data from the video encoder (303) with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown).

[0070] The controller (350) may manage the operation of the video encoder (303). During coding, the controller (350) may assign a particular coded picture type to each coded picture, which may affect the coding technique that may be applied to each picture. For example, pictures may often be assigned one of the following picture types:

[0071] Intra-pictures (I-pictures) can be coded and decoded without using any other picture in the sequence as a source of prediction. Some video codecs allow different types of intra-pictures, including, for example, Independent Decoder Refresh ("IDR") pictures.

[0072] Predictive pictures (P pictures) can be coded and decoded by intra-prediction or inter-prediction using motion vectors and reference indices to predict the sample values ​​of each block.

[0073] Bidirectionally predicted pictures (B pictures) can be coded and decoded by intra- or inter-prediction using two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multi-predicted pictures can use two or more reference pictures and associated metadata for the reconstruction of a single block.

[0074] A source picture is generally spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples, respectively) and may be coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks determined by the coding assignment applied to each picture of the block. For example, blocks of an I-picture may be non-predictively coded or predictively coded with reference to already coded blocks of the same picture (spatial prediction or intra prediction). Pixel blocks of a P-picture may be predictively coded via spatial or temporal prediction with reference to one pre-coded reference picture. Blocks of a B-picture may be predictively coded via spatial or temporal prediction with reference to one or two pre-coded reference pictures.

[0075] The video encoder (303) may perform coding operations in accordance with a predetermined video coding technique or standard, such as ITU-T Recommendation H.265. During operation, the video encoder (303) may perform various compression operations, including predictive coding operations that exploit temporal and spatial redundancy in the input video sequence. Thus, the coded video data may conform to a syntax specified by the video coding technique or standard used.

[0076] In one embodiment, the transmitter (340) may transmit additional data along with the encoded video. The source coder (330) may include such data as part of the coded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0077] A video may be captured as multiple source pictures (video pictures) in a time sequence. Intra-picture prediction (often abbreviated as "intra-prediction") exploits spatial correlation within a given picture, while inter-picture prediction exploits correlation (temporal or otherwise) between pictures. In one example, a particular picture being encoded / decoded, called the current picture, is divided into blocks. If a block in the current picture is similar to a reference block in a previously coded and still buffered reference picture in the video, the block in the current picture can be coded by a vector called a motion vector. A motion vector points to a reference block in the reference picture and may have a third dimension that identifies the reference picture if multiple reference pictures are used.

[0078] In some embodiments, bi-prediction techniques can be used in inter-picture prediction. Bi-prediction techniques use two reference pictures, such as a first reference picture and a second reference picture, each of which is earlier in decoding order than a current picture in a video (but can be earlier and later in display order, respectively). A block in the current picture can be coded with a first motion vector that points to a first reference block in the first reference picture and a second motion vector that points to a second reference block in the second reference picture. A block can be predicted from a combination of the first reference block and the second reference block.

[0079] Furthermore, merge mode techniques can be used in inter-picture prediction to improve coding efficiency.

[0080] According to some embodiments of the present disclosure, prediction, such as inter-picture prediction and intra-picture prediction, is performed on a block-by-block basis. For example, according to the HEVC standard, a picture in a sequence of video pictures is divided into coding tree units (CTUs) for compression, and the CTUs within a picture have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, a CTU includes three coding tree blocks (CTBs), one luma CTB and two chroma CTBs. Each CTU can be recursively quadtree-divided into one or more coding units (CUs). For example, a 64x64 pixel CTU can be divided into one 64x64 pixel CU, four 32x32 pixel CUs, or sixteen 16x16 pixel CUs. In one example, each CU is analyzed to determine the prediction type of the CU, such as inter-prediction type or intra-prediction type. The CU is divided into one or more prediction units (PUs) according to temporal and / or spatial predictability. Generally, each PU includes one luma prediction block (PB) and two chroma PBs. In one embodiment, the prediction operation in coding (encoding / decoding) is performed in units of prediction blocks. Using a luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values ​​(e.g., luma values) of 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.

[0081] It should be noted that the video encoders (103) and (303) and the video decoders (110) and (210) may be implemented using any suitable technology. In one embodiment, the video encoders (103) and (303) and the video decoders (110) and (210) may be implemented using one or more integrated circuits. In another embodiment, the video encoders (103) and (303) and the video decoders (110) and (210) may be implemented using one or more processors executing software instructions.

[0082] Examples of intra block copy modes (also called IntraBC modes or IBC modes), such as those used in HEVC and VVC, are described below.

[0083] Some IBC coding tools are used as current picture referencing (CPR) in the HEVC Screen Content Coding ("SCC") extension. The IBC mode can use coding techniques used for inter prediction, in which the current picture (also called the current frame) is used as the reference picture (also called the reference frame) in the IBC mode. The advantage of using the IBC mode is the reference structure of the IBC mode, which allows two-dimensional (2D) spatial vectors to be used as a representation of the addressing mechanism to reference samples. The advantage of the IBC mode architecture is that the specification changes required to integrate IBC are relatively small, which can ease the implementation burden for manufacturers who have already implemented a given prediction technique, such as in HEVC Version 1. The CPR in the HEVC SCC extension can be a spatial inter prediction mode, with a syntax structure identical to or similar to that of the inter prediction mode and a decoding process similar to that of the inter prediction mode.

[0084] IBC mode can be integrated into inter prediction processing. In some examples, IBC mode (or CPR) is an inter prediction mode, and an intra-only predicted slice should be the predicted slice to allow the use of IBC mode. If IBC mode is applicable, the coder can extend the reference picture list by adding a pointer to the current picture. For example, the current picture uses a one-picture-sized buffer in the shared decoded picture buffer ("DPB"). IBC mode signaling can be implicit. For example, if the selected reference picture points to the current picture, the CU can adopt IBC mode. In various embodiments, the reference samples used in IBC processing are unfiltered, which differs from regular inter prediction. The corresponding reference picture used in IBC processing is a long-term reference. To minimize memory requirements, the coder can release the buffer after reconstructing the current picture, for example, the coder releases the buffer immediately after reconstructing the current picture. The filtered reconstructed picture can be added back into the DPB as a short-term reference by the coder when the reconstructed picture is a reference picture.

[0085] In block vector (BV) coding, reference to the reconstructed area can be made via 2D BVs, which are similar to the MVs used in inter prediction. Prediction and coding of BVs can reuse MV prediction and coding in the inter prediction process. In some examples, luma BVs are integer resolution, rather than the quarter (or 1 / 4-pel) precision of the MVs used in typical inter-coded CTUs.

[0086] FIG. 4 illustrates a BV associated with a current CU (401) according to an embodiment of the present disclosure. Each rectangle (400) may represent a CTU. Gray shaded areas represent areas or regions that have already been coded, while white unshaded areas represent areas or regions to be coded. The current CTU (400(4)) being reconstructed includes the current CU (401), a coded area (402), and an area to be coded (403). In one example, the area (403) is coded after coding the current CU (401).

[0087] For example, in HEVC, the gray shaded area excluding the two CTUs (400(1)-400(2)) to the upper right of the current CTU (400(4)) can be used as a reference area in IBC mode, allowing Wavefront Parallel Processing (WPP). BVs allowed in HEVC can refer to blocks within the reference area (e.g., the gray shaded area excluding the two CTUs (400(1)-400(2))). For example, BVs allowed in HEVC (405) refer to the reference block (411).

[0088] In an example such as in VVC, in addition to the current CTU (400(4)), only the left-neighboring CTU (400(3)) to the left of the current CTU (400(4)) is allowed as a reference area in IBC mode. In one example, the reference area used in IBC mode in VVC is within the dotted area (415) and includes coded samples. For example, the BV (406) allowed in VVC refers to the reference block (412). In one example, the decoded motion vector difference ("MVD") or block vector difference ("BVD") of the BV is shifted left (e.g., by two) before being added to the BV predictor to determine the final BV.

[0089] IBC mode can differ from inter-prediction modes and may use special operations for implementation and performance reasons, such as those described below. In an embodiment, IBC reference samples are unfiltered; for example, reconstructed samples before in-loop filtering processes, including but not limited to deblocking filters ("DBF") and sample adaptive offsets ("SAO"), are used as reference samples in IBC mode. Note that other inter-prediction modes, such as those used in HEVC, employ filtered samples as reference samples. In an embodiment, there is no luma sample interpolation for IBC mode. In an embodiment, chroma BV is derived from luma BV, and chroma sample interpolation is used when the chroma BV is non-integer. In an embodiment, the chroma BV is non-integer and the reference block is near the boundary of the available region. For example, surrounding reconstructed samples are outside the boundary, and chroma sample interpolation is performed. A BV pointing to a line near one boundary would not be able to avoid such cases.

[0090] An exemplary IBC architecture, such as that used in VVC, is described below. For an IBC mode, such as that used in the HEVC SCC extension, the valid reference area can include substantially the entire already reconstructed area of ​​the current picture, with a partial exception for parallel processing purposes, such as that described in FIG. 4. FIG. 4 illustrates the reference area for the IBC mode in HEVC and its configuration in VVC. For example, referring to FIG. 4, only the CTU (400(3)) to the left of the current CTU (400(4)) can serve as the reference sample area at the start of the reconstruction process for the current CTU (400(4)). In some examples, a reversion of the concept in HEVC is a requirement for additional memory in DPBs whose hardware implementations employ external memory. In one example, the additional access to external memory increases memory bandwidth, making the use of DPBs less attractive. In some embodiments, an IBC mode, such as that in VVC, can be implemented on-chip and use fixed memory, which can significantly reduce the complexity of implementing the IBC mode in a hardware architecture. In one embodiment, the key modification corresponds to a signaling concept away from integration within the inter prediction process, such as in the HEVC SCC extension.

[0091] 5 illustrates a reference sample memory (RSM) (510) update process at four intermediate points (501)-(504) during the reconstruction process, according to an embodiment of the present disclosure. The light gray shaded area may represent the reference sample of the left adjacent CTU. The dark gray shaded area may represent the reference sample of the current CTU. The white and unshaded area may represent the area to be coded (e.g., the next coding area).

[0092] Examples of syntax and semantics for IBC modes, such as those used in VVC, are described below. An IBC architecture, such as that used in VVC, can form a dedicated coding mode in which the IBC mode is a third prediction mode in addition to intra- and inter-prediction modes. The bitstream can carry an IBC syntax element (e.g., an sIBC syntax element) indicating the IBC mode of a coding unit, for example, when the block size is 64x64 or smaller. In one embodiment, the maximum CU size that can utilize the IBC mode is 64x64, implementing the continuous memory update mechanism of the RSM. The reference sample addressing mechanism can be identical to that used in the HEVC SCC extension by indicating a two-dimensional offset and reusing the vector coding process of the inter-prediction mode. In one example, a chroma separate tree ("CST") is active, and the coder cannot derive chroma BVs from luma BVs, resulting in the use of IBC mode only for luma coding blocks.

[0093] The reference area and sample memory in an IBC mode, such as that used in VVC, are described below. An IBC design, such as that used in VVC, can employ a fixed memory size (e.g., 128x128) per color component to store reference samples, thus providing the possibility of on-chip placement in hardware implementation. In one example, the maximum CTU size in VVC is 128x128. In one embodiment, when the maximum CTU size setting is equal to 128x128, the RSM can store samples for one CTU. In one example, the RSM features include a continuous update mechanism that can replace the reconstructed samples of the current CTU with the reconstructed samples of the left-neighboring CTU.

[0094] FIG. 5 illustrates an example RSM (e.g., a simplified RSM example) for an update mechanism at four intermediate points (501)-(504) during the reconstruction process. Referring to FIG. 5, at the first intermediate point (501), which represents the start of reconstruction of the current CTU, in one example, the RSM (510) includes only reference samples from the left-neighboring CTU. At the other three intermediate points (502)-(504), the reconstruction process replaces samples from the left-neighboring CTU with variants from the current CTU. A potential partitioning of the RSM (510) can be applied, dividing the RSM (510) into four disjoint 64×64 areas (511)-(514). When mapping the RSM to a CTU, a reset of the area can occur when the coder processes the first coding unit in the corresponding area, reducing hardware implementation effort.

[0095] In the example shown in Figure 5, a fixed memory (e.g., RSM (510)) can be allocated to store the reference areas used in IBC mode. During the coding process (e.g., encoding process or reconstruction process), parts of the RSM can be updated at different intermediate points (e.g., (501)-(504)). Figure 5 shows the reference areas for IBC mode in VVC and their settings in VVC.

[0096] 5, the RSM (510) can include a portion of the current CTU and / or a portion of the CTU to the left. In the example shown in FIG. 5, the size of the RSM is equal to the size of the CTU. The RSM (510) can include portions (511)-(514).

[0097] At the first intermediate point (501) of the coding process, which is the start of the coding process for the current CTU, the RSM (510) includes the entire left-neighboring CTU, which can serve as a reference area in IBC mode at the start of the coding process for the current CTU. The RSM (510) at the start of the coding process for the current CTU does not include the current CTU, and portions (511)-(514) include reconstructed samples of the left-neighboring CTU.

[0098] At a second intermediate point (502) in the coding process for the current CTU, a sub-area (531) in the upper left region of the current CTU has already been coded (e.g., encoded or reconstructed), a sub-area (532) in the upper left region of the current CTU is the current CU being coded (e.g., being encoded or reconstructed), and a sub-area (533) in the upper left region of the current CTU will be coded in the future. The RSM (510) is updated to include a portion of the CTU to the left and a portion of the current CTU. For example, portions (512)-(514) in the RSM (510) store the same reconstructed samples in the CTU to the left as at the first intermediate point (501), while portion (511) is updated to store the sub-area (531) of the current CTU. The reference area at the second intermediate point (502) may include the reconstructed samples of the left-neighboring CTU stored in portions (512)-(514) and the reconstructed samples of the sub-area (531) of the current CTU stored in portion (511).

[0099] At the third intermediate point (503) in the coding process for the current CTU, the upper left region of the current CTU has already been reconstructed. The upper right region of the current CTU includes sub-areas (541)-(543). Sub-area (541) (shaded dark gray) has already been coded (e.g., encoded or reconstructed), sub-area (542) is the current CU being coded (e.g., being encoded or reconstructed), and sub-area (543) (white and unshaded) will be coded in the future. While portions (513)-(514) of RSM (510) store the reconstructed samples in the CTU to the left as in the first intermediate point (501), portions (511)-(512) have been updated so that portion (511) stores the reconstructed samples in the upper left region of the current CTU and portion (512) stores sub-area (541) of the current CTU. The reference area at the third intermediate point (503) may include (i) reconstructed samples of the neighboring CTU to the left stored in portions (513)-(514), and (ii) reconstructed samples of the upper left region of the current CTU stored in portion (511) and reconstructed samples of a sub-area (541) of the current CTU stored in portion (512).

[0100] At a fourth intermediate point (504) in the coding process for the current CTU, the upper-left, upper-right, and lower-left regions of the current CTU have already been reconstructed. The lower-right region of the current CTU includes sub-areas (551)-(553). Sub-area (551) (shaded dark gray) has already been coded (e.g., encoded or reconstructed), sub-area (552) is the current CU being coded (e.g., being encoded or reconstructed), and sub-area (553) (white and unshaded) will be coded in the future. While portion (511) stores the same reconstructed samples for the upper-left region of the current CTU as at the third intermediate point (503), portions (512)-(514) have been updated so that portions (512)-(513) store reconstructed samples for the upper-right and lower-left regions of the current CTU, respectively, and portion (514) stores sub-area (551) of the current CTU. The reference area at the fourth intermediate point (504) can include the reconstructed samples of the current CTU stored in portions (511)-(514). At the fourth intermediate point (504), the RSM (510) does not include the area in the CTU to the left.

[0101] Figure 6 illustrates the left-neighbor CTU (601) and the current CTU (602), showing the valid reference areas according to the RSM design and continuous update mechanism. The left-neighbor CTU (601) can include areas 611-614. The current CTU (602) can include areas 621-624. Area 623 within the current CTU (602) includes the current CU (603) being coded, the sub-area (651) that has already been coded, and the sub-area (653) to be coded. The gray-shaded areas can include samples stored in the RSM, while the white and unshaded areas can include replaced or unreconstructed samples.

[0102] Figure 6 spatially illustrates an example of the continuous update concept of the RSM. During reconstruction in the example shown in Figure 6, the RSM update process replaced samples covered by the white and unshaded areas 611-613 in the left-neighbor CTU (601) with the gray shaded areas (e.g., areas 621-622 and subarea 651) of the current CTU (602). In Figure 6, the RSM can include (i) area 614 in the left-neighbor CTU (601) and (ii) areas 621-622 and subarea 651 of the current CTU (602).

[0103] An RSM may include more than one CTU to the left, for example, when the maximum CTU size is smaller than the RSM size (e.g., 128x128), multiple CTUs to the left can be used as reference areas in IBC mode. For example, when the maximum CTU size is equal to 32x32, an RSM with a size of 128x128 may store samples of 15 CTUs to the left.

[0104] An exemplary block vector (BV) for IBC mode, such as that used in VVC, is described below. BV coding can adopt the process defined for inter prediction. BV coding for IBC mode can use simpler rules for candidate list construction. For example, candidate list construction for inter prediction may include five spatial candidates, one temporal candidate, and six history-based candidates. In inter prediction, multiple candidate comparisons are used for the history-based candidates to avoid duplicate entries in the final candidate list. Also, in inter prediction, candidate list construction may include pairwise averaged candidates. In one embodiment, the IBC list construction process considers only two spatially neighboring BVs and five history-based BVs ("HBVPs"), and compares only the first HBVP with a spatial candidate when added to the candidate list. While two different candidate lists can be used, one for regular inter prediction merge mode and the other for regular modes, the candidate list in IBC mode accommodates both cases. In IBC mode, merge mode may use up to six candidates in the candidate list, while normal mode uses only the first and second candidates in the candidate list. Block vector difference (BVD) coding in IBC mode can employ the motion vector difference (MVD) process used in inter prediction, resulting in a final BV of any appropriate size. In one embodiment, the reconstructed BV may point to an area outside the reference sample area, and correction is applied to the reconstructed BV, for example, by removing the absolute offset in each direction (e.g., horizontally and vertically, respectively) modulo the width and height of the RSM.

[0105] The chroma BV derivation process may include the following: When the current coding tree type is SINGLE_TREE, a chroma block corresponds to a luma block. The BV of a chroma block coded in IBC mode may be derived from the BV of a luma block with appropriate scaling taking into account the chroma sampling format (e.g., 4:2:0, 4:2:2) and the chroma BV precision. The derivation process is described below. The input to the process may include a luma BV at 1 / 16th piece sample precision bvL. The output to the process may include a chroma BV at 1 / 32nd piece sample precision bvC. The chroma BV may be derived from the corresponding luma BV. The chroma BV bvC may be derived as follows: bvC[0]=((bvL[0]>>(3+SubWidthC))*32 Formula (1) bvC[1]=((bvL[1]>>(3+SubHeightC))*32 Formula (2)

[0106] The variables SubWidthC and SubHeightC can be specified in Table 1 according to the chroma format sampling structure, which can be specified by sps_chroma_format_idc. [Table 1]

[0107] In monochrome sampling (e.g., chroma format is monochrome), there is only one sample array that is nominally considered to be the luma array.

[0108] With 4:2:0 sampling, each of the two chroma arrays can have half the height and half the width of the luma array.

[0109] In 4:2:2 sampling, each of the two chroma arrays can have the same height and half the width of the luma array.

[0110] In 4:4:4 sampling, each of the two chroma arrays can have the same height and width as the luma array.

[0111] The number of bits required to represent each sample in the luma and chroma arrays in a video sequence can range from 8 to 16, inclusive.

[0112] IntraBC modes, such as those used in AV1, are described below. In one embodiment, such as in AV1, intra block copy (IntraBC) mode can use a vector to place a prediction block within the same picture of the current block. This vector is called a block vector (BV). The BV can be signaled in the bitstream, and the precision for representing the BV can be integer points. The prediction process in IntraBC mode is similar to inter-picture prediction. The difference between IntraBC mode and inter prediction is that in IntraBC mode, the predictor block can be formed from reconstructed samples of the current picture before applying loop filtering. Therefore, IntraBC mode can be thought of as "motion compensation" within the current picture using the BV as the MV.

[0113] For a current block, a flag indicating whether the IntraBC mode is possible for the current block can be first transmitted in the bitstream. Then, if the current block is coded in IntraBC mode, the BV difference can be derived by subtracting the predicted BV from the current BV. Depending on the horizontal and vertical components of the BV difference value, the BV difference can be classified into multiple types (e.g., four types). The type information can be signaled in the bitstream, and then the BV difference values ​​of the two (horizontal and vertical) components can be signaled.

[0114] IntraBC mode may be exceptionally useful for coding certain content, such as screen content. In one example, IntraBC mode also introduces challenges to hardware design. To facilitate hardware design, the following modifications may be employed: When IntraBC mode is enabled, the loop filter is disabled. The loop filter may include a DBF and / or a constrained directional enhancement filter ("CDEF") and / or a loop restoration ("LR") filter, etc. Disabling the loop filter avoids the need for a dedicated second picture buffer to enable IntraBC mode.

[0115] To facilitate parallel decoding, prediction cannot exceed a limited area. In one embodiment, for a superblock or CTU, if the coordinates of the top-left position of the superblock (or CTU) are (x0, y0), the prediction at position (x, y) can be accessed by IntraBC mode only if the vertical coordinate is less than y0 and the horizontal coordinate is less than x0+2(y0-y).

[0116] To allow for hardware write-back delays, IntraBC prediction cannot access the nearest reconstruction area. The limited nearest reconstruction area can be 1 to n superblocks (or CTUs). Thus, in addition to the above-mentioned modifications, if the coordinates of the top-left position of a superblock (or CTU) are (x0, y0), IntraBC mode can access prediction at position (x, y) if the vertical coordinate is less than y0 and the horizontal coordinate is less than x0+2(y0-y)-D, where D indicates the limited nearest reconstruction area for IntraBC mode. The prediction area when D is two superblocks, such as those specified in AVM, is shown in Figure 7.

[0117] FIG. 7 illustrates an example of a prediction area for IntraBC mode in one superblock prediction according to an embodiment of the present disclosure. Each rectangle may represent a superblock or a CTU. The gray shaded areas may include permitted search areas accessible in IBC mode for each current superblock (710) being reconstructed, for example. The black shaded areas may include disallowed search areas inaccessible in IBC mode for each current superblock (710) being reconstructed, for example, when D includes two superblocks (or two CTUs). The white unshaded areas include the superblocks to be coded (e.g., to be reconstructed). In one example, for a current superblock (710(1)), the nearest reconstruction area includes the two superblocks (721)-(722) to the left of the current superblock (710(1)) (e.g., D is two superblocks). The superblocks (721)-(722) are not accessible to the current superblock (710(1)). The allowed search area (730) is accessible to the current superblock (710(1)).

[0118] The IntraBC mode with a local reference range, such as in AV1, is described below. The IntraBC mode can be used with a local reference range, such as in the AV1 codec. In one embodiment, a memory reuse mechanism for a 64x64-based application, such as that shown in Figures 8, 9A-9B, allocates one superblock (SB) size of "on-chip" memory (referred to as RSM) to store reference samples. For example, in addition to the design of the IntraBC mode in AV1, the following modifications (1)-(3) are made: (1) The maximum block size in IntraBC mode can be limited to 64x64. (2) The reference block and the current block are in the same SB row. In one example, the reference block can only be placed in the current SB or one SB to the left of the current SB. (3) When any of the 64x64 units of reference sample memory starts updating with reconstructed samples from the current SB, reference samples previously stored in the entire 64x64 unit (e.g., from the left SB) are marked as unusable for generating predicted samples in IntraBC mode.

[0119] FIG. 8 shows an example of a memory reclamation mechanism or memory update mechanism in an RSM during decoding of a CTU or SB (e.g., the current SB (801)) in a current picture according to an embodiment of the present disclosure. Rows 1-2 show an example from the perspective of the RSM. Row 1 shows the RSM (810) in state (0). Row 2 shows the RSM (810) in states (1)-(4). Row 3 shows an example from the perspective of pictures such as the current SB (801) and the left-neighboring SB (802) being coded in the current picture in states (0)-(4). Quadtree division can be used at the SB root. An SB can include four regions. In one example, the size of each of the four regions is 64x64. In one example, the current SB (801) includes four regions 4-7, and the left-neighboring SB (802) includes four regions 0-3.

[0120] Referring to Figure 8, at the start of coding each SB (state (0)), the RSM stores samples from the previously coded SB (e.g., the neighboring SB (802) to the left). If the current block is in one of the four regions (e.g., four 64x64 regions) in the current SB (801) (e.g., as shown in one of states (1)-(4)), the corresponding region in the RSM (810) is emptied and can be used to store samples from the current coding region (e.g., the current 64x64 coding region). In this way, the samples in the RSM (810) can be gradually updated by the samples in the current SB (801), as shown in states (1) to (4), etc.

[0121] Referring to state (1), the current block (811) is in region 4 in the current SB (801), leaving the corresponding region (e.g., the upper left region) in the RSM (810) empty and available for storing samples of region 4, the current region being coded. Referring to row 3, a BV (e.g., encoded BV or decoded BV) (821) can point from the current block (811) to a reference block (831) within a search range 841 of the current block (811) (the boundary of the search range (841) is shown by a dotted line). Referring to row 2, a corresponding offset (851) in the RSM (810) can point from the current block (811) to a reference block (831) within the RSM (810). In state (1), the search range (841) includes regions 1-3 of the left neighboring SB (802) and the coded sub-region (861) within region 4. The search range (841) does not include area 0 of the SB (802) to the left.

[0122] Referring to state (2), the current block (812) is in region 5 in the current SB (801), and the corresponding region in the RSM (810) (e.g., the upper right region) is emptied and can be used to store samples for region 5, the current region being coded. The BV (822) can point from the current block (812) to a reference block (832) within a search range 842 of the current block (812) (the boundary of the search range (842) is shown by a dotted line). The corresponding offset (852) in the RSM (810) can point from the current block (812) to the reference block (832) within the RSM (810). In state (2), the search range (842) includes (i) regions 2-3 of the left-neighboring SB (802) and (ii) coded sub-regions (862) within regions 4 and 5 in the current SB (801). The search range (842) does not include the area 0-1 of the left adjacent SB (802).

[0123] Referring to state (3), the current block (813) is in region 6 in the current SB (801), leaving the corresponding region in the RSM (810) (e.g., the bottom-left region) empty and available for storing samples of region 6, the current region being coded. The BV (823) can point from the current block (813) to a reference block (833) within a search range 843 of the current block (813) (the boundary of the search range (843) is shown by a dotted line). The corresponding offset (853) in the RSM (810) can point from the current block (813) to the reference block (833) within the RSM (810). In state (3), the search range (843) includes (i) region 3 in the neighboring SB (802) to the left, and (ii) regions 4-5 in the current SB (801) and the coded sub-region (863) within region 6. The search range (843) does not include the area 0-2 of the SB (802) to the left.

[0124] Referring to state (4), the current block (814) is in region 7 in the current SB (801), leaving the corresponding region in the RSM (810) (e.g., the bottom-right region) empty and available for storing samples of region 7, the current region being coded. The BV (824) can point from the current block (814) to a reference block (834) within a search range 844 of the current block (814) (the boundary of the search range (844) is shown by a dotted line). The corresponding offset (854) in the RSM (810) can point from the current block (814) to the reference block (834) within the RSM (810). In state (4), the search range (844) includes regions 4-6 in the current SB (801) and the coded sub-region (864) within region 7. The search range (844) does not include regions 0-3 in the neighboring SB (802) to the left.

[0125] Once the current SB (801) is fully coded (state (4)), the entire RSM (810) can be filled with samples (e.g., all samples) of the current SB (801).

[0126] In the example shown in Figure 8, the current SB (801) is first divided using quadtree division. The coding order of the four 64x64 regions is the upper-left region (e.g., region 4), the upper-right region (e.g., region 5), the lower-left region (e.g., region 6), and the lower-right region (e.g., region 7), with the upper-left region coded first, followed by the upper-left, upper-right, and lower-left regions, and then the lower-right region. For other block division decisions, such as that shown in Figure 9B, the RSM update process may be similar, for example, by replacing each region of the RSM with a reconstructed sample in the current SB.

[0127] 9A-9B illustrate examples of memory update operations in the RSM during decoding of the current SB (or CTU) (901) according to an embodiment of the present disclosure, performed in either (a) horizontal splitting at the SB root (FIG. 9A) or (b) vertical splitting at the SB root (FIG. 9B).

[0128] In Figures 9A-9B, the left neighboring SB (902) has already been coded. The current SB (901) is currently being coded (e.g., encoded or decoded). In one example, the size of each of the current SB (901) and the left neighboring SB (902) is 128x128. Each of the current SB (901) and the left neighboring SB (902) can include four regions (e.g., four blocks) of size 64x64. The current SB (901) can include blocks 4-7, and the left neighboring SB (902) can include blocks 0-3.

[0129] In Figure 9A, horizontal division is performed at the SB route, followed by vertical division. The current SB (901) may include four blocks: an upper left block (e.g., block 4), a lower left block (e.g., block 6), an upper right block (e.g., block 5), and a lower right block (e.g., block 7). The coding order of the current SB (901) may be the upper left block (state 1), the upper right block (state 2), the lower left block (state 3), and the lower right block (state 4).

[0130] In Figure 9B, vertical division is performed at the SB route, followed by horizontal division. The coding order of the current SB (901) can be the top left block (state 1), the bottom left block (state 2), the top right block (state 3), and the bottom right block (state 4).

[0131] Referring to Figures 9A-9B, depending on the relative position of the current coding block with respect to the current SB (901), the following may apply:

[0132] 1. Referring to state (1) in Figures 9A-9B, if the current block (931) corresponds to the upper left block (e.g., block 4) (e.g., a 64x64 block) of the current SB (901), the current block (931) can refer to reference samples in the lower right block 3 (e.g., a 64x64 block), the lower left block 2 (e.g., a 64x64 block), and the upper right block 1 (e.g., a 64x64 block) of the left SB (902) in addition to the already reconstructed samples in block (961) of the current SB (901). The search range of the current block (931) can include blocks 1-3 and block (961).

[0133] 2. Referring to state (2) of FIG. 9A or state (3) of FIG. 9B, if the current block (932) corresponds to block 5 (e.g., a 64×64 block) to the upper right of the current SB (901), in addition to the already reconstructed samples of the current SB (901), (a) if the luminance sample at the relative position (0,64) with respect to the current SB (901) has not been reconstructed, as shown in state (2) of FIG. 9A, the current block (932) can refer to reference samples in block 2 (e.g., a 64×64 block) to the lower left and block 3 (e.g., a 64×64 block) to the lower right of the left SB (902), and the search range of the current block (932) can include blocks 2-4 and block (962). (b) Otherwise, if the luminance sample in the upper left corner (e.g., at a relative position of (0,64) relative to the current SB (901)) has been reconstructed, then the current block (932) can refer to a reference sample in block 3 (e.g., a 64x64 block) at the bottom right of the left SB (902), as shown in state (3) of Figure 9B, and the search range of the current block (932) can include blocks 3, 4, 6, and block (962).

[0134] 3. Referring to state (3) of FIG. 9A or state (2) of FIG. 9B, if the current block (933) corresponds to the lower left block of the current SB (901), in addition to the already reconstructed samples of the current SB (901), (a) if the relative luminance position (64,0) has not yet been reconstructed for the current SB (901), as shown in state (2) of FIG. 9B, the current block (933) can refer to reference samples within block 1 (e.g., a 64x64 block) in the upper right corner of the left SB (902) and block 3 (e.g., a 64x64 block) in the lower right corner, and the search range of the current block (933) can include blocks 1, 3, 4 and block (963). (b) Otherwise, if the luminance sample in the upper left corner of block 5 (e.g., relative position (64,0) to the current SB (901)) has been reconstructed, then, as shown in state (3) of Figure 9A, the current block (933) can refer to a reference sample in block 3 (e.g., a 64x64 block) at the bottom right of the left SB (902), and the search range of the current block (933) can include blocks 3-5 and block (963).

[0135] 4. If the current block (934) corresponds to block 7 at the bottom right of the current SB (901), the current block (934) can only refer to already reconstructed samples in the current SB (901), such as already reconstructed samples in blocks 4-6 and block (964), and the search range of the current block (934) can include blocks 4-6 and block (964).

[0136] FIG. 10 illustrates an example of an intra template matching prediction ("IntraTMP") mode according to an embodiment of the present disclosure. In one embodiment, such as ECM software, IntraTMP is a spatial intra prediction mode that can copy a best prediction block (1021) from a reconstructed portion of the current frame (or current picture), and the template (e.g., an L-shaped template) (1020) of the best prediction block (1021) can match the current template (1010) of the current block (1011). For a predetermined search range, the encoder can search the reconstructed portion of the current frame for a template (1020) that is most similar to the current template (1010) and use the corresponding block (1021) as the prediction block. The encoder can signal the use of IntraTMP mode, and the same prediction operation can be performed at the decoder side.

[0137] A prediction signal can be generated by matching a current template (1010), such as an L-shaped causal neighborhood of the current block (1011), with a template (e.g., (1020)) of another block (e.g., (1021)) within a predetermined search area. The exemplary search area shown in FIG. 10 can include multiple CTUs (or SBs). Referring to FIG. 10, the search area can include the current CTU R1 (e.g., a portion of the current CTU R1), the upper-left CTU R2, the upper CTU R3, and the left CTU R4. The cost function can include any suitable cost function, such as the sum of absolute differences ("SAD").

[0138] Within each region, the decoder can search for the template (e.g., (1020)) that has the smallest cost (e.g., smallest SAD) relative to the current template (1010), and can use the block (e.g., (1021)) associated with the template with the smallest SAD as the predicted block.

[0139] The size of the area indicated by (SearchRange_w, SearchRange_h) can be set as follows so that it is proportional to the block dimensions (BlkW, BlkH) and so that the number of SAD comparisons per pixel is fixed. SearchRange_w=a*BlkW Equation (3) SearchRange_h=a*BlkH Equation (4)

[0140] The parameter "a" may be a constant that controls the tradeoff between gain and complexity. In one example, "a" is 5.

[0141] The intra template matching tool may be enabled for CUs of a given size, such as width and height sizes up to 64. The maximum CU size for IntraTMP mode may be configurable.

[0142] When decoder-side intra mode derivation ("DIMD") is not used for the current CU, the IntraTMP mode can be signaled, for example, via a dedicated flag at the CU level.

[0143] In the context of a dual tree block structure, chroma IBC mode can be enabled. In embodiments such as in VVC, when the coding tree type is a dual tree type such as a chroma subtree (e.g., DUAL_TREE_CHORMA), IBC mode is applied only for luma coding blocks, and chroma intra-coding blocks only need to use other intra-prediction modes, limiting the coding efficiency of intra-chroma coding blocks for the chroma subtree (e.g., DUAL_TREE_CHORMA). In some examples, chroma IBC mode can be enabled in the chroma subtree case.

[0144] In one embodiment, all reconstructed reference samples within the same slice or tile can be used for IBC prediction. In various examples, stricter restrictions are applied to allow only a subset of samples within the reference area described above, such as those illustrated in Figures 4-8, 9A, and 9B.

[0145] For example, when the CTU size is 128x128 in luma samples, in addition to the reconstructed portion of the current CTU, it is possible to reference multiple left CTUs (e.g., previously coded CTUs in the same row as the current CTU) along with two CTU rows above the current row. The search range for IBC mode can include the reconstructed portion of the current CTU, multiple left CTUs, and two CTU rows above the current row.

[0146] In another example, when the CTU size is 256x256 in luma samples, in addition to the reconstructed portion of the current CTU, it is possible to reference multiple left CTUs (e.g., previously coded CTUs in the same row as the current CTU) along with one CTU row above the current row. The search range for IBC mode can include the reconstructed portion of the current CTU, multiple left CTUs, and one CTU row above the current row.

[0147] The difference between the above two cases is that the memory used to store the reference samples for IBC prediction is roughly the same.

[0148] In some embodiments, when using the chroma IBC mode in the CST case, corresponding luma samples for a chroma coding block may not be aligned to the same coding block size and location. For example, corresponding luma samples may be collocated with a chroma coding block and include luma samples from multiple luma blocks. Thus, validating a chroma BV may not be the same as validating a luma BV. In some examples, an efficient method for determining whether a chroma BV is valid for the CST case is desirable. This disclosure relates to enabling the IBC mode on chroma components when separate intra-luminance / chroma coding tree structures (e.g., intra-dual trees) are used, such as validating a chroma BV for a chroma coding block. For example, this disclosure provides an efficient method for determining whether a chroma BV of a chroma block is valid in the chroma tree case (e.g., as illustrated in Figures 11-15), which may be efficient and improve coding efficiency in the chroma tree case.

[0149] In one embodiment, the verification of a BV of a block includes two criteria: a) whether the reconstruction of the reference block pointed to by the BV has been completed, and b) whether the reference block is allowed for IBC prediction or IBC mode. When both criteria are met, for example, when the reconstruction of the reference block pointed to by the BV has been completed and the reference block is allowed for IBC mode, the BV is a valid BV. Otherwise, the BV is an invalid BV.

[0150] A second criterion, e.g., that a reference block is allowable for IBC mode, may include that the reference block is within the block's allowed IBC referencing range. The block's allowed IBC referencing range may include any suitable coded area (e.g., a reconstructed area) within the current picture that contains the block. This disclosure describes various examples of a block's allowed IBC referencing range. Examples include: (i) the gray-shaded area excluding two CTUs (400(1)-400(2)) of the current CU (401), such as those used in HEVC as shown in FIG. 4; (ii) coded samples (e.g., reconstructed samples) within the dotted area (415) that includes the current CTU (400(4)) and its left neighbor CTU (400(3)), such as those used in VVC as shown in FIG. 4; and (iii) reference areas used in VVC and with fixed-memory-sized RSMs and RSM update processes, such as those shown in FIGS. 5-6. (iv) the allowed search area used in AV1 and shown in FIG. 7; (v) a search range such as that used in AV1 (e.g., one of (841)-(844) in FIG. 8) or one of the search ranges described in FIGS. 9A-9B that may be used in AV1; (vi) a predefined search range in IntraTMP mode such as that described in FIG. 10; and (vii) any suitable search range for IBC mode, IntraBC mode, or IntraTMP mode, such as the search ranges described in this disclosure.

[0151] The permitted IBC reference range of the block may also be referred to as a reference range, a reference area, a search range, and / or a search area, etc. In some examples, the permitted IBC reference range of the block may be referred to as a local reference range when the permitted IBC reference range is limited to, for example, the current CTU.

[0152] In one embodiment, a region (or coding region) (1102) in a picture being coded (e.g., being reconstructed) or current picture (1101) includes a luma coding region (1120) and a chroma coding region (1110). The chroma coding region (1110) is collocated with the luma coding region (1120), e.g., the chroma coding region (1110) and the luma coding region (1120) correspond to the same physical region (1102) in the current picture (1101). The dimensions (e.g., width and / or height) of the chroma coding region (1110) and the luma coding region (1120) may be related by variables SubWidthC and SubHeightC, such as specified in Table 1. The variables SubWidthC and SubHeightC may depend on the chroma format sampling structure (or chroma sampling format), such as 4:2:0 and 4:2:2, such as specified in Table 1. In the example shown in Figure 11, the chroma format sampling structure is 4:2:0, and the width and height of the chroma coding region (1110) are half the width and height, respectively, of the luma coding region (1120).

[0153] The coding tree type may be a dual tree type, such as that used in VVC. In the dual tree type of the region (1102), the luma coding region (1120) and the chroma coding region (1110) may be divided using two separate coding tree structures. In one example, the region (1102) is coded using reconstructed samples of the picture (1101) using IBC mode, IntraBC mode, and / or IntraTMP mode. In one example, the picture (1101) is an intra picture (I picture). The luma coding region (1120) and the chroma coding region (1110) may be divided using separate intra luma / chroma coding tree structures (e.g., intra dual trees).

[0154] The luma coding region (1120) can be divided using any suitable coding tree structure. The chroma coding region (1110) can be divided using any suitable coding tree structure. In the example shown in FIG. 11, the chroma coding region (1110) is divided into chroma blocks (1111)-(1112), for example, by a binary tree. The chroma block (1111) is the block to be coded (e.g., encoded or reconstructed) and can be referred to as the current chroma block. In one example, the chroma block (1112) is the block to be coded after the current chroma block (1111) is coded. In the example shown in FIG. 11, the luma coding region (1120) is divided into luma blocks (1121)-(1129), for example, by quadtree division and / or binary tree. For example, the luma coding region (1120) is divided into four blocks using quadtree division. The upper left block of the luminance coding region (1120) is further divided into luminance blocks (1121)-(1122) using a binary tree. The upper right block of the luminance coding region (1120) is further divided into luminance blocks (1127)-(1128) using a binary tree. The lower left block of the luminance coding region (1120) is further divided into luminance blocks (1123)-(1126) using a quadtree division. The lower right block of the luminance coding region (1120) is not divided and is the luminance block (1129).

[0155] In one embodiment, the region (1102) is the current CTU being coded (e.g., being reconstructed) in the picture (1101), the luma coding region (1120) is a luma coding tree block (CTB) within the current CTU (1102), and the chroma coding region (1110) is a chroma CTB within the current CTU (1102). The luma CTB and chroma CTB can be split using separate coding tree structures such as those described above.

[0156] In one embodiment, the current CTU being coded (e.g., being reconstructed) in a picture (1101) can be divided into coding units, such as into four coding units using quadtree partitioning. The region (1102) can be one of the four coding units. The luma coding region (1120) and the chroma coding region (1110) within that coding unit (or region (1102)) can be divided using separate coding tree structures, such as those described above.

[0157] A chroma block vector (BV) (1113) of a chroma block (1111) in a chroma coding region (1110) can be determined. The current chroma block (1111) can be coded using IBC mode, IntraBC mode, or IntraTMP mode. The chroma BV (1113) can point to a chroma reference block (1131) in the picture (1101). Whether the chroma BV (1113) is valid can be determined based on the collocated luma samples of the current chroma block (1111) and the collocated luma samples of the chroma reference block (1131).

[0158] When a dual tree is used for the region 1102, the current chroma block 1111 can be collocated with one or more luma blocks in the luma coding region 1120. The number of luma blocks collocated with the current chroma block 1111 can depend on the coding tree structure used to divide the region 1102. Referring to FIG. 11, the current chroma block 1111 can be collocated with the luma blocks 1121-1126. The luma region 1141 in the luma coding region 1120 includes the luma blocks 1121-1126 and is collocated with the current chroma block 1111. The collocated luma samples of the current chroma block 1111 can include luma samples in the luma region 1141 (or the luma blocks 1121-1126).

[0159] The chroma reference block (1131) may be collocated with the luma region (1132), e.g., the chroma reference block (1131) and the luma region (1132) correspond to the same physical region (1103) in the current picture (1101). The region (1103) may include the chroma reference block (1131) and the luma region (1132). The collocated luma samples of the chroma reference block (1131) may include luma samples in the luma region (1132). The luma region (1132) may include one or more luma blocks, depending on, for example, the coding tree structure used to partition (i) the luma region (1132) or (ii) a luma CTU that includes the luma region (1132).

[0160] In one embodiment, before coding the current chroma block (1111), the luma samples in the luma coding region (1120) and the luma region (1132) have already been coded (e.g., reconstructed).

[0161] In response to determining that the chroma BV (1113) is valid, the current chroma block (1111) can be coded (e.g., encoded or reconstructed) based on the chroma reference block (1131) indicated by the chroma BV (1113). In one example, if the chroma BV (1113) is invalid, the chroma BV (1113) can be corrected to obtain a valid chroma BV (e.g., by removing the absolute offset in each direction by modulo operation with the width and height of the RSM corrected by the aforementioned scaling factor). The valid chroma BV can be used to reconstruct the current chroma block (1111).

[0162] According to one embodiment of the present disclosure, a chroma BV is determined to be valid if it satisfies two criteria: (i) the collocated luma samples of the chroma reference block (1131) (e.g., luma samples in the luma region (1132)) are within the permitted IBC reference range of the luma region (1141) that contains the collocated luma samples of the current chroma block (1111), and (ii) the chroma samples in the chroma reference block (1131) have already been reconstructed. In an example such as that shown in Figure 11, the first criterion requires that the luma samples in the luma region (1132) are within the permitted IBC reference range of the luma region (1141) if the luma region (1141) is a luma block to be coded in IBC mode, IntraBC mode, IntraTMP mode, or a similar mode. Examples of allowed IBC reference ranges for the luminance domain (1141) are described in this disclosure, such as in Figures 4-8, 9A-9B, and 10.

[0163] In one embodiment, the allowed IBC reference range includes reconstructed luminance samples in the current CTU and / or one or more previously reconstructed CTUs, where the current CTU includes region (1102).

[0164] In one embodiment, if the chroma BV (1113) is not valid, the chroma BV (1113) can be corrected to obtain a valid chroma BV. The current chroma block (1111) can be coded (e.g., encoded or reconstructed) based on another chroma reference block indicated by the valid chroma BV. For example, (i) the collocated luma samples of the other chroma reference block are within the allowed IBC reference range of the luma domain (1141), and (ii) the chroma samples in the other chroma reference block have already been reconstructed.

[0165] In one embodiment, the chroma BV (1113) can be determined by explicitly decoding the chroma BV (1113) from the bitstream (e.g., from coding information in the bitstream), which is similar to the decoding of the MV used in inter prediction. The prediction and coding of the chroma BV (1113) can reuse the MV prediction and coding in the inter prediction process.

[0166] In one embodiment, the chroma BV(1113) can be determined by deriving the chroma BV(1113), potentially using, for example, an IntraTMP mode, a derived block vector mode, or a direct block vector ("DBV") mode.

[0167] An example of the direct block vector (DBV) mode is described below. When the chroma dual tree is active in an intra slice, for a chroma CU coded as the direct block vector (DBV) mode, one of the luma blocks at multiple positions (e.g., five positions) of the luma component is coded in the IBC mode or the IntraTmp mode, and a block vector (e.g., luma BV bvL) is used to derive the chroma BV (bvC) for the chroma CB. The block vector scaling process can be determined according to template matching.

[0168] In one example, the coding information in the bitstream includes a flag (e.g., sps_qtbtt_dual_tree_intra_flag) indicating that the luma coding region (1120) and the chroma coding region (1110) are split using two separate coding tree structures. The flag can be signaled at any appropriate level, such as the sequence level in a sequence parameter set ("SPS"). In one example, the flag sps_qtbtt_dual_tree_intra_flag equal to 1 specifies that, for an I-slice, each CTU is split using a potential quad-tree partition into coding units having 64x64 luma samples, and these coding units are the roots of two separate coding tree syntax structures for the luma and chroma components. The flag sps_qtbtt_dual_tree_intra_flag equal to 0 specifies that no separate coding tree syntax structure is used for the I-slice. When sps_qtbtt_dual_tree_intra_flag is not present, it is inferred to be equal to 0.

[0169] According to another embodiment of the present disclosure, whether the chroma BV (1113) is valid can be determined based on (i) whether the chroma samples in the chroma reference block (1131) have already been reconstructed, and (ii) whether the chroma reference block (1131) is within the allowed IBC reference range of the current chroma block (1111). In one embodiment, the allowed IBC reference range of the current chroma block (1111) is scaled from the allowed IBC reference range of the corresponding luma region. The corresponding luma region can include collocated luma samples of the current chroma block (1111) (e.g., luma samples in the luma region (1141)). In one example, the corresponding luma region is the luma region (1141).

[0170] The scaling factor between the allowed IBC reference range of the current chroma block (1111) and the allowed IBC reference range of the luma domain (1141) can depend on the chroma format sampling structure.

[0171] The scaling factor can include a horizontal scaling factor and a vertical scaling factor. Since the chroma format sampling structure is 4:2:0, the horizontal scaling factor is 2 and the vertical scaling factor is 2. For example, when used in the chroma case, the luma width and luma height are reduced by a factor of 2. In the 4:2:0 format, the horizontal dimension (e.g., horizontal dimension) of the allowed IBC reference range of the current chroma block (1111) is half the horizontal dimension of the allowed IBC reference range of the luma region (1141), and the vertical dimension (e.g., vertical dimension) of the allowed IBC reference range of the current chroma block (1111) is half the vertical dimension of the allowed IBC reference range of the luma region (1141). The shape of the allowed IBC reference range of the luma region (1141) can have any suitable shape, such as a rectangle, such as that shown in FIG. 4, or an irregular shape, such as that shown in FIGS. 6, 8, 9A, and 9B.

[0172] Since the chroma format sampling structure is 4:2:2, the horizontal scale factor is 2 and the vertical scale factor is 1. For example, in a 4:2:2 format, the luma width can be reduced by a factor of 2 while the luma height remains the same as in the chroma case. Since the chroma format sampling structure is 4:4:4, the horizontal scale factor is 1 and the vertical scale factor is 1.

[0173] In one embodiment, to determine whether the chroma BV (1113) of the current chroma block (1111) is valid, parameters designed for the luma case (such as parameters related to the width and / or height of the region) can be scaled accordingly to the chroma case. For chroma channels or components (e.g., U and V channels), the scaling factors can be the same or different in different dimensions (e.g., width and / or height), as described above.

[0174] 12 is a flowchart illustrating an overview of process (1200) according to an embodiment of the present disclosure. Process (1200) can be used in a video decoder. In various embodiments, process (1200) is performed by a processing circuit, such as a processing circuit performing the functions of video decoder (110) and a processing circuit performing the functions of video decoder (210). In some embodiments, process (1200) is implemented in software instructions, such that the processing circuit performs process (1200) when executing the software instructions. Process (1200) begins at (S1201) and proceeds to (S1210).

[0175] At (S1210), a bitstream of a current region (e.g., region (1102)) in a picture (e.g., picture (1101)) is received. The current region (e.g., (1102)) to be reconstructed includes a luma coding region (e.g., (1120)) and a chroma coding region (e.g., (1110)). The coding information in the bitstream may indicate that the luma coding region and the chroma coding region are split using two separate coding tree structures. In one example, the coding information in the bitstream includes a flag (e.g., sps_qtbtt_dual_tree_intra_flag) indicating that the luma coding region and the chroma coding region are split using two separate coding tree structures.

[0176] In one example, the current region is the current CTU to be reconstructed, the luma coding region is a luma coding treeblock (CTB) within the current CTU, and the chroma coding region is a chroma CTB within the current CTU.

[0177] In another example, the current CTU in the picture is divided into four coding units using quadtree partitioning, and the current region is one coding unit of the four coding units.

[0178] In (S1220), a chroma block vector (BV) (e.g., (1113)) of a current chroma block (e.g., (1111)) being reconstructed in a chroma coding domain (e.g., (1110)) can be determined, such as described in Figure 11. The chroma BV can point to a chroma reference block (e.g., (1131)) in the picture (e.g., (1101)).

[0179] In one example, BV coding employs the process specified for inter prediction but uses simpler rules for candidate list construction. In one example, IBC BVs can be derived from the BVs of luma blocks.

[0180] In one example, the current chroma block is predicted in one of: (i) IBC mode, (ii) IntraTMP mode, and (iii) DBV mode.

[0181] The chroma BV can be determined by explicitly decoding it, e.g., from coding information. In one example, the chroma BV is explicitly decoded from coding information depending on whether the current chroma block is predicted in IBC mode. The chroma BV can be determined by implicitly deriving it, such as using IntraTMP mode, DBV mode, or another mode. In one example, the chroma BV is derived using IntraTMP mode or DBV mode depending on whether the current chroma block is predicted in IntraTMP mode or DBV mode, respectively.

[0182] The above method is not only applicable to the availability of explicitly decoded chroma BVs, but also to other derived BV modes such as IntraTMP or DBV modes.

[0183] In (S1230), it can be determined whether the chroma BV is valid based on the collocated luma samples of the current chroma block and the collocated luma samples of the chroma reference block, as described in FIG. 11, etc.

[0184] In one example, the collocated luma samples of the current chroma block can be used for evaluation to determine whether the chroma block vector is valid. In one example, the collocated luma samples should be within the permitted IBC reference range or the current CTU, and the reference chroma block should have been reconstructed. In one example, the validity of the chroma BV is determined based on whether the collocated luma samples of the chroma reference block are within the permitted region of the luma region that includes the collocated luma samples of the current chroma block. For example, the disclosed method determines whether the chroma BV is valid based on whether the collocated luma samples of the current chroma block and the collocated luma samples of the chroma reference block are within the permitted range. In response to determining that the chroma BV is valid, the disclosed method can reconstruct the current chroma block based on the chroma reference block indicated by the chroma BV.

[0185] In one embodiment, a chroma BV is determined to be valid if (i) the collocated luma samples of the chroma reference block are within the allowed intra block copy (IBC) reference range of the luma domain that includes the collocated luma samples of the current chroma block, and (ii) the chroma samples in the chroma reference block have already been reconstructed.

[0186] In one example, the allowed IBC reference range includes reconstructed luminance samples in the current CTU and / or one or more previously reconstructed CTUs, where the current CTU includes the current region.

[0187] In (S1240), if the saturation BV is valid, the current saturation block can be reconstructed based on the saturation reference block indicated by the saturation BV.

[0188] Thereafter, the process proceeds to (S1299) and ends.

[0189] The process 1200 may be adapted as appropriate. Steps of the process 1200 may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0190] In one example, if the saturation BV is not valid, the saturation BV is corrected to obtain a valid saturation BV. The current saturation block can be reconstructed based on another saturation reference block indicated by the valid saturation BV. In one example, (i) the collocated luma samples of the other saturation reference block are within the allowed IBC reference range in the luma domain, and (ii) the saturation samples in the other saturation reference block have already been reconstructed.

[0191] 13 is a flowchart illustrating an overview of process (1300) according to an embodiment of the present disclosure. Process (1300) can be used in a video encoder. In various embodiments, process (1300) is performed by a processing circuit, such as a processing circuit performing the functions of video encoder (103), a processing circuit performing the functions of video encoder (303), or the like. In some embodiments, process (1300) is implemented in software instructions, such that the processing circuit performs process (1300) when executing the software instructions. Processing begins at (S1301) and proceeds to (S1310).

[0192] In (S1310), a chroma BV (e.g., (1113)) of a current chroma block (e.g., (1111)) being reconstructed in a chroma coding region (e.g., (1110)) can be determined. The chroma BV can point to a chroma reference block (e.g., (1131)) in a picture (e.g., (1101)). The luma coding region and the chroma coding region in the current region (e.g., (1102)) of the picture can be split using two separate coding tree structures.

[0193] In (S1320), it can be determined whether the chroma BV is valid based on the collocated luma samples of the current chroma block and the collocated luma samples of the chroma reference block, such as described in Figures 11-12.

[0194] In (S1330), in response to determining that the saturation BV is valid, the current saturation block may be encoded based on the saturation reference block indicated by the saturation BV.

[0195] Thereafter, the process proceeds to (S1399) and ends.

[0196] The process 1300 may be adapted as appropriate. Steps of the process 1300 may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0197] In one example, the encoded chroma coding region is included in a bitstream and sent to a decoder. Coding information can be encoded to indicate that the luma coding region and the chroma coding region are split using two separate coding tree structures. In one example, a flag indicating that the luma coding region and the chroma coding region are split using two separate coding tree structures is encoded and included in the bitstream.

[0198] 14 is a flowchart illustrating an overview of a process (1400) according to an embodiment of the present disclosure. The process (1400) can be used in a video decoder. In various embodiments, the process (1400) is performed by a processing circuit, such as a processing circuit performing the functions of the video decoder (110) and a processing circuit performing the functions of the video decoder (210). In some embodiments, the process (1400) is implemented in software instructions, such that the processing circuit performs the process (1400) when executing the software instructions. The process (1400) begins at (S1401) and proceeds to (S1410).

[0199] At (S1410), a bitstream for a current region (e.g., region (1102)) in a picture (e.g., picture (1101)) is received. The current region (e.g., (1102)) includes a luma coding region (e.g., (1120)) and a chroma coding region (e.g., (1110)). The coding information in the bitstream may indicate that the luma coding region and the chroma coding region are split using two separate coding tree structures. In one example, the coding information in the bitstream includes a flag indicating that the luma coding region and the chroma coding region are split using two separate coding tree structures.

[0200] In one example, the current region is the current coding tree unit (CTU) being reconstructed, the luma coding region is a luma coding tree block (CTB) within the current CTU, and the chroma coding region is a chroma CTB within the current CTU.

[0201] In another example, the current CTU in the picture is divided into four coding units using quadtree partitioning, and the current region is one coding unit of the four coding units.

[0202] In (S1420), a chroma block vector (BV) (e.g., (1113)) of a current chroma block (e.g., (1111)) in a chroma coding domain (e.g., (1110)) can be determined, such as described in Figures 11-12. The chroma BV can point to a chroma reference block (e.g., (1131)) in a picture (e.g., (1101)).

[0203] The saturation BV can be determined by explicitly decoding the saturation BV, or by implicitly deriving the saturation BV, such as using IntraTMP mode, DBV mode, or other modes.

[0204] In (S1430), it can be determined whether the chroma BV is valid based on whether (i) the chroma samples in the chroma reference block have already been reconstructed, and (ii) whether the chroma reference block is within the allowed IBC reference range of the current chroma block scaled from the allowed IBC reference range of the luma domain containing the collocated luma samples of the current chroma block, such as described in FIG. 11.

[0205] In one example, whether a chroma BV is valid can be determined by scaling all parameters (such as those related to the width or height of a region) designed for the luma case accordingly to the chroma case. For example, the disclosed method may scale the allowed IBC reference range of a luma region that includes the collocated luma samples of the current chroma block to determine the allowed IBC reference range of the current chroma block. The disclosed method may also determine whether a chroma BV is valid based on (i) whether the chroma samples in the chroma reference block have already been reconstructed and (ii) whether the chroma reference block is within the allowed intra block copy (IBC) reference range of the current chroma block. In response to determining that the chroma BV is valid, the disclosed method may reconstruct the current chroma block based on the chroma reference block indicated by the chroma BV.

[0206] In one embodiment, the scale factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma region may depend on the chroma format sampling structure. The scale factor may include a horizontal scale factor and a vertical scale factor. If the chroma format sampling structure is 4:2:0, the horizontal scale factor is 2 and the vertical scale factor is 2. If the chroma format sampling structure is 4:2:2, the horizontal scale factor is 2 and the vertical scale factor is 1. If the chroma format sampling structure is 4:4:4, the horizontal scale factor is 1 and the vertical scale factor is 1.

[0207] In one example, for the U and V channels, the scaling factors may not be the same in different dimensions (such as in a 4:2:2 format). For example, in a 4:2:0 format, when used in the chroma case, all luma widths and luma heights are reduced by a factor of 2. In another example, in a 4:2:2 format, the luma widths can be reduced by a factor of 2, while the luma heights can remain the same as in the chroma case.

[0208] In one example, the scale factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma domain is different in different dimensions.

[0209] In one example, the allowed IBC reference range includes reconstructed luminance samples in the current CTU and / or one or more previously reconstructed CTUs, where the current CTU includes the current region.

[0210] In (S1440), in response to determining that the saturation BV is valid, the current saturation block may be reconstructed based on the saturation reference block indicated by the saturation BV.

[0211] Thereafter, the process proceeds to (S1499) and ends.

[0212] The process 1400 may be adapted as appropriate. Steps of the process 1400 may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0213] In one example, in response to determining that the saturation BV is not valid, the saturation BV is corrected to obtain a valid saturation BV. The current saturation block can be reconstructed based on another saturation reference block indicated by the valid saturation BV. In one example, (i) the saturation samples in the saturation reference block have already been reconstructed, and (ii) the other saturation reference block is within the allowed IBC reference range of the current saturation block.

[0214] 15 is a flowchart outlining a process (1500) according to an embodiment of the present disclosure. The process (1500) may be used in a video encoder. In various embodiments, the process (1500) is performed by a processing circuit, such as a processing circuit performing the functions of the video encoder (103), a processing circuit performing the functions of the video encoder (303), or the like. In some embodiments, the process (1500) is implemented in software instructions, such that the processing circuit performs the process (1500) when executing the software instructions. The process begins at (S1501) and proceeds to (S1510).

[0215] At (S1510), a chroma block vector (BV) of a current chroma block in a chroma coding region can be determined. The chroma BV can point to a chroma reference block in the picture. The luma coding region and the chroma coding region in the current region of the picture can be divided using two separate coding tree structures.

[0216] In (S1520), it can be determined whether the chroma BV is valid based on whether (i) the chroma samples in the chroma reference block have already been reconstructed, and (ii) whether the chroma reference block is within the allowed intra block copy (IBC) reference range of the current chroma block scaled from the allowed IBC reference range of the luma domain containing the collocated luma samples of the current chroma block, such as described in Figures 11 and 14.

[0217] In one example, to determine whether a chroma block vector is valid, all parameters designed for the luma case (such as those related to the width or height of a region) are scaled accordingly to the chroma. For the U and V channels, the scaling factors may not be the same in different dimensions (such as in a 4:2:2 format). For example, in a 4:2:0 format, when used in the chroma case, all luma widths and luma heights must be scaled by a factor of 2. In another example, in a 4:2:2 format, the luma widths must be scaled by a factor of 2, and the luma heights can remain the same as the chroma.

[0218] In one embodiment, the scale factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma region may depend on the chroma format sampling structure. The scale factor may include a horizontal scale factor and a vertical scale factor. If the chroma format sampling structure is 4:2:0, the horizontal scale factor is 2 and the vertical scale factor is 2. If the chroma format sampling structure is 4:2:2, the horizontal scale factor is 2 and the vertical scale factor is 1. If the chroma format sampling structure is 4:4:4, the horizontal scale factor is 1 and the vertical scale factor is 1.

[0219] In (S1530), in response to determining that the saturation BV is valid, the current saturation block may be encoded based on the saturation reference block indicated by the saturation BV.

[0220] Thereafter, the process proceeds to (S1599) and ends.

[0221] The process 1500 may be adapted as appropriate. Steps of the process 1500 may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0222] In one example, the encoded current chroma block is included in a bitstream and sent to a decoder. Coding information can be encoded to indicate that the luma coding region and the chroma coding region are split using two separate coding tree structures. In one example, a flag indicating that the luma coding region and the chroma coding region are split using two separate coding tree structures is encoded and included in the bitstream.

[0223] The embodiments of the present disclosure may be used separately or combined in any order. Also, each of the methods (or embodiments), encoders, and decoders may be implemented in processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored on a non-transitory computer-readable medium.

[0224] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 16 illustrates a computer system (1600) suitable for implementing certain embodiments of the disclosed subject matter.

[0225] Computer software can be coded using any suitable machine code or computer language that can be assembled, compiled, linked, or similar mechanisms to create code containing instructions that can be executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc. directly, or by interpretation, microcode execution, etc.

[0226] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, Internet of Things devices, and the like.

[0227] 16 for computer system 1600 are exemplary in nature and are not intended to suggest any limitation on the use or scope of functionality of the computer software implementing embodiments of the present disclosure. The arrangement of components should not be interpreted as having any dependency or requirement regarding any one or combination of components shown in the exemplary embodiment of computer system 1600.

[0228] The computer system (1600) may include certain human interface input devices that can respond to input by one or more human users, for example, through tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), and olfactory input (not shown). The human interface devices may also be used to capture certain media that are not necessarily directly associated with conscious human input, such as audio (e.g., speech, music, ambient sounds), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., two-dimensional video, three-dimensional video, including stereoscopic video).

[0229] The input human interface devices may include one or more of a keyboard (1601), a mouse (1602), a trackpad (1603), a touchscreen (1610), a data glove (not shown), a joystick (1605), a microphone (1606), a scanner (1607), and a camera (1608) (only one of each is shown).

[0230] The computer system (1600) may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touchscreen (1610), data gloves (not shown), or joystick (1605), but may also be haptic feedback devices that do not function as input devices), audio output devices (e.g., speakers (1609), headphones (not shown), etc.), visual output devices (e.g., screens (1610), including CRT screens, LCD screens, plasma screens, OLED screens, etc., each with or without touchscreen input and haptic feedback capabilities, some of which may output two-dimensional visual output or three-dimensional or higher-dimensional output via means such as stereographic output, virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0231] The computer system (1600) may also include human-accessible storage devices and their associated media, such as optical media including CD / DVD ROM / RW (1620) or similar media (1621) with CDs / DVDs, thumb drives (1622), and removable hard drives or solid state drives (1623), legacy magnetic media such as tape and floppy disks (not shown), dedicated ROM / ASIC / PLD-based devices such as security dongles (not shown), etc.

[0232] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the subject matter disclosed herein does not include transmission media, carrier waves, or other transitory signals.

[0233] The computer system 1600 may also include an interface 1654 to one or more communications networks 1655. The networks may be, for example, wireless, wired, or optical networks. The networks may further include local, wide-area, metropolitan, vehicular, industrial, real-time, delay-tolerant networks, and the like. Examples of networks include local area networks such as Ethernet and wireless LAN; cellular networks including GSM, 3G, 4G, 5G, LTE, and the like; TV wired or wireless wide-area digital networks including cable TV, satellite TV, and terrestrial broadcast TV; and vehicular and industrial networks including CAN buses and the like. Particular networks typically require an external network interface adapter connected to a particular general-purpose data port or peripheral bus 1649 (e.g., a USB port on the computer system 1600). Other networks are typically integrated into the core of the computer system 1600 by connecting to a system bus, as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system (1600) can communicate with other entities. Such communications may be unidirectional receive-only (e.g., broadcast TV), unidirectional transmit-only (e.g., from a CAN bus to a particular CAN bus device), or bidirectional with other computer systems, for example, using local or wide-area digital networks. As noted above, specific protocols and protocol stacks may be used for each of these networks and network interfaces.

[0234] The aforementioned human interface devices, human-accessible storage devices, and network interfaces may be connected to the core (1640) of the computer system (1600).

[0235] The cores (1640) may include one or more central processing units (CPUs) (1641), graphics processing units (GPUs) (1642), dedicated programmable processing units in the form of field programmable gate arrays (FPGAs) (1643), hardware accelerators for specific tasks (1644), and graphics adapters (1650). These devices may be connected via a system bus (1648), along with read-only memory (ROM) (1645), random access memory (1646), and internal mass storage devices (1647) such as non-user-accessible internal hard drives or SSDs. In some computer systems, the system bus (1648) is accessible in the form of one or more physical plugs, allowing expansion with additional CPUs, GPUs, and the like. Peripheral devices may be connected directly to the core's system bus (1648) or via a peripheral bus (1649). In one example, a screen (1610) may be connected to the graphics adapter (1650). Peripheral bus architectures include PCI, USB, and the like.

[0236] The CPU (1641), GPU (1642), FPGA (1643), and accelerator (1644) may combine to execute specific instructions that may constitute the aforementioned computer code. The computer code may be stored in ROM (1645) or RAM (1646). Transient data may also be stored in RAM (1646), while permanent data may be stored, for example, in internal mass storage device (1647). Cache memory, which may be closely associated with one or more of the CPU (1641), GPU (1642), mass storage device (1647), ROM (1645), RAM (1646), etc., may be used to enable fast storage and retrieval from any memory device.

[0237] The computer-readable medium may bear computer code for performing various computer-implemented operations. The medium and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind well known and available to those skilled in the computer software arts.

[0238] By way of example and not limitation, the architecture (1600), and in particular a computer system having a core (1640), can provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media may be media associated with a user-accessible mass storage device, as introduced above, in addition to specific storage of the core (1640) that is non-transitory in nature, such as the core's internal mass storage device (1647) or ROM (1645). Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core (1640). The computer-readable media may include one or more memory devices or chips, depending on particular needs. The software can cause the core (1640), and in particular the processor (including a CPU, GPU, FPGA, etc.) therein, to perform certain processes or portions of certain processes described herein, including defining data structures stored in RAM (1646) and modifying such data structures according to the software-defined processes. Additionally or alternatively, a computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator (1644)) that can operate in place of or in conjunction with software to perform particular processes or portions of particular processes described herein. References to software may, where appropriate, include logic, and vice versa. References to computer-readable media may, where appropriate, include circuitry (such as an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both. The present disclosure includes any suitable combination of hardware and software.

[0239] The use of "at least one of" or "one of" in this disclosure contemplates any one or combination of the listed elements. For example, reference to at least one of A, B, or C; at least one of A, B, and C; at least one of A, B, and / or C; at least one of A through C is intended to include A only, B only, C only, or any combination thereof. Reference to one of A or B and one of A and B is intended to include A or B or (A and B). The use of "one of" does not exclude any combination of the listed elements, where applicable, such as when the elements are not mutually exclusive.

[0240] While this disclosure has described certain exemplary embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. It should thus be understood that those skilled in the art can devise numerous systems and methods that embody the principles of the disclosure, but which are within its spirit and scope.

Claims

1. 1. A video decoding method at a decoder, comprising: receiving a bitstream for a current region in a picture, the current region including a luma coding region and a chroma coding region, and coding information in the bitstream indicating that the luma coding region and the chroma coding region are to be split using separate coding tree structures; determining a chroma block vector (BV) of a current chroma block in the chroma coding domain, the chroma BV indicating a chroma reference block in the picture; determining whether the chroma BV is valid based on whether the collocated luma samples of the chroma reference block are within an allowed range of a luma region that includes the collocated luma samples of the current chroma block; In response to determining that the saturation BV is valid, reconstructing the current saturation block based on the saturation reference block indicated by the saturation BV.

2. 2. The method of claim 1, wherein the current chroma block is predicted in one of: (i) an intra block copy (IBC) mode; (ii) an intra template matching prediction (IntraTMP) mode; and (iii) a direct block vector (DBV) mode.

3. Determining whether the chroma BV is valid in response to the current chroma block being predicted in the IBC mode includes:

3. The method of claim 2, comprising determining that the chroma BV is valid in response to: (i) the collocated luma samples of the chroma reference block are within an allowed IBC reference range of the luma region that includes the collocated luma samples of the current chroma block; and (ii) that chroma samples in the chroma reference block have already been reconstructed, wherein the allowed range is the allowed IBC reference range.

4. In response to determining that the saturation BV is not valid, correcting the saturation BV to obtain an effective saturation BV; and reconstructing the current chroma block based on another chroma reference block indicated by the valid chroma BV; (i) the collocated luma samples of the other chroma reference block are in the allowed IBC reference range of the luma domain, and (ii) the chroma samples in the other chroma reference block have already been reconstructed. The method of claim 3.

5. Determining the chroma BV in response to the current chroma block being predicted in the IBC mode includes: The method of claim 2 , comprising explicitly decoding the chroma BV from the coding information.

6. Determining whether the chroma BV is valid in response to the current chroma block being predicted in the IntraTMP mode or the DBV mode includes:

3. The method of claim 2, comprising determining that the chroma BV is valid in response to: (i) the collocated luma samples of the chroma reference block are within the allowed range of the luma region that contains the collocated luma samples of the current chroma block; and (ii) the chroma samples in the chroma reference block have already been reconstructed.

7. Determining the chroma BV according to whether the current chroma block is predicted in the IntraTMP mode or the DBV mode includes: The method of claim 2 , comprising deriving the chroma BV using the IntraTMP mode or the DBV mode, respectively.

8. the current region is a current coding tree unit (CTU), the luma coding region is a luma coding tree block (CTB) within the current CTU; The method of claim 1 , wherein the chroma coding region is a chroma CTB within the current CTU.

9. a current coding tree unit (CTU) in the picture is divided into four coding units using quadtree partitioning; The method of claim 1 , wherein the current region is a coding unit of the four coding units.

10. 3. The method of claim 2, wherein the allowed range includes at least one of reconstructed luma samples in a current coding tree unit (CTU) or one or more previously reconstructed CTUs, the current CTU including the current region.

11. The method of claim 1 , wherein the coding information in the bitstream includes a flag indicating that the luma coding region and the chroma coding region are split using the separate coding tree structures.

12. 1. A video decoding method at a decoder, comprising: receiving a bitstream for a current region in a picture, the current region including a luma coding region and a chroma coding region, and coding information in the bitstream indicating that the luma coding region and the chroma coding region are to be split using separate coding tree structures; determining a chroma block vector (BV) of a current chroma block in the chroma coding domain, the chroma BV indicating a chroma reference block in the picture; scaling an allowed intra block copy (IBC) reference range of a luma region that includes collocated luma samples of the current chroma block to determine an allowed IBC reference range of the current chroma block; determining whether the chroma BV is valid based on (i) whether chroma samples in the chroma reference block have already been reconstructed, and (ii) whether the chroma reference block is within the allowed IBC reference range of the current chroma block; In response to determining that the saturation BV is valid, reconstructing the current saturation block based on the saturation reference block indicated by the saturation BV.

13. The method of claim 12 , wherein the scaling factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma domain depends on a chroma sampling format.

14. The magnification includes a horizontal magnification and a vertical magnification, In response to the chroma sampling format being 4:2:0, the horizontal magnification is 2 and the vertical magnification is 2; In response to the chroma sampling format being 4:2:2, the horizontal magnification is 2 and the vertical magnification is 1; 14. The method of claim 13, wherein the horizontal scale factor is 1 and the vertical scale factor is 1 in response to the chroma sampling format being 4:4:

4.

15. The method of claim 12 , wherein a scaling factor between the allowed IBC reference range of the current chroma block and the allowed IBC reference range of the luma domain is different in different dimensions.

16. Determining whether the saturation BV is valid includes:

13. The method of claim 12, comprising determining that the chroma BV is valid in response to: (i) the chroma samples in the chroma reference block have already been reconstructed; and (ii) the chroma reference block is within the allowed IBC reference range of the current chroma block.

17. In response to determining that the saturation BV is not valid, correcting the saturation BV to obtain an effective saturation BV; and reconstructing the current chroma block based on another chroma reference block indicated by the valid chroma BV; 17. The method of claim 16, wherein (i) the chroma samples in the chroma reference block have already been reconstructed, and (ii) the other chroma reference block is within the allowed IBC reference range of the current chroma block.

18. Determining the saturation BV comprises: (i) explicitly decoding the chroma BV from the coding information, or (ii) deriving the chroma BV using an intra-template matching prediction (IntraTMP) mode or a direct block vector (DBV) mode; 13. The method of claim 12, comprising:

19. the current region is a current coding tree unit (CTU), the luma coding region is a luma coding tree block (CTB) within the current CTU; The method of claim 12 , wherein the chroma coding region is a chroma CTB within the current CTU.

20. receiving a bitstream for a current region in a picture, the current region including a luma coding region and a chroma coding region, and coding information in the bitstream indicating that the luma coding region and the chroma coding region are to be split using separate coding tree structures; determining a chroma block vector (BV) of a current chroma block in the chroma coding domain, the chroma BV indicating a chroma reference block in the picture; determining whether the chroma BV is valid based on whether the collocated luma samples of the chroma reference block are within an allowed range of a luma region that includes the collocated luma samples of the current chroma block; a processing circuit configured to, in response to the determining that the saturation BV is valid, reconstruct the current saturation block based on the saturation reference block indicated by the saturation BV; 21. Receiving a bitstream for a current region in a picture, the current region including a luma coding region and a chroma coding region, and coding information in the bitstream indicating that the luma coding region and the chroma coding region are split using separate coding tree structures; determining a chroma block vector (BV) of a current chroma block in the chroma coding domain, the chroma BV indicating a chroma reference block in the picture; scaling an allowed intra block copy (IBC) reference range of a luma region that includes collocated luma samples of the current chroma block to determine an allowed IBC reference range of the current chroma block; determining whether the chroma BV is valid based on (i) whether chroma samples in the chroma reference block have already been reconstructed, and (ii) whether the chroma reference block is within the allowed IBC reference range of the current chroma block; a processing circuit configured to, in response to the determining that the saturation BV is valid, reconstruct the current saturation block based on the saturation reference block indicated by the saturation BV;

22. A computer program comprising computer instructions, the computer instructions being executed by a processor of a computing device, causing the computing device to carry out a method according to any one of claims 1 to 19.

Images