Chroma block vector and chroma coding mode derivation

Abstract

The present disclosure includes a method and an apparatus including a processing circuit for deriving a chroma prediction mode for a chroma block in a chroma coding region based on luma coding information of a luma block associated with a position in a reconstructed luma area that is co-located with the chroma block. The chroma coding region is partitioned separately from a co-located luma coding region that includes the reconstructed luma area. The luma coding information indicates that the luma block is coded in a first coding mode (IBC mode or IntraTMP mode) using a first luma BV and a second coding mode. The processing circuit derives a chroma BV for the chroma block based on the luma BV of the luma block and reconstructs the chroma block based on a chroma prediction mode including the first coding mode and the second coding mode.

Description

[Technical Field]

[0001] This application claims the benefit of priority to U.S. Provisional Application No. 63 / 437,973, entitled "Chroma Block Vector Derivation," filed January 9, 2023, which claims the benefit of priority to U.S. Patent Application No. 18 / 376,337, entitled "Chroma Block Vector and Chroma Coding Mode Derivation," filed October 3, 2023. The disclosures of these prior applications are incorporated herein by reference in their entireties.

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

[0003] The background discussion provided herein is intended to provide a general overview of the context for the disclosure. To the extent described in this background section, the work of the named inventors, and aspects of the disclosure that may not otherwise qualify as prior art at the time of filing, are not admitted, explicitly or implicitly, as prior art to the present disclosure.

[0004] Image / video compression can help transmit image / video data across different devices, storage devices, and networks with minimal quality degradation. In some examples, video codec technology 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 being reconstructed 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 a previously reconstructed picture using motion compensation. Motion compensation can be indicated by a motion vector (MV). Summary of the Invention

[0005] Aspects of the present disclosure include methods and apparatuses for video encoding / decoding. In some examples, the apparatus for video decoding 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 derives a chroma prediction mode for a current chroma block in the chroma coding region based on the luma coding information of a first luma block. The first luma block is associated with a first position in a reconstructed luma area that is co-located with the current chroma block. The luma coding information indicates that the first luma block is coded in a combination of (i) a first coding mode (e.g., intra block copy (IBC) mode or intra template matching prediction (IntraTMP) mode) using a first luma block vector (BV) and (ii) a second coding mode (e.g., intra prediction mode, local illumination compensation (LIC) mode, or SKIP mode). The processing circuit derives a chroma block vector (BV) of a current chroma block based on a first luma block vector (BV) of the first luma block, and reconstructs the current chroma block based on a chroma prediction mode that is a combination of a first coding mode and a second coding mode used to code the first luma block.

[0006] In one embodiment, the processing circuit determines that the first luma block is predicted by at least a first coding mode that uses a first luma BV.

[0007] In one embodiment, the second coding mode is an intra-prediction mode, and the first luma block is coded in a combined intra-block copy and intra-prediction (IBC-CIIP) mode. The processing circuit determines a first prediction of the current chroma block using the IBC mode or the IntraTMP mode and the chroma BV. The processing circuit determines a second prediction of the current chroma block using the intra-prediction mode. The processing circuit determines a chroma prediction of the current chroma block based on a weighted sum of the first prediction and the second prediction, and reconstructs the current chroma block based on the chroma prediction.

[0008] In one embodiment, the second coding mode is an intra-prediction mode, and the first luma block is coded using IBC with Geometry Partitioning Mode (IBC-GPM). The processing circuit determines a first prediction of a first sub-partition of the current chroma block using the IBC mode or IntraTMP mode and a chroma BV. The current chroma block is partitioned into a first sub-partition and a second sub-partition using the GPM mode. The processing circuit determines a second prediction of a second sub-partition of the current chroma block using the intra-prediction mode, and reconstructs the current chroma block based on the first and second predictions.

[0009] In one embodiment, the second coding mode is LIC mode, and the first luma block is coded in IBC with LIC (IBC-LIC) mode. The processing circuit determines an initial prediction using the IBC mode or the IntraTMP mode and a chroma BV. The initial prediction is from a reference chroma block indicated by the chroma BV. The processing circuit determines LIC parameters for the current chroma block based on a current template for the current chroma block and a reference template for the reference chroma block. The processing circuit determines a prediction based on the initial prediction and the LIC parameters using the LIC mode. The processing circuit reconstructs the current chroma block based on the prediction.

[0010] In one embodiment, the second coding mode is SKIP mode and the first luma block is coded in IBC-SKIP mode, and the processing circuit determines a prediction using IBC mode or IntraTMP mode and a chroma BV, and reconstructs the current chroma block from the prediction using SKIP mode without using a residual.

[0011] In one embodiment, the processing circuit derives a chroma BV based on a first luma BV of a first luma block and a second luma BV of a second luma block, the second luma block being associated with a second position within the reconstructed luma area that is co-located with the current chroma block.

[0012] In one example, the first luma block is coded using a valid BV in IBC or IntraTMP mode.

[0013] In one example, the bitstream includes intra prediction mode information or IBC mode information indicating that (i) the chroma prediction mode of the current chroma block is derived from the luma coding information of the first luma block, or (ii) the chroma BV is derived from the first luma BV of the first luma block.

[0014] In one example, the processing circuit derives the chroma BV by scaling the first luma BV with a scaling factor that depends on the chroma subsampling format.

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

[0016] In one example, a current coding tree unit (CTU) in a picture is divided into four coding units using quadtree partitioning, and the current region is a coding unit among the four coding units.

[0017] 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]

[0018] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings. [Figure 1] FIG. 1 is a schematic diagram of an exemplary block diagram of a communication system (100). [Figure 2] FIG. 2 is a schematic diagram of an exemplary block diagram of a decoder. [Figure 3] FIG. 2 is a schematic diagram of an exemplary block diagram of an encoder. [Figure 4] 4 illustrates the BVs currently associated with a CU (401), according to some embodiments of the present disclosure. [Figure 5] 1 illustrates a reference sample memory (RSM) update process at four intermediate points during the reconstruction process, according to one embodiment of the present disclosure. [Figure 6] 1 illustrates a left-neighboring coding tree unit (CTU) and a current CTU representing a valid reference region according to one embodiment of the present disclosure. [Figure 7] 1 illustrates an example of a prediction area for an intra block copy (IntraBC) mode in one super-block prediction according to one embodiment of the present disclosure. [Figure 8] 1 illustrates an example of a memory reclamation mechanism or memory update process in an RSM during decoding of a CTU or superblock (SB) in a current picture according to one embodiment of the present disclosure. [Figure 9] 9A-9B show examples of memory update processes in an RSM during decoding of a current SB (or CTU) using (a) horizontal splitting at the SB root (FIG. 9A) or (b) vertical splitting at the SB root (FIG. 9B) according to an embodiment of the present disclosure. [Figure 10] 1 illustrates an example of an intra-template matching prediction (IntraTMP) mode according to one embodiment of the present disclosure. [Figure 11] 10 illustrates the upper and left neighboring blocks used in weight derivation in a joint inter-intra prediction (CIIP) mode, according to one embodiment of the present invention. [Figure 12] 10 illustrates example division lines for geometric partitioning modes in some examples. [Figure 13] 1 illustrates a current chroma block and its colocated chroma area, according to some embodiments of the present disclosure. [Figure 14] 1 shows a flowchart outlining a decoding process according to some embodiments of the present disclosure. [Figure 15] 1 shows a flowchart outlining an encoding process according to some embodiments of the present disclosure. [Figure 16] FIG. 1 is a schematic diagram of a computer system according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] 1 shows 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, which is a video encoder and video decoder in a streaming environment. The disclosed subject matter can be equally applied to other video-enabled applications, including, for example, video conferencing, digital TV, streaming services, and storage of compressed video on digital media, including CDs, DVDs, memory sticks, and the like.

[0020] The video processing system 100 may include a capture subsystem 113, which may include a video source 101, such as a digital camera, that produces 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 is depicted as a thick line to emphasize its high data volume compared to the encoded video data 104 (or coded video bitstream), which may be processed by electronics 120 including a video encoder 103 coupled to the video source 101. The video encoder 103 may 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), depicted as a thin line to emphasize its low data volume compared to the stream of video pictures 102, may be stored on a streaming server 105 for later 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 can include a video decoder 110, for example, within an electronic device 130. The video decoder 110 can decode the incoming copy of the encoded video data 107 and produce an outgoing stream of video pictures 111, which 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) can be encoded according to a particular video coding / compression standard.Examples of such standards include ITU-T Recommendation H.265. In one example, a video coding standard under development is informally known as Versatile Video Coding (VVC). The subject matter disclosed herein may be used in the context of VVC.

[0021] It should be noted that the electronics 120 and 130 may include other components (not shown). For example, the electronics 120 may include a video decoder (not shown), and the electronics 130 may also include a video encoder (not shown).

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

[0023] The receiver (231) can receive one or more coded video sequences, e.g., in a bitstream, to be decoded by the video decoder (210). In one aspect, one coded video sequence is received at a time, and the decoding of each coded video sequence is independent of the decoding of other coded video sequences. The coded video sequences can be received from a channel (201), which can be a hardware / software link to a storage device that stores the coded video data. The receiver (231) can also receive the coded video data along with other data, such as coded audio data and / or auxiliary data streams, which can be forwarded to their respective using entities (not shown). The receiver (231) can separate the coded video sequences from other data. To combat network jitter, a buffer memory (215) can be coupled between the receiver (231) and the entropy decoder / parser 520 (hereinafter, "parser (220)"). In certain applications, the buffer memory (215) is part of the video decoder (210). In others, it may be external to the video decoder 210 (not shown). In still others, there may be a buffer memory (not shown) external to the video decoder 210, e.g., to combat network jitter, and there may be another buffer memory 215 internal to the video decoder 210, e.g., to handle playback timing. When the receiver 231 is receiving data from a store-and-forward device with sufficient bandwidth and controllability or from an equally synchronous network, the buffer memory 215 may not be required or may be small. For use over best-effort packet networks, such as the Internet, the buffer memory 215 may be required and may be relatively large and advantageously sized adaptively, and may be implemented, at least in part, in an operating system or similar element (not shown) external to the video decoder 210.

