Dual tree for non-intra regions

Abstract

A compressed bitstream is received. A first syntax element is decoded from the compressed bitstream, indicating whether a luma block and a chroma block associated with a coding unit are to be split using a single tree or a dual tree. The single tree refers to a partitioning structure where the luma block and the chroma block have the same partitioning, and the dual tree refers to a partitioning structure where the luma block and the chroma block have different partitionings. Based on the first syntax element, the luma block and the chroma block are split.

Description

DUAL TREE FOR NON-INTRA REGIONSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Patent Application Serial No. 63 / 664,013, filed June 25, 2024, the entire disclosure of which is incorporated herein by reference.BACKGROUND

[0002] Digital video streams may represent video using a sequence of frames or still images. Digital video can be used for various applications including, for example, video conferencing, high-definition video entertainment, video advertisements, or sharing of usergenerated videos. A digital video stream can contain a large amount of data and consume a significant amount of computing or communication resources of a computing device for processing, transmission, or storage of the video data. Various approaches have been proposed to reduce the amount of data in video streams, including encoding or decoding techniques.SUMMARY

[0003] A first aspect of the disclosed implementations relates to a method that includes receiving a compressed bitstream; decoding, from the compressed bitstream, a first syntax element indicative of whether a luma block associated with a coding unit and a chroma block associated with the coding unit are to be split using a single tree or a dual tree, where the single tree refers to a partitioning structure where the luma block and the chroma block have a same partitioning, and the dual tree refers to a partitioning structure where the luma block and the chroma block have different partitionings; and splitting, based on the first syntax element, the luma block and the chroma block.

[0004] In some implementations, splitting, based on the first syntax element, the luma block and the chroma block includes decoding, from the compressed bitstream, a second syntax element indicating a first partition type of the luma block; and decoding, from the compressed bitstream, a third syntax element indicating a second partition type of the chroma block.

[0005] In some implementations, the second syntax element indicates that the first partition type of the luma block is a quadtree, a binary tree, or a ternary tree.

[0006] In some implementations, the third syntax element indicates that the second partition type of the chroma block is a quadtree or a binary tree.

[0007] In some implementations, the aspect further includes decoding, from the compressed bitstream, a second syntax element indicating that the compressed bitstream includes the first syntax element.

[0008] In some implementations, the second syntax element is included in a sequence parameter set (SPS).

[0009] In some implementations, the second syntax element is included in a picture parameter set (PPS).

[0010] In some implementations, the second syntax element is included in a slice header.

[0011] In some implementations, the aspect further includes obtaining a sub-block of the chroma block based on the splitting; and determining not to split the sub-block based on a size of the sub-block.

[0012] In some implementations, the aspect further includes determining that a sub-block of the luma block uses a luma displacement vector; and in response to determining that the sub-block of the luma block uses the luma displacement vector, using a chroma displacement vector for a corresponding sub-block of the chroma block that is based on the luma displacement vector.

[0013] In some implementations, the aspect further includes identifying two or more luma displacement vectors for the sub-block of the luma block; and determining the chroma displacement vector for the corresponding sub-block of the chroma block based on the two or more luma displacement vectors.

[0014] In some implementations, determining the chroma displacement vector for the corresponding sub-block of the chroma block based on the two or more luma displacement vectors includes setting the chroma displacement vector to an average of the two or more luma displacement vectors.

[0015] In some implementations, a first of the two or more luma displacement vectors is associated with a top-left luma sub-sub-block of the sub-block of the luma block and a second of the two or more luma displacement vectors is associated with a bottom-right luma sub- sub-block of the sub-block of the luma block.

[0016] In some implementations, the aspect further includes identifying a plurality of displacement vectors for a plurality of luma sub-blocks corresponding to the correspondingsub-block of the chroma block; and determining the displacement vector for the corresponding sub-block of the chroma block by calculating a weighted average of the plurality of displacement vectors.

[0017] In some implementations, splitting the luma block and the chroma block using the dual tree includes splitting the luma block into a plurality of luma sub-blocks; and not splitting the chroma block.

[0018] In some implementations, the aspect further includes determining a current split depth or a size of the coding unit; and in response to determining the current split depth or the size of the coding unit, selectively splitting the luma block and the chroma block using the dual tree.

[0019] A second aspect of the disclosed implementations relates to a device that includes a processor that is configured to perform the method of the first aspect.

[0020] A third aspect of the disclosed implementations relates to a device that includes a memory and a processor. The processor is configured to execute instructions stored in the memory to perform the method of the first aspect.

[0021] A fourth aspect of the disclosed implementations relates to a non-transitory computer-readable storage medium, including executable instructions that, when executed by a processor, facilitate performance of the method of the first aspect.

[0022] A fifth aspect of the disclosed implementations relates to a non-transitory computer-readable storage medium having stored thereon an encoded bitstream, where the encoded bitstream is configured for decoding by the method of the first aspect.

[0023] These and other aspects of the present disclosure are disclosed in the following detailed description of the embodiments, the appended claims and the accompanying figures. It will be appreciated that aspects can be implemented in any convenient form. For example, aspects may be implemented by appropriate computer programs which may be carried on appropriate carrier media which may be tangible carrier media (e.g. disks) or intangible carrier media (e.g. communications signals). Aspects may also be implemented using suitable apparatus which may take the form of programmable computers running computer programs arranged to implement the methods and / or techniques disclosed herein. Aspects can be combined such that features described in the context of one aspect may be implemented in another aspect.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The description herein makes reference to the accompanying drawings described below, wherein like reference numerals refer to like parts throughout the several views.

[0025] FIG. 1 is a schematic of a video encoding and decoding system.

[0026] FIG. 2 is a block diagram of an example of a computing device that can implement a transmitting station or a receiving station.

[0027] FIG. 3 is a diagram of a typical video stream to be encoded and subsequently decoded.

[0028] FIG. 4 is a block diagram of an encoder.

[0029] FIG. 5 is a block diagram of a decoder.

[0030] FIG. 6 is a block diagram of a representation of a portion of a frame.

[0031] FIG. 7A is a block diagram of an example of a quad-tree representation of a block.

[0032] FIG. 7B is a block diagram of an example of a binary tree representation and an example of a ternary tree representation.

[0033] FIG. 8A is an example of dual tree partitioning of a coding unit.

[0034] FIG. 8B is an example of syntax elements that can be used to indicate a partitioning structure of luma and chroma coding units (CUs) in a compressed bitstream.

[0035] FIG. 9 is a flowchart of a technique for decoding coding units using dual trees.

[0036] FIG. 10 illustrates an example of cross-component filtering.

[0037] FIG. 11 illustrates an example of a neighborhood of an intermediate pixel of an intermediate prediction block.

[0038] FIG. 12 illustrates an example of obtaining a cross-component prediction.

[0039] FIG. 13 illustrates an example of obtaining a cross-component prediction.DETAILED DESCRIPTION

[0040] Video compression schemes may include breaking frames into coding tree units (CTUs), also referred to as superblocks or macroblocks, which are partitioned into smaller coding units (CUs) encoded using techniques to limit the information included in a compressed (e.g., encoded) bitstream. The bitstream can be decoded to re-create the source frames from the limited information. Encoding CTUs to or decoding CTUs from a bitstream can include predicting the values of pixels or CTUs based on similarities with other pixels or CTUs in the same frame which have already been coded. Those similarities can be determined using intra prediction, which attempts to predict the pixel values of a coding unit (CU) of a CTU using pixels peripheral to the CU (e.g., pixels that are in the same frame as the CU, but which are outside the CU).

[0041] A CU includes a luminance (or luma) component and two chrominance (or chroma) components. These luma and chroma components may in some cases be referred to as a luma block and chroma blocks. The luma component of a CU may, for example, be expressed within a Y plane of the CU and the chroma components may be expressed either within U and V planes or Cr and Cb planes of the CU. The luma component is understood to include some number of luma samples and each chroma component is understood to include some number of chroma samples. Generally, the luma samples provide measures of brightness throughout a subject CU and thus represents the structural qualities of the video content of the subject CU, whereas the chroma samples provide measures of color throughout the subject CU. Because of this, conventional video compression schemes often use finer prediction approaches for predicting luma components of CUs than chroma components thereof. Such schemes may also use approaches directed to predicting those chroma components from the predicted luma components.

[0042] A frame can be divided into blocks (CTUs) of the maximum possible size, often also referred to as superblocks or macroblocks. The partitioning strategies of CTUs into CUs are signaled in a compressed bitstream. The partitioning of a CTU can be hierarchical. That is, a CTU may be recursively divided into progressively smaller CUs. The partitioning of a CTU is communicated in the form of, or referred to as, a partition. The partition tree is a hierarchical structure that represents the division of a CTU into smaller coding blocks. Each node in the tree corresponds to a block, with the root node representing the CTU and the leaf nodes representing the smallest CUs.

[0043] At least in the case of a CU that is intra-predicted, conventional codecs may signal a single block partition tree for the CU. The block partition tree is used for both the luma and chroma components of the CU. Thus, the same partition structure is applied to each of the luma Y, chroma U, and chroma V components of the CU. Intra-prediction broadly refers to any coding mode that leverages spatial similarities between the block in a current frame and other blocks within the same frame.

[0044] To illustrate, in H.265 / HEVC (ITU-T Rec. H.265, “High Efficiency Video Coding,” December, 2016), the coding tree of a coding tree unit (CTU) is shared by Y, U, and V components. In the joint exploration model (JEM), versatile video coding (VVC) codec, a single tree structure is used for P and B slices. However, the luma and chroma components may be encoded separately in I slices. As such, a luma CTU (containing only one luma coding tree block of the original CTU) forms one coding tree, and a chroma CTU (containing onlytwo chroma coding tree blocks of the original CTU) forms a chroma separate tree (CST). The CST design in I slices may also be referred to as “CTU dual tree.”