[0024] The video decoder (210) may include a parser (220) for reconstructing symbols (221) from the coded video sequence. These symbol categories include information used to manage the operation of the video decoder (210) and possibly information for controlling a rendering device, such as a render 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. The control information for the rendering device(s) 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 may be according to a video coding technique or standard and may follow various principles, including variable-length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The parser (220) may extract from the coded video sequence a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder 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 from the coded video sequence information, such as transform coefficients, quantization parameter values, motion vectors, etc.

[0025] The parser (220) may perform an entropy decoding / parsing process on the video sequence received from the buffer memory (215) to produce symbols (221).

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

[0027] Beyond the functional blocks already described, the video decoder (210) may be conceptually subdivided into a number of functional units, as described below. In practical implementations 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 subject matter of this disclosure, the following conceptual division into functional units is appropriate:

[0028] The first unit is a scalar / inverse transform unit (251), which receives quantized transform coefficients as symbol(s) (221) from the parser (220), along with control information including which transform to use, block size, quantization coefficients, quantization scaling matrix, etc. The scalar / inverse transform unit (251) can output blocks of sample values ​​that can be input to an aggregator (255).

[0029] In some cases, the output samples of the scaler / inverse transform unit (251) may relate to intra-coded blocks. Intra-coded blocks are blocks that 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 can 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 fetched from the current picture buffer (258). The current picture buffer (258), for example, buffers partially reconstructed and / or fully reconstructed current pictures. In some cases, the aggregator (255) adds, 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).

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

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

[0032] The output of the loop filter unit (256) can be a sample stream that can be output to a render device (212), which can also be stored in a reference picture memory (257) for use in future inter-picture prediction.

[0033] Once a particular coded picture is fully reconstructed, it can be used as a reference picture for future prediction. For example, once a coded picture corresponding to a current picture is fully reconstructed and that 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 next coded picture.

[0034] The video decoder (210) may perform decoding according to a given video compression technology or standard, such as ITU-T Recommendation H.265. The coded video sequence may conform to the syntax specified by the video compression technology or standard used, in the sense of adhering 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, such that only those tools are available for use under that profile. Compliance also requires that the complexity of the coded video sequence be within a range specified by the level of the video compression technology or standard. In some cases, the level constrains the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may optionally be further constrained through a Hypothetical Reference Decoder (HRD) specification and metadata for HRD buffer management signaled in the coded video sequence.

[0035] In one embodiment, the receiver (231) may receive additional (redundant) data along with the encoded video. The additional data may be included as part of one or more coded video sequences. The additional data may be used by the video decoder (210) to properly decode the data and / or to 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.

[0036] 3 shows an exemplary block diagram of a video encoder (303). The video encoder (303) is included in an electronic device (320). For example, 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.

[0037] The video encoder (303) may receive video samples from a video source (301) (not part of the electronics (320) in the example of FIG. 6) that may capture video image(s) to be coded by the video encoder (303). In another example, the video source (301) is part of the electronics (320).

[0038] 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 that may be of any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 Y CrCB, RGB, ...), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media service provision system, the video source (301) may be a storage device containing pre-prepared video. In a video conferencing system, the video source (301) may be a camera capturing local image information as a video sequence. The video data may be provided as multiple individual pictures that convey motion when viewed in sequence. The pictures themselves may be organized as a spatial array of pixels, each of which may have one or more samples, depending on the sampling structure, color space, etc. used. The following discussion focuses on samples.

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

[0040] 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, e.g., a symbol stream, based on an input picture to be coded and one or more reference pictures) and a (local) decoder (333) embedded in the video encoder (303). The decoder (333) reconstructs the symbols to generate sample data, in a manner similar to that used by a (remote) decoder. The reconstructed sample stream (sample data) is input to a reference picture memory (334). Because decoding of the symbol stream yields bit-accurate results independent of the decoder location (local or remote), the contents of the reference picture memory (334) are also bit-accurate 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 synchronism (and the resulting drift when synchronism cannot be maintained, for example due to channel errors) is also used in some related art.

[0041] The operation of the "local" decoder (333) may be the same as that of a "remote" decoder, such as the video decoder (210), which has already been described in detail above in connection with Figure 2. However, briefly referring also to Figure 2, because symbols are available and the encoding / decoding of the 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).

[0042] In one embodiment, decoder technology, excluding parsing / entropy decoding, present in the decoder is present in the corresponding encoder in the same or substantially the same functional form. Therefore, the subject matter of this disclosure focuses on decoder operation. A description of the encoder technology can be omitted, as it is the reverse of the decoder technology that has been thoroughly described. In certain areas, more detailed descriptions are provided below.

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

[0044] The local video decoder (333) may decode coded video data of pictures that may be designated as reference pictures based on symbols created by the source coder (330). The operation of the coding engine (332) may 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 error. The local video decoder (333) may replicate the decoding process that may be performed by a video decoder on the reference pictures, causing the reconstructed reference pictures to be stored in the reference picture memory (334). In this way, the video encoder (303) may locally store copies of reconstructed reference pictures that have content in common with reconstructed reference pictures that will be obtained by a far-end video decoder.

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

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

[0047] The outputs of all the aforementioned functional units may be subjected to entropy coding in 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.

[0048] A transmitter (340) may buffer the coded video sequence(s) produced by the entropy coder (345) and prepare them for transmission over a communication channel (360), which may be a hardware / software link to a storage device that stores the coded video data. The transmitter (340) may 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).

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

[0050] 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 several different types of intra-pictures, including, for example, Independent Decoder Refresh (IDR) pictures.

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

[0052] Bidirectionally predicted pictures (B pictures) can be coded and decoded using 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 more than two reference pictures and associated metadata for the reconstruction of a single block.

[0053] A source picture is generally spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and may be coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks as determined by the coding assignment applied to their respective pictures. For example, blocks of an I-picture may be coded non-predictively, or they may be 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 coded non-predictively or via spatial or temporal prediction with reference to one previously coded reference picture. Blocks of a B-picture may be coded non-predictively or via spatial or temporal prediction with reference to one or two previously coded reference pictures.

[0054] The video encoder (303) may perform coding operations according to a predetermined video coding technique or standard, such as ITU-T Recommendation H.265. In 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. The coded video data may therefore conform to a syntax defined by the video coding technique or standard being used.

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

[0056] 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 coded / decoded, called the current picture, is divided into multiple blocks. When 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.

[0057] 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, both of which are earlier in a video than the current picture in decoding order (but may be earlier and later, respectively, in display order). A block in the current picture can be coded with a first motion vector pointing to a first reference block in the first reference picture and a second motion vector pointing to a second reference block in the second reference picture. The block can be predicted by a combination of the first and second reference blocks.

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

[0059] 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 multiple coding tree units (CTUs) for compression, and the CTUs within a picture have the same size, such as 64×64 pixels, 32×32 pixels, or 16×16 pixels. Generally, a CTU includes three coding tree blocks (CTBs), one luma CTB and two chroma CTBs. Each CTU may be recursively quadtree-decomposed into one or more coding units (CUs). For example, a 64×64 pixel CTU can be divided into one CU of 64×64 pixels, four CUs of 32×32 pixels, or 16 CUs of 16×16 pixels. In one example, each CU is analyzed to determine the prediction type of that CU, such as an inter-prediction type or an intra-prediction type. A CU is divided into one or more prediction units (PUs) depending on temporal and / or spatial predictability. Generally, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, prediction operations during coding (encoding / decoding) are performed in units of prediction blocks. Taking a luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values ​​(e.g., luma values), such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, and the like.

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

[0061] An example of an intra block copy mode (also called IntraBC mode or IBC mode), as used in, for example, HEVC and VVC, is described below.

[0062] Some IBC coding tools are used in the HEVC Screen Content Coding (SCC) extension as current picture referencing (CPR). The IBC mode can use the coding technique used for inter prediction when the current picture (also referred to as the current frame) is used as a reference picture (also referred to as the reference frame) in the IBC mode. The benefit of using the IBC mode is the reference structure of the IBC mode, which can use a two-dimensional (2D) space vector as an expression for the addressing mechanism to the reference sample. The benefit of the IBC mode architecture is that the integration of IBC requires only relatively small changes to the specification, reducing the implementation burden for manufacturers who have already implemented a certain prediction technique, such as in HEVC Version 1. CPR in the HEVC SCC extension can be said to be a special inter prediction mode, resulting in the same or similar syntax structure as that of the inter prediction mode and a decoding process similar to that of the inter prediction mode.

[0063] The IBC mode may be integrated into the inter prediction process. In some examples, the IBC mode (or CPR) is an inter prediction mode, and an intra-only predicted slice becomes the predicted slice to enable the use of the IBC mode. When the IBC mode is applicable, the coder can extend the reference picture list by one entry for a pointer to the current picture. For example, the current picture uses a one-picture-sized buffer in a shared decoded picture buffer (DPB). The IBC mode signaling can be implicit. For example, the CU can use the IBC mode when the selected reference picture points to the current picture. In various embodiments, the reference samples used in the IBC process are not filtered, which differs from normal inter prediction. The corresponding reference picture used in the IBC process 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. When the reconstructed picture is a reference picture, a filtered version of the reconstructed picture may be added back into the DPB by the coder as a short-term reference.

[0064] In block vector (BV) coding, referencing the reconstructed area can be done by 2D BVs 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, the luma BVs are at integer resolution, rather than 1 / 4 (or 1 / 4 pel) precision MVs as used in regular inter coding CTUs.

[0065] 4 illustrates a BV associated with a current CU (401) according to one embodiment of the present disclosure. Each square (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) will be coded after coding the current CU (401).

[0066] In one example, such as 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 to enable wavefront parallel processing (WPP). A BV allowed in HEVC can refer to a block within the reference area (e.g., the gray-shaded area excluding the two CTUs (400(1)-400(2))). For example, a BV (405) allowed in HEVC refers to the reference block (411).

[0067] In one example, such as in VVC, only the current CTU (400(4)) and the left neighboring CTU (400(3)) to the left of the current CTU (400(4)) are allowed as reference areas 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 left-shifted (e.g., by 2) before being added to the BV predictor to determine the final BV.