[0045] Another conventional approach interleaves luma component partition trees (i.e., luma trees) with chroma component partition trees (i.e., chroma trees). To illustrate, a bitstream may include, in the following order and with additional data (e.g., residual data) interspersed therebetween, a first luma tree for the luma component of a first CU, a first chroma tree for the chroma components of the first CU, a second luma tree for the luma component of a second CU, and a second chroma tree for the chroma components of the second CU.

[0046] These conventional approaches have their limits and problems.

[0047] One significant limitation is that the use of a single partition tree for both luma and chroma components may not efficiently capture the distinct spatial characteristics of luma and chroma information. Luma, which represents brightness, often has more detailed and fine-grained structures compared to chroma, which represents color. Consequently, a partition scheme optimized for luma may not be optimal for chroma and vice versa, leading to suboptimal compression efficiency.

[0048] Additionally, the interleaving of luma and chroma trees in a bitstream can complicate the decoding process and limit the parallel processing capabilities, thus increasing the computational load and processing time. The separate encoding of luma and chroma in I slices, while beneficial for capturing distinct spatial characteristics, requires careful synchronization to avoid artifacts, such as color bleeding, and may result in increased signaling overhead due to the need for separate partition trees.

[0049] These issues highlight the need for more adaptive and efficient partitioning and prediction techniques in video compression schemes to balance the trade-offs between compression efficiency, computational complexity, and visual quality.

[0050] Implementations of dual tree for non-intra regions according to this disclosure solve problems such as these by introducing a luma-chroma dual tree structure for non-intra regions allowing for efficient partitioning of luma and chroma components. Both of the luma and chroma components can share the same partitioning structure at least up to a certain depth of the tree. Beyond this depth, the luma and chroma components may be partitioned independently, allowing for more tailored and efficient encoding. Said another way, the luma and chroma components may share a single tree partitioning structure up to a specified depth, after which a dual tree structure allows independent partitioning of luma and chroma blocks. With respect to a CU, syntax elements are used to signal the partitioning decisions, indicatingwhether a dual tree or single tree is being utilized. These syntax elements include flags or values that determine the splitting behavior at various depths and specify the partitioning type for luma and chroma blocks.

[0051] This approach reduces inefficiencies inherent in single tree structures and minimizes signaling overhead by constraining further chroma block splitting at specific depths or block sizes. Additionally, hardware manufacturers prefer CTU-level dual tree structures as they align with existing architectures used in current video coding standards, enabling reuse of existing chip designs. Maintaining a similar architecture allows manufacturers to save on costs and streamline production. Furthermore, the ability to signal dual tree usage at the CTU level provides flexibility while maintaining compatibility with multi- standard hardware decoders.

[0052] According to some implementations, a compressed bitstream is received. A syntax element (e.g., one or more syntax elements) indicative of whether a luma block associated with a coding unit and a chroma block associated with the coding unit are to be split using a single tree or a dual tree is decoded from the compressed bitstream. Single tree refers to a partitioning structure where the luma block and the chroma block have a same partitioning; and dual tree refers to a partitioning structure where the luma block and the chroma block have different partitionings. Based on the syntax element, the luma block and the chroma block are split (e.g., partitioned).

[0053] While the description herein is mainly described with respect to one color space, namely, the YUV color space, the disclosure is not so limited. Although terminology such as luma and chroma planes, or Y / U / V planes is used, the disclosure herein can be easily extended to other color formats, such as the YCoCg, YCbCr, RGB, or other color spaces. Additionally, according to the teachings herein, more planes can be included in a compressed bitstream. For example, the planes may include a transparency plane in addition to the luma and chroma planes or a depth plane in addition to the red, green, and blue planes.

[0054] As used herein, cross-component prediction refers to predicting chroma components from luma components (or vice versa) within a coding unit. Inter crosscomponent prediction applies when, for example, the chroma block uses inter-prediction (data from another frame) with luma-derived data, while intra cross-component prediction applies when, for example, the chroma block uses intra-prediction (data within the same frame) with luma-derived data.

[0055] Further details of techniques for dual tree for non-intra regions are described herein with initial reference to a system in which they can be implemented. FIG. 1 is a schematic of a video encoding and decoding system 100. A transmitting station 102 can be,for example, a computer having an internal configuration of hardware such as that described in FIG. 2. However, other implementations of the transmitting station 102 are possible. For example, the processing of the transmitting station 102 can be distributed among multiple devices.

[0056] A network 104 can connect the transmitting station 102 and a receiving station 106 for encoding and decoding of the video stream. Specifically, the video stream can be encoded in the transmitting station 102, and the encoded video stream can be decoded in the receiving station 106. The network 104 can be, for example, the Internet. The network 104 can also be a local area network (LAN), wide area network (WAN), virtual private network (VPN), cellular telephone network, or any other means of transferring the video stream from the transmitting station 102 to, in this example, the receiving station 106.

[0057] The receiving station 106, in one example, can be a computer having an internal configuration of hardware such as that described in FIG. 2. However, other suitable implementations of the receiving station 106 are possible. For example, the processing of the receiving station 106 can be distributed among multiple devices.

[0058] Other implementations of the video encoding and decoding system 100 are possible. For example, an implementation can omit the network 104. In another implementation, a video stream can be encoded and then stored for transmission at a later time to the receiving station 106 or any other device having memory. In one implementation, the receiving station 106 receives (e.g., via the network 104, a computer bus, and / or some communication pathway) the encoded video stream and stores the video stream for later decoding. In an example implementation, a real-time transport protocol (RTP) is used for transmission of the encoded video over the network 104. In another implementation, a transport protocol other than RTP may be used (e.g., a Hypertext Transfer Protocol-based (HTTP-based) video streaming protocol).

[0059] When used in a video conferencing system, for example, the transmitting station 102 and / or the receiving station 106 may include the ability to both encode and decode a video stream as described below. For example, the receiving station 106 could be a video conference participant who receives an encoded video bitstream from a video conference server (e.g., the transmitting station 102) to decode and view and further encodes and transmits his or her own video bitstream to the video conference server for decoding and viewing by other participants.

[0060] FIG. 2 is a block diagram of an example of a computing device 200 that can implement a transmitting station or a receiving station. For example, the computing device200 can implement one or both of the transmitting station 102 and the receiving station 106 of FIG. 1. The computing device 200 can be in the form of a computing system including multiple computing devices, or in the form of one computing device, for example, a mobile phone, a tablet computer, a laptop computer, a notebook computer, a desktop computer, and the like.

[0061] A processor 202 in the computing device 200 can be a conventional central processing unit. Alternatively, the processor 202 can be another type of device, or multiple devices, capable of manipulating or processing information now existing or hereafter developed. For example, although the disclosed implementations can be practiced with one processor as shown (e.g., the processor 202), advantages in speed and efficiency can be achieved by using more than one processor.

[0062] A memory 204 in computing device 200 can be a read only memory (ROM) device or a random-access memory (RAM) device in an implementation. However, other suitable types of storage device can be used as the memory 204. The memory 204 can include code and data 206 that is accessed by the processor 202 using a bus 212. The memory 204 can further include an operating system 208 and application programs 210, the application programs 210 including at least one program that permits the processor 202 to perform the techniques described herein. For example, the application programs 210 can include applications 1 through N, which further include a video coding application that performs the techniques described herein. The computing device 200 can also include a secondary storage 214, which can, for example, be a memory card used with a mobile computing device.Because the video communication sessions may contain a significant amount of information, they can be stored in whole or in part in the secondary storage 214 and loaded into the memory 204 as needed for processing.

[0063] The computing device 200 can also include one or more output devices, such as a display 218. The display 218 may be, in one example, a touch sensitive display that combines a display with a touch sensitive element that is operable to sense touch inputs. The display 218 can be coupled to the processor 202 via the bus 212. Other output devices that permit a user to program or otherwise use the computing device 200 can be provided in addition to or as an alternative to the display 218. When the output device is or includes a display, the display can be implemented in various ways, including by a liquid crystal display (LCD), a cathode-ray tube (CRT) display, or a light emitting diode (LED) display, such as an organic LED (OLED) display.

[0064] The computing device 200 can also include or be in communication with an image-sensing device 220, for example, a camera, or any other image-sensing device 220 now existing or hereafter developed that can sense an image such as the image of a user operating the computing device 200. The image-sensing device 220 can be positioned such that it is directed toward the user operating the computing device 200. In an example, the position and optical axis of the image-sensing device 220 can be configured such that the field of vision includes an area that is directly adjacent to the display 218 and from which the display 218 is visible.

[0065] The computing device 200 can also include or be in communication with a soundsensing device 222, for example, a microphone, or any other sound-sensing device now existing or hereafter developed that can sense sounds near the computing device 200. The sound-sensing device 222 can be positioned such that it is directed toward the user operating the computing device 200 and can be configured to receive sounds, for example, speech or other utterances, made by the user while the user operates the computing device 200.

[0066] Although FIG. 2 depicts the processor 202 and the memory 204 of the computing device 200 as being integrated into one unit, other configurations can be utilized. The operations of the processor 202 can be distributed across multiple machines (wherein individual machines can have one or more processors) that can be coupled directly or across a local area or other network. The memory 204 can be distributed across multiple machines such as a network-based memory or memory in multiple machines performing the operations of the computing device 200. Although depicted here as one bus, the bus 212 of the computing device 200 can be composed of multiple buses. Further, the secondary storage 214 can be directly coupled to the other components of the computing device 200 or can be accessed via a network and can comprise an integrated unit such as a memory card or multiple units such as multiple memory cards. The computing device 200 can thus be implemented in a wide variety of configurations.