[0068] The IBC mode may differ from the inter-prediction mode, and therefore, special handling may be used for implementation and execution reasons, as described below. In one embodiment, the IBC reference samples are not filtered; for example, reconstructed samples before in-loop filtering processes, including but not limited to a deblocking filter (DBF) and a sample adaptive offset (SAO) filter, are used as reference samples in the IBC mode, while other inter-prediction modes, such as those used in HEVC, use filtered samples as reference samples. In one embodiment, there is no luma sample interpolation for the IBC mode. In one embodiment, chroma sample interpolation is used when the chroma BV is non-integer when derived from the luma BV. In one embodiment, the chroma BV is non-integer and the reference block is near the boundary of the available area. For example, the surrounding reconstructed samples are outside the boundary for performing chroma sample interpolation. A BV pointing to a single boundary neighbor line may not be able to avoid such cases.

[0069] An exemplary IBC architecture, such as that used in VVC, may be described as follows: The valid reference area for an IBC mode, such as that used in the HEVC SCC extension, can include almost the entire already reconstructed area of ​​the current picture, with some exceptions for parallel processing purposes, such as those described in FIG. 4. FIG. 4 illustrates the reference area for the IBC mode in HEVC and VVC configurations. 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 drawback of the concept in HEVC is the additional memory requirement in the DPB, for which hardware implementations use external memory. In one example, the additional access to external memory results in increased memory bandwidth, making the use of the DPB less attractive. In some embodiments, an IBC mode, such as that in VVC, can use fixed memory, which can be realized on-chip, thus significantly reducing the complexity of implementing the IBC mode in a hardware architecture. In one embodiment, a significant change addresses the signaling concept that deviates from integration within the inter prediction process, such as in the HEVC SCC extensions.

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

[0071] An example of the syntax and semantics of an IBC mode, such as that used in VVC, may be described as follows: An IBC architecture, such as that used in VVC, may form a dedicated coding mode, where the IBC mode is a third prediction mode in addition to the intra-prediction mode and the inter-prediction mode. The bitstream may carry an IBC syntax element (e.g., an sIBC syntax element) indicating the IBC mode for 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 to realize the continuous memory update mechanism of the RSM. The reference sample addressing mechanism represents a two-dimensional offset and can be the same as that used in the HEVC SCC extension by 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 the IBC mode only for luma coding blocks.

[0072] The reference area and sample memory in an IBC mode, such as that used in VVC, may be described below. An IBC design, such as that used in VVC, may use a fixed memory size (e.g., 128x128) for each color component to store reference samples, thus enabling on-chip placement feasibility in hardware implementation. In one example, the maximum CTU size in VVC is 128x128. In one embodiment, the RSM may store samples of a single CTU when the maximum CTU size configuration is equal to 128x128. In one example, a feature of the RSM includes a continuous update mechanism that may replace the reconstructed samples of a left-neighboring CTU with the reconstructed samples of the current CTU.

[0073] FIG. 5 shows an example of an RSM (e.g., a simplified RSM example) for the 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 the current CTU reconstruction, in one example, the RSM (510) includes only the reference samples of the left neighboring CTU. At the other three intermediate points (502)-(504), the reconstruction process replaces the samples of the left neighboring CTU with the variants of the current CTU. An implicit partitioning of the RSM (510) can be applied, dividing the RSM (510) into four disjoint 64×64 areas (511)-(514). Area resetting can be performed when the coder processes the first coding unit within the corresponding area when mapping the RSM to a CTU, reducing hardware implementation effort.

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

[0075] 5, the RSM (510) can include a portion of the current CTU and / or a portion of the left adjacent CTU. 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).

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

[0077] 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 coded or reconstructed), and a sub-area (533) in the upper left region of the current CTU will be coded thereafter. The RSM (510) is updated to include a portion of the left adjacent CTU and a portion of the current CTU. For example, portions (512)-(514) in the RSM (510) store the same reconstructed samples in the left adjacent CTU 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 reconstructed samples of the left adjacent CTU stored in portions (512)-(514) and reconstructed samples of the subarea (531) of the current CTU stored in portion (511).

[0078] 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 subareas (541)-(543). Subarea (541) (shaded dark gray) has already been coded (e.g., encoded or reconstructed), subarea (542) is the current CU being coded (e.g., being coded or reconstructed), and subarea (543) (not shaded white) will be coded later. Portions (513)-(514) in the RSM (510) store reconstructed samples in the same left-neighboring CTU as at the first intermediate point (501), while portions (511)-(512) are updated so that portion (511) stores reconstructed samples for the upper left region of the current CTU and portion (512) stores subarea (541) of the current CTU. The reference area at the third intermediate point (503) may include (i) reconstructed samples of the left adjacent CTU stored in portions (513)-(514), and (ii) reconstructed samples of the upper left region of the current CTU stored in portion (511) and the sub-area (541) of the current CTU stored in portion (512).

[0079] 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 coded or reconstructed), and sub-area (553) (not shaded white) will be coded later. Portion (511) stores reconstructed samples of the upper-left region within the current CTU, as at the third intermediate point (503), while portions (512)-(514) are updated so that portions (512)-(513) store reconstructed samples of 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 time point (504) can include the reconstructed samples of the current CTU stored in portions (511)-(514). The RSM (510) at the fourth intermediate time point (504) does not include the area in the left adjacent CTU.

[0080] Figure 6 shows a left-neighboring CTU (601) and a current CTU (602) that represent valid reference areas for the RSM design and continuous update mechanism. The left-neighboring 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, unshaded areas can include replaced or unreconstructed samples.

[0081] Figure 6 spatially illustrates an example of the RSM continuous update concept. At the time of reconstruction in the example shown in Figure 6, the RSM update process replaces samples covered by the white unshaded areas 611-613 in the left-neighboring 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-neighboring CTU 601 and (ii) areas 621-622 and subarea 651 of the current CTU 602.

[0082] An RSM can include more than one left-neighboring CTU, for example, when the maximum CTU size is smaller than the RSM size (e.g., 128x128), and multiple left-neighboring CTUs 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 can store samples of 15 left-neighboring CTUs.

[0083] An example of block vector (BV) coding for IBC mode, such as that used in VVC, is described below. BV coding can use 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 history-based candidates to avoid duplicate entries in the final candidate list. In addition, in inter prediction, candidate list construction may include pair-averaged candidates. In one embodiment, the IBC list construction process considers only the BVs of two spatial neighbors and five history-based BVs (HBVPs), and only the first HBVP is compared with the spatial candidate when adding it to the candidate list. While regular inter prediction can use two different candidate lists, one for merge mode and another for regular mode, the candidate list in IBC mode is for both cases. In IBC mode, merge mode can use up to six candidates in the candidate list, and normal mode uses only the first two candidates in the candidate list. Block vector differential (BVD) coding in IBC mode can use the motion vector differential (MVD) process used in inter prediction and can result in a final BV of any suitable size. In one embodiment, the reconstructed BV can point to an area outside the reference sample area, and therefore a correction is made to the reconstructed BV, for example, by using a modulo operation with the width and height of the RSM to remove the absolute offset in each direction (e.g., horizontally and vertically).

[0084] The derivation process for chroma BVs may include the following: When the current coding tree type is SINGLE_TREE, a chroma block corresponds to a luma block. The BVs of chroma blocks coded in IBC mode may be derived from the BVs of luma blocks using appropriate scaling that takes into account the chroma sampling format (e.g., 4:2:0, 4:2:2) and the chroma BV precision. The derivation process may be described as follows: The input to the process may include bvL, a luma BV with 1 / 16 fractional sample precision. The output of the process may include bvC, a chroma BV with 1 / 32 fractional sample precision. The chroma BVs may be derived from the corresponding luma BVs. The chroma BV bvC may be derived as follows:

number

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

[0086] In monochrome sampling (eg, the chroma format is Monochrome), there is only one sample array that is nominally considered the luma array.

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

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

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

[0090] The number of bits required to represent each of the samples in the luma and chroma arrays in a video sequence can be in the range of 8 to 16 inclusive.

[0091] The IntraBC mode, such as that used in AV1, is described below. In one embodiment, such as in AV1, the intra block copy (IntraBC) mode can use a vector to identify the location of a predictive block within the same picture of a current block. The 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 considered as "motion compensation" within the current picture using the BV as the motion vector.

[0092] For a current block, a flag used to indicate whether IntraBC mode is enabled for the current block may be transmitted in the bitstream first. Then, if the current block is coded in IntraBC mode, a BV difference may be derived by subtracting the predicted BV from the current BV. The BV difference may be classified into multiple types (e.g., four types) according to the horizontal and vertical components of the BV difference value. This type information may be signaled in the bitstream, followed by the BV difference values ​​of the two (horizontal and vertical) components.

[0093] IntraBC mode can be particularly useful for coding certain content, such as screen content. In one example, IntraBC mode also introduces challenges in hardware design. To facilitate the hardware design, the following modifications can be adopted: When IntraBC mode is enabled, the loop filter is disabled. The loop filter may include a DBF, a constrained directional enhancement filter (CDEF), a loop restoration (LR) filter, and / or the like. By disabling the loop filter, a second picture buffer dedicated to enabling IntraBC mode can be avoided.

[0094] To facilitate parallel decoding, predictions cannot exceed a constrained area. In one embodiment, for one 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 the IntraBC mode only if its vertical coordinate is less than y0 and its horizontal coordinate is less than x0+2(y0-y).

[0095] To allow for hardware writeback delay, the nearest reconstruction area cannot be accessed by IntraBC prediction. The constrained nearest reconstruction area can be 1 to n superblocks (or CTUs). Thus, in addition to the above-mentioned changes, if the coordinates of the top-left position of a superblock (or CTU) are (x0, y0), the prediction at position (x, y) can be accessed by IntraBC mode if the vertical coordinate is less than y0 and the horizontal coordinate is less than x0+2(y0-y)-D, where D represents the constrained nearest reconstruction area for IntraBC mode. When D is, for example, two superblocks as defined in AVM, the prediction area is shown in Figure 7.