[0067] FIG. 3 is a diagram of an example of a video stream 300 to be encoded and subsequently decoded. The video stream 300 includes a video sequence 302. At the next level, the video sequence 302 includes a number of adjacent frames 304. While three frames are depicted as the adjacent frames 304, the video sequence 302 can include any number of adjacent frames 304. The adjacent frames 304 can then be further subdivided into individual frames, for example, a frame 306. At the next level, the frame 306 can be divided into a series of planes or segments 308. The segments 308 can be subsets of frames that permit parallel processing, for example. The segments 308 can also be subsets of frames that can separatethe video data into separate colors. For example, a frame 306 of color video data can include a luminance plane and two chrominance planes. The segments 308 may be sampled at different resolutions.

[0068] Whether or not the frame 306 is divided into segments 308, the frame 306 may be further subdivided into blocks 310, which can contain data corresponding to, for example, 16x16 pixels in the frame 306. The blocks 310 can also be arranged to include data from one or more segments 308 of pixel data. The blocks 310 can also be of any other suitable size such as 4x4 pixels, 8x8 pixels, 16x8 pixels, 8x16 pixels, 16x16 pixels, or larger. Unless otherwise noted, the terms block and macroblock are used interchangeably herein.

[0069] FIG. 4 is a block diagram of an encoder 400. The encoder 400 can be implemented, as described above, in the transmitting station 102, such as by providing a computer software program stored in memory, for example, the memory 204. The computer software program can include machine instructions that, when executed by a processor such as the processor 202, cause the transmitting station 102 to encode video data in the manner described in FIG. 4. The encoder 400 can also be implemented as specialized hardware included in, for example, the transmitting station 102. In one particularly desirable implementation, the encoder 400 is a hardware encoder.

[0070] The encoder 400 has the following stages to perform the various functions in a forward path (shown by the solid connection lines) to produce an encoded or compressed bitstream 420 using the video stream 300 as input: an intra / inter prediction stage 402, a transform stage 404, a quantization stage 406, and an entropy encoding stage 408. The encoder 400 may also include a reconstruction path (shown by the dotted connection lines) to reconstruct a frame for encoding of future blocks. In FIG. 4, the encoder 400 has the following stages to perform the various functions in the reconstruction path: a dequantization stage 410, an inverse transform stage 412, a reconstruction stage 414, and a loop filtering stage 416. Other structural variations of the encoder 400 can be used to encode the video stream 300.

[0071] When the video stream 300 is presented for encoding, respective adjacent frames 304, such as the frame 306, can be processed in units of blocks. At the intra / inter prediction stage 402, respective blocks can be encoded using intra-frame prediction (also called intraprediction) or inter- frame prediction (also called inter-prediction). In any case, a prediction block can be formed. In the case of intra-prediction, a prediction block may be formed from samples in the current frame that have been previously encoded and reconstructed. In the case-l iof inter-prediction, a prediction block may be formed from samples in one or more previously constructed reference frames.

[0072] Next, the prediction block can be subtracted from the current block at the intra / inter prediction stage 402 to produce a residual block (also called a residual). The transform stage 404 transforms the residual into transform coefficients in, for example, the frequency domain using block-based transforms. The quantization stage 406 converts the transform coefficients into discrete quantum values, which are referred to as quantized transform coefficients, using a quantizer value or a quantization level. For example, the transform coefficients may be divided by the quantizer value and truncated.

[0073] The quantized transform coefficients are then entropy encoded by the entropy encoding stage 408. The entropy-encoded coefficients, together with other information used to decode the block (which may include, for example, syntax elements such as used to indicate the type of prediction used, transform type, motion vectors, a quantizer value, or the like), are then output to the compressed bitstream 420. The compressed bitstream 420 can be formatted using various techniques, such as variable length coding (VLC) or arithmetic coding. The compressed bitstream 420 can also be referred to as an encoded video stream or encoded video bitstream, and the terms will be used interchangeably herein.

[0074] The reconstruction path (shown by the dotted connection lines) can be used to ensure that the encoder 400 and a decoder 500 (described below with respect to FIG. 5) use the same reference frames to decode the compressed bitstream 420. The reconstruction path performs functions that are similar to functions that take place during the decoding process (described below with respect to FIG. 5), including dequantizing the quantized transform coefficients at the dequantization stage 410 and inverse transforming the dequantized transform coefficients at the inverse transform stage 412 to produce a derivative residual block (also called a derivative residual). At the reconstruction stage 414, the prediction block that was predicted at the intra / inter prediction stage 402 can be added to the derivative residual to create a reconstructed block. The loop filtering stage 416 can be applied to the reconstructed block to reduce distortion such as blocking artifacts.

[0075] Other variations of the encoder 400 can be used to encode the compressed bitstream 420. In some implementations, a non-transform-based encoder can quantize the residual signal directly without the transform stage 404 for certain blocks or frames. In some implementations, an encoder can have the quantization stage 406 and the dequantization stage 410 combined in a common stage.

[0076] FIG. 5 is a block diagram of a decoder 500. The decoder 500 can be implemented in the receiving station 106, for example, by providing a computer software program stored in the memory 204. The computer software program can include machine instructions that, when executed by a processor such as the processor 202, cause the receiving station 106 to decode video data in the manner described in FIG. 5. The decoder 500 can also be implemented in hardware included in, for example, the transmitting station 102 or the receiving station 106.

[0077] The decoder 500, similar to the reconstruction path of the encoder 400 discussed above, includes in one example the following stages to perform various functions to produce an output video stream 516 from the compressed bitstream 420: an entropy decoding stage 502, a dequantization stage 504, an inverse transform stage 506, an intra / inter prediction stage 508, a reconstruction stage 510, a loop filtering stage 512, and a deblocking filtering stage 514. Other structural variations of the decoder 500 can be used to decode the compressed bitstream 420.

[0078] When the compressed bitstream 420 is presented for decoding, the data elements within the compressed bitstream 420 can be decoded by the entropy decoding stage 502 to produce a set of quantized transform coefficients. The dequantization stage 504 dequantizes the quantized transform coefficients (e.g., by multiplying the quantized transform coefficients by the quantizer value), and the inverse transform stage 506 inverse transforms the dequantized transform coefficients to produce a derivative residual that can be identical to that created by the inverse transform stage 412 in the encoder 400. Using header information decoded from the compressed bitstream 420, the decoder 500 can use the intra / inter prediction stage 508 to create the same prediction block as was created in the encoder 400 (e.g., at the intra / inter prediction stage 402).

[0079] At the reconstruction stage 510, the prediction block can be added to the derivative residual to create a reconstructed block. The loop filtering stage 512 can be applied to the reconstructed block to reduce blocking artifacts. Other filtering can be applied to the reconstructed block. In this example, the deblocking filtering stage 514 is applied to the reconstructed block to reduce blocking distortion, and the result is output as the output video stream 516. The output video stream 516 can also be referred to as a decoded video stream, and the terms will be used interchangeably herein. Other variations of the decoder 500 can be used to decode the compressed bitstream 420. In some implementations, the decoder 500 can produce the output video stream 516 without the deblocking filtering stage 514.

[0080] FIG. 6 is a block diagram of a representation of a portion 600 of a frame, such as the frame 306 of FIG. 3. As shown, the portion 600 of the frame includes four 64x64 blocks 610, which may be referred to as superblocks, in two rows and two columns in a matrix or Cartesian plane. A superblock can have a larger or a smaller size. For example, a superblock can be 128x128. A superblock can also be referred to as a coding tree block (CTB). While FIG. 6 is explained with respect to a superblock of size 64x64, the description is easily extendable to larger (e.g., 128x128) or smaller superblock sizes.

[0081] In an example, a superblock can be a basic or maximum coding unit (CU). Each superblock can include four 32x32 blocks 620. Each 32x32 block 620 can include four 16x16 blocks 630. Each 16x16 block 630 can include four 8x8 blocks 640. Each 8x8 block 640 can include four 4x4 blocks 650. Each 4x4 block 650 can include 16 pixels, which can be represented in four rows and four columns in each respective block in the Cartesian plane or matrix. The pixels can include information representing an image captured in the frame, such as luminance information, color information, and location information. In an example, a block, such as a 16xl6-pixel block as shown, can include a luminance block 660, which can include luminance pixels 662; and two chrominance blocks 670 / 680, such as a U or Cb chrominance block 670, and a V or Cr chrominance block 680. The chrominance blocks 670 / 680 can include chrominance pixels 690. For example, the luminance block 660 can include 16x16 luminance pixels 662, and each chrominance block 670 / 680 can include 8x8 chrominance pixels 690, as shown. Although one arrangement of blocks is shown, any arrangement can be used. Although FIG. 6 shows NxN blocks, in some implementations, NxM, where N^M, blocks can be used. For example, 32x64 blocks, 64x32 blocks, 16x32 blocks, 32x16 blocks, or any other size blocks can be used. In some implementations, Nx2N blocks, 2NxN blocks, or a combination thereof can be used.

[0082] In some implementations, video coding can include ordered block-level coding. Ordered block-level coding can include coding blocks of a frame in an order, such as rasterscan order, wherein blocks can be identified and processed starting with a block in the upper left comer of the frame, or a portion of the frame, and proceeding along rows from left to right and from the top row to the bottom row, identifying each block in turn for processing. For example, the superblock in the top row and left column of a frame can be the first block coded, and the superblock immediately to the right of the first block can be the second block coded. The second row from the top can be the second row coded, such that the superblock in the left column of the second row can be coded after the superblock in the rightmost column of the first row.