[0096] FIG. 7 illustrates an example of a prediction area for IntraBC mode in one superblock prediction according to one embodiment of the present disclosure. Each square may represent a superblock or a CTU. The gray-shaded areas may include allowable search areas accessible in IBC mode for each current superblock (710) being reconstructed, for example. The black-shaded areas may include non-allowable search areas inaccessible in IBC mode for each current superblock (710), for example, when D includes two superblocks (or two CTUs). The white-unshaded areas include superblocks to be coded (e.g., 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). Superblocks (721)-(722) are not accessible for the current superblock (710(1)). The allowed search area (730) is currently accessible for the superblock (710(1)).

[0097] The IntraBC mode with a local reference range, such as in AV1, may be described below. The IntraBC mode can be used with a local reference range, such as in the AV1 codec. In one embodiment, a 64x64-based memory reuse mechanism is applied, and an "on-chip" memory (referred to as RSM) of one superblock (SB) size is allocated to store reference samples, as shown in Figures 8 and 9A-9B. For example, the following modifications (1)-(3) are made to the design of the IntraBC mode in AV1: (1) The maximum block size in IntraBC mode may 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 located within the current SB or one SB to the left of the current SB. (3) When any of the 64x64 unit reference sample memories starts updating with reconstructed samples from the current SB, previously stored reference samples within the entire 64x64 unit (e.g., from the left SB) are marked as unavailable for generating predicted samples in IntraBC mode.

[0098] FIG. 8 shows an example of a memory reclamation mechanism or memory update process in an RSM during decoding of a CTU or SB (e.g., current SB (801)) in a current picture according to one 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 a picture, such as the current SB (801) being coded and the left-neighboring SB (802) in the current picture, in states (0)-(4). Quadtree partitioning may 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.

[0099] 8, at the start of coding each SB (state (0)), the RSM stores samples of the previous coded SB (e.g., the left adjacent SB (802)). When the current block is located 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 of the current coding region (e.g., the current 64x64 coding region). Thus, the samples in the RSM (810) can be gradually updated with samples in the current SB (801), for example, as shown from state (1) to state (4).

[0100] Referring to state (1), the current block (811) is located in region 4 in the current SB (801), and the corresponding region (e.g., the top-left region) in the RSM (810) is emptied and may be used to store samples of region 4, the current region being coded. Referring to row 3, a BV (e.g., an encoded BV or a decoded BV) (821) may point from the current block (811) to a reference block (831) within a search range (841) for the current block (811) (the boundary of the search range (841) is marked with a dashed line). Referring to row 2, a corresponding offset (851) in the RSM (810) may point from the current block (811) to the reference block (831) within the RSM (810). In state (1), the search range (841) includes regions 1-3 in the left-neighboring SB (802) and a coded subregion (861) within region 4. The search range (841) does not include area 0 in the left adjacent SB (802).

[0101] Referring to state (2), the current block (812) is located 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 may be used to store samples of region 5, the current region being coded. The BV (822) may point from the current block (812) to a reference block (832) within a search range (842) for the current block (812) (the boundary of the search range (842) is marked with a dashed line). The corresponding offset (852) in the RSM (810) may 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 in the left-neighboring SB (802) and (ii) region 4 and the coded subregion (862) within region 5 in the current SB (801). The search range (842) does not include the area 0-1 in the left adjacent SB (802).

[0102] Referring to state (3), the current block (813) is located in region 6 in the current SB (801), and the corresponding region in the RSM (810) (e.g., the bottom-left region) is emptied and may be used to store samples of region 6, the current region being coded. The BV (823) may point from the current block (813) to a reference block (833) within a search range (843) for the current block (813) (the boundary of the search range (843) is marked with a dashed line). The corresponding offset (853) in the RSM (810) may 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 left-neighboring SB (802) and (ii) regions 4-5 and the coded subregion (863) within region 6 in the current SB (801). The search range (843) does not include the area 0-2 in the left adjacent SB (802).

[0103] Referring to state (4), the current block (814) is located in region 7 in the current SB (801), and the corresponding region in the RSM (810) (e.g., the bottom-right region) is emptied and may be used to store samples of region 7, the current region being coded. The BV (824) may point from the current block (814) to a reference block (834) within a search range (844) for the current block (814) (the boundary of the search range (844) is marked with a dashed line). The corresponding offset (854) in the RSM (810) may 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 subregion (864) within region 7. The search range (844) does not include regions 0-3 in the left-neighboring SB (802).

[0104] When the current SB (801) is completely coded (state (4)), the entire RSM (810) may be filled with the samples (e.g., all samples) of the current SB (801).

[0105] In the example shown in Figure 8, the current SB (801) is first partitioned using quadtree partitioning. The coding order of the four 64x64 regions can be 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. In other block partitioning decisions, such as those shown in Figure 9B, the RSM update process can be similar, e.g., using reconstructed samples in the current SB to replace each region in the RSM.

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

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

[0108] 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).

[0109] 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), bottom left block (state 2), top right block (state 3), and bottom right block (state 4).

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

[0111] 1. Referring to state (1) in Figures 9A-9B, when the current block (931) enters 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) in the current SB (902). The search range of the current block (931) can include blocks 1-3 and block (961).

[0112] 2. Referring to state (2) of FIG. 9A or state (3) of FIG. 9B, when the current block (932) enters the upper right block 5 (e.g., a 64×64 block) of the current SB (901), in addition to the already reconstructed samples in the current SB (902), (a) for example, as shown in state (2) of FIG. 9A, if the luma sample located at (0,64) relative to the current SB (901) has not yet been reconstructed, the current block (932) will be reconstructed from the reference samples in the lower left block 2 (e.g., a 64×64 block) and lower right block 3 (e.g., a 64×64 block) of the left SB (902). (b) For example, when a luma sample located in the upper left corner (e.g., (0,64) relative to the current SB (901)) is being reconstructed, as shown in state (3) of Figure 9B, the current block (932) can refer to a reference sample in block 3 (e.g., a 64x64 block) to the lower right of the left SB (902), and the search range of the current block (932) can include blocks 3, 4, and 6 and block (962).

[0113] 3. Referring to state (3) of FIG. 9A or state (2) of FIG. 9B, when the current block (933) is located in the lower left block of the current SB (901), in addition to the already reconstructed samples in the current SB (902), (a) for example, as shown in state (2) of FIG. 9B, when the luma position (64,0) for the current SB (901) has not yet been reconstructed, the current block (933) can refer to reference samples in the upper right block 1 (e.g., a 64x64 block) and the lower right block 3 (e.g., a 64x64 block) of the left SB (902), and the current block (933) can refer to the reference samples in the upper right block 1 (e.g., a 64x64 block) and the lower right block 3 (e.g., a 64x64 block) of the left SB (902). The search range of block (933) can include blocks 1, 3, and 4 and block (963); otherwise, (b) for example, as shown in state (3) of Figure 9A, when the luma sample located at the upper left corner of block 5 (e.g., (64,0) relative to the current SB (901)) is being reconstructed, 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 current block (933) can include blocks 3-5 and block (963).

[0114] 4. If the current block (934) is in block 7 to the lower 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).

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

[0116] The prediction signal can be generated by matching a current template (1010), such as an L-shaped causal neighbor 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 may include multiple CTUs (or SBs). Referring to FIG. 10, the search area may 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 may include any suitable cost function, such as the sum of absolute differences (SAD).

[0117] 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 use the block (e.g., (1021)) associated with the template with the smallest SAD as the predicted block.

[0118] The dimensions of the region indicated by (SearchRange_w, SearchRange_h) can be set to be proportional to the block dimensions (BlkW, BlkH) to have a fixed number of SAD comparisons per pixel.

number

[0119] The parameter 'a' may be a constant that controls the trade-off between gain and complexity. In one example, 'a' is 5.

[0120] The intra template matching tool may be enabled for CUs with a specific size, for example, width and height sizes less than or equal to 64. The maximum CU size for IntraTMP mode may be configurable.

[0121] IntraTMP mode may be signaled at the CU level, for example, through a dedicated flag when decoder-side intra mode derivation (DIMD) is not currently used for the CU.

[0122] Chroma IBC mode may be enabled in the context of a dual tree block structure. In an example, such as in VVC, when the coding tree type is a dual tree type, IBC mode is applied only to luma coding blocks, and chroma intra-coding blocks may use only other intra-prediction modes. In some examples, the above method may limit the coding efficiency of intra-chroma coding blocks for chroma separation trees (e.g., indicated by DUAL_TREE_CHROMA). In some examples, chroma IBC mode (e.g., implementing IBC mode for chroma blocks) may be enabled for chroma separation tree cases.

[0123] A combined inter and intra prediction (CIIP) mode may be applied in video coding, such as in VVC. When a CU is coded in merge mode, if the CU contains at least 64 luma samples (e.g., CU width × CU height is 64 or more), and if both the CU width and CU height are smaller than 128 luma samples, a flag (e.g., an additional flag) may be signaled to indicate whether the CIIP mode is applied to the CU (or the current CU). CIIP prediction or CIIP mode may combine an inter prediction signal with an intra prediction signal. The inter prediction signal P in CIIP mode may be inter can be derived using the same inter prediction process as normally applied in merge mode. intra may be derived according to a normal intra prediction process as a planar mode. Then, the intra prediction signal and the inter prediction signal may be combined using a weighted average. Figure 11 shows the upper neighbor block (or upper neighbor) (1191) and the left neighbor block (or left neighbor) (1192) used in CIIP weight derivation according to one embodiment of the present invention. The weight (or weight value) (wt) may be calculated based on the coding modes of the upper neighbor block (1191) and the left neighbor block (1192) as follows: - if the top neighbor (1191) is available and is intra-coded, the parameter isIntraTop is set to 1, otherwise isIntraTop is set to 0; - if the left neighbor (1192) is available and is intra-coded, the parameter isIntraLeft is set to 1, otherwise isIntraLeft is set to 0; - if (isIntraLeft+isIntraTop) is equal to 2, then the weight (wt) is set to 3; - Otherwise, if (isIntraLeft+isIntraTop) is equal to 1, then wt is set to 2; - Otherwise, set wt to 1.

[0124] CIIP Forecast P CIIP can be formed as follows:

number