[0083] In an example, coding a block can include using quad-tree coding, which can include coding smaller block units with a block in raster-scan order. The 64x64 superblock shown in the bottom-left corner of the portion of the frame shown in FIG. 6, for example, can be coded using quad-tree coding in which the top-left 32x32 block can be coded, then the top-right 32x32 block can be coded, then the bottom-left 32x32 block can be coded, and then the bottom-right 32x32 block can be coded. Each 32x32 block can be coded using quad-tree coding in which the top-left 16x16 block can be coded, then the top-right 16x16 block can be coded, then the bottom-left 16x16 block can be coded, and then the bottom-right 16x16 block can be coded. Each 16x16 block can be coded using quad-tree coding in which the top-left 8x8 block can be coded, then the top-right 8x8 block can be coded, then the bottom-left 8x8 block can be coded, and then the bottom-right 8x8 block can be coded. Each 8x8 block can be coded using quad-tree coding in which the top-left 4x4 block can be coded, then the topright 4x4 block can be coded, then the bottom-left 4x4 block can be coded, and then the bottom-right 4x4 block can be coded. In some implementations, 8x8 blocks can be omitted for a 16x16 block, and the 16x16 block can be coded using quad-tree coding in which the top-left 4x4 block can be coded, and then the other 4x4 blocks in the 16x16 block can be coded in raster-scan order.

[0084] In an example, video coding can include compressing the information included in an original, or input, frame by omitting some of the information in the original frame from a corresponding encoded frame. For example, coding can include reducing spectral redundancy, reducing spatial redundancy, reducing temporal redundancy, or a combination thereof.

[0085] In an example, reducing spectral redundancy can include using a color model based on a luminance component (Y) and two chrominance components (U and V or Cb and Cr), which can be referred to as the YUV or YCbCr color model or color space. Using the YUV color model can include using a relatively large amount of information to represent the luminance component of a portion of a frame and using a relatively small amount of information to represent each corresponding chrominance component for the portion of the frame. For example, a portion of a frame can be represented by a high-resolution luminance component, which can include a 16x16 block of pixels, and by two lower resolution chrominance components, each of which representing the portion of the frame as an 8x8 block of pixels. A pixel can indicate a value (e.g., a value in the range from 0 to 255) and can be stored or transmitted using, for example, eight bits. Although this disclosure is described with reference to the YUV color model, any color model can be used.

[0086] As mentioned, a coding unit can be coded using tree coding. A coding block may be partitioned using a quad-tree, a binary tree, a ternary tree, or some other tree. That a block is said to be partitioned according to a certain tree type should be understood to mean that the block is divided into smaller sub-blocks based on the specific partitioning rules of the given tree type for the next level of partitioning. For example, a quad-tree partition divides the block into four sub-blocks, a binary tree partition divides the block into two sub-blocks, and a ternary tree partition divides the block into three sub-blocks. Each type of tree partitioning follows its own set of rules for how the block is split, facilitating efficient compression by adapting to the spatial characteristics of the video content.

[0087] FIG. 7A is a block diagram of an example 700 of a quad-tree representation of a block. The example 700 includes a block 702. As mentioned above, the block 702 can be referred to as a superblock or a CTB. The example 700 illustrates a partition of the block 702. However, the block 702 can be partitioned differently, such as by an encoder (e.g., the encoder 400 of FIG. 4).

[0088] The example 700 illustrates that the block 702 is partitioned into four blocks, namely, blocks 702-1, 702-2, 702-3, and 702-4. The block 702-2 is further partitioned into blocks 702-5, 702-6, 702-7, and 702-8. As such, if, for example, the size of the block 702 is NxN (e.g., 128x128), then the blocks 702-1, 702-2, 702-3, and 702-4 are each of size N / 2xN / 2 (e.g., 64x64), and the blocks 702-5, 702-6, 702-7, and 702-8 are each of size N / 4xN / 4 (e.g., 32x32). If a block is partitioned, it is partitioned into four equally sized, nonoverlapping square sub-blocks.

[0089] A quad- tree data representation is used to describe how the block 702 is partitioned into sub-blocks, such as blocks 702-1, 702-2, 702-3, 702-4, 702-5, 702-6, 702-7, and 702-8. A quad-tree 703 of the partition of the block 702 is shown. Each node of the quadtree 703 is assigned a flag of “1” if the node is further split into four sub-nodes and assigned a flag of “0” if the node is not split. The flag can be referred to as a split bit (e.g., 1) or a stop bit (e.g., 0) and is coded in a compressed bitstream. In a quad-tree, a node either has four child nodes or has no child nodes. A node that has no child nodes corresponds to a block that is not split further. Each of the child nodes of a split block corresponds to a sub-block.

[0090] In the quad-tree 703, each node corresponds to a sub-block of the block 702. The sub-block is shown between parentheses. For example, a node 704-1, which has a value of 0, corresponds to the block 702-1.

[0091] A root node 704-0 corresponds to the block 702. As the block 702 is split into four sub-blocks, the value of the root node 704-0 is the split bit (e.g., 1). At an intermediate level,the flags indicate whether a sub-block of the block 702 is further split into four sub- subblocks. In this case, a node 704-2 includes a flag of “1” because the block 702-2 has been split into the blocks 702-5, 702-6, 702-7, and 702-8. Each of nodes 704-1, 704-3, and 704-4 includes a flag of “0” because the corresponding blocks are not split. As nodes 704-5, 704-6, 704-7, and 704-8 are at a bottom level, no flag of “0” or “1” is necessary for those nodes because of corresponding CUs. That the blocks 702-5, 702-6, 702-7, and 702-8 are not split further can be inferred from the absence of additional flags corresponding to these blocks.

[0092] The quad-tree data representation for the quad- tree 703 can be represented by the binary data of “10100,” where each bit represents a node of the quad-tree 703. The binary data indicates the partitioning of the block 702 to the encoder and decoder. The encoder can encode the binary data in a compressed bitstream, such as the compressed bitstream 420 of FIG. 4, in a case where the encoder needs to communicate the binary data to a decoder, such as the decoder 500 of FIG. 5.

[0093] The blocks corresponding to the leaf nodes of the quad- tree 703 can be used as the bases for prediction. That is, prediction can be performed for each of the blocks 702-1, 702-5, 702-6, 702-7, 702-8, 702-3, and 702-4, referred to herein as coding blocks. As mentioned with respect to FIG. 6, the coding block can be a luminance block or a chrominance block. It is noted that, in an example, the superblock partitioning can be determined with respect to luminance blocks. The same partition can be used with the chrominance blocks.

[0094] A prediction type (e.g., intra- or inter-prediction) is determined at the coding block (e.g., a block 702-1, 702-5, 702-6, 702-7, 702-8, 702-3, or 702-4) level. That is, a coding block is the decision point for prediction.

[0095] FIG. 7B is a block diagram of an example 720 of a binary tree representation and an example 730 of a ternary tree representation. The binary tree representation of example 720 starts with a block 722 of size 2Nx2N. The block 722 can be split horizontally or vertically. In the binary horizontal partitioning, the block 722 is split horizontally into two sub-blocks 724A and 724B, each of size 2NxN. In the binary vertical partitioning, the block 722 is split vertically in two sub-blocks 726A and 726B, each of size Nx2N.

[0096] The example 730 of the ternary tree representation begins with a block 732 of size 2Nx2N. The block 732 can be split horizontally or vertically. In the horizontal partitioning, the block 732 is split into three sub-blocks 734A, 734B, and 734C of sizes 2NxN / 2, 2NxN, and 2NxN / 2, respectively. In the vertical partitioning, the block 732 is split into three subblocks 736A, 736B, and 736C of sizes N / 2x2N, Nx2N, and N / 2x2N, respectively.

[0097] FIG. 8A is an example 800 of dual tree partitioning of a coding unit. In an example, dual tree partitioning can be used for non-intra regions, such as those regions (e.g., coding units) coded using inter prediction or intra block copy (IBC).

[0098] The example 800 illustrates that a first level partitioning 804 of a coding unit 802 is used for both of the luma and the chroma components of the coding unit 802. The first level partitioning 804 includes sub-blocks 804A, 804B, and 804C. The example 800 illustrates that the chroma block corresponding to the sub-block 804A is partitioned according to a quad-tree partition 806 whereas the luma block corresponding to the sub-block 804A is partitioned according to a binary tree partition 808. The example 800 also illustrates that the chroma block corresponding to the sub-block 804B is not further partitioned, as indicated by a partition 812, but that the luma block corresponding to the sub-block 804B is partitioned according to a ternary tree partition 810. Furthermore, the sub-block 804C is partitioned according to a single tree. That is, the luma and chroma components of the subblock 804C are both partitioned according to a partition 814.

[0099] FIG. 8B is an example 850 of syntax elements that can be used to indicate a partitioning structure of luma and chroma coding units (CUs) in a compressed bitstream, such as the compressed bitstream 420 of FIG. 4 or FIG. 5. At a coding unit 852 level, the compressed bitstream may include one or more of a split indicator 854, a split type indicator 856, a luma split type 858, and a chroma split type 860. The compressed bitstream may include control information 870.

[0100] The split indicator 854 (e.g., NO_SPLIT_OR_DUAL_OR_SINGLE) indicates whether the coding unit is not split, uses a dual tree, or uses a single tree partitioning structure. A “no split” value indicates that neither the luma nor the chroma block is further split. The single tree partitioning structure indicates that the indicated partition type is used for both the luma block and the chroma block. The dual tree partitioning structure indicates that different partitioning types are used for each of the luma block and the chroma block. When a coding unit is partitioned using a dual tree structure, the resulting sub-blocks inherently follow the dual tree scheme, eliminating the need for additional signaling to indicate whether a dual or single tree structure is used. That is, once a dual tree structure is indicated for a coding unit, the partitioning of its sub-blocks will inherently follow the dual tree scheme without requiring additional indicators. This arrangement ensures that the bitstream remains efficient by reducing redundant signaling and allows for more flexible and efficient partitioning tailored to the distinct characteristics of luma and chroma components.

[0101] The split type indicator 856 (e.g., SINGLE_TYPE) specifies the type of partitioning applied to the coding unit when a single tree structure is used. This indicator determines the partitioning type that will be uniformly applied to both luma and chroma blocks. For instance, the split type indicator 856 can indicate whether the coding unit is partitioned using a quadtree (QT), binary tree (BT), or ternary tree (TT).

[0102] The luma split type 858 (e.g., LUMA_SPLIT_TYPE) and the chroma split type 860 (CHROMA_SPLIT_TYPE) specify the partitioning types applied to the luma and chroma blocks, respectively, when a dual tree structure is used. The luma split type 858 indicates the partitioning scheme for the luma block, such as no split, quadtree, binary tree, or ternary tree, allowing the encoder to select the most efficient partitioning method based on the luma block's characteristics. Similarly, the chroma split type 860 (e.g., CHROMA_SPLIT_TYPE ) defines the partitioning type for the chroma block, which may include partitioning schemes such as no split, quadtree, binary tree, or ternary tree. This separation allows for tailored partitioning strategies that optimize compression efficiency by addressing the distinct spatial and color characteristics of luma and chroma components. In an example, the luma split type 858 may be the split type indicator 856. That is, the same syntax element may be used to indicate the single split type and the luma partition type in the case of the dual tree case. As can be appreciated, the compressed bitstream for a coding unit may include either the split type indicator 856 or may include the luma split type 858 and the chroma split type 860.

[0103] In an example, the types of partitions allowed (e.g., available) for luma blocks may vary from the types of partitions allowed for chroma blocks. To illustrate, luma blocks may be partitioned using a quadtree, binary tree, or ternary tree, providing a high degree of flexibility to capture the fine-grained structural details typically present in the brightness component of the video. On the other hand, chroma blocks, which represent color information and often exhibit smoother variations, may be restricted to simpler partitioning methods such as quadtree or binary tree. This differentiation in allowed partition types enables the compression algorithm of the encoder to optimize the partitioning process according to the specific characteristics of the luma and chroma components, enhancing overall compression efficiency and maintaining high video quality.

[0104] This restriction is motivated by the fact that chroma content typically exhibits simpler spatial texture compared to luma, and therefore does not benefit significantly from the increased flexibility of more complex partition types such as ternary trees. Limiting the partition types for chroma blocks helps reduce signaling overhead without noticeablyimpacting compression efficiency. By tailoring the partitioning strategies to the unique attributes of luma and chroma blocks, the encoder can achieve more effective data representation, reduce redundancy in the compressed bitstream, and improve overall coding efficiency.

[0105] The control information 870 may include zero or more of an enable dual tree flag 872, allowed partition types 874, a chroma threshold 876, and a chroma depth threshold 878. The control information 870 may be predefined or signaled in bitstreams at a level no lower than slice, such as in the Sequence Parameter Set (SPS), Picture Parameter Set (PPS), picture header, or slice header. In some implementations, codecs may be configured with default values for these control information 870.

[0106] The enable dual tree flag 872 (e.g., ENABLE_DUAL_TREE) indicates whether dual tree partitioning is permitted (e.g., enabled) for coding units. The allowed partition types 874 (e.g., ALLOWED_PARTITION_TYPES) specifies the types of partitions that are permitted for chroma blocks. For example, while luma blocks may be allowed to use quadtree, binary tree, and ternary tree partitions, chroma blocks might be restricted to using only quadtree and binary tree partitions.

[0107] The chroma threshold 876 (e.g., CHROMA_THRESHOLD) defines a threshold value for the chroma block size or depth. This chroma threshold 876 can be used to determine conditions under which further partitioning of chroma blocks is either allowed or restricted. The chroma threshold 876 defines a block size or depth threshold below which further partitioning of chroma blocks is restricted to reduce signaling overhead. A decoder can use this threshold to prevent unnecessary partitioning of chroma blocks, reducing the signaling overhead and computational load while maintaining high compression efficiency.

[0108] The chroma depth threshold 878 (e.g., CHROMA_DEPTH_THRESHOLD) indicates a condition under which dual tree partitioning is allowed based on the current split depth (or, equivalently, block size). The chroma depth threshold 878 specifies a split depth or block size above which dual tree partitioning is permitted, ensuring that dual tree is used only for sufficiently large blocks. Specifically, the dual tree may only be allowed when the current split depth in a single tree is below a certain depth threshold. Alternatively, the dual tree may only be possible when the current block size is above a certain threshold size.

[0109] FIG. 9 is a flowchart of a technique 900 for decoding coding units using dual trees. The technique 900 can be implemented, for example, as a software program that may be executed by computing devices such as transmitting station 102 or receiving station 106. The software program can include machine-readable instructions that may be stored in amemory such as the memory 204 or the secondary storage 214, and that, when executed by a processor, such as processor 202, may cause the computing device to perform the technique 900. The technique 900 may be implemented in whole or in part in the intra / inter prediction stage 508 of the decoder 500 of FIG. 5. The technique 900 can be implemented using specialized hardware or firmware. Multiple processors, memories, or both, may be used.

[0110] At 902, a compressed bitstream is received. Receiving the compressed bitstream may include, for example, receiving it over a network from a transmitting station or reading it from a non-transitory computer-readable storage medium, such as a hard disk, solid-state drive, memory card, or optical disc. In some implementations, the bitstream may be stored locally and accessed by a decoder process or device for subsequent decoding operations. The compressed bitstream can be the compressed bitstream 420 of FIG. 5.

[0111] With respect to coding units, the compressed bitstream includes respective partitioning information. That is, with respect to a coding unit that includes a luma block and one or more chroma blocks, the compressed bitstream can include partitioning information for the luma blocks and partitioning information for the one or more chroma blocks. As described herein, the partitioning information for a luma block and the corresponding chroma blocks may be the same.

[0112] At 904, a first syntax element indicative of whether a luma block associated with the coding unit and a chroma block associated with the coding unit are to be split using a single tree or a dual tree is decoded from the compressed bitstream. As described above, the single tree refers to a partitioning structure where the luma block and the chroma block have a same partitioning; and the dual tree refers to a partitioning structure where the luma block and the chroma block have different partitionings.

[0113] The first syntax element can be the split indicator 854 described with respect to FIG. 8B. As such, the first syntax element can have a value selected from a first value indicating no split, a second value indicating a single tree partitioning structure, and a third value indicating a dual tree partitioning structure. The no split value indicates that neither the luma block nor the chroma block is further split (e.g., divided or partitioned). The single tree value specifies that both the luma and chroma blocks share the same partitioning structure, while the dual tree value allows for different partitioning structures for the luma and chroma blocks, optimizing the partitioning based on the distinct characteristics of each component.

[0114] In an example, the first syntax element may be implemented as one or more syntax elements. For example, a first flag may indicate that the luma block is to be split and a second syntax element (e.g., a second flag) may indicate whether the chroma block is alsosplit. That is, the usage of the dual tree may be signaled after a tree split flag if the split flag is true. Such a design can indicate that the luma block must be split while the chroma block may not be. The case that the luma block is not split while chroma block is split may not be allowed to simplify signaling.

[0115] In an example, a control flag may first be decoded indicating whether dual tree is enabled in the compressed bitstream. For example, as described herein, unless the enable dual tree flag 872 is set to a first value (e.g., 1), the first syntax element would not indicate a dual tree partitioning structure. Said another way, a control flag (e.g., a third flag) indicates that the compressed bitstream includes the first syntax element. If the enable dual tree flag is not set, the coding unit must use a single tree partitioning structure or no split at all. This ensures that dual tree partitioning is only used when explicitly enabled. As described above, the enable dual tree flag can be included in the compressed bitstream at a level that is no lower than a slice. As such, the enable dual tree flag may be signaled in the sequence parameter set (SPS), a picture parameter set (PPS), a picture (e.g., frame) header, or a slice header.

[0116] At 906, the luma block and the chroma block are split based on the first syntax element. In the case that the first syntax element indicates different partition types for the luma block and the chroma block, splitting the first syntax element can include decoding, from the compressed bitstream, a second syntax element (e.g., the luma split type 858) indicating a first partition type of the luma block; and decoding, from the compressed bitstream, a third syntax element (e.g., chroma split type 860) indicating a second partition type of the chroma block(s). Splitting the luma block and the chroma block using the dual tree can include splitting the luma block into a plurality of luma sub-blocks but not splitting the chroma block.

[0117] As described above, the dual tree may only be allowed when the current split depth in a single tree is below a certain threshold (e.g., a certain chroma depth threshold). Alternatively, the dual tree may only be possible when the current block size is above a certain threshold size. As such, technique 900 may include determining a current split depth or a size of the coding unit; and, in response to determining the current split depth or the size of the coding unit, selectively splitting the luma block and the chroma block using the dual tree.

[0118] In an example, the threshold size for chroma blocks may be 4x4 chroma samples when the chroma sampling format is 4:2:0, which corresponds to 8x8 luma samples. In some implementations, even 8x8 chroma samples (equivalent to 16x16 luma samples in 4:2:0 format) may be considered small enough to constrain further partitioning. These specific sizethresholds may be chosen because partitioning chroma blocks smaller than these dimensions typically yields minimal improvement in visual quality or distortion reduction while consuming additional signaling bits in the compressed bitstream.

[0119] As described above, different partition types may be available for luma blocks vs. chroma blocks. In an example, the chroma partition types may be a subset of the luma partition types. As such, the second syntax element may indicate that the first partition type of the luma block is either a quadtree, a binary tree, or a ternary tree; and the third syntax element may indicate that the second partition type of the chroma block is either a quadtree or a binary tree. As mentioned above, the partition types available for chroma blocks may be encoded in the control information 870, which may be encoded (e.g., included in the compressed bitstream) at a level that is no lower than a slice (e.g., SPS, PPS, picture level, or slide level).