[0125] In some examples (e.g., VVC), a geometric partitioning mode (GPM) is supported for inter prediction. The geometric partitioning mode is signaled as a type of merge mode using a CU-level flag, along with other merge modes such as normal merge mode, MMVD mode, CIIP mode, sub-block merge mode, and the like. In some examples, the CU size w×h is 2, where m, n∈{3...6}, except for 8×64 and 64×8. m ×2 n For , a total of 64 partitions are supported by the geometric partitioning mode.

[0126] In some examples, when the geometric partitioning mode is used, the CU is divided into two parts by a geometrically positioned straight line, also referred to as a division line.

[0127] FIG. 12 shows examples of division lines for the geometric partitioning mode in some examples. The division lines are grouped by the same angle. Specifically, each rectangle (1201) in FIG. 12 represents a CU. Multiple parallel lines are shown within each rectangle. The multiple parallel lines correspond to division lines of the same angle. In FIG. 12, three division lines are shown at different positions within the block for the same angle. The multiple division lines have different offsets.

[0128] The position of the split line can be mathematically derived based on the angle and offset parameters of a particular partition. In one example, each part of the two geometric partitions caused by the split line within a CU is inter-predicted using its own motion, and only uni-prediction is allowed for each partition. Thus, each part has one motion vector and one reference index. The uni-prediction motion constraint is applied to ensure that CUs in GPM mode can be coded as conventional bi-predictive, e.g., two motion-compensated predictions are performed for each CU.

[0129] In some examples, when a geometric partitioning mode is used for the current CU, a geometric partition index indicating the partition mode of the geometric partition (e.g., indicating the angle and offset) and two merge indices (one for each partition) are further signaled. In some examples, the number of maximum GPM candidate sizes is explicitly signaled in the SPS, specifying the syntax binarization for the GPM merge indices. After predicting each portion of the geometric partition, the sample values ​​along the geometric partition edges are adjusted using a blending process with adaptive weights to obtain a prediction signal for the entire CU. Then, a transform and quantization process can be applied to the entire CU, similar to other prediction modes. Finally, the motion field of the CU predicted using the geometric partitioning mode is stored.

[0130] Local illumination compensation (LIC) can be performed. In one embodiment, LIC or LIC mode is an inter-prediction technique that models local illumination variations between a current block and a respective predicted block as a function of illumination variations between a current block template and a reference block template. The parameters of the function (e.g., LIC function) can be represented by a scale α and an offset β, which form a linear equation, e.g., α*p[x]+β, to compensate for illumination changes. p[x] may be a reference sample pointed to by the MV at position x on the reference picture. Because α and β can be derived based on the current block template and the reference block template, no signaling overhead for α and β is required, except that a LIC flag is signaled for AMVP mode to indicate the use of LIC.

[0131] In one embodiment, local illumination compensation is used for uni-predictive inter CUs with the following modifications: intra-neighbor samples can be used in LIC parameter derivation, LIC is disabled for blocks with fewer than 32 luma samples, for both non-subblock and affine modes, LIC parameter derivation can be performed based on the template block samples corresponding to the current CU instead of the partial template block samples corresponding to the first top-left 16x16 unit, and reference block template samples are generated by using motion compensation (MC) with block MVs without rounding the block MVs to integer pel precision.

[0132] A combined intra block copy and intra prediction (IBC-CIIP) mode may be used in video coding. IBC-CIIP uses an IBC mode and intra prediction to generate two prediction signals (e.g., an IBC prediction signal C ibc and the intra-prediction signal P intra), and these two prediction signals can be weighted and added together to generate the final prediction (or final prediction signal). For IBC-CIIP mode, the following formula can be used:

number

[0133] P ibc and P intra can represent (or denote) an IBC prediction signal and an intra prediction signal. ibc , shift) may be set equal to (13,4) and (1,1) for IBC merge mode and IBC AMVP mode, respectively.

[0134] An intra-prediction mode (IPM) candidate list may be used to generate an intra-prediction signal, and the size of the IPM candidate list may be predetermined as 2. An IPM index may be signaled to indicate which IPM is used.

[0135] Other IBC designs are described below. In one embodiment, when the intra prediction mode is planar mode or DC mode, the final prediction can be obtained as equation (6), where P ibc and P intra can represent (or denote) the IBC prediction signal and the intra prediction signal, respectively. ibc , shift) may be set equal to (1,2) if both the top CU and the left CU are intra-coded. ibc , shift) may be set equal to (2,2) if one of the top CU and left CU is intra-coded. ibc, shift) may be set equal to (3,2) if both the top CU and the left CU are IBC coded. Otherwise (i.e., if the intra prediction is in directional mode), the final prediction may be obtained by adaptively switching between intra-mode and IBC mode prediction samples. For illustrative purposes, assuming that the size of the current CU is w×h and the intra mode is horizontal mode or vertical mode, when both the upper and left adjacent CUs are intra-coded, the left 3 / 4w×h part (intra mode is horizontal mode) or the upper w×3 / 4h part (intra mode is vertical mode) of the final prediction is set as the intra-prediction signal; when only one of the upper and left CUs is intra-coded, the left 1 / 2w×h part (intra mode is horizontal mode) or the upper w×1 / 2h part (intra mode is vertical mode) of the final prediction is set as the intra-prediction signal; when both the upper and left CUs are IBC or inter-coded, the left 1 / 4w×h part (intra mode is horizontal mode) or the upper w×1 / 4h part (intra mode is vertical mode) of the final prediction is set as the intra-prediction signal. In the above description, in addition to the intra-prediction part, other parts of the final prediction are set as IBC prediction samples.

[0136] Intra Block Copy with Geometry Partitioning Mode (IBC-GPM) is a coding tool in video coding. IBC-GPM can geometrically divide a CU into two subpartitions. Prediction signals for the two subpartitions can be generated using IBC mode and intra prediction, respectively. IBC-GPM can be applied to the normal IBC merge mode or IBC TM merge mode. An intra prediction mode (IPM) candidate list can be constructed using the same method as GPM, which uses inter prediction and intra prediction for intra prediction. In one example, the IPM candidate list size is predetermined as 3. In one example, there are a total of 48 geometry partitioning modes, which are divided into two geometry partitioning mode sets, such as the first geometry partitioning mode set shown in Table 2 and the second geometry partitioning mode set shown in Table 3. [Table 2] [Table 3]

[0137] When the IBC-GPM mode is used, an IBC-GPM geometry partitioning mode set flag may be signaled, followed by a geometry partitioning mode index, to indicate whether the first or second geometry partitioning mode set is selected. An IBC-GPM intra flag may be signaled to indicate whether intra prediction is used for the first sub-partition. When intra prediction is used for the sub-partition, an intra-prediction mode index may be signaled. When IBC is used for the sub-partition, a merge index may be signaled.

[0138] Intra block copy with local illumination compensation (IBC-LIC) mode is a coding tool that uses a linear formula to compensate for local illumination variations within a picture between a CU (e.g., coded in IBC mode) and each predicted block in the picture. The parameters of the linear formula can be derived in the same manner as LIC in inter prediction, except that the reference template is generated using block vectors in IBC-LIC mode.

[0139] In some examples, in a separation tree case, such as a chroma separation tree (CST) case, the IBC mode is not applied to chroma coding blocks. For luma coding blocks, the IBC mode can be used together with other coding methods, such as CIIP mode, GPM, LIC mode, or skip mode. The coding information of the luma IBC block can be further utilized in chroma block prediction. For example, embodiments described in this disclosure, such as those described below in Figures 13-15, include applying IBC-related modes to chroma coding blocks in the chroma separation tree case. The embodiments described below in Figures 13-15 provide an efficient method for applying IBC-related modes to chroma coding blocks in the chroma separation tree case.

[0140] In some embodiments, when the chroma IBC mode is used for the CST case, for a chroma coding block, the corresponding luma samples may not be aligned with the same coding block size and the same position, for example, the corresponding luma samples may be collocated with the chroma coding block and may include luma samples from multiple luma blocks.

[0141] In one embodiment, a region (or coding region) (1102) in a picture being coded (e.g., during reconstruction) 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, for example, as defined in Table 1. The variables SubWidthC and SubHeightC may depend on the chroma subsampling format (also referred to as the chroma format sampling structure or chroma sampling format), such as 4:2:0 and 4:2:2, as specified in Table 1. In the example shown in Figure 13, 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 of the luma coding region (1120), respectively.

[0142] The coding tree type can be a dual tree type (also referred to as a dual tree block structure) or a chroma separation tree (e.g., DUAL_TREE_CHROMA), as used in VVC. In a chroma separation tree, the luma coding region (1120) and the chroma coding region (1110) within the region (1102) can be partitioned using two separate coding tree structures. In one example, the picture (1101) is an intra-picture (I-picture). The luma coding region (1120) and the chroma coding region (1110) can be partitioned using separate luma / chroma coding tree structures.

[0143] The luma coding region (1120) may be partitioned using any suitable coding tree structure. The chroma coding region (1110) may be partitioned using any suitable coding tree structure. In the example shown in FIG. 13, the chroma coding region (1110) is partitioned into chroma blocks (1111)-(1112), for example, by a binary tree. The chroma block (1111) is the target for coding (e.g., encoding or reconstructing) and may be referred to as the current chroma block. In one example, the chroma block (1112) will be coded after the current chroma block (1111) is coded. In the example shown in FIG. 13, the luma coding region (1120) is partitioned into luma blocks (1121)-(1129), for example, by quadtree partitioning, binary tree partitioning, and / or the like. For example, the luma coding region (1120) is divided into four blocks using quadtree partitioning. The upper left block of the luma coding region (1120) is further divided into luma blocks (1121)-(1122) using a binary tree. The upper right block of the luma coding region (1120) is further divided into luma blocks (1127)-(1128) using a binary tree. The lower left block of the luma coding region (1120) is further divided into luma blocks (1123)-(1126) using a quadtree partition. The lower right block of the luma coding region (1120) is not partitioned and is the luma block (1129).

[0144] In one embodiment, the region (1102) may be 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) in the current CTU (1102), and the chroma coding region (1110) is a chroma CTB in the current CTU (1102). The luma CTB and chroma CTB may be partitioned using separate coding tree structures (e.g., two separate coding tree structures), for example, as described above.

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