[0120] When the coding unit is split, a sub-block of the chroma block (e.g., a chroma sub-block) is obtained and a sub-block of the luma block (e.g., a luma sub-block) is obtained. In an example, whether the chroma sub-block is further split can depend on the size of the chroma sub-block. That is, if the chroma sub-block size is equal to a threshold size, then the chroma sub-block is no longer split. As such, the compressed bitstream would not include a syntax element indicating whether the chroma sub-block is to be split. As such, the semantics of the split indicator 854 may change to only indicate whether to split or not to split the corresponding luma block (in the case of the single tree). In an example, the threshold size may be encoded in the compressed bitstream. The threshold size may be indicated by the chroma threshold 876.

[0121] The constraint on further splitting of chroma sub-blocks at a certain threshold size can be particularly beneficial because chroma information generally exhibits smoother textures and less complex spatial variation compared to luma information. Further partitioning of already small chroma blocks may provide minimal improvement in distortion reduction while incurring additional signaling overhead. By preventing unnecessary partitioning of chroma blocks when they reach a sufficiently small size (for example, 4x4 or 8x8 chroma samples), the compressed bitstream achieves better efficiency by reducing signaling bits without sacrificing visual quality. This approach is especially effective since larger chroma blocks are often preferred for smoother color regions, which are prevalent in typical video content.

[0122] In some implementations, the technique 900 may further determine that the luma sub-block is encoded using a displacement vector. The displacement vector may be a motionvector (MV) or a block vector (BV). For example, the technique 900 may decode a prediction mode for the luma sub-block from the compressed bitstream. The prediction mode indicates that a displacement vector is used for decoding the luma sub-block. An MV indicates the displacement of a block from its position in the current frame to its position in a reference frame, facilitating motion compensation by predicting the block’s movement between frames. A BV refers to the displacement used in intra block copy (IBC) mode, where a block in the current frame is predicted using another block from the same frame, enabling the reuse of spatial information within a single frame for efficient compression.

[0123] In such a case, the corresponding chroma sub-block is decoded using a chroma displacement vector that is based on the luma displacement vector. The granularity of the chroma displacement vector can be derived from the granularity of the luma displacement vector. To illustrate, the MV or BV may be at the 4x4 luma block level. In a 4:2:0 color format, the chroma block granularity may be 2x2 chroma samples. In a 4:4:4 color format, the chroma block granularity can be 4x4 chroma samples. In an example, the displacement vector information for chroma blocks can be a down-sampled or weighted average of the displacement vectors of collocated luma blocks. In an example, in a 4x4 chroma block of a 4:2:0 color format, the displacement vector can be calculated by averaging the displacement vectors of the top-left and bottom-right collocated 4x4 luma blocks. The approach of deriving chroma displacement vectors from luma displacement vectors can ensure that luma and chroma components maintain spatial coherence during motion compensation, which helps prevent color bleeding artifacts that would otherwise occur if luma and chroma blocks were to move independently of each other.

[0124] As such, the technique 900 may identify two or more luma displacement vectors for sub-blocks of the luma block corresponding to a chroma sub-block. The chroma displacement vector for the corresponding sub-block of the chroma block can be determined based on the two or more luma displacement vectors. In an example, the chroma displacement vector can be set to the average of the two or more luma displacement vectors. In an example, the chroma displacement vector may be set to the average of a first displacement vector associated with a top-left luma sub-sub-block of the sub-block of the luma block and a second displacement vector associated with a bottom-right luma sub- subblock of the sub-block of the luma block. This approach may be particularly effective for affine motion models, where averaging just the top-left and bottom-right vectors is mathematically equivalent to averaging all four 2x2 chroma blocks, while reducing hardware complexity by requiring fewer calculations. As such, hardware manufacturers can implementthis simplified approach for motion compensation of a 4x4 chroma block rather than processing four separate 2x2 chroma blocks with different motion vectors.

[0125] In some implementations, if a dual tree is used for a block (e.g., if the chroma block is partitioned differently from the luma block), then the chroma block may not be coded using IBC. This restriction may be applied because IBC relies on spatial redundancy within a single frame, and differing luma and chroma partitioning structures in a dual tree may cause misalignment issues or introduce untested complexity, potentially reducing prediction accuracy. Such misalignment can complicate the prediction process and reduce the effectiveness of IBC, as the spatial relationship between luma and chroma blocks becomes inconsistent. Therefore, to maintain efficient and accurate prediction, IBC may not be used for chroma blocks in dual tree structures.

[0126] In an example, whether inter cross-component prediction (e.g., filtering) is to be applied can be signaled in the compressed bitstream. That is, the technique 900 can decode one or more syntax elements from the compressed bitstream indicating whether inter-cross- component prediction is to be applied and the type of cross-component prediction to be applied.

[0127] However, in some implementations, inter cross-component prediction may be allowed only for chroma blocks whose collocated luma blocks have at least one non-zero residual. As such, if no non-zero residuals are associated with the luma block, then the technique does not decode, and the compressed bitstream would not include, the syntax elements relating to inter cross-component prediction. When an inter cross-component prediction mode is used, it may be at sub-block level, such as at a block of 4x4 chroma samples, or a chroma block which corresponds to a luma 4x4 block. Examples of inter crosscomponent filtering are described with respect to FIGS. 10-13.

[0128] In some codec implementations of dual tree for non-intra regions, the encoder and decoder may be configured with one or more of the following constraints. In some implementations, mode signaling may be constrained such that no intra block (including palette mode) is allowed in the dual tree case. This constraint helps manage complexity by focusing the dual tree approach primarily on inter-predicted regions. However, other implementations may allow the mixing of intra and inter coding within dual tree structures. In some implementations, mode (e.g., prediction or filtering) signaling within the dual tree may be constrained such that at least one luma block within the tree has non-zero residuals. That is, unless one luma block within the partition of a coding unit is associated with at least one non-zero residual, then dual tree is not allowed (e.g., different partitionings of chroma andluma blocks). In some implementations, when the luma tree contains intra-coded block(s), the chroma tree may be constrained from using an inter prediction mode. That is, every chroma block in the collocated chroma tree can only use intra prediction modes. In other alternative implementations, when the luma tree contains at least one intra-coded block, only intra crosscomponent prediction modes can be applied to the chroma block(s) in the collocated chroma tree.

[0129] FIG. 10 illustrates an example 1000 of cross-component filtering. The example 1000 illustrates pixels that are filled with different patterns. The example 1000 is used to illustrate a current block template and is also used to illustrate a reference block template.

[0130] When used to describe a current block template, a block 1008 illustrates a current block (i.e., the block being decoded). While the block 1008 is shown as being of size 8x4, the disclosure is not so limited. The block 1008 can be of any other size. Pixels filled with a pattern 1002 are pixels of the current block of a current frame. Pixels filled with a pattern 1006 (or a subset thereof, as further described herein) illustrate reconstructed pixels of the current frame. Pixels filled with a pattern 1004 are pixels that are not available and may contain a padding value (i.e., are set to a padding value). Depending on the neighborhood used for a filter, one or more pixels used by the filter may not be available (such as because these pixels are outside the frame boundary or are outside a largest coding unit that includes the block 1008). As such, a padding value may be used (e.g., assumed) for such pixels.

[0131] When used to describe a reference block template, the block 1008 illustrates a reference block in a reference frame. Again, while the block 1008 is shown as being of size 8x4, the disclosure is not so limited. The block 1008 can be of a size corresponding to the size of the current block. As such, pixels filled with the pattern 1002 are pixels of the reference block of a reference frame. Pixels filled with the pattern 1006 (or a subset thereof, as further described herein) illustrate reconstructed pixels of the reference frame. Pixels filled with the pattern 1004 are pixels that are not available and may contain a padding value.

[0132] The template may include a top region 1010 that may include 1 to N (where N>1) rows of pixels. The template may include a top-right region 1012 that includes 1 to N rows. The template may include a left region 1014 of 1 to M (where M>1) columns of pixels. The template may include a bottom- left region 1016 of 1 to M (where M>1) columns of pixels.

[0133] In an example, N=M. In an example, if the current block is a luma block, then the template can be 4-sample wide. If the current block is a chroma block, the template (i.e., a chroma template) may be based on the chroma color format. For example, for 4:4:4 content, the chroma template can also be 4-sample wide; and for 4:2:0 or 4:2:2 color formats, thechroma template can be 2-sample wide. In an example, when the top-right region 1012 is available, only a 4x4 luma block at the top-right is included in the template. Similarly, if the bottom-left region 1016 is available, only a 4x4 luma block at bottom-right is included in the template. The chroma template can be adjusted accordingly based on the chroma color format. In another example, the top template may always be 1 -sample wide for both luma and chroma while the left template may be 4- sample wide for luma.

[0134] In an example, the filter coefficients include at least two coefficients. In an example, the filter coefficients include more than two coefficients for at least one of the color components (i.e., at least of the luma or the chroma component). In an example, the number (i.e., cardinality) of the filter coefficients can be decoded from the compressed bitstream. For example, an indicator of the number of filter coefficients can be decoded from the compressed bitstream. That is, if the indicator of the number of coefficients is the first value (e.g., 0), then no filtering is performed on the prediction block. If the indicator of the number of the fdter coefficients is a second value (e.g., 1), then two filter coefficients are derived; and if the indicator of the number of filter coefficients is a third value (e.g., 2), then more than two filter coefficients are derived.

[0135] In an example, the filter can be a convolutional filter. The filter coefficients can be obtained by minimizing an error metric between the first reconstructed pixels and the second reconstructed pixels. The error metric can be a mean square error (MSE) between pixel values of the respective reconstructed pixels. The error can be a sum of absolute differences (SAD) error between the pixel values of the reconstructed pixels. Any other suitable error metric can be used.

[0136] In an example, the number of coefficients to be obtained depends on which pixels within the neighborhood of the intermediate prediction pixel to which the filter is to be applied are used in the filtering. The pixels within the neighborhood of an intermediate prediction pixel that are used for filtering are referred to herein as at least a subset of pixels of the neighborhood.

[0137] FIG. 11 illustrates an example 1100 of a neighborhood of an intermediate pixel 1102 of an intermediate prediction block. The example 1100 illustrates a 3x3 neighborhood. However, the neighborhood can be larger or smaller, rectangular, or some other shape (e.g., diamond). The example 1100 illustrates that pixels 1104, 1106, 1108, 1110 (i.e., pixels to the north, east, south, and west of the intermediate pixel 1102, respectively) are used in the filtering. As such, the filter coefficients include at least five coefficients: one coefficient to be used with each of the pixels 1102 through 1110.- l-

[0138] As such, the filter is a 5-tap filter and the prediction pixel corresponding to the intermediate pixel 1102 can be obtained using equation (1), where Ci (i=0,...,4) are the filter coefficients, pred is the filter pixel of the final prediction block. Equation (1) is shown as further including a constant term (i.e., cs), which may also be derived and used in some implementations . pred = c0C + c4N + c2S + c3E + c4W + c5(1)

[0139] In an example, one or more but not all filter coefficients may be further refined after being derived. As such, the obtained filter coefficients may be considered to be predicted filter coefficients. The difference (i.e., a coefficient refinement value) between a predicted filter coefficient and the actual value of the filter coefficient may be signaled in the compressed bitstream. As such, obtaining the filter coefficients for the filter can include obtaining a predicted filter coefficient for a filter coefficient of the filter coefficients; decoding, from the compressed bitstream, a coefficient refinement value; and adjusting the predicted filter coefficient using the coefficient refinement value to obtain the filter coefficient.

[0140] In another example, a 7-tap convolutional filter may be used to obtain the chroma prediction block from a luminance prediction block. The convolutional filter may include a 5- tap plus sign shape spatial component, a nonlinear term, and a bias term. The input to the spatial 5-tap component of the filter consists of a center (C) luma sample which is collocated with the chroma sample to be predicted and its above / north (N), below / south (S), left / west (W) and right / east (E) neighbors, as described above with respect to equation (1). As such, the prediction pixel can be obtained using equation (2): predChromaVal = c0C + c4N + c2S + c3E + c4W + c5P + c6B (2)

[0141] In equation (2), P is the non-linear term. In an example, the nonlinear term P can be represented as power of two of the center luma sample C (i.e., intermediate pixel 1102) and scaled to the sample value range of the content using equation (3).P = (C2+ midVal » bitDepth. (3)

[0142] To illustrate, assuming 10-bit content, then P is calculated as P = ( C2+ 512 ) » 10. Other non-linear terms are possible. The bias term B, when used, can represent a scalar offset between the input and output. The coefficients Ci can be obtained in a similar way as described above with respect to equation (1). For example, the coefficients Ci can be obtained by minimizing MSE between predicted and reconstructed chroma samples in a reference area. In equation (2), C, N, S, E, and W correspond to the values of the lumaprediction values, such as shown in FIG. 11.

[0143] In an example, the coefficient refinement value corresponds (i.e., is used for) the intermediate prediction pixel itself. That is, for example, the coefficient refinement value may be used to refine the filter coefficient obtained for the intermediate pixel 1102 of FIG. 11. As such, the coefficient refinement value is used for an intermediate prediction pixel to which the filter is applied. In an example, the coefficient refinement value can be used to refine a coefficient corresponding to a non-linear term of the filter. For example, the filter may include a filter coefficient corresponding to the intermediate prediction pixel, one non-linear term, and a constant value. The non-linear term (i.e., a non-linear component) can be a square term of the intermediate prediction pixel. As such, the filter can be given by a X p[x]2+ b X p[x] + c, where a and b are the filter coefficients, c is a constant component, and p[x] is the value of the intermediate prediction pixel at location x.

[0144] In an example, and as described with respect to FIG. 11, the filter coefficients can be applied to at least a subset of pixels in a 3x3 neighborhood of an intermediate prediction pixel to obtain the prediction pixel of the final prediction block. A 3x3 neighborhood can be used whether the current block is a luma block or a chroma block. The subset of the pixels can form (e.g., can be of any) shape. In an example, the subset of the pixels in a 3x3 neighborhood can be those pixels that form a cross shape, such as shown in FIG. 11. That is the subset of the pixels can be the pixels 1102 through 1110. That is, the at least a subset of pixels in a 3x3 neighborhood of an intermediate prediction pixel can be or include the intermediate prediction pixel, a pixel above the intermediate prediction pixel, a pixel right of the intermediate prediction pixel, a pixel below the intermediate prediction pixel, and a pixel left of the intermediate prediction pixel.

[0145] In an example, the filter can use at least a subset of pixels in a 3x3 neighborhood and may further include a constant term (also referred to as a DC value). In an example, one shape (i.e., a first filter shape) may be used for a luma block and a different second filter shape may be used for a chroma block. As such, a first filter shape may be used in a case that the current block is a luma block and a second filter shape that is different from the first filter shape may be used in a case that the current block is a chroma block.

[0146] FIG. 12 illustrates an example of obtaining a cross -component prediction. In cross-component filtering, a prediction obtained for a luma block can be used to obtain the prediction for a chroma block. Said another way, in the case that the current block is a luma block, a chroma prediction block for a chroma block corresponding to the current block is derived from the final prediction block. In an example, a 3x3 luma filter plus 1x1 chromafilter plus a DC value may be used. Alternatively, a 3x3 luma filter plus 3x3 chroma filter plus a DC value may be used.

[0147] In an example of cross-component filtering, chroma samples are predicted based on the reconstructed luma samples of the same coding unit (which may be referred to as a largest coding unit, a macroblock, or other such nomenclature) of the current block by using a linear model that is according to equation (4): predc(i,j) = a x reci'(i,f) + / 3 (4)

[0148] In equation (4), predc(i,f) represents the chroma sample predictions, reci'(i, ) represents a down-sampled reconstructed luma predictions of the current luma block. Downsampling is performed in the case that the chroma samples and the luma samples do not have the same resolution. For example, down-sampling may be performed in that case that a 4:2:2 or a 4:2:0 format is used. The down-sampling aligns the resolution of luma and chroma blocks.

[0149] The cross-component parameters (a and >) can be derived with at most four neighboring chroma samples and their corresponding down-sampled luma samples. FIG. 12 illustrates an example 1200 of the locations of left and above samples and the sample of the current block involved in the cross-component filtering mode. The division operation to calculate parameter a may be implemented with a look-up table. With respect to a luma block 1202, the locations of left and above samples are shown as filled circles, such as a filled circle 1204. With respect to a chroma block 1206, the locations of left and above samples are shown as filled circles, such as a filled circle 1208.

[0150] FIG. 13 illustrates an example 1300 of obtaining a cross-component prediction. Obtaining the cross-component prediction may be referred to as a cross-component residual prediction technique. A cross -component residual prediction can be used in the case that a block is inter predicted or is predicted IBC and when there are non-zero luma residuals. The cross-component filters can be derived using the prediction signals of the luma block and the chroma block. The derived filters can be applied to the reconstructed luma signal producing a final chroma prediction.

[0151] The cross-component filters can be derived using the prediction signals of luma and chroma. The derived filters can be applied to the reconstructed luma signal producing the final chroma predictions. The filtering can use an 8-tap filter. The 8-tap filter can consist of 6 spatial luma samples, a nonlinear term, and a bias term. The spatial luma samples (Lo,...,L5) can be obtained from the luma grid selecting the 6 luma samples closest to the chromaposition C without down sampling. For example, given a chroma pixel 1302, the luma values of the luma pixels at locations 1304, 1306, 1308, 1310, 1312, 1314 can be used. The predicted chroma value can be obtained using equation (5):nonlinear( L0+ L3+ 1) » 1) + c7B (5)

[0152] In equation (5), c0to c7are filter coefficients, nonlinear can be an operator that is as described with respect to equation (3), and B is a bias term.

[0153] For simplicity of explanation, the technique 900 of FIG. 9, is depicted and described as a series of steps or operations. However, the steps or operations in accordance with this disclosure can occur in various orders and / or concurrently. Additionally, other steps or operations not presented and described herein may be used. Furthermore, not all illustrated steps or operations may be required to implement a technique in accordance with the disclosed subject matter.

[0154] Some implementations are described below as numbered clauses (Clause 1, 2, 3, etc.). These clauses are provided as examples only and do not limit the other implementations disclosed herein.

[0155] Clause 1. A method, comprising: receiving a compressed bitstream; decoding, from the compressed bitstream, a first syntax element indicative of whether a luma block associated with a coding unit and a chroma block associated with the coding unit are to be split using a single tree or a dual tree, wherein the single tree refers to a partitioning structure where the luma block and the chroma block have a same partitioning, and the dual tree refers to a partitioning structure where the luma block and the chroma block have different partitionings; and splitting, based on the first syntax element, the luma block and the chroma block.

[0156] Clause 2. The method of clause 1, wherein splitting, based on the first syntax element, the luma block and the chroma block comprises: decoding, from the compressed bitstream, a second syntax element indicating a first partition type of the luma block; and decoding, from the compressed bitstream, a third syntax element indicating a second partition type of the chroma block.

[0157] Clause 3. The method of clause 2, wherein the second syntax element indicates that the first partition type of the luma block is a quadtree, a binary tree, or a ternary tree.

[0158] Clause 4. The method of clause 2, wherein the third syntax element indicates that the second partition type of the chroma block is a quadtree or a binary tree.

[0159] Clause 5. The method of clause 2, further comprising: decoding, from the compressed bitstream, a second syntax element indicating that the compressed bitstream includes the first syntax element.