[0146] When CST is used, the current chroma block 1111 may be co-located with one or more luma blocks in the luma coding region 1120. The number of luma blocks co-located with the current chroma block 1111 may depend on the coding tree structure used to partition the region 1102. Referring to FIG. 13, the current chroma block 1111 may be co-located with luma blocks 1121-1126. The luma area 1141 in the luma coding region 1120 includes luma blocks 1121-1126 and is co-located with the current chroma block 1111. The co-located luma samples of the current chroma block 1111 may include luma samples in the luma area 1141 (or in the luma blocks 1121-1126).

[0147] In one embodiment, the luma samples in the luma coding region (1120) are already coded (eg, reconstructed) before coding the current chroma block (1111).

[0148] In one aspect, the chroma predictor is derived in the chroma separation tree case, e.g., the block vectors are used directly and the coding information is derived from the collocator blocks.

[0149] In one example, a chroma predictor can be derived in the chroma separation tree case. The block vector(s) and coding information derived from the colocated luma block (e.g., luma area (1141)) can be used (e.g., directly).

[0150] Referring to Figure 13, in the CST case, a chroma predictor used to predict a current chroma block (1111) may be derived, for example, a chroma predictor including a predicted sample in a reference chroma block (1131) in a picture (1101). The reference chroma block (1131) in a picture (1101) may be pointed to by a chroma block vector (BV) (1113) of the current chroma block (1111). At least one of (i) one or more BVs and (ii) coding information derived from a luma area (1141) collocated with the current chroma block (1111) may be used to derive the chroma BV (1113) and / or determine how the current chroma block (1111) should be coded. One or more predetermined positions in the luma area (1141), such as a top-left position (TL), a top-right position (TR), a bottom-left position (BL), a bottom-right position (BR), and a center position (C), may be used. Each position (e.g., TL) is associated with a luma block coded in a specific coding mode, such as an IBC-related mode or a combination of an IBC-related mode and another coding mode. The IBC mode may refer to an IBC merge mode or an IBC AMVP mode. The IBC-related mode may refer to an IBC mode, an IntraTMP mode, or a mode that predicts a block based on another block in the same picture, where the other block is indicated by the block's BV. Referring to Figure 13, positions TL, TR, BL, BR, and C are associated with luma blocks (1121), (1122), (1125), (1126), and (1124), respectively. In some examples, multiple positions may be associated with the same luma block.

[0151] According to one embodiment of the present disclosure, a chroma prediction mode (also referred to as a chroma coding mode) of a current chroma block (1111) may be derived based on luma coding information of a first luma block. The first luma block may be associated with a first position within a reconstructed luma area (1141) that is co-located with the current chroma block (1111). For example, the first position is TL, and the first luma block is luma block (1121). The first luma block (1121) may include one or more first luma samples located at the first position TL. The luma coding information may indicate that the first luma block (1121) is coded in a combination of (i) a first coding mode that is an IBC-related mode (e.g., IBC mode, IntraTMP mode, or a coding mode that predicts the first luma block (1121) using a block vector that points to a reference luma block in the same picture as the first luma block (1121)), and (ii) a second coding mode. The second coding mode may be different from the first coding mode. In one example, the second coding mode is one of an intra prediction mode (e.g., different from an IBC-related mode), an LIC mode, or a SKIP mode. The second coding mode, that is, the intra prediction mode, may be a planar mode (e.g., INTRA_PLANAR), a DC mode (e.g., INTRA_DC), an angular mode, etc.

[0152] For example, the first luma block (1121) may be coded using an IBC-CIIP mode (e.g., a combination of an IBC-related mode and an intra-prediction mode), an IBC-GPM mode (e.g., a combination of an IBC-related mode and an intra-prediction mode using geometric partitioning of the first luma block (1121)), an IBC-LIC mode (e.g., a combination of an IBC-related mode and an LIC mode), or an IBC-SKIP mode (e.g., a combination of an IBC-related mode and a SKIP mode).

[0153] The chroma BV (1113) of the current chroma block (1111) may be derived based on one or more BVs associated with respective predetermined positions (e.g., TL, TR, BL, BR, and / or C) within the luma area (1141). The chroma BV (1113) of the current chroma block (1111) may be derived based on a first luma BV (1114) of a first luma block (1121) associated with the predetermined position TL. The first luma BV (1114) points to a reference luma block (1151) for the first luma block (1121).

[0154] In one example, multiple luma BVs associated with respective predetermined positions (e.g., TL, TR, BL, BR, and / or C) in the luma area (1141) are used to derive the chroma BV (1113). For example, the chroma BV (1113) is derived based on the first luma BV (1114) of the first luma block (1121) and the second luma BV of the second luma block. The second luma block may be associated with a second position in the reconstructed luma area (1141). For example, the second position may be one of TR, BL, BR, and C. If the second position is C, the second luma block is the luma block (1124).

[0155] The current chroma block (1111) can be reconstructed based on the chroma coding mode, i.e., the combination of the first coding mode and the second coding mode used to code the first luma block (1121), for example.

[0156] In one embodiment, one or more predetermined positions of a colocator block (e.g., luma area (1141)), such as the top left corner (e.g., TL in FIG. 13), top right corner (e.g., TR in FIG. 13), bottom left corner (e.g., BL in FIG. 13), bottom right corner (e.g., BR in FIG. 13), and center position (e.g., C in FIG. 13) of the colocator block, are used to derive a block vector (e.g., (1113)) for a chroma block (e.g., (1111)).

[0157] In one embodiment, if the prediction unit (e.g., (1121) in FIG. 13) at the current position (e.g., TL in FIG. 13) is in a mode (e.g., IBC mode, IntraTMP mode, etc.) that includes a valid block vector (e.g., (1114)), a block vector can be derived from this position. Referring to FIG. 13, the luma block (1121) at the first position TL is coded in an IBC-related mode (e.g., IBC mode or IntraTMP mode, etc.). The first luma BV (1114) of the luma block (1121) is valid, for example, the reference luma block (1151) is within a reference range (e.g., a reference area, search range, search area, or local reference range, etc.) for the first luma block (1121), for example, as described in FIGS. 4-8, 9A, 9B, and 10. In one example, the second luma block (eg, (1124)) is coded using a valid BV in an IBC-related mode (eg, IBC mode or IntraTMP mode).

[0158] In one embodiment, this mode may be signaled as an intra-prediction mode or an IBC mode. In one example, the bitstream includes intra-prediction mode information or IBC mode information that indicates (i) that the chroma prediction mode of the current chroma block (1111) is derived from the luma coding information of the first luma block (1121), or (ii) that the chroma BV (1113) is derived from the first luma BV (1114) of the first luma block (1121).

[0159] In one embodiment, to derive the chroma BVs, the luma BVs are scaled based on the chroma subsampling format of the video. The chroma BV (1113) may be derived by scaling the first luma BV (1114) by one or more scaling factors that depend on the chroma subsampling format. In one example, when multiple luma BVs are used to derive the chroma BV (1113), the chroma BV (1113) may be derived based on a weighted average of the multiple luma BVs. In one example, when the chroma subsampling format is 4:2:2, the scaling factors include horizontal and vertical scaling factors that are 2 and 1, respectively. In one example, when the chroma subsampling format is 4:4:4, the horizontal and vertical scaling factors are 1 and 1, respectively.

[0160] In one embodiment, if a colocated luma block used to derive a current BV is coded in IBC mode, some coding information of the luma block may be applied to chroma prediction. For example, the disclosed method may determine that a first luma block associated with a first position in a reconstructed luma area colocated with the current chroma block is predicted by at least a first coding mode using a block vector (BV). Here, the first coding mode may include one of (i) intra block copy (IBC) mode and (ii) intra template matching prediction (IntraTMP) mode. Furthermore, the disclosed method may derive a chroma prediction mode of a current chroma block in a chroma coding region based on the luma coding information of the first luma block. Specifically, the luma coding information may indicate a combination of (i) a first coding mode and (ii) a second coding mode. Then, the disclosed method may derive a chroma block BV of the current chroma block based on the first luma block vector (BV) of the first luma block.

[0161] In one example, if a collocator block is coded in IBC-CIIP mode, a combination method of IBC-CIIP and intra mode can be derived from this block (e.g., collocator block) and used to generate a chroma predictor.

[0162] 13 , in one embodiment, the first coding mode is an IBC-related mode (e.g., IBC mode or IntraTMP mode), the second coding mode is an intra-prediction mode (e.g., angular mode), and the first luma block (1121) is coded in IBC-CIIP mode. The current chroma block (1111) may be coded in the same coding mode used by the first luma block (1121), and thus the current chroma block is coded in IBC-CIIP mode. For example, the current chroma block (1111) is coded in the same IBC-related mode (e.g., IBC mode or IntraTMP mode) used by the first luma block (1121) and the same intra-prediction mode used by the first luma block (1121). A first prediction (also referred to as a first prediction signal) of the current chroma block (1111) may be determined using the same IBC-related mode and chroma BV (1113). A second prediction (also referred to as a second prediction signal) of the current chroma block (1111) may be determined using the same intra-prediction mode. A chroma prediction (also referred to as a final prediction signal) of the current chroma block (1111) may be determined based on a weighted sum of the first prediction and the second prediction, as described in this disclosure (e.g., using Equation 6). The current chroma block (1111) may be reconstructed based on the chroma prediction and, optionally, based on a residual signal.

[0163] In one example, if a collocator block is coded in IBC-GPM mode, a GPM partition and an intra mode can be derived from this block (e.g., the collocator block) and used to generate a chroma predictor.

[0164] Referring to FIG. 13 , in one embodiment, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is an intra prediction mode, and the first luma block is coded using IBC-GPM. The current chroma block (1111) may be divided into a first subpartition and a second subpartition using GPM mode. A first prediction (also referred to as a first prediction signal) of the first subpartition of the current chroma block (1111) may be determined using IBC mode or IntraTMP mode and a chroma BV. A second prediction (also referred to as a second prediction signal) of the second subpartition of the current chroma block may be determined using an intra prediction mode. The current chroma block (1111) may be reconstructed based on the first prediction, the second prediction, and optionally a residual signal.