[0160] Clause 6. The method of clause 5, wherein the second syntax element is included in a sequence parameter set (SPS).

[0161] Clause 7. The method of clause 5, wherein the second syntax element is included in a picture parameter set (PPS).

[0162] Clause 8. The method of clause 5, wherein the second syntax element is included in a slice header.

[0163] Clause 9. The method of clause 1, further comprising: obtaining a sub-block of the chroma block based on the splitting; and determining not to split the sub-block based on a size of the sub-block.

[0164] Clause 10. The method of clause 1, further comprising: determining that a subblock of the luma block uses a luma displacement vector; and in response to determining that the sub-block of the luma block uses the luma displacement vector, using a chroma displacement vector for a corresponding sub-block of the chroma block that is based on the luma displacement vector.

[0165] Clause 11. The method of clause 10, further comprising: identifying two or more luma displacement vectors for the sub-block of the luma block; and determining the chroma displacement vector for the corresponding sub-block of the chroma block based on the two or more luma displacement vectors.

[0166] Clause 12. The method of clause 11, wherein determining the chroma displacement vector for the corresponding sub-block of the chroma block based on the two or more luma displacement vectors comprises: setting the chroma displacement vector to an average of the two or more luma displacement vectors.

[0167] Clause 13. The method of clause 11, wherein a first of the two or more luma displacement vectors is associated with a top-left luma sub-sub-block of the sub-block of the luma block and a second of the two or more luma displacement vectors is associated with a bottom-right luma sub- sub-block of the sub-block of the luma block.

[0168] Clause 14. The method of clause 10, further comprising: identifying a plurality of displacement vectors for a plurality of luma sub-blocks corresponding to the corresponding sub-block of the chroma block; and determining the displacement vector for the corresponding sub-block of the chroma block by calculating a weighted average of the plurality of displacement vectors.

[0169] Clause 15. The method of clause 1, wherein splitting the luma block and the chroma block using the dual tree comprises: splitting the luma block into a plurality of luma sub-blocks; and not splitting the chroma block.

[0170] Clause 16. The method of clause 1, further comprising: determining a current split depth or a size of the coding unit; and in response to determining the current split depth or the size of the coding unit, selectively splitting the luma block and the chroma block using the dual tree.

[0171] Clause 17. A device comprising: a processor that is configured to perform the method of any one of clauses 1-16.

[0172] Clause 18. A device, comprising: a memory; and a processor, the processor configured to execute instructions stored in the memory to perform the method of any one of clauses 1-16.

[0173] Clause 19. A non-transitory computer-readable storage medium, comprising executable instructions that, when executed by a processor, facilitate performance of operations, comprising operations that perform the method of any one of clauses 1-16.

[0174] Clause 20. A non-transitory computer-readable storage medium having stored thereon an encoded bitstream, wherein the encoded bitstream is configured for decoding by the method of any one of clauses 1-16.

[0175] The aspects of encoding and decoding described above illustrate some examples of encoding and decoding techniques. However, it is to be understood that encoding and decoding, as those terms are used in the claims, could mean compression, decompression, transformation, or any other processing or change of data.

[0176] The word “example” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example” is not necessarily to be construed as being preferred or advantageous over other aspects or designs. Rather, use of the word “example” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise or clearly indicated otherwise by the context, the statement “X includes A or B” is intended to mean any of the natural inclusive permutations thereof. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more,” unless specified otherwise or clearly indicated by the context to be directed to a singular form. Moreover, use of the term “an implementation” or the term “oneimplementation” throughout this disclosure is not intended to mean the same embodiment or implementation unless described as such.

[0177] Implementations of the transmitting station 102 and / or the receiving station 106 (and the algorithms, methods, instructions, etc., stored thereon and / or executed thereby, including by the encoder 400 and the decoder 500) can be realized in hardware, software, or any combination thereof. The hardware can include, for example, computers, intellectual property (IP) cores, application- specific integrated circuits (ASICs), programmable logic arrays, optical processors, programmable logic controllers, microcode, microcontrollers, servers, microprocessors, digital signal processors, or any other suitable circuit. In the claims, the term “processor” should be understood as encompassing any of the foregoing hardware, either singly or in combination. The terms “signal” and “data” are used interchangeably. Further, portions of the transmitting station 102 and the receiving station 106 do not necessarily have to be implemented in the same manner.

[0178] Further, in one aspect, for example, the transmitting station 102 or the receiving station 106 can be implemented using a general-purpose computer or general-purpose processor with a computer program that, when executed, carries out any of the respective methods, algorithms, and / or instructions described herein. In addition, or alternatively, for example, a special purpose computer / processor can be utilized which can contain other hardware for carrying out any of the methods, algorithms, or instructions described herein.

[0179] The transmitting station 102 and the receiving station 106 can, for example, be implemented on computers in a video conferencing system. Alternatively, the transmitting station 102 can be implemented on a server, and the receiving station 106 can be implemented on a device separate from the server, such as a handheld communications device. In this instance, the transmitting station 102, using an encoder 400, can encode content into an encoded video signal and transmit the encoded video signal to the communications device. In turn, the communications device can then decode the encoded video signal using a decoder 500. Alternatively, the communications device can decode content stored locally on the communications device, for example, content that was not transmitted by the transmitting station 102. Other suitable transmitting and receiving implementation schemes are available. For example, the receiving station 106 can be a generally stationary personal computer rather than a portable communications device, and / or a device including an encoder 400 may also include a decoder 500.

[0180] Further, all or a portion of implementations of the present disclosure can take the form of a computer program product accessible from, for example, a computer-usable orcomputer-readable medium. A computer-usable or computer-readable medium can be any device that can, for example, tangibly contain, store, communicate, or transport the program for use by or in connection with any processor. The medium can be, for example, an electronic, magnetic, optical, electromagnetic, or semiconductor device. Other suitable mediums are also available.

[0181] The above-described embodiments, implementations, and aspects have been described in order to facilitate easy understanding of this disclosure and do not limit this disclosure. On the contrary, this disclosure is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope is to be accorded the broadest interpretation as is permitted under the law so as to encompass all such modifications and equivalent arrangements.

Claims

What is claimed is:

1. A method, comprising: receiving a compressed bitstream; decoding, from the compressed bitstream, a first syntax element indicative of whether a luma block associated with a coding unit and a chroma block associated with the coding unit are to be split using a single tree or a dual tree, wherein the single tree refers to a partitioning structure where the luma block and the chroma block have a same partitioning, and the dual tree refers to a partitioning structure where the luma block and the chroma block have different partitionings; and splitting, based on the first syntax element, the luma block and the chroma block.

2. The method of claim 1, wherein splitting, based on the first syntax element, the luma block and the chroma block comprises: decoding, from the compressed bitstream, a second syntax element indicating a first partition type of the luma block; and decoding, from the compressed bitstream, a third syntax element indicating a second partition type of the chroma block.

3. The method of claim 2, wherein the second syntax element indicates that the first partition type of the luma block is a quadtree, a binary tree, or a ternary tree.

4. The method of claim 2, wherein the third syntax element indicates that the second partition type of the chroma block is a quadtree or a binary tree.

5. The method of claim 2, further comprising: decoding, from the compressed bitstream, a second syntax element indicating that the compressed bitstream includes the first syntax element.

6. The method of claim 5, wherein the second syntax element is included in a sequence parameter set (SPS).

7. The method of claim 5, wherein the second syntax element is included in a picture parameter set (PPS).

8. The method of claim 5, wherein the second syntax element is included in a slice header.

9. The method of claim 1, further comprising: obtaining a sub-block of the chroma block based on the splitting; and determining not to split the sub-block based on a size of the sub-block.

10. The method of claim 1, further comprising: determining that a sub-block of the luma block uses a luma displacement vector; and in response to determining that the sub-block of the luma block uses the luma displacement vector, using a chroma displacement vector for a corresponding sub-block of the chroma block that is based on the luma displacement vector.

11. The method of claim 10, further comprising: identifying two or more luma displacement vectors for the sub-block of the luma block; and determining the chroma displacement vector for the corresponding sub-block of the chroma block based on the two or more luma displacement vectors.

12. The method of claim 11, wherein determining the chroma displacement vector for the corresponding sub-block of the chroma block based on the two or more luma displacement vectors comprises: setting the chroma displacement vector to an average of the two or more luma displacement vectors.

13. The method of claim 11, wherein a first of the two or more luma displacement vectors is associated with a top-left luma sub-sub-block of the sub-block of the luma block and a second of the two or more luma displacement vectors is associated with a bottom-right luma sub-sub-block of the sub-block of the luma block.

14. The method of claim 10, further comprising: identifying a plurality of displacement vectors for a plurality of luma sub-blocks corresponding to the corresponding sub-block of the chroma block; anddetermining the displacement vector for the corresponding sub-block of the chroma block by calculating a weighted average of the plurality of displacement vectors.

15. The method of claim 1, wherein splitting the luma block and the chroma block using the dual tree comprises: splitting the luma block into a plurality of luma sub-blocks; and not splitting the chroma block.

16. The method of claim 1, further comprising: determining a current split depth or a size of the coding unit; and in response to determining the current split depth or the size of the coding unit, selectively splitting the luma block and the chroma block using the dual tree.

17. A device comprising: a processor that is configured to perform the method of any one of claims 1-16.

18. A device, comprising: a memory; and a processor, the processor configured to execute instructions stored in the memory to perform the method of any one of claims 1-16.

19. A non-transitory computer-readable storage medium, comprising executable instructions that, when executed by a processor, facilitate performance of operations, comprising operations that perform the method of any one of claims 1-16.

20. A non-transitory computer-readable storage medium having stored thereon an encoded bitstream, wherein the encoded bitstream is configured for decoding by the method of any one of claims 1-16.

Images