[0165] In one example, when a collocated chroma block is coded in IBC-LIC mode, the reference block of the chroma block is determined based on the current BV. LIC parameters are calculated based on the templates of the current chroma block and the reference block of the current chroma block. Then, a chroma predictor is generated using LIC.

[0166] 13, in one embodiment, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is LIC mode, and the first luma block (1121) is coded in IBC-LIC mode. The current chroma block (1111) may be coded based on the same IBC-LIC mode, which includes the same first coding mode and the same LIC mode used by the first luma block (1121). An initial prediction (also referred to as an initial prediction signal) for the current chroma block (1111) may be determined using the IBC mode or IntraTMP mode and the chroma BV (1113). The initial prediction signal may be from a reference chroma block (1131) pointed to by the chroma BV (1113). LIC parameters for the current chroma block (1111) (e.g., the scale α and offset β used in the LIC functions described in this disclosure) may be determined based on the current template (1160) of the current chroma block (1111) and the reference template (1170) of the reference chroma block (1131). The current template (1160) (e.g., having an “L” shape) may include N rows and / or M columns of adjacent chroma samples adjacent to the current chroma block (1111). The reference template (1170) (e.g., having an “L” shape) may include N rows and / or M columns of adjacent chroma samples adjacent to the reference chroma block (1131). A prediction (also referred to as a prediction signal) may be determined based on the initial prediction and the LIC parameters using the LIC mode. For example, a scale α and an offset β may be obtained, and the prediction signal may be equal to α*p[x]+β, where p[x] represents the initial prediction signal. The current chroma block (1111) can be reconstructed based on the prediction and optionally the residual signal.

[0167] In one example, if the collocator block is coded in IBC-SKIP mode, the steps of residual decoding, inverse transform, and inverse quantization of the current chroma block are skipped.

[0168] 13, in one embodiment, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is SKIP mode, and the first luma block (1121) is coded in IBC-SKIP mode. A prediction (also referred to as a prediction signal) for the current chroma block (1111) may be determined using the IBC mode or IntraTMP mode and the chroma BV (1113). The current chroma block (1111) may be reconstructed (e.g., directly) from the prediction using SKIP mode without using a residual signal.

[0169] 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 partitioned using two separate coding tree structures. The flag may be signaled at any suitable level, such as at the sequence level within a sequence parameter set (SPS). In one example, a flag sps_qtbtt_dual_tree_intra_flag equal to 1 specifies that, for an I-slice, each CTU is partitioned into coding units with 64x64 luma samples using implicit quadtree partitioning, and these coding units are the roots of two separate coding_tree syntax structures for the luma and chroma components. A flag sps_qtbtt_dual_tree_intra_flag equal to 0 specifies that separate coding_tree syntax structures are not used for an I-slice. If sps_qtbtt_dual_tree_intra_flag is not present, it is inferred to be equal to 0.

[0170] 14 shows a flowchart outlining a process (1400) according to one 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 that performs the functions of the video decoder (110), a processing circuit that performs the functions of the video decoder (210), and the like. In some aspects, the process (1400) is implemented in software instructions, and thus the processing circuit performs the process (1400) when the processing circuit executes the software instructions. The process (1400) begins at (S1401) and proceeds to (S1410).

[0171] At (S1410), a bitstream for a current region in a picture may be received. 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.

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

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

[0174] In one example, the bitstream includes intra prediction mode information or IBC mode information indicating that (i) the chroma prediction mode of the current chroma block is derived from the luma coding information of the first luma block, or (ii) the chroma BV is derived from the first luma BV of the first luma block.

[0175] At (S1420), a chroma prediction mode (or chroma coding mode) of a current chroma block in the chroma coding region may be derived based on luma coding information of the first luma block. The first luma block is associated with a first position in the reconstructed luma area that is co-located with the current chroma block. The luma coding information indicates that the first luma block is coded in a first coding mode that uses at least a first luma BV. In one example, the luma coding information indicates that the first luma block is coded in a combination of (i) a first coding mode including one of an intra block copy (IBC) mode or an intra template matching prediction (IntraTMP) mode, and (ii) a second coding mode. The second coding mode may include one of an intra prediction mode, a local illumination compensation (LIC) mode, or a SKIP mode. The reconstructed luma area is within the luma coding region.

[0176] In one example, if the colocated luma block used to derive the current BV is coded in IBC mode, some coding information of the luma block may also be applied to chroma prediction. In one example, the first luma block is coded using a valid BV in IBC mode or IntraTMP mode. For example, the first luma BV is valid.

[0177] At (S1430), a chroma block vector (BV) of the current chroma block may be derived based on the first luma BV of the first luma block.

[0178] In one example, the chroma predictor in the chroma separation tree case is derived, and the block vectors and coding information are derived from the collocator blocks.

[0179] In one example, the chroma BV is derived by scaling the first luma BV with a scaling factor(s) that depends on the chroma subsampling format.

[0180] In one example, a chroma BV is derived based on a first luma BV of a first luma block and at least one other luma BV (e.g., a second luma BV of a second luma block, etc.), for example, using a weighted average, where the second luma block is associated with a second position in the reconstructed luma area that is co-located with the current chroma block.

[0181] In one example, the second luma block is coded using a valid BV in IBC mode or IntraTMP mode, for example, the second luma BV is valid.

[0182] At (S1440), the current chroma block is reconstructed based on a chroma coding mode that is a combination of the first coding mode and the second coding mode used to code the first luma block.

[0183] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is an intra prediction mode, and the first luma block is coded in IBC-CIIP mode. A first prediction (or a first prediction signal) of the current chroma block may be determined using the IBC mode or IntraTMP mode and the chroma BV. A second prediction (or a second prediction signal) of the current chroma block may be determined using the intra prediction mode. A chroma predictor (also referred to as a chroma prediction or a final prediction signal) of the current chroma block may be determined based on a weighted sum of the first prediction and the second prediction. The current chroma block may be reconstructed based on the chroma prediction.

[0184] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is an intra prediction mode, and the first luma block is coded using IBC-GPM. A first prediction (or a first prediction signal) of a first subpartition of a current chroma block may be determined using IBC mode or IntraTMP mode and a chroma BV. The current chroma block is divided into a first subpartition and a second subpartition using GPM mode. A second prediction (or a second prediction signal) of a second subpartition of the current chroma block may be determined using an intra prediction mode. The current chroma block is reconstructed based on the first prediction and the second prediction.

[0185] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is LIC mode, and the first luma block is coded in IBC-LIC mode. An initial prediction (or initial prediction signal) may be determined using the IBC mode or IntraTMP mode and a chroma BV. The initial prediction is from a reference chroma block indicated by the chroma BV. LIC parameters for a current chroma block may be determined based on a current template of the current chroma block and a reference template of the reference chroma block. A prediction (also referred to as a predictor or prediction signal) may be determined based on the initial prediction and the LIC parameters using the LIC mode. The current chroma block may be reconstructed based on the prediction.

[0186] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is SKIP mode, and the first luma block is coded in IBC-SKIP mode. A predictor (also called a prediction or a prediction signal) may be determined using the IBC mode or IntraTMP mode and the chroma BV. A current chroma block may be reconstructed from the prediction using SKIP mode without using a residual signal.

[0187] Then, the process proceeds to (S1499) and ends.

[0188] The process (1400) may be suitably adapted. Step(s) of the process (1400) may be modified and / or omitted. Further step(s) may be added. Any suitable order of implementation may be used. In one example, prior to deriving the chroma prediction mode for the current chroma block, a first luma block associated with a first position in the reconstructed luma area is predicted and determined by at least a first coding mode using a first luma BV.

[0189] 15 shows a flowchart outlining a process (1500) according to one embodiment of the present disclosure. The process (1500) can 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, and thus the processing circuit performs the process (1500) when the processing circuit executes the software instructions. The process begins at (S1501) and proceeds to (S1510).

[0190] At (S1510), a chroma coding mode of a current chroma block in a chroma coding region may be derived based on luma coding information of a first luma block. The first luma block is associated with a first position in a reconstructed luma area that is co-located with the current chroma block. The luma coding information indicates that the first luma block is coded using a combination of (i) a first coding mode that is an intra block copy (IBC) mode or an intra template matching prediction (IntraTMP) mode, and (ii) a second coding mode. In one example, the second coding mode is one of an intra prediction mode, a local illumination compensation (LIC) mode, or a SKIP mode. The current region in the picture includes a luma coding region and a chroma coding region that are partitioned using separate coding tree structures. The reconstructed luma area is located within the luma coding region. The luma coding region is co-located with the chroma coding region.

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

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

[0193] In one example, the first luma block is coded using a valid BV in IBC mode or IntraTMP mode, for example, the first luma BV is valid.

[0194] At (S1520), the chroma BV of the current chroma block is derived based on the first luma BV of the first luma block.

[0195] In one example, the chroma BV is derived by scaling the first luma BV with a scaling factor(s) that depends on the chroma subsampling format.

[0196] In one example, a chroma BV is derived based on a first luma BV of a first luma block and at least one other luma BV (e.g., a second luma BV of a second luma block, etc.), for example, using a weighted average, where the second luma block is associated with a second position in the reconstructed luma area that is co-located with the current chroma block.

[0197] In one example, the second luma block is coded using a valid BV in IBC mode or IntraTMP mode, for example, the second luma BV is valid.

[0198] At (S1530), the current chroma block may be coded based on a chroma coding mode that is a combination of the first coding mode and the second coding mode used to code the first luma block.

[0199] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is an intra prediction mode, and the first luma block is coded in IBC-CIIP mode. A first prediction of the current chroma block may be determined using the IBC mode or IntraTMP mode and a chroma BV. A second prediction of the current chroma block may be determined using the intra prediction mode. A chroma prediction (or chroma predictor) may be determined based on a weighted sum of the first prediction and the second prediction. The current chroma block may be encoded based on the chroma prediction.

[0200] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is an intra-prediction mode, and the first luma block is coded using IBC-GPM. A first sub-partition of a current chroma block may be coded using IBC mode or IntraTMP mode and a chroma BV. The current chroma block is divided into a first sub-partition and a second sub-partition using GPM mode. The second sub-partition of the current chroma block may be coded using an intra-prediction mode.

[0201] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is LIC mode, and the first luma block is coded in IBC-LIC mode. An initial prediction may be determined using the IBC mode or IntraTMP mode and a chroma BV. The initial prediction is from a reference chroma block indicated by the chroma BV. LIC parameters for the current chroma block may be determined based on a current template of the current chroma block and a reference template of the reference chroma block. A prediction may be determined based on the initial prediction and the LIC parameters using the LIC mode. The current chroma block may be encoded based on the prediction.

[0202] In one example, the first coding mode is IBC mode or IntraTMP mode, the second coding mode is SKIP mode, and the first luma block is coded in IBC-SKIP mode. The current chroma block may be coded using IBC mode or IntraTMP mode and SKIP mode. No residual signal is generated for the current chroma block.

[0203] In one example, intra-prediction mode information or IBC mode information indicating that (i) the chroma coding mode of the current chroma block is derived from the luma coding information of the first luma block, or (ii) the chroma BV is derived from the luma BV of the first luma block, is encoded and included in the bitstream. The intra-prediction mode information indicates prediction information of the intra-prediction mode. The IBC mode information indicates prediction information of the IBC mode.

[0204] In one example, coding information indicating that the luma coding region and the chroma coding region are partitioned using separate coding tree structures is encoded into the bitstream.

[0205] Then, the process proceeds to (S1599) and ends.

[0206] Process 1500 may be adapted as desired. Step(s) of process 1500 may be modified and / or omitted. Additional step(s) may be added. Any suitable order of performance may be used.

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

[0208] The term "IBC" mode can be used to refer to any IBC-related mode, such as IBC mode (e.g., IBC merge mode or IBC AMVP mode), IntraTMP mode, IntraBC mode, or other modes that predict coding blocks in a picture based on BVs that point to reference blocks in the same picture.

[0209] The techniques described above can be implemented as computer software with computer-readable instructions 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.

[0210] Computer software may be coded using any suitable machine code or computer language that can be assembled, compiled, linked, or similarly subjected to mechanisms to produce code having instructions that can be executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), and the like, either directly or via interpretation, microcode execution, and the like.

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

[0212] 16 with respect to computer system (1600) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in this exemplary embodiment of computer system (1600).

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

[0214] 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).

[0215] 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), although some haptic feedback devices may 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, and OLED screens (each with or without touchscreen input capability, each with or without haptic feedback capability, some of which may be capable of outputting two-dimensional visual output or four or more dimensional output through means such as stereoscopic output), virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown), etc.), and printers (not shown).

[0216] The computer system (1600) may also include human-accessible storage devices and their associated media, such as optical media including, for example, a CD / DVD ROM / RW (1620) with CD / DVD or similar media (1621), a thumb drive (1622), a removable hard drive or solid state drive (1623), legacy magnetic media such as tape and floppy disks (registered trademark, not shown), specialized ROM / ASIC / PLD-based devices (not shown) such as security dongles, and the like.

[0217] Those skilled in the art will also appreciate 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.

[0218] The computer system 1600 may also include an interface 1654 to one or more communications networks 1655. Networks may be, for example, wireless, wired, or optical. Networks may further be local, wide-area, metropolitan, vehicular, and industrial, real-time, latency-tolerant, and the like. Examples of networks include local area networks such as Ethernet, wireless LANs, 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 CANbus. Certain networks typically require an external network interface adapter that attaches to a particular general-purpose data port or peripheral bus 1649 (e.g., a USB port on the computer system 1600), while others are typically integrated into the core of the computer system 1600 by attachment to a system bus (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, computer system 1600 can communicate with other entities. Such communication may be one-way receive only (e.g., broadcast TV), one-way transmit only (e.g., CANbus to a specific CANbus device), or two-way, for example, to other computer systems using local or wide-area digital networks. Specific protocols and protocol stacks may be used on each network and network interface, as described above.

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

[0220] The core (1640) may include one or more central processing units (CPUs) (1641), graphics processing units (GPUs) (1642), specialized programmable processing units in the form of field programmable gate arrays (FPGAs) (1643), task-specific hardware accelerators (1644), graphics adapters (1650), etc. 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 (1647), such as internal non-user-accessible hard drives, SSDs, and the like. In some computer systems, the system bus (1648) may be made accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, and the like. Peripheral devices may be attached either directly to the core's system bus (1648) or via a peripheral bus (1649). In one example, a screen 1610 can be connected to a graphics adapter 1650. Peripheral bus architectures include PCI, USB, and the like.

[0221] The CPU (1641), GPU (1642), FPGA (1643), and accelerator (1644) may execute specific instructions that, in combination, 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 (1647). Rapid storage and retrieval from any of the memory devices may be enabled through the use of cache memory, which may be associated with one or more of the CPU (1641), GPU (1642), mass storage (1647), ROM (1645), RAM (1646), and the like.

[0222] The computer-readable media may have computer code thereon for performing various computer-implemented processes. The media 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.

[0223] By way of example, and not limitation, a computer system having the architecture (1600), and in particular the core (1640), can provide functionality as a result of the execution by one or more processors (including CPUs, GPUs, FPGAs, accelerators, and the like) of software embodied in one or more tangible computer-readable media. Such computer-readable media can be specific storage of the core (1640) that is non-transitory in nature, such as the core's internal mass storage (1647) or ROM (1645), and media associated with user-accessible mass storage as introduced above. Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core (1640). The computer-readable media can include one or more memory devices or chips, depending on specific needs. Software may cause the core (1640) and particularly the processors therein (including CPUs, GPUs, FPGAs, and the like) to perform particular processes or portions of particular processes described herein, including by defining data structures stored in RAM (1646) and modifying such data structures according to processes defined by the software. Additionally, or alternatively, the computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerators (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 include logic, and vice versa, where appropriate. References to computer-readable media may include circuitry (e.g., integrated circuits (ICs)) storing software for execution, circuitry embodying logic for execution, or both, where appropriate. The present disclosure includes any suitable combination of hardware and software.

[0224] The use of "at least one of" or "one of" in this disclosure is intended to include any one or combination of the described 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; and 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 described elements where applicable, such as when the elements are not mutually exclusive.

[0225] While this disclosure describes several exemplary embodiments, there are alterations, permutations, and various equivalent alternatives that fall within the scope of the disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the disclosure and are therefore within its spirit and scope.

Claims

1. 1. A method for video decoding executed by one or more processors, 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 partitioned using separate coding tree structures; determining that a first luma block associated with a first position in a reconstructed luma area that is collocated with a current chroma block is predicted by a first coding mode using at least a first luma block vector (BV), the first coding mode comprising one of (i) an intra block copy (IBC) mode and (ii) an intra template matching prediction (IntraTMP) mode; deriving a chroma prediction mode for the current chroma block in the chroma coding domain based on luma coding information of the first luma block, the luma coding information indicating a combination of (i) the first coding mode and (ii) a second coding mode; deriving a chroma BV of the current chroma block based on the first luma BV of the first luma block; reconstructing the current chroma block based on the chroma prediction mode, which is the combination of the first coding mode and the second coding mode used to code the first luma block; A method having the following.

2. the first luma block is coded in a joint intra block copy and intra prediction (IBC-CIIP) mode; the second coding mode is an intra-prediction mode; The step of reconstructing the current chroma block includes: determining a first prediction of the current chroma block using the IBC mode or the IntraTMP mode and the chroma BV; determining a second prediction of the current chroma block using the intra prediction mode; and determining a chroma prediction for the current chroma block based on a weighted sum of the first prediction and the second prediction; reconstructing the current chroma block based on the chroma prediction; Including, The method of claim 1.

3. the first luma block is coded using IBC with Geometry Partitioning Mode (IBC-GPM); the second coding mode is an intra-prediction mode; The step of reconstructing the current chroma block includes: determining a first prediction of a first sub-partition of the current chroma block using the IBC mode or the IntraTMP mode and the chroma BV, wherein the current chroma block is divided into the first sub-partition and a second sub-partition using the GPM mode; determining a second prediction of the second sub-partition of the current chroma block using the intra prediction mode; and reconstructing the current chroma block based on the first prediction and the second prediction; Including, The method of claim 1.

4. the second coding mode is a local illumination compensation (LIC) mode; the first luma block is coded in IBC with LIC (IBC-LIC) mode; The step of reconstructing the current chroma block includes: determining an initial prediction using the IBC mode or the IntraTMP mode and the chroma BV, wherein the initial prediction is from a reference chroma block indicated by the chroma BV; determining LIC parameters for the current chroma block based on a current template for the current chroma block and a reference template for the reference chroma block; determining a prediction based on the initial prediction and the LIC parameters using the LIC mode; reconstructing the current chroma block based on the prediction; and Including, The method of claim 1.

5. the second coding mode is a SKIP mode, and the first luma block is coded in an IBC-SKIP mode; The step of reconstructing the current chroma block includes: determining a prediction using the IBC mode or the IntraTMP mode and the chroma BV; reconstructing the current chroma block from the prediction using the SKIP mode without using a residual; and Including, The method of claim 1.

6. The step of deriving the chroma BV comprises: deriving the chroma BV based on the first luma BV of the first luma block and a second luma BV of a second luma block, the second luma block being associated with a second position in the reconstructed luma area that is co-located with the current chroma block; 2. The method of claim 1, comprising:

7. The method of claim 1 , wherein the first luma block is coded using a BV that is valid in the IBC mode or the IntraTMP mode.

8. 2. The method of claim 1, wherein the bitstream includes intra-prediction mode information or IBC mode information indicating that (i) the chroma prediction mode of the current chroma block is derived from the luma coding information of the first luma block, or (ii) the chroma BV is derived from the first luma BV of the first luma block.

9. The step of deriving the chroma BV comprises: deriving the chroma BV by scaling the first luma BV with a scaling factor that depends on a chroma subsampling format; 2. The method of claim 1, comprising:

10. the current region is a current coding tree unit (CTU), the luma coding region is a luma coding tree block (CTB) in the current CTU, The chroma coding region is a chroma CTB in the current CTU. The method of claim 1.

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

12. one or more processors; one or more memories storing a computer program; and The computer program causes the one or more processors to perform the method of any one of claims 1 to 11. Device.

13. A computer program causing a computer to carry out the method according to any one of claims 1 to 11.

Images