Methods and apparatuses for block partitioning at picture boundary

Abstract

To provide a video processing method and apparatus.SOLUTION: The method includes: determining whether a coding block comprises samples outside a picture boundary; and, in response to the coding block being determined to comprise samples outside a picture boundary, performing quad tree splitting of the coding block regardless of a value of a first parameter, where the first parameter indicates whether the quad tree is allowed to be used to split the coding block.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This disclosure claims priority to U.S. Provisional Patent Application No. 62 / 948,856, filed December 17, 2019, the entirety of which is incorporated by reference herein.

[0002] Technical Field FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to video processing, and more particularly to methods and apparatus for performing block partitioning at picture boundaries. [Background technology]

[0003] background

[0003] A video is a set of static pictures (or "frames") that capture visual information. To reduce storage memory and transmission bandwidth, a video can be compressed before storage or transmission and decompressed before display. The compression process is typically referred to as encoding, and the decompression process is typically referred to as decoding. There are various video coding formats that use standardized video coding techniques, most commonly based on prediction, transform, quantization, entropy coding, and in-loop filtering. Standardization organizations have developed video coding standards that specify specific video coding formats, such as the High Efficiency Video Coding (HEVC / H.265) standard, the Versatile Video Coding (VVC / H.266) standard, and the AVS standard. As more and more advanced video coding techniques are adopted into video standards, the coding efficiency of new video coding standards becomes increasingly higher. Summary of the Invention [Means for solving the problem]

[0004] Disclosure Overview

[0004] In some embodiments, an exemplary video processing method includes determining whether a coding block contains samples outside a picture boundary, and in response to determining that the coding block contains samples outside the picture boundary, performing quadtree partitioning of the coding block regardless of the value of a first parameter, the first parameter indicating whether a quadtree is allowed to be used to partition the coding block.

[0005] In some embodiments, an exemplary video processing device includes at least one memory for storing instructions and at least one processor configured to execute the instructions to cause the device to: determine whether a coding block includes samples outside a picture boundary; and, in response to determining that the coding block includes samples outside the picture boundary, perform quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether using a quadtree to partition the coding block is allowed.

[0006] In some embodiments, an exemplary non-transitory computer-readable storage medium stores a set of instructions executable by one or more processing devices to cause a video processing apparatus to: determine whether a coding block includes samples outside a picture boundary; and, in response to determining that the coding block includes samples outside the picture boundary, perform quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether using a quadtree to partition the coding block is permitted.

[0007] BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments and various aspects of the present disclosure are illustrated in the following detailed description and the accompanying drawings, in which the various features illustrated are not drawn to scale. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram illustrating the structure of an exemplary video sequence, according to some embodiments of the present disclosure. [Figure 2A]

[0009] FIG. 2A is a schematic diagram illustrating an example encoding process of a hybrid video encoding system according to an embodiment of the present disclosure. [Figure 2B]

[0010] FIG. 2B is a schematic diagram illustrating another example encoding process of a hybrid video encoding system according to an embodiment of the present disclosure. [Figure 3A]

[0011] FIG. 3A is a schematic diagram illustrating an example decoding process of a hybrid video coding system according to an embodiment of the present disclosure. [Figure 3B]

[0012] FIG. 3B is a schematic diagram illustrating another exemplary decoding process of a hybrid video coding system, according to an embodiment of the present disclosure. [Figure 4]

[0013] FIG. 4 is a block diagram of an exemplary apparatus for encoding or decoding video according to some embodiments of the present disclosure. [Figure 5]

[0014] FIG. 10 is a schematic diagram illustrating an example of a multi-type tree splitting mode, according to some embodiments of the present disclosure. [Figure 6]

[0015] FIG. 1 is a schematic diagram illustrating an example signaling mechanism for partition split information in a quadtree (QT) with nested multi-type tree coding tree structure, according to some embodiments of the present disclosure. [Figure 7]

[0016] 1 shows an exemplary Table 1 illustrating an exemplary multitype tree split mode (MttSplitMode) derivation based on multitype tree syntax elements, according to some embodiments of the present disclosure. [Figure 8]

[0017] 1 is a schematic diagram illustrating examples of disallowed ternary tree (TT) and binary tree (BT) partitions, according to some embodiments of the present disclosure. [Figure 9]

[0018] 1 is a schematic diagram illustrating exemplary block partitioning on a picture boundary according to some embodiments of the present disclosure. [Figure 10]

[0019] 1 shows exemplary Table 2 illustrating exemplary specifications of parallel ternary tree splitting (parallelTtSplit) based on two-split mode (btSplit) and coding block size (cbSize) according to some embodiments of the present disclosure. [Figure 11]

[0020] 10 shows exemplary Table 3 illustrating exemplary specifications for cbSize based on ternary tree splitting mode (ttSplit), according to some embodiments of the present disclosure. [Figure 12A]

[0021] 1 shows exemplary Table 4 illustrating an exemplary coding tree syntax according to some embodiments of the present disclosure. [Figure 12B]

[0021] Figure 4 shows an example Table 4 illustrating an example coding tree syntax, according to some embodiments of the present disclosure. [Figure 12C]

[0021] Figure 4 shows an example Table 4 illustrating an example coding tree syntax, according to some embodiments of the present disclosure. [Figure 13]

[0022] FIG. 10 is a schematic diagram illustrating an example of a multi-type tree splitting mode indicated by MttSplitMode, according to some embodiments of the present disclosure. [Figure 14]

[0023] 10 shows exemplary Table 5 illustrating exemplary specifications for MttSplitMode according to some embodiments of the present disclosure. [Figure 15]

[0024] 10 shows an example Table 6 illustrating an example sequence parameter set RBSP syntax according to some embodiments of the present disclosure. [Figure 16]

[0025] 10 shows exemplary Table 7 illustrating an exemplary picture header RBSP syntax according to some embodiments of the present disclosure. [Figure 17]

[0026] FIG. 1 is a schematic diagram illustrating an example block where neither QT, TT, nor BT splitting is allowed at a picture boundary, according to some embodiments of the present disclosure. [Figure 18]

[0027] FIG. 1 is a schematic diagram illustrating an example block where neither QT, TT, nor BT splitting is allowed at a picture boundary, according to some embodiments of the present disclosure. [Figure 19]

[0028] FIG. 1 is a schematic diagram illustrating an example of using BT and TT partitioning, according to some embodiments of the present disclosure. [Figure 20]

[0029] 1 shows a flowchart of an exemplary video processing method according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0009] Detailed Description

[0030] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which like reference numerals in different drawings represent the same or similar elements unless otherwise indicated. The implementations set forth in the following description of exemplary embodiments do not represent all implementations in accordance with the present invention. Rather, they are merely examples of apparatus and methods in accordance with aspects related to the present invention as recited in the appended claims. Certain aspects of the present disclosure are described in more detail below. In the event of a conflict with terms and / or definitions incorporated by reference, the terms and definitions provided herein shall control.

[0010]

[0031] The ITU-T Video Coding Expert Group (ITU-T VCEG) and the ISO / IEC Moving Picture Expert Group (ISO / IEC MPEG) Joint Video Experts Team (JVET) are currently developing the Versatile Video Coding (VVC / H.266) standard. The VVC standard aims to double the compression efficiency of its predecessor, the High Efficiency Video Coding (HEVC / H.265) standard. In other words, the goal of VVC is to achieve the same subjective quality as HEVC / H.265 while using half the bandwidth.

[0011]

[0032] To achieve the same subjective quality as HEVC / H.265 using half the bandwidth, JVET is developing technology beyond HEVC using the joint exploration model (JEM) reference software. Because the coding technology was incorporated into JEM, JEM achieved substantially higher coding performance than HEVC.

[0012]

[0033] The VVC standard is a recent development and continues to incorporate more coding techniques that result in better compression performance. VVC is based on the same hybrid video coding system that has been used in modern video compression standards such as HEVC, H.264 / AVC, MPEG2, H.263, etc.

[0013]

[0034] Video is a set of static pictures (or "frames") arranged in time sequence to store visual information. A video capture device (e.g., a camera) can be used to capture and store these pictures in time sequence, and a video playback device (e.g., a television, a computer, a smartphone, a tablet computer, a video player, or any end-user terminal with display capabilities) can be used to display such pictures in time sequence. In some applications, a video capture device can also transmit the captured video in real time to a video playback device (e.g., a computer with a monitor) for purposes such as supervision, conferencing, or live broadcasting.

[0014]

[0035] To reduce the storage space and transmission bandwidth required by such applications, video can be compressed before storage and transmission and decompressed before display. Compression and decompression can be performed by software executed by a processor (e.g., a processor in a general-purpose computer) or by specialized hardware. A module for compression is commonly referred to as an “encoder,” and a module for decompression is commonly referred to as a “decoder.” Collectively, the encoder and decoder can be referred to as a “codec.” The encoder and decoder can be implemented as any of a variety of suitable hardware, software, or combinations thereof. For example, hardware implementations of the encoder and decoder can include circuitry such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, or any combination thereof. Software implementations of the encoder and decoder can include program code, computer-executable instructions, firmware, or any suitable computer-implemented algorithm or process fixed in a computer-readable medium. Video compression and decompression may be performed by various algorithms or standards, such as MPEG-1, MPEG-2, MPEG-4, the H.26x series, or the like. In some applications, a codec may decompress video from a first encoding standard and recompress the decompressed video using a second encoding standard. In this case, the codec may be referred to as a "transcoder."

[0015]

[0036] A video coding process can identify and retain useful information that can be used to reconstruct a picture and ignore information that is not important for reconstruction. If the ignored, unimportant information cannot be perfectly reconstructed, such a coding process may be called "lossy." Otherwise, it may be called "lossless." Most coding processes are lossy; this is a tradeoff to reduce the required storage space and transmission bandwidth.

[0016]

[0037] Useful information about the picture being coded (called the "current picture") includes changes relative to a reference picture (e.g., a previously coded and reconstructed picture). Such changes may include changes in pixel position, brightness, or color, with position changes being the most important. Changes in the position of a group of pixels representing an object may reflect the movement of the object between the reference picture and the current picture.

[0017]

[0038] A picture that is coded without reference to another picture (i.e., it is its own reference picture) is called an "I-picture." A picture that is coded using a previous picture as a reference picture is called a "P-picture." A picture that is coded using both a previous picture and a future picture as a reference picture (i.e., the referencing is "bidirectional") is called a "B-picture."

[0018]

[0039] 1 illustrates the structure of an exemplary video sequence 100 according to some embodiments of the present disclosure. The video sequence 100 can be live video or captured and archived video. The video 100 can be real video, computer-generated video (e.g., computer game video), or a combination thereof (e.g., real video with augmented reality effects). The video sequence 100 can be input from a video capture device (e.g., a camera), a video archive containing previously captured video (e.g., video files stored in a storage device), or a video supply interface (e.g., a video broadcast transceiver) for receiving video from a video content provider.

[0019]

[0040] As shown in FIG. 1, video sequence 100 may include a series of pictures arranged temporally along a timeline, including pictures 102, 104, 106, and 108. Pictures 102-106 are consecutive, with additional pictures between pictures 106 and 108. In FIG. 1, picture 102 is an I-picture, and its reference picture is picture 102 itself. Picture 104 is a P-picture, and its reference picture is picture 102, as indicated by the arrow. Picture 106 is a B-picture, and its reference pictures are pictures 104 and 108, as indicated by the arrows. In some embodiments, the reference picture of a picture (e.g., picture 104) need not immediately precede or follow that picture. For example, the reference picture of picture 104 can be a picture before picture 102. It should be noted that the reference pictures of pictures 102-106 are merely examples, and this disclosure does not limit the reference picture embodiments to the examples shown in FIG.

[0020]

[0041] Typically, video codecs do not encode or decode an entire picture at once due to the computational complexity of such a task. Rather, they may divide a picture into elementary segments and encode or decode the picture segment by segment. Such elementary segments are referred to as basic processing units ("BPUs") in this disclosure. For example, structure 110 in FIG. 1 shows an example structure of a picture (e.g., any of pictures 102-108) of video sequence 100. In structure 110, the picture is divided into 4x4 basic processing units, the boundaries of which are shown as dashed lines. In some embodiments, basic processing units may be referred to as "macroblocks" in some video coding standards (e.g., MPEG family, H.261, H.263, or H.264 / AVC) or as "coding tree units" ("CTUs") in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC). The basic processing units can have variable sizes in pictures or any shape and size of pixels, such as 128x128, 64x64, 32x32, 16x16, 4x8, 16x32, etc. The size and shape of the basic processing unit can be selected based on a balance between coding efficiency and the level of detail to be maintained in the basic processing unit for the picture.

[0021]

[0042] A basic processing unit may be a logical unit that can include groups of different types of video data stored in computer memory (e.g., in a video frame buffer). For example, a basic processing unit for a color picture may include a luma component (Y) that represents colorless luminance information, one or more chroma components (e.g., Cb and Cr) that represent color information, and related syntax elements, where the luma and chroma components may have the same size of a basic processing unit. The luma and chroma components may be referred to as "coding tree blocks" (CTBs) in some video coding standards (e.g., H.265 / HEVC or H.266 / VVC). Any operation performed on a basic processing unit may be performed repeatedly on each of its luma and chroma components.

[0022]

[0043] Video coding has multiple computational stages, examples of which are shown in Figures 2A-2B and 3A-3B. At each stage, the size of the basic processing unit may still become too large for processing and therefore may be further divided into segments referred to as "basic processing subunits" in this disclosure. In some embodiments, the basic processing subunits may be referred to as "blocks" in some video coding standards (e.g., MPEG family, H.261, H.263, or H.264 / AVC) or as "coding units" ("CUs") in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC). The basic processing subunits may have the same or smaller size than the basic processing units. Similar to the basic processing units, the basic processing subunits are also logical units that may contain groups of different types of video data (e.g., Y, Cb, Cr, and related syntax elements) stored in computer memory (e.g., in a video frame buffer). Any operation performed on a basic processing sub-unit may be repeatedly performed on each of its luma and chroma components. Note that such division may be performed to further levels as needed for processing. Also, note that different stages may use different schemes to divide the basic processing units.

[0023]

[0044] For example, in a mode decision stage (an example of which is shown in FIG. 2B ), an encoder can decide what prediction mode (e.g., intra-picture prediction or inter-picture prediction) to use for a basic processing unit, but the basic processing unit may be too large to make such a decision. The encoder can divide the basic processing unit into multiple basic processing sub-units (e.g., CUs, as in the case of H.265 / HEVC or H.266 / VVC) and decide the type of prediction for each individual basic processing sub-unit.

[0024]

[0045] As another example, in the prediction stage (an example of which is shown in FIGS. 2A-2B), the encoder may perform prediction operations at the level of basic processing sub-units (e.g., CUs). However, in some cases, the basic processing sub-units may still be too large to process. The encoder may further divide the basic processing sub-units into smaller segments (e.g., referred to as "prediction blocks" or "PBs" in H.265 / HEVC or H.266 / VVC), at which level the prediction operations may be performed.

[0025]

[0046] As another example, in the transform stage (an example of which is shown in FIGS. 2A-2B), the encoder may perform transform operations for residual basic processing sub-units (e.g., CUs). However, in some cases, the basic processing sub-units may still be too large to process. The encoder may further divide the basic processing sub-units into smaller segments (e.g., referred to as "transform blocks" or "TBs" in H.265 / HEVC or H.266 / VVC), at which levels the transform operations may be performed. Note that the division scheme of the same basic processing sub-unit may be different in the prediction stage and the transform stage. For example, in H.265 / HEVC or H.266 / VVC, the prediction blocks and transform blocks of the same CU may have different sizes and numbers.

[0026]

[0047] 1, the basic processing unit 112 is further divided into 3x3 basic processing sub-units, the boundaries of which are shown as dotted lines. Different basic processing units of the same picture may be divided into basic processing sub-units in different ways.

[0027]

[0048] In some implementations, to provide parallel processing and error resilience capabilities to video encoding and decoding, a picture can be divided into regions for processing, so that the encoding or decoding process does not rely on information about a region of the picture from any other region of the picture. In other words, each region of a picture can be processed independently. By doing so, the codec can process different regions of the picture in parallel, thus increasing coding efficiency. Also, when data for a region is corrupted during processing or lost during network transmission, the codec can correctly encode or decode other regions of the same picture without relying on the corrupted or lost data, thus providing error resilience. Some video coding standards allow pictures to be divided into different types of regions. For example, H.265 / HEVC and H.266 / VVC provide two types of regions: "slices" and "tiles." It should also be noted that different pictures in video sequence 100 can have different partitioning schemes for dividing the picture into regions.

[0028]

[0049] For example, in Figure 1, structure 110 is divided into three regions 114, 116, and 118, the boundaries of which are shown as solid lines within structure 110. Region 114 includes four basic processing units. Regions 116 and 118 each include six basic processing units. It should be noted that the basic processing units, basic processing subunits, and regions of structure 110 in Figure 1 are merely examples, and the present disclosure does not limit the embodiments thereof.

[0029]

[0050] FIG. 2A shows a schematic diagram of an exemplary encoding process 200A according to an embodiment of the present disclosure. For example, encoding process 200A may be performed by an encoder. As shown in FIG. 2A, the encoder may encode a video sequence 202 into a video bitstream 228 according to process 200A. Similar to video sequence 100 in FIG. 1, video sequence 202 may include a set of pictures (referred to as "original pictures") arranged in a temporal order. Similar to structure 110 in FIG. 1, each original picture in video sequence 202 may be divided into basic processing units, basic processing sub-units, or regions for processing by the encoder. In some embodiments, the encoder may perform process 200A at the level of basic processing units for each original picture in video sequence 202. For example, the encoder may perform process 200A in an iterative manner, in which case the encoder may encode a basic processing unit in one iteration of process 200A. In some embodiments, the encoder may perform process 200A in parallel for regions of each original picture of video sequence 202 (eg, regions 114-118).

[0030]

[0051] 2A , an encoder may provide a fundamental processing unit (referred to as an “original BPU”) of an original picture of a video sequence 202 to a prediction stage 204 to generate prediction data 206 and a prediction BPU 208. The encoder may subtract the prediction BPU 208 from the original BPU to generate a residual BPU 210. The encoder may provide the residual BPU 210 to a transform stage 212 and a quantization stage 214 to generate quantized transform coefficients 216. The encoder may provide the prediction data 206 and the quantized transform coefficients 216 to a binary coding stage 226 to generate a video bitstream 228. Components 202, 204, 206, 208, 210, 212, 214, 216, 226, and 228 may be referred to as a “forward path.” During process 200A, after quantization stage 214, the encoder may provide quantized transform coefficients 216 to inverse quantization stage 218 and inverse transform stage 220 to generate reconstructed residual BPU 222. The encoder may add reconstructed residual BPU 222 to prediction BPU 208 to generate prediction reference 224, which is used in prediction stage 204 for the next iteration of process 200A. Components 218, 220, 222, and 224 of process 200A may be referred to as a "reconstruction path." The reconstruction path may be used to ensure that both the encoder and decoder use the same reference data for prediction.

[0031]

[0052] The encoder may iteratively perform process 200A to encode each original BPU of the original picture (in the forward path) and generate (in the reconstruction path) a prediction reference 224 for encoding the next original BPU of the original picture. After encoding all original BPUs of the original picture, the encoder may proceed to encode the next picture in video sequence 202.

[0032]

[0053] Referring to process 200A, an encoder may receive a video sequence 202 generated by a video capture device (e.g., a camera). As used herein, the term "receive" may refer to receiving, inputting, acquiring, obtaining, getting, reading, accessing, or any act in any manner to input data.

[0033]

[0054] In the prediction step 204, in the current iteration, the encoder may receive the original BPU and a prediction reference 224, perform a prediction operation, and generate predicted data 206 and a predicted BPU 208. The prediction reference 224 may be generated from a reconstruction path of a previous iteration of the process 200A. The purpose of the prediction step 204 is to reduce information redundancy by extracting predicted data 206, which can be used to reconstruct the original BPU as a predicted BPU 208 from the predicted data 206 and the prediction reference 224.

[0034]

[0055] Ideally, predicted BPU 208 can be identical to the original BPU. However, due to non-ideal prediction and reconstruction operations, predicted BPU 208 generally differs slightly from the original BPU. To record such differences, after generating predicted BPU 208, the encoder can subtract it from the original BPU to generate residual BPU 210. For example, the encoder can subtract pixel values (e.g., grayscale or RGB values) of predicted BPU 208 from corresponding pixel values of the original BPU. Each pixel of residual BPU 210 can have a residual value that is the result of such a subtraction between the corresponding pixel of the original BPU and predicted BPU 208. Compared to the original BPU, predicted data 206 and residual BPU 210 can have fewer bits, which can be used to reconstruct the original BPU without significant quality degradation. Therefore, the original BPU is compressed.

[0035]

[0056] To further compress the residual BPU 210, in the transform stage 212, the encoder can reduce spatial redundancy in the residual BPU 210 by decomposing it into a set of two-dimensional "basis patterns," each associated with a "transform coefficient." The basis patterns can have the same size (e.g., the size of the residual BPU 210). Each basis pattern can represent a change frequency (e.g., a frequency of luminance change) component of the residual BPU 210. No basis pattern can be reconstructed from any combination (e.g., a linear combination) of any other basis patterns. In other words, the decomposition can decompose the changes in the residual BPU 210 into the frequency domain. Such a decomposition is similar to a discrete Fourier transform of a function, where the basis patterns are similar to the basis functions (e.g., trigonometric functions) of the discrete Fourier transform, and the transform coefficients are similar to the coefficients associated with the basis functions.

[0036]

[0057] Different transform algorithms can use different basis patterns. For example, various transform algorithms, such as a discrete cosine transform, a discrete sine transform, or the like, can be used in transform stage 212. The transform in transform stage 212 is invertible. That is, the encoder can recover residual BPU 210 by inverting the transform (referred to as an "inverse transform"). For example, to recover pixels of residual BPU 210, the inverse transform can multiply the values of corresponding pixels in the basis pattern by their associated coefficients and add the products to generate a weighted sum. For video coding standards, both the encoder and decoder can use the same transform algorithm (and therefore the same basis pattern). Therefore, the encoder can record only the transform coefficients, and the decoder can reconstruct residual BPU 210 from the transform coefficients without receiving the basis pattern from the encoder. Compared to residual BPU 210, the transform coefficients can have fewer bits, but they can be used to reconstruct residual BPU 210 without significant quality degradation. Therefore, the residual BPU 210 is further compressed.

[0037]

[0058] The encoder can further compress the transform coefficients in the quantization stage 214. In the transform process, different basis patterns can represent different change frequencies (e.g., luminance change frequencies). Because the human eye is generally better at perceiving low-frequency changes, the encoder can ignore high-frequency change information without significant quality degradation during decoding. For example, in the quantization stage 214, the encoder can generate quantized transform coefficients 216 by dividing each transform coefficient by an integer value (referred to as a "quantization parameter") and rounding the quotient to its nearest integer. After such an operation, some transform coefficients of high-frequency basis patterns can be converted to zero, and some transform coefficients of low-frequency basis patterns can be converted to smaller integers. The encoder can ignore zero-valued quantized transform coefficients 216, thereby further compressing the transform coefficients. The quantization process can also be inverted, in which case the quantized transform coefficients 216 can be reconstructed into transform coefficients in the inverse operation of quantization (referred to as "dequantization").

[0038]

[0059] Because the encoder ignores the remainder of such a division in a rounding operation, quantization stage 214 can be lossy. Typically, quantization stage 214 can contribute the greatest information loss in process 200A. The greater the information loss, the fewer bits are required for quantized transform coefficients 216. To achieve different levels of information loss, the encoder can use different values of the quantization parameter or any other parameter of the quantization process.

[0039]

[0060] In binary encoding stage 226, the encoder may encode the prediction data 206 and the quantized transform coefficients 216 using a binary encoding technique, such as, for example, entropy coding, variable length coding, arithmetic coding, Huffman coding, context-adaptive binary arithmetic coding, or any other lossless or lossy compression algorithm. In some embodiments, in addition to the prediction data 206 and the quantized transform coefficients 216, the encoder may encode other information in binary encoding stage 226, such as, for example, a prediction mode used in prediction stage 204, parameters of the prediction operation, the type of transform in transform stage 212, parameters of the quantization process (e.g., quantization parameters), encoder control parameters (e.g., bitrate control parameters), or the like. The encoder may generate a video bitstream 228 using the output data of binary encoding stage 226. In some embodiments, the video bitstream 228 may be further packetized for network transmission.

[0040]

[0061] Referring to the reconstruction path of process 200A, in an inverse quantization stage 218, the encoder may perform inverse quantization on the quantized transform coefficients 216 to generate reconstructed transform coefficients. In an inverse transform stage 220, the encoder may generate a reconstructed residual BPU 222 based on the reconstructed transform coefficients. The encoder may add the reconstructed residual BPU 222 to a prediction BPU 208 to generate a prediction reference 224 to be used in the next iteration of process 200A.

[0041]

[0062] It should be noted that other variations of process 200A may be used to encode video sequence 202. In some embodiments, the stages of process 200A may be performed in a different order by the encoder. In some embodiments, one or more stages of process 200A may be combined into a single stage. In some embodiments, a single stage of process 200A may be split into multiple stages. For example, transform stage 212 and quantization stage 214 may be combined into a single stage. In some embodiments, process 200A may include additional stages. In some embodiments, process 200A may omit one or more stages in FIG. 2A.

[0042]

[0063] 2B shows a schematic diagram of another exemplary encoding process 200B according to an embodiment of the present disclosure. Process 200B may be modified from process 200A. For example, process 200B may be used by an encoder compliant with a hybrid video coding standard (e.g., the H.26x series). Compared to process 200A, the forward path of process 200B additionally includes a mode decision stage 230 and divides the prediction stage 204 into a spatial prediction stage 2042 and a temporal prediction stage 2044. The reconstruction path of process 200B additionally includes a loop filter stage 232 and a buffer 234.

[0043]

[0064] Generally, prediction techniques can be categorized into two types: spatial prediction and temporal prediction. Spatial prediction (e.g., intra-picture prediction or "intra-prediction") can use pixels from one or more already-encoded neighboring BPUs within the same picture to predict the current BPU. That is, the prediction reference 224 in spatial prediction can include neighboring BPUs. Spatial prediction can reduce the inherent spatial redundancy of a picture. Temporal prediction (e.g., inter-picture prediction or "inter-prediction") can use regions from one or more already-encoded pictures to predict the current BPU. That is, the prediction reference 224 in temporal prediction can include an encoded picture. Temporal prediction can reduce the inherent temporal redundancy of a picture.

[0044]

[0065] Referring to process 200B, within the forward path, the encoder performs prediction operations in a spatial prediction step 2042 and a temporal prediction step 2044. For example, in the spatial prediction step 2042, the encoder may perform intra prediction. For an original BPU of a picture being encoded, the prediction reference 224 may include one or more neighboring BPUs within the same picture that are coded (in the forward path) and reconstructed (in the reconstruction path). The encoder may generate the predicted BPU 208 by extrapolating the neighboring BPUs. Extrapolation techniques may include, for example, linear extrapolation or interpolation, polynomial extrapolation or interpolation, or the like. In some embodiments, the encoder may perform extrapolation at the pixel level, such as by extrapolating, for each pixel of the predicted BPU 208, the value of the corresponding pixel. The neighboring BPUs used for extrapolation can be located relative to the original BPU from various directions, such as vertically (e.g., above the original BPU), horizontally (e.g., to the left of the original BPU), diagonally (e.g., below-left, below-right, above-left, or above-right of the original BPU), or any direction defined in the video coding standard used. For intra prediction, the prediction data 206 can include, for example, the locations (e.g., coordinates) of the neighboring BPUs used, the sizes of the neighboring BPUs used, parameters of the extrapolation, the orientations of the neighboring BPUs used relative to the original BPU, or the like.

[0045]

[0066] As another example, in the temporal prediction stage 2044, the encoder may perform inter-prediction. For the original BPU of the current picture, the prediction reference 224 may include one or more pictures (referred to as "reference pictures") that have been coded (in the forward path) and reconstructed (in the reconstruction path). In some embodiments, the reference pictures may be coded and reconstructed for each BPU. For example, the encoder may add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a reconstructed BPU. When all the reconstructed BPUs of the same picture have been generated, the encoder may generate the reconstructed picture as the reference picture. The encoder may perform a "motion estimation" operation to search for a matching region within a range (referred to as a "search window") of the reference picture. The location of the search window in the reference picture may be determined based on the location of the original BPU of the current picture. For example, the search window may be centered in the reference picture at a location having the same coordinates as the original BPU in the current picture and may extend outward over a predetermined distance. When the encoder identifies a region similar to the original BPU within the search window (e.g., by using a pel-recursive algorithm, a block matching algorithm, or the like), the encoder can determine such a region as a matching region. The matching region can have different dimensions than the original BPU (e.g., smaller than, equal to, larger than, or a different shape than the original BPU). Because the reference picture and the current picture are temporally separated in a timeline (e.g., as shown in FIG. 1), the matching region can be considered to "move" toward the location of the original BPU over time. The encoder can record the direction and distance of such movement as a "motion vector." When multiple reference pictures are used (e.g., as picture 106 in FIG. 1), the encoder can search for the matching region for each reference picture and determine its associated motion vector. In some embodiments, the encoder can assign weights to the pixel values of the matching region in each matching reference picture.

[0046]

[0067] Motion estimation can be used to identify various types of motion, such as, for example, translation, rotation, zooming, or the like. For inter prediction, prediction data 206 can include, for example, the location (e.g., coordinates) of the matching region, a motion vector associated with the matching region, the number of reference pictures, weights associated with the reference pictures, or the like.

[0047]

[0068] To generate the predicted BPU 208, the encoder may perform a "motion compensation" operation. Motion compensation may be used to reconstruct the predicted BPU 208 based on the prediction data 206 (e.g., a motion vector) and the prediction reference 224. For example, the encoder may shift the matching region of a reference picture according to the motion vector, in which case the encoder may predict the original BPU of the current picture. When multiple reference pictures are used (e.g., as picture 106 in FIG. 1), the encoder may shift the matching region of the reference picture according to each motion vector and average the pixel values of the matching region. In some embodiments, if the encoder weights the pixel values of the matching region of each matching reference picture, the encoder may add a weighted sum of pixel values to the shifted matching region.

[0048]

[0069] Depending on the embodiment, inter-prediction can be unidirectional or bidirectional. Unidirectional inter-prediction can use one or more reference pictures in the same temporal direction relative to the current picture. For example, picture 104 in FIG. 1 is a unidirectional inter-predicted picture in which a reference picture (i.e., picture 102) precedes picture 104. Bidirectional inter-prediction can use one or more reference pictures in both temporal directions relative to the current picture. For example, picture 106 in FIG. 1 is a bidirectional inter-predicted picture in which reference pictures (i.e., pictures 104 and 108) are in both temporal directions relative to picture 104.

[0049]

[0070] Still referring to the forward path of process 200B, after spatial prediction 2042 and temporal prediction step 2044, in mode decision step 230, the encoder may select a prediction mode (e.g., one of intra prediction or inter prediction) for the current iteration of process 200B. For example, the encoder may perform a rate-distortion optimization technique. In this technique, the encoder may select a prediction mode to minimize the value of a cost function that depends on the bitrate of the candidate prediction mode and the distortion of the reconstructed reference picture under the candidate prediction mode. Depending on the selected prediction mode, the encoder may generate a corresponding predicted BPU 208 and predicted data 206.

[0050]

[0071] Within the reconstruction path of process 200B, if an intra-prediction mode is selected within the forward path, after generating the prediction reference 224 (e.g., the current BPU coded and reconstructed in the current picture), the encoder can directly provide the prediction reference 224 to the spatial prediction stage 2042 for later use (e.g., for extrapolation of the next BPU of the current picture). If an inter-prediction mode is selected within the forward path, after generating the prediction reference 224 (e.g., the current picture coded and reconstructed in all BPUs), the encoder can provide the prediction reference 224 to the loop filter stage 232, where the encoder can apply a loop filter to the prediction reference 224 to reduce or eliminate distortions (e.g., blocking artifacts) introduced by the inter prediction. The encoder can apply various loop filter techniques within the loop filter stage 232, such as deblocking, sample adaptive offset, adaptive loop filter, or the like. The loop-filtered reference picture may be stored in a buffer 234 (or "decoded picture buffer") for later use (e.g., to be used as an inter-prediction reference picture for a future picture in the video sequence 202). The encoder may store one or more reference pictures in the buffer 234 for use in the temporal prediction stage 2044. In some embodiments, the encoder may encode loop filter parameters (e.g., loop filter strength) along with the quantized transform coefficients 216, the prediction data 206, and other information in the binary encoding stage 226.

[0051]

[0072] FIG. 3A shows a schematic diagram of an exemplary decoding process 300A according to an embodiment of the present disclosure. Process 300A may be a decompression process corresponding to compression process 200A in FIG. 2A. In some embodiments, process 300A may be similar to the reconstruction path of process 200A. A decoder may follow process 300A to decode video bitstream 228 into video stream 304. Video stream 304 may be similar to video sequence 202. However, due to information loss in the compression and decompression processes (e.g., quantization stage 214 in FIGS. 2A-2B), video stream 304 is generally not identical to video sequence 202. Similar to processes 200A and 200B in FIGS. 2A-2B, a decoder may perform process 300A at the level of a basic processing unit (BPU) for each picture encoded in video bitstream 228. For example, the decoder may perform process 300A in an iterative manner, in which case the decoder may decode a basic processing unit in one iteration of process 300A. In some embodiments, the decoder may perform process 300A in parallel for regions (e.g., regions 114-118) of each picture encoded in video bitstream 228.

[0052]

[0073] In FIG. 3A , a decoder may provide a portion of a video bitstream 228 associated with a basic processing unit (referred to as a “coding BPU”) of a coded picture to a binary decoding stage 302. In the binary decoding stage 302, the decoder may decode the portion into prediction data 206 and quantized transform coefficients 216. The decoder may provide the quantized transform coefficients 216 to an inverse quantization stage 218 and an inverse transform stage 220 to generate a reconstructed residual BPU 222. The decoder may provide the prediction data 206 to a prediction stage 204 to generate a prediction BPU 208. The decoder may add the reconstructed residual BPU 222 to the prediction BPU 208 to generate a prediction reference 224. In some embodiments, the prediction reference 224 may be stored in a buffer (e.g., a decoded picture buffer in computer memory). The decoder can provide the prediction reference 224 to the prediction stage 204 to perform the prediction operation in the next iteration of the process 300A.

[0053]

[0074] The decoder may perform process 300A iteratively to decode each coded BPU of a coded picture and generate a prediction reference 224 for encoding the next coded BPU of the coded picture. After decoding all coded BPUs of a coded picture, the decoder may output the picture to video stream 304 for display and proceed to decode the next coded picture in video bitstream 228.

[0054]

[0075] In binary decoding stage 302, the decoder may perform the inverse operation of the binary coding technique used by the encoder (e.g., entropy coding, variable length coding, arithmetic coding, Huffman coding, context-adaptive binary arithmetic coding, or any other lossless compression algorithm). In some embodiments, in addition to prediction data 206 and quantized transform coefficients 216, the decoder may decode other information in binary decoding stage 302, such as, for example, a prediction mode, parameters of the prediction operation, type of transform, parameters of the quantization process (e.g., quantization parameters), encoder control parameters (e.g., bitrate control parameters), or the like. In some embodiments, if video bitstream 228 is transmitted in packets over a network, the decoder may depacketize video bitstream 228 before providing it to binary decoding stage 302.

[0055]

[0076] 3B shows a schematic diagram of another exemplary decoding process 300B according to an embodiment of the present disclosure. Process 300B may be modified from process 300A. For example, process 300B may be used by a decoder compliant with a hybrid video coding standard (e.g., the H.26x series). Compared to process 300A, process 300B additionally divides prediction stage 204 into spatial prediction stage 2042 and temporal prediction stage 2044, and additionally includes loop filter stage 232 and buffer 234.

[0056]

[0077] In process 300B, prediction data 206 decoded by the decoder from binary decoding stage 302 for a coding basic processing unit (referred to as the “current BPU”) of a coding picture being decoded (referred to as the “current picture”) may include various types of data, depending on what prediction mode was used by the encoder to encode the current BPU. For example, if intra prediction was used by the encoder to encode the current BPU, prediction data 206 may include a prediction mode indicator (e.g., a flag value) indicating intra prediction, parameters of the intra prediction operation, or the like. Parameters of the intra prediction operation may include, for example, the location (e.g., coordinates) of one or more neighboring BPUs used as references, the size of the neighboring BPUs, parameters of extrapolation, the orientation of the neighboring BPUs relative to the original BPU, or the like. As another example, if inter prediction was used by the encoder to encode the current BPU, prediction data 206 may include a prediction mode indicator (e.g., a flag value) indicating inter prediction, parameters of the inter prediction operation, or the like. Parameters for the inter prediction operation may include, for example, the number of reference pictures associated with the current BPU, weights associated with each of the reference pictures, locations (e.g., coordinates) of one or more matching regions within each reference picture, one or more motion vectors associated with each of the matching regions, or the like.

[0057]

[0078] Based on the prediction mode indicator, the decoder may determine whether to perform spatial prediction (e.g., intra prediction) in spatial prediction step 2042 or temporal prediction (e.g., inter prediction) in temporal prediction step 2044. Details of performing such spatial or temporal prediction are described in FIG. 2B and will not be repeated below. After performing such spatial or temporal prediction, the decoder may generate a predicted BPU 208. The decoder may add the predicted BPU 208 and the reconstructed residual BPU 222 to generate a prediction reference 224, as described in FIG. 3A.

[0058]

[0079] In process 300B, the decoder may provide the prediction reference 224 to the spatial prediction stage 2042 or the temporal prediction stage 2044 to perform the prediction operation in the next iteration of process 300B. For example, if the current BPU is decoded using intra prediction in spatial prediction stage 2042, after generating the prediction reference 224 (e.g., the decoded current BPU), the decoder may provide the prediction reference 224 directly to the spatial prediction stage 2042 for later use (e.g., for extrapolation of the next BPU of the current picture). If the current BPU is decoded using inter prediction in temporal prediction stage 2044, after generating the prediction reference 224 (e.g., the reference picture from which all BPUs are decoded), the encoder may provide the prediction reference 224 to the loop filter stage 232 to reduce or eliminate distortion (e.g., blocking artifacts). The decoder may apply a loop filter to the prediction reference 224 in the manner described in FIG. 2B . The loop-filtered reference picture may be stored in a buffer 234 (e.g., a decoded picture buffer in computer memory) for later use (e.g., to be used as an inter-prediction reference picture for a future coded picture of the video bitstream 228). The decoder may store one or more reference pictures in the buffer 234 for use in the temporal prediction stage 2044. In some embodiments, when the prediction mode indicator of the prediction data 206 indicates that inter-prediction was used to encode the current BPU, the prediction data may further include parameters of the loop filter (e.g., loop filter strength).

[0059]

[0080] 4 is a block diagram of an exemplary device 400 for encoding or decoding video, according to an embodiment of the present disclosure. As shown in FIG. 4, the device 400 may include a processor 402. When the processor 402 executes instructions described herein, the device 400 can become a specialized machine for video encoding or decoding. The processor 402 can be any type of circuitry capable of manipulating or processing information. For example, processor 402 may include any number and combination of a central processing unit (or "CPU"), a graphics processing unit (or "GPU"), a neural processing unit ("NPU"), a microcontroller unit ("MCU"), an optical processor, a programmable logic controller, a microcontroller, a microprocessor, a digital signal processor, an intellectual property (IP) core, a programmable logic array (PLA), a programmable array logic (PAL), a generic array logic (GAL), a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a system on chip (SoC), an application-specific integrated circuit (ASIC), or the like. In some embodiments, processor 402 may also be a set of processors grouped as a single logical entity. For example, as shown in Figure 4, processor 402 may include multiple processors, including processor 402a, processor 402b, and processor 402n.

[0060]

[0081] The device 400 may also include a memory 404 configured to store data (e.g., a set of instructions, computer code, intermediate data, or the like). For example, as shown in FIG. 4, the stored data may include program instructions (e.g., program instructions for performing steps in processes 200A, 200B, 300A, or 300B) and data for processing (e.g., video sequence 202, video bitstream 228, or video stream 304). The processor 402 may access the program instructions and data for processing (e.g., via bus 410), execute the program instructions, and perform operations or manipulations on the data for processing. The memory 404 may include a high-speed random-access storage device or a non-volatile storage device. In some embodiments, memory 404 may include any number or combination of random-access memory (RAM), read-only memory (ROM), optical disks, magnetic disks, hard drives, solid-state drives, flash drives, security digital (SD) cards, memory sticks, compact flash (CF) cards, or the like. Memory 404 may also be a group of memories (not shown in FIG. 4) grouped as a single logical entity.

[0061]

[0082] Bus 410 can be a communication device that transfers data between components internal to apparatus 400, such as an internal bus (e.g., a CPU-memory bus), an external bus (e.g., a Universal Serial Bus port, a Peripheral Component Interconnect Express port), or the like.

[0062]

[0083] For ease of explanation and without ambiguity, the processor 402 and other data processing circuitry will be collectively referred to in this disclosure as "data processing circuitry." The data processing circuitry may be implemented entirely in hardware or as a combination of software, hardware, or firmware. In addition, the data processing circuitry may be a single, stand-alone module or may be fully or partially combined with any other component of the device 400.

[0063]

[0084] Device 400 may further include a network interface 406 for providing wired or wireless communication with a network (e.g., the Internet, an intranet, a local area network, a mobile communication network, or the like). In some embodiments, network interface 406 may include any number or combination of a network interface controller (NIC), a radio frequency (RF) module, a transponder, a transceiver, a modem, a router, a gateway, a wired network adapter, a wireless network adapter, a Bluetooth® adapter, an infrared adapter, a near-field communication ("NFC") adapter, a cellular network chip, or the like.

[0064]

[0085] In some embodiments, apparatus 400 may optionally further include a peripheral interface 408 for providing connection to one or more peripheral devices. As shown in Figure 4, the peripheral devices may include, but are not limited to, a cursor control device (e.g., a mouse, a touchpad, or a touchscreen), a keyboard, a display (e.g., a cathode ray tube display, a liquid crystal display, or a light emitting diode display), a video input device (e.g., a camera, or an input interface coupled to a video archive), or the like.

[0065]

[0086] It should be noted that a video codec (e.g., a codec performing process 200A, 200B, 300A, or 300B) may be implemented as any combination of software or hardware modules within device 400. For example, some or all of the stages of process 200A, 200B, 300A, or 300B may be implemented as one or more software modules of device 400, such as program instructions that may be loaded into memory 404. As another example, some or all of the stages of process 200A, 200B, 300A, or 300B may be implemented as one or more hardware modules of device 400, such as specialized data processing circuitry (e.g., FPGA, ASIC, NPU, or the like).

[0066]

[0087] In the quantization and inverse quantization functional blocks (e.g., quantization 214 and inverse quantization 218 in FIG. 2A or 2B, inverse quantization 218 in FIG. 3A or 3B), a quantization parameter (QP) is used to determine the amount of quantization (and inverse quantization) applied to the prediction residual. The initial QP value used for coding a picture or slice can be signaled at a high level, for example, using the init_qp_minus26 syntax element in the Picture Parameter Set (PPS) and the slice_qp_delta syntax element in the slice header. Furthermore, the QP value can be adapted at a local level per CU using delta QP values sent at the granularity of the quantization group.

[0067]

[0088] In some embodiments, a picture may be divided into multiple coding tree units (CTUs). The CTUs are then further divided into one or more coding units (CUs) using a quadtree (SPLIT_QT) with nested multitype trees using bipartite and tripartite segmentation structures. Figure 5 is a schematic diagram illustrating an example of a multitype tree division mode, according to some embodiments of the present disclosure. As shown in Figure 5, division types in the multitype tree structure may include quadtree division (SPLIT_QT) 501, vertical bipartite (SPLIT_BT_VER) 502, horizontal bipartite (SPLIT_BT_HOR) 503, vertical tripartite (SPLIT_TT_VER) 504, and horizontal tripartite (SPLIT_TT_HOR) 505. The leaf nodes of the multitype tree are called coding units (CUs) and may have either a square or rectangular shape.

[0068]

[0089] 6 is a schematic diagram illustrating an example signaling mechanism for partition split information in a quadtree with a nested multitype tree coding tree structure according to some embodiments of the present disclosure. As shown in FIG. 6, the CTU is treated as the root of the quadtree and is initially partitioned by the quadtree structure. Each quadtree leaf node (when large enough to allow it) is further partitioned by the multitype tree structure. In the multitype tree structure, a first flag (e.g., mtt_split_cu_flag) is signaled to indicate whether the node is further partitioned. When the node is further partitioned, a second flag (e.g., mtt_split_cu_vertical_flag) is signaled to indicate the split direction, and then a third flag (e.g., mtt_split_cu_binary_flag) is signaled to indicate whether the split is bipartite or tripartite. Based on the values of the second flag mtt_split_cu_vertical_flag and the third flag mtt_split_cu_binary_flag, the multitype tree split mode (MttSplitMode) of the CU may be derived. Figure 7 shows example Table 1 illustrating an example MttSplitMode derivation based on the multitype tree syntax element according to some embodiments of the present disclosure.

[0069]

[0090] A vertical pipeline data unit (VPDU) is defined as a non-overlapping unit within a picture. In a hardware decoder, consecutive VPDUs are processed by multiple pipeline stages simultaneously. The VPDU size is roughly proportional to the buffer size in most pipeline stages, and therefore, it is important to keep the VPDU size small. In most hardware decoders, the VPDU size may be set to 64x64 luma samples. However, in some embodiments, ternary tree (TT) and binary tree (BT) partitioning may lead to an increase in the VPDU size. In accordance with this disclosure, certain standard partitioning restrictions may be applied to maintain the VPDU size as 64x64 luma samples. Figure 8 shows examples of disallowed TT and BT partitioning according to some embodiments of the present disclosure. As shown in Figure 8, TT partitioning is not allowed for blocks with either width or height equal to 128, or both width and height equal to 128. For 128xN CUs (e.g., width equal to 128 and height less than 128) with N <= 64, horizontal BT is not allowed. For Nx128 CUs (e.g., height equal to 128 and width less than 128) with N <= 64, vertical BT is not allowed.

[0070]

[0091] As required in HEVC, when part of a tree node block exceeds the bottom or right picture boundary, the tree node block is forced to split until all samples of every coding CU are located inside the picture boundary. The following splitting rules apply in VVC Draft 7: - if part of a tree node block exceeds both the bottom and right picture boundaries, - If the block is a QT node and the size of the block is larger than the minimum QT size, the block is forcibly split in QT split mode. - Otherwise, the block is forcibly split in SPLIT_BT_HOR mode. - Otherwise, if any part of the tree node block extends beyond the bottom picture boundary, - If the block is a QT node, and the size of the block is larger than the minimum QT size, and the size of the block is larger than the maximum BT size, the block is forcibly split in QT split mode. - Otherwise, if the block is a QT node, and the size of the block is larger than the minimum QT size and smaller than or equal to the maximum BT size, the block is forcibly split in QT split mode or SPLIT_BT_HOR mode. - Otherwise (if the block is a BT node or the size of the block is less than or equal to the minimum QT size), the block is forcibly split in SPLIT_BT_HOR mode. - Otherwise, if any part of the tree node block exceeds the right picture boundary, - If the block is a QT node, and the size of the block is larger than the minimum QT size, and the size of the block is larger than the maximum BT size, the block is forcibly split in QT split mode. - Otherwise, if the block is a QT node, and the size of the block is larger than the minimum QT size and smaller than or equal to the maximum BT size, the block is forcibly split in QT split mode or SPLIT_BT_VER mode. - Otherwise (for example, if the block is a BT node or the size of the block is less than or equal to the minimum QT size), the block is forcibly split in SPLIT_BT_VER mode.

[0071]

[0092] 9 illustrates exemplary block partitioning on a picture boundary according to some embodiments of the present disclosure. As shown in FIG. 9, for CTU 911, either SPLIT_QT or SPLIT_BT_VER may be performed. For CTU 913, if SPLIT_QT is allowed, SPLIT_QT may be performed. If SPLIT_QT is not allowed, SPLIT_BT_HOR may be performed. For CTU 915, either SPLIT_QT or SPLIT_BT_HOR may be performed.

[0072]

[0093] VVC Draft 7 has two sections related to block partitioning. The first is section 6.4, which defines whether blocks can be split using a quadtree, binary tree, or ternary tree. The outputs of section 6.4 are the variables allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer. These variables are used in section 7.3.9.4 to determine whether the corresponding CU-level split flags (shown by boxes 1201-1204 in Table 4 of Figure 12) are signaled, as shown in Table 4 of Figure 12.

[0073]

[0094] Section 6.4.1 of VVC Draft 7 states: 6.4 Availability Process 6.4.1 Allowed Quadrant Processes The inputs to this process are: - coding block size in luma samples, cbSize - Multitype tree depth mttDepth - variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the coding tree nodes, and whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently processed when a dual tree is used; - a variable modeType that specifies whether intra coding modes (MODE_INTRA), IBC coding modes (MODE_IBC), and inter coding modes can be used (MODE_TYPE_ALL), or only intra coding modes and IBC coding modes (MODE_TYPE_INTRA), or only inter coding modes (MODE_TYPE_INTER) for coding units inside a coding tree node;

[0074]

[0095] The output of this process is the variable allowSplitQt, which is derived as follows: - allowSplitQt is set equal to FALSE if one or more of the following conditions are true: - treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA and cbSize is less than or equal to MinQtSizeY. - treeType is equal to DUAL_TREE_CHROMA and cbSize / SubWidthC is less than or equal to MinQtSizeC. - mttDepth is not equal to 0. - treeType is equal to DUAL_TREE_CHROMA and (cbSize / SubWidthC) is less than or equal to 4. - treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA. - Otherwise, allowSplitQt is set equal to TRUE.

[0075]

[0096] Section 6.4.2 of VVC Draft 7 states: 6.4.2 Allowed Bisection Processes The inputs to this process are: - 2-way split mode btSplit - cbWidth - coded block width in luma samples - coded block height in luma samples, cbHeight - the position (x0,y0) of the top left luma sample of the considered coding block relative to the top left luma sample of the picture - Multitype tree depth mttDepth - Maximum multitype tree depth with offset maxMttDepth - Maximum binary tree size maxBtSize - Minimum quadtree size minQtSize - Partition index partIdx - variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the coding tree nodes, and whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently processed when a dual tree is used; - a variable modeType that specifies whether intra coding modes (MODE_INTRA), IBC coding modes (MODE_IBC), and inter coding modes can be used (MODE_TYPE_ALL), or only intra coding modes and IBC coding modes (MODE_TYPE_INTRA), or only inter coding modes (MODE_TYPE_INTER) for coding units inside a coding tree node;

[0076]

[0097] The output of this process is the variable allowBtSplit. Figure 10 shows exemplary Table 2 illustrating exemplary specifications for the variables parallelTtSplit and cbSize based on btSplit, according to some embodiments of the present disclosure.

[0077]

[0098] The variable allowBtSplit is derived as follows: allowBtSplit is set equal to FALSE if one or more of the following conditions are true: - cbSize is less than or equal to MinBtSizeY. - cbWidth is greater than maxBtSize. - cbHeight is greater than maxBtSize. - mttDepth is greater than or equal to maxMttDepth. - treeType is equal to DUAL_TREE_CHROMA and (cbWidth / SubWidthC) * (cbHeight / SubHeightC) is less than or equal to 16. - treeType is equal to DUAL_TREE_CHROMA, (cbWidth / SubWidthC) is equal to 4, and btSplit is equal to SPLIT_BT_VER. - treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA. - cbWidth x cbHeight is equal to 32 and modeType is equal to MODE_TYPE_INTER. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_VER. - y0+cbHeight is greater than pic_height_in_luma_samples. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_VER. - cbHeight is greater than 64. - x0+cbWidth is greater than pic_width_in_luma_samples. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_HOR. - cbWidth is greater than 64. - y0+cbHeight is greater than pic_height_in_luma_samples. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is greater than pic_height_in_luma_samples. - cbWidth is greater than minQtSize. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_HOR. - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is less than or equal to pic_height_in_luma_samples. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - mttDepth is greater than 0. - partIdx equals 1. - MttSplitMode[x0][y0][mttDepth-1] is equal to parallelTtSplit. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_VER. - cbWidth is less than or equal to 64. - cbHeight is greater than 64. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_HOR. - cbWidth is greater than 64. - cbHeight is less than or equal to 64. Otherwise, allowBtSplit is set equal to TRUE.

[0078]

[0099] Section 6.4.3 of VVC Draft 7 states: 6.4.3 Allowed Three-Part Process The inputs to this process are: - 3-way split mode ttSplit - cbWidth - coded block width in luma samples - coded block height in luma samples, cbHeight - the position (x0,y0) of the top left luma sample of the considered coding block relative to the top left luma sample of the picture - Multitype tree depth mttDepth - Maximum multitype tree depth with offset maxMttDepth - Maximum ternary tree size maxTtSize - variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the coding tree nodes, and whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently processed when a dual tree is used; - a variable modeType that specifies whether intra coding modes (MODE_INTRA), IBC coding modes (MODE_IBC), and inter coding modes can be used (MODE_TYPE_ALL), or only intra coding modes and IBC coding modes (MODE_TYPE_INTRA), or only inter coding modes (MODE_TYPE_INTER) for coding units inside a coding tree node;

[0079]

[0100] The output of this process is the variable allowTtSplit. Figure 11 shows exemplary Table 3 illustrating an exemplary specification of the variable cbSize based on ttSplit according to some embodiments of the present disclosure.

[0080]

[0101] The variable allowTtSplit is derived as follows: allowTtSplit is set equal to FALSE if one or more of the following conditions are true: - cbSize is less than or equal to 2*MinTtSizeY. - cbWidth is greater than Min(64,maxTtSize). - cbHeight is greater than Min(64,maxTtSize). - mttDepth is greater than or equal to maxMttDepth. - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is greater than pic_height_in_luma_samples. - treeType is equal to DUAL_TREE_CHROMA and (cbWidth / SubWidthC) * (cbHeight / SubHeightC) is less than or equal to 32. - treeType is equal to DUAL_TREE_CHROMA, (cbWidth / SubWidthC) is equal to 8, and ttSplit is equal to SPLIT_TT_VER. - treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA. - cbWidth x cbHeight is equal to 64 and modeType is equal to MODE_TYPE_INTER. Otherwise, allowTtSplit is set equal to TRUE.

[0081]

[0102] FIG. 12 illustrates an example Table 4 showing an example coding tree syntax (highlighted with italics and shading) of section 7.3.9.4 of VVC Draft 7, according to some embodiments of the present disclosure.

[0082]

[0103] The variables allowSplitQt, allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, and allowSplitTtHor are derived as follows: - The quad split process allowed as specified in clause 6.4.1 is called with the coding block size cbSize set equal to cbWidth, the current multitype tree depth mttDepth, treeTypeCurr, and modeTypeCurr as input, and the output is assigned to allowSplitQt. The variables minQtSize, maxBtSize, maxTtSize, and maxMttDepth are derived as follows: If treeType is equal to DUAL_TREE_CHROMA, minQtSize, maxBtSize, maxTtSize, and maxMttDepth are set equal to MinQtSizeC, MaxBtSizeC, MaxTtSizeC, and MaxMttDepthC+depthOffset, respectively. - Otherwise, minQtSize, maxBtSize, maxTtSize, and maxMttDepth are set equal to MinQtSizeY, MaxBtSizeY, MaxTtSizeY, and MaxMttDepthY+depthOffset, respectively. - The bisection process allowed as specified in clause 6.4.2 is called with bisection mode SPLIT_BT_VER, coded block width cbWidth, coded block height cbHeight, position (x0,y0), current multitype tree depth mttDepth, max multitype tree depth with offset maxMttDepth, max bitree size maxBtSize, min quadtree size minQtSize, current partition index partIdx, treeTypeCurr, and modeTypeCurr as inputs, and the output is assigned to allowSplitBtVer. - The bisection process allowed as specified in clause 6.4.2 is called with bisection mode SPLIT_BT_HOR, coding block height cbHeight, coding block width cbWidth, position (x0,y0), current multitype tree depth mttDepth, maximum multitype tree depth with offset maxMttDepth, maximum bitree size maxBtSize, minimum quadtree size minQtSize, current partition index partIdx, treeTypeCurr, and modeTypeCurr as inputs, and the output is assigned to allowSplitBtHor. - The allowed ternary split process as specified in clause 6.4.3 is called with the ternary split mode SPLIT_TT_VER, the coding block width cbWidth, the coding block height cbHeight, the position (x0,y0), the current multitype tree depth mttDepth, the maximum multitype tree depth with offset maxMttDepth, the maximum ternary tree size maxTtSize, treeTypeCurr, and modeTypeCurr as inputs, and the output is assigned to allowSplitTtVer. - The allowed ternary split process as specified in clause 6.4.3 is called with the ternary split mode SPLIT_TT_HOR, the coding block height cbHeight, the coding block width cbWidth, the position (x0,y0), the current multitype tree depth mttDepth, the maximum multitype tree depth with offset maxMttDepth, the maximum ternary tree size maxTtSize, treeTypeCurr, and modeTypeCurr as inputs, and the output is assigned to allowSplitTtHor.

[0083]

[0104] The syntax element split_cu_flag equal to 0 specifies that the coding unit is not split. The syntax element split_cu_flag equal to 1 specifies that the coding unit is split into four coding units using a 4-way split as indicated by the syntax element split_qt_flag, or into two coding units using a 2-way split as indicated by the syntax element mtt_split_cu_binary_flag, or into three coding units using a 3-way split. The 2-way or 3-way split can be either vertical or horizontal, as indicated by the syntax element mtt_split_cu_vertical_flag.

[0084]

[0105] When the syntax element split_cu_flag is not present, the value of split_cu_flag is inferred as follows: - The value of split_cu_flag is inferred to be equal to 1 if one or more of the following conditions are true: - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is greater than pic_height_in_luma_samples. - Otherwise, the value of split_cu_flag is inferred to be equal to 0.

[0085]

[0106] The syntax element split_qt_flag specifies whether the coding unit is split into coding units with half the horizontal and vertical size.

[0086]

[0107] When the syntax element split_qt_flag is not present, the following applies: - If allowSplitQt is equal to TRUE, the value of split_qt_flag is inferred to be equal to 1. - Otherwise, the value of split_qt_flag is inferred to be equal to 0.

[0087]

[0108] The syntax element mtt_split_cu_vertical_flag equal to 0 specifies that the coding unit is split in the horizontal direction. The syntax element mtt_split_cu_vertical_flag equal to 1 specifies that the coding unit is split in the vertical direction.

[0088]

[0109] When the syntax element mtt_split_cu_vertical_flag is not present, it is inferred as follows: If allowSplitBtHor is equal to TRUE or allowSplitTtHor is equal to TRUE, the value of mtt_split_cu_vertical_flag is inferred to be equal to 0. - Otherwise, the value of mtt_split_cu_vertical_flag is inferred to be equal to 1.

[0089]

[0110] The syntax element mtt_split_cu_binary_flag equal to 0 specifies that the coding unit is split into three coding units using a 3-way split. The syntax element mtt_split_cu_binary_flag equal to 1 specifies that the coding unit is split into two coding units using a 2-way split.

[0090]

[0111] When the syntax element mtt_split_cu_binary_flag is not present, it is inferred as follows: If allowSplitBtVer is equal to FALSE and allowSplitBtHor is equal to FALSE, the value of mtt_split_cu_binary_flag is inferred to be equal to 0. Otherwise, if allowSplitTtVer is equal to FALSE and allowSplitTtHor is equal to FALSE, the value of mtt_split_cu_binary_flag is inferred to be equal to 1. Otherwise, if allowSplitBtHor is equal to TRUE and allowSplitTtVer is equal to TRUE, the value of mtt_split_cu_binary_flag is inferred to be equal to !mtt_split_cu_vertical_flag. - Otherwise (allowSplitBtVer is equal to TRUE and allowSplitTtHor is equal to TRUE), the value of mtt_split_cu_binary_flag is inferred to be equal to mtt_split_cu_vertical_flag.

[0091]

[0112] 14 shows an example Table 5 illustrating an example specification for MttSplitMode, according to some embodiments of the present disclosure. The variable MttSplitMode[x][y][mttDepth] is derived from the value of the syntax element mtt_split_cu_vertical_flag and from the value of the syntax element mtt_split_cu_binary_flag, as defined in Table 4 for x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1.

[0092]

[0113] MttSplitMode[x0][y0][mttDepth] represents a horizontal halving, vertical halving, horizontal 3-way split, and vertical 3-way split of a coding unit in a multitype tree. Array indices x0, y0 specify the position (x0, y0) of the top-left luma sample of a possible coding block relative to the top-left luma sample of a picture. Figure 13 shows examples of multitype tree splitting modes indicated by MttSplitMode, according to some embodiments of the present disclosure. As shown in Figure 13, the multitype tree splitting modes may include a vertical halving (SPLIT_BT_VER) 1301, a horizontal halving (SPLIT_BT_HOR) 1302, a vertical 3-way split (SPLIT_TT_VER) 1303, and a horizontal 3-way split (SPLIT_TT_HOR) 1304.

[0093]

[0114] Note that the CTU size, minimum block size, and block size restrictions for quadtree, binary, and ternary tree partitioning are signaled either in the sequence parameter set or in the picture header.

[0094]

[0115] 15 shows an example Table 6 illustrating an example Sequence Parameter Set RBSP syntax of section 7.3.2.3 of VVC Draft 7, according to some embodiments of the present disclosure. FIG. 16 shows an example Table 7 illustrating an example Picture Header RBSP syntax of section 7.3.2.6 of VVC Draft 7, according to some embodiments of the present disclosure.

[0095]

[0116] According to some embodiments, when a portion of a tree node block exceeds the bottom or right picture boundary, the tree node block is forced to split until all samples of every coding block are located inside the picture boundary. However, not all tree partitioning modes may be allowed for blocks that are located on a picture boundary and contain samples that exceed the picture boundary. Figure 17 shows an example block where neither QT, TT, nor BT partitioning is allowed at a picture boundary, according to some embodiments of the present disclosure. For example, Figure 17 shows CTU 1701, CTU 1703, and CTU 1705 at a picture boundary where neither QT, TT, nor BT partitioning is allowed.

[0096]

[0117] As a first exemplary case where all tree splitting modes are not allowed, when both the CTU size and the minimum QT size are set to 128, the variables allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are all set to false.

[0097]

[0118] The variable allowSplitQt is set to false due to the following conditions (highlighted in italics): 6.4.1 Allowed Quadrant Processes ... - allowSplitQt is set equal to FALSE if one or more of the following conditions are true: - treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA and cbSize is less than or equal to MinQtSizeY. - treeType is equal to DUAL_TREE_CHROMA and cbSize / SubWidthC is less than or equal to MinQtSizeC. ...

[0098]

[0119] The variable allowSplitBtHor is set to false due to the following conditions (highlighted in italics): 6.4.2 Allowed Bisection Processes ... Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_HOR. - cbWidth is greater than 64. - y0+cbHeight is greater than pic_height_in_luma_samples. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is greater than pic_height_in_luma_samples. - cbWidth is greater than minQtSize. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_HOR. - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is less than or equal to pic_height_in_luma_samples. ...

[0099]

[0120] The variable allowSplitBtVer is set to false due to the following conditions (highlighted in italics): 6.4.2 Allowed Bisection Processes ... Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_VER. - y0+cbHeight is greater than pic_height_in_luma_samples. Otherwise, if all of the following conditions are true, allowBtSplit is set equal to FALSE: - btSplit is equal to SPLIT_BT_VER. - cbHeight is greater than 64. - x0+cbWidth is greater than pic_width_in_luma_samples. ...

[0100]

[0121] The variables allowSplitTtHor and allowSplitTtVer are set to false due to the following conditions (highlighted in italics): 6.4.3 Allowed Three-Part Process ... allowTtSplit is set equal to FALSE if one or more of the following conditions are true: - cbSize is less than or equal to 2*MinTtSizeY. - cbWidth is greater than Min(64,maxTtSize). - cbHeight is greater than Min(64,maxTtSize). - mttDepth is greater than or equal to maxMttDepth. - x0+cbWidth is greater than pic_width_in_luma_samples. - y0+cbHeight is greater than pic_height_in_luma_samples. ...

[0101]

[0122] When all these variables are set to false, no split flag may be signaled at the CU level: the syntax element split_cu_flag is inferred to be 1, the syntax element split_qt_flag is inferred to be 0, the syntax element mtt_split_cu_vertical_flag is inferred to be 1, and the syntax element mtt_split_cu_binary_flag is inferred to be 0. In this case, the block may be split using SPLIT_TT_VER, which may violate the VPDU constraints.

[0102]

[0123] As a second exemplary case where all tree partitioning modes are disallowed, all tree partitioning is disallowed for blocks that are located on a picture boundary and contain samples that cross the picture boundary. When the minimum QT size is greater than the minimum CU size (syntax element log2_min_luma_coding_block_size_minus2 in the previous table) and the maximum BT / TT depth (syntax elements sps_max_mtt_hierarchy_depth_inter_slice, sps_max_mtt_hierarchy_depth_intra_slice_luma, sps_max_mtt_hierarchy_depth_intra_slice_chroma, pic_max_mtt_hierarchy_depth_inter_slice, pic_max_mtt_hierarchy_depth_intra_slice_luma, and pic_max_mtt_hierarchy_depth_intra_slice_chroma in the previous table) is equal to 0, the variables allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are all set to false.

[0103]

[0124] 18 illustrates an example block where neither QT, BT, nor BT splitting is allowed at a picture boundary, according to some embodiments of the present disclosure. A CTU (e.g., CTU1801, CTU1803, or CTU1805) is first split using a quadtree into four 64x64 blocks. Each of the 64x64 blocks cannot then be further split. However, portions of the grayed-out block extend beyond the right and / or bottom picture boundaries, which is not allowed in the VVC design. For the grayed-out block, the variable allowSplitQt is set to false due to the following condition (highlighted in italics): 6.4.1 Allowed Quadrant Processes ... - allowSplitQt is set equal to FALSE if one or more of the following conditions are true: - treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA and cbSize is less than or equal to MinQtSizeY. - treeType is equal to DUAL_TREE_CHROMA and cbSize / SubWidthC is less than or equal to MinQtSizeC. ...

[0104]

[0125] For the blocks shown in grey, the variables allowSplitBtHor and allowSplitBtVer are set to false due to the following conditions (highlighted in italics): 6.4.2 Allowed Bisection Processes ...

[0105]

[0126] The variable allowBtSplit is derived as follows: allowBtSplit is set equal to FALSE if one or more of the following conditions are true: - cbSize is less than or equal to MinBtSizeY. - cbWidth is greater than maxBtSize. - cbHeight is greater than maxBtSize. - mttDepth is greater than or equal to maxMttDepth. ...

[0106]

[0127] For the blocks shown in grey, the variables allowSplitTtHor and allowSplitTtVer are set to false due to the following conditions (highlighted in italics): 6.4.3 Allowed Three-Part Process ...

[0107]

[0128] The variable allowTtSplit is derived as follows: allowTtSplit is set equal to FALSE if one or more of the following conditions are true: - cbSize is less than or equal to 2*MinTtSizeY. - cbWidth is greater than Min(64,maxTtSize). - cbHeight is greater than Min(64,maxTtSize). - mttDepth is greater than or equal to maxMttDepth. ...

[0108]

[0129] As illustrated in the first exemplary case where all tree partitioning modes are not allowed, in the current VVC Draft 7, a CU may contain samples outside the picture boundary, but the CU cannot be further divided under some conditions. In some embodiments of the present disclosure, the QT partitioning conditions in VVC may be changed. In some aspects, for a block that contains samples outside the picture boundary and whose width or height is equal to N (e.g., N=128), QT partitioning is used when the minimum QT size is less than N (e.g., 128). In addition, in some embodiments, QT partitioning may be used even when the minimum QT size is equal to N (e.g., 128). In other aspects, using QT partitioning may be simpler than using BT or TT partitioning. FIG. 19 is a schematic diagram illustrating an example of using BT and TT partitioning according to some embodiments of the present disclosure. Multiple steps may be required to partition a block. Furthermore, the partitioning may be different for blocks located at different positions, which may lead to complications. For example, for block 1903, SPLIT_BT_HOR, SPLIT_BT_HOR, SPLIT_TT_VER, SPLIT_TT_VER, and SPLIT_TT_VER are executed in sequence.

[0109]

[0130] In some embodiments, when none of the block partitions are allowed, quadtree partitioning may be used and the syntax element split_qt_flag may be inferred to be 1. The syntax element split_qt_flag specifies whether the coding unit is split into coding units with half the horizontal and vertical size.

[0110]

[0131] When the syntax element split_qt_flag is not present, the following applies (emphasis in italics): - split_qt_flag is inferred to be equal to 1 if all of the following conditions are true: - split_cu_flag is equal to 1. - allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are equal to FALSE. - Otherwise, if allowSplitQt is equal to TRUE, the value of split_qt_flag is inferred to be equal to 1. - Otherwise, the value of split_qt_flag is inferred to be equal to 0.

[0111]

[0132] In some embodiments, the minimum QT size constraint cannot be applied to blocks located on picture boundaries. When part of a block exceeds the bottom or right picture boundary, the block may be split using a quadtree. The allowed quadtree splitting process is described as follows: 6.4.1 Allowed Quadrant Processes The inputs to this process are: - coding block size in luma samples, cbSize - Multitype tree depth mttDepth - variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the coding tree nodes, and whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently processed when a dual tree is used; - a variable modeType that specifies whether intra coding modes (MODE_INTRA), IBC coding modes (MODE_IBC), and inter coding modes can be used (MODE_TYPE_ALL), or only intra coding modes and IBC coding modes (MODE_TYPE_INTRA), or only inter coding modes (MODE_TYPE_INTER) for coding units inside a coding tree node; The output of this process is the variable allowSplitQt.

[0112]

[0133] The variable allowSplitQt is derived as follows (emphasis in italics): - allowSplitQt is set equal to TRUE if all of the following conditions are true: - treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA. - cbSize equals 128. - MinQtSizeY equals 128. - x0+cbWidth is greater than pic_width_in_luma_samples or y0+cbHeight is greater than pic_height_in_luma_samples. - Otherwise, if all of the following conditions are true, allowSplitQt is set equal to TRUE: - treeType is equal to DUAL_TREE_CHROMA. - CbSize / SubWidthC equals 128. - MinQtSizeC equals 128. - x0+cbWidth is greater than pic_width_in_luma_samples or y0+cbHeight is greater than pic_height_in_luma_samples. - Otherwise, if one or more of the following conditions are true, allowSplitQt is set equal to FALSE: - treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA and cbSize is less than or equal to MinQtSizeY. - treeType is equal to DUAL_TREE_CHROMA and cbSize / SubWidthC is less than or equal to MinQtSizeC. - mttDepth is not equal to 0. - treeType is equal to DUAL_TREE_CHROMA and (cbSize / SubWidthC) is less than or equal to 4. - treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA. - Otherwise, allowSplitQt is set equal to TRUE.

[0113]

[0134] In some embodiments, bitstream conformance may be added to the minimum QT size syntax, which may require that the minimum QT size must be 64 or less.

[0114]

[0135] The syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma specifies the default difference between the base-2 logarithm of the minimum size of luma samples in luma residual blocks resulting from the quadtree partitioning of a CTU and the base-2 logarithm of the minimum coded block size in luma samples for luma CUs of a slice having a slice_type equal to 2(I) that references the SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default difference may be overridden by the syntax element pic_log2_diff_min_qt_min_cb_luma present in the PH that references the SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma is in the range from 0 to CtbLog2SizeY - MinCbLog2SizeY, inclusive. The base-2 logarithm of the minimum size of luma samples in luma residual blocks resulting from the quadtree partitioning of a CTU is derived as follows (emphasized in italics). MinQtLog2SizeIntraY = sps_log2_diff_min_qt_min_cb_intra_slice_luma + MinCbLog2SizeY VSize = Min(64, CtbSizeY)

[0115]

[0136] In some embodiments, it may be a bitstream compliance requirement that the value of (1 << MinQtLog2SizeIntraY) is less than or equal to VSize.

[0116]

[0137] The syntax element sps_log2_diff_min_qt_min_cb_inter_slice specifies the default difference between the base-2 logarithm of the minimum size in luma samples of the luma leaf blocks resulting from the quadtree partitioning of a CTU, and the base-2 logarithm of the minimum luma coded block size in luma samples of a slice having a slice_type equal to 0 (B) or 1 (P) that refers to the SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default difference may be overridden by the syntax element pic_log2_diff_min_qt_min_cb_luma present in PH that refers to the SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_inter_slice is in the range from 0 to CtbLog2SizeY - MinCbLog2SizeY (including both ends). The base-2 logarithm of the minimum size in luma samples of the luma leaf blocks resulting from the quadtree partitioning of a CTU is derived as follows (emphasized in italics). MinQtLog2SizeInterY = sps_log2_diff_min_qt_min_cb_inter_slice + MinCbLog2SizeY VSize = Min(64, CtbSizeY)

[0117]

[0138] In some embodiments, it may be a bitstream compliance requirement that the value of (1 << MinQtLog2SizeInterY) is less than or equal to VSize.

[0118]

[0139] The syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma specifies the default difference between the logarithm to the base 2 of the minimum size of the luma samples in the chroma leaf blocks resulting from the quadtree partitioning of a chroma CTU having a treeType equal to DUAL_TREE_CHROMA, and the logarithm to the base 2 of the minimum coded block size of the luma samples for a chroma CU having a treeType equal to DUAL_TREE_CHROMA in a slice having a slice_type equal to 2(I) that references the SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default difference may be overridden by the syntax element pic_log2_diff_min_qt_min_cb_chroma present in the PH that references the SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma is in the range from 0 to CtbLog2SizeY - MinCbLog2SizeY (including both ends). If not present, the value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma is assumed to be equal to 0. The logarithm to the base 2 of the minimum size of the luma samples in the chroma leaf blocks resulting from the quadtree partitioning of a CTU having a treeType equal to DUAL_TREE_CHROMA is derived as follows (emphasized in italics). MinQtLog2SizeIntraC = sps_log2_diff_min_qt_min_cb_intra_slice_chroma + MinCbLog2SizeY VSize = Min(64, CtbSizeY)

[0119]

[0140] According to some embodiments, it may be a bitstream compliance requirement that the value of (1 << MinQtLog2SizeIntraC) is less than or equal to VSize.

[0120]

[0141] The syntax element pic_log2_diff_min_qt_min_cb_intra_slice_luma specifies the difference between the base 2 logarithm of the minimum size in luma samples of a luma ref block resulting from the quadtree decomposition of a CTU and the base 2 logarithm of the minimum coded block size in luma samples for a luma CU of a slice with slice_type equal to 2(I) associated with a PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_luma lies in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is inferred to be equal to the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma. In some embodiments, a requirement for bitstream conformance may be that the value of (1<<(pic_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY)) is less than or equal to Min(64,CtbSizeY).

[0121]

[0142] The syntax element pic_log2_diff_min_qt_min_cb_inter_slice specifies the difference between the base 2 logarithm of the minimum size in luma samples of a luma ref block resulting from the quadtree decomposition of a CTU and the base 2 logarithm of the minimum luma coding block size in luma samples for a luma CU of a slice with slice_type equal to 0 (B) or 1 (P) associated with a PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_inter_slice lies in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is inferred to be equal to the syntax element sps_log2_diff_min_qt_min_cb_inter_slice. In some embodiments, it may be a requirement for bitstream conformance that the value of (1<<(pic_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY)) be less than or equal to Min(64,CtbSizeY).

[0122]

[0143] The syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma specifies the difference between the base 2 logarithm of the minimum size in luma samples of a chroma leaf block resulting from quadtree decomposition of a chroma CTU with treeType equal to DUAL_TREE_CHROMA and the base 2 logarithm of the minimum coded block size in luma samples for a chroma CU with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) associated with a PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma is in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma is inferred to be equal to the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma. In some embodiments, it may be a requirement for bitstream conformance that the value of (1<<(pic_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY)) be less than or equal to Min(64,CtbSizeY).

[0123]

[0144] In some embodiments, in the second exemplary case above where all tree splitting modes are not allowed, when none of the block partitioning modes are allowed, quadtree splitting may be used and the syntax element split_qt_flag may be inferred to be 1.

[0124]

[0145] The syntax element split_qt_flag specifies whether a coding unit is split into coding units with half the horizontal and vertical size. When the syntax element split_qt_flag is not present, the following applies (emphasis in italics): - split_qt_flag is inferred to be equal to 1 if all of the following conditions are true: - split_cu_flag is equal to 1. - allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are equal to FALSE. - Otherwise, if allowSplitQt is equal to TRUE, the value of split_qt_flag is inferred to be equal to 1. - Otherwise, the value of split_qt_flag is inferred to be equal to 0.

[0125]

[0146] In some embodiments, in the second exemplary case above where all tree splitting modes are not allowed, bitstream conformance may be added to the syntax of minimum QT size and maximum BT / TT depth.

[0126]

[0147] The syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma specifies the default difference between the base 2 logarithm of the minimum size in luma samples of a luma ref block resulting from the quadtree decomposition of a CTU and the base 2 logarithm of the minimum coded block size in luma samples for a luma CU of a slice with slice_type equal to 2(I) that references an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default difference can be overridden by the syntax element pic_log2_diff_min_qt_min_cb_luma that is present in a PH that references an SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma is in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY (inclusive). The base 2 logarithm of the minimum size in luma samples of a luma reh block resulting from the quadtree decomposition of a CTU is derived as follows (emphasis in italics): MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY

[0127]

[0148] The syntax element sps_max_mtt_hierarchy_depth_intra_slice_luma specifies the default maximum hierarchy depth for coding units resulting from a multi-type tree partition of a quadtree leaf in a slice with slice_type equal to 2(I) that references an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default maximum hierarchy depth can be overridden by the syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma that is present in a PH that references an SPS. The value of the syntax element sps_max_mtt_hierarchy_depth_intra_slice_luma is in the range from 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY), inclusive. In some embodiments, a requirement for bitstream conformance may be that the value of (MinQtLog2SizeIntraY-sps_max_mtt_hierachy_depth_intra_slice_luma / 2) is less than or equal to MinCbLog2SizeY.

[0128]

[0149] The syntax element sps_log2_diff_min_qt_min_cb_inter_slice specifies the default difference between the base 2 logarithm of the minimum size in luma samples of a luma reef block resulting from a quadtree partitioning of a CTU and the base 2 logarithm of the minimum luma coding block size in luma samples for a luma CU of a slice with slice_type equal to 0 (B) or 1 (P) that references an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default difference can be overridden by the syntax element pic_log2_diff_min_qt_min_cb_luma that is present in a PH that references an SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_inter_slice is in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY (inclusive). The base 2 logarithm of the minimum size in luma samples of a luma reef block resulting from a quadtree partitioning of a CTU is derived as follows: MinQtLog2SizeInterY=sps_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY

[0129]

[0150] The syntax element sps_max_mtt_hierarchy_depth_inter_slice specifies the default maximum hierarchy depth for coding units resulting from a multi-type tree partition of a quadtree leaf in a slice with slice_type equal to 0 (B) or 1 (P) that references an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default maximum hierarchy depth can be overridden by the syntax element pic_max_mtt_hierarchy_depth_inter_slice that is present in a PH that references an SPS. The value of the syntax element sps_max_mtt_hierarchy_depth_inter_slice is in the range from 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY), inclusive. In some embodiments, it may be a bitstream conformance requirement that the value of (MinCbLog2SizeInterY - sps_max_mtt_hierarchy_depth_inter_slice / 2) be less than or equal to MinCbLog2SizeY.

[0130]

[0151] The syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma specifies the default difference between the base 2 logarithm of the minimum size in luma samples of a chroma leaf block resulting from quadtree partitioning of a chroma CTU with treeType equal to DUAL_TREE_CHROMA and the base 2 logarithm of the minimum coded block size in luma samples for a chroma CU with treeType equal to DUAL_TREE_CHROMA of a slice with slice_type equal to 2(I) that references an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default difference can be overridden by the syntax element pic_log2_diff_min_qt_min_cb_chroma that is present in a PH that references an SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma is in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma is inferred to be equal to 0. The base 2 logarithm of the minimum size in luma samples of a luma reh block resulting from a quadtree decomposition of a CTU with treeType equal to DUAL_TREE_CHROMA is derived as follows: MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY

[0131]

[0152] The syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma specifies the default maximum hierarchy depth for a chroma coding unit resulting from a multi-type tree partition of a chroma quadtree leaf with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) that references an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default maximum hierarchy depth can be overridden by the syntax element pic_max_mtt_hierarchy_depth_chroma, which is present in a PH that references an SPS. The value of the syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma is in the range from 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY), inclusive. If not present, the value of the syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma is inferred to be equal to 0. In some embodiments, a requirement for bitstream conformance may be that the value of (MinQtLog2SizeIntraC-sps_max_mtt_hierachy_depth_intra_slice_chroma / 2) is less than or equal to MinCbLog2SizeY.

[0132]

[0153] The syntax element pic_log2_diff_min_qt_min_cb_intra_slice_luma specifies the difference between the base 2 logarithm of the minimum size in luma samples of a luma ref block resulting from the quadtree decomposition of a CTU and the base 2 logarithm of the minimum coded block size in luma samples for a luma CU in a slice with slice_type equal to 2(I) associated with a PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_luma is in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is inferred to be equal to the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma.

[0133]

[0154] The syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma specifies the maximum hierarchical depth for coding units resulting from a multi-type tree split of a quadtree leaf in a slice with slice_type equal to 2(I) associated with PH. The value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma lies in the range from 0 to 2 * (CtbLog2SizeY - MinCbLog2SizeY), inclusive. If not present, the value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma is inferred to be equal to the syntax element sps_max_mtt_hierarchy_depth_intra_slice_luma. In some embodiments, a requirement for bitstream conformance may be that the value of (pic_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY-pic_max_mtt_hierarchy_depth_intra_slice_luma / 2) is less than or equal to MinCbLog2SizeY.

[0134]

[0155] The syntax element pic_log2_diff_min_qt_min_cb_inter_slice specifies the difference between the base 2 logarithm of the minimum size in luma samples of a luma ref block resulting from the quadtree decomposition of a CTU and the base 2 logarithm of the minimum luma coding block size in luma samples for a luma CU of a slice with slice_type equal to 0 (B) or 1 (P) associated with a PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_inter_slice lies in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is inferred to be equal to the syntax element sps_log2_diff_min_qt_min_cb_inter_slice.

[0135]

[0156] The syntax element pic_max_mtt_hierarchy_depth_inter_slice specifies the maximum hierarchy depth for coding units resulting from a multi-type tree split of a quadtree leaf in a slice with slice_type equal to 0 (B) or 1 (P) associated with PH. The value of the syntax element pic_max_mtt_hierarchy_depth_inter_slice lies in the range from 0 to 2 * (CtbLog2SizeY - MinCbLog2SizeY), inclusive. If not present, the value of the syntax element pic_max_mtt_hierarchy_depth_inter_slice is inferred to be equal to the syntax element sps_max_mtt_hierarchy_depth_inter_slice. In some embodiments, a bitstream conformance requirement may be that the value of (pic_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY-pic_max_mtt_hierarchy_depth_inter_slice / 2) is less than or equal to MinCbLog2SizeY.

[0136]

[0157] The syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma specifies the difference between the base 2 logarithm of the minimum size in luma samples of a chroma leaf block resulting from quadtree decomposition of a chroma CTU with treeType equal to DUAL_TREE_CHROMA and the base 2 logarithm of the minimum coded block size in luma samples for a chroma CU with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) associated with a PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma is in the range from 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. If not present, the value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma is inferred to be equal to the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma.

[0137]

[0158] The syntax element pic_max_mtt_hierarchy_depth_intra_slice_chroma specifies the maximum hierarchy depth for a chroma coding unit resulting from a multi-type tree split of a chroma quadtree leaf with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) associated with a PH. The value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_chroma lies in the range from 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY), inclusive. If not present, the value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_chroma is inferred to be equal to the syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma. In some embodiments, a requirement for bitstream conformance may be that the value of (pic_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY-pic_max_mtt_hierarchy_depth_intra_slice_chroma / 2) is less than or equal to MinCbLog2SizeY.

[0138]

[0159] 20 shows a flowchart of an exemplary video processing method 2000 according to some embodiments of the present disclosure. Method 2000 may be performed by an encoder (e.g., by process 200A of FIG. 2A or process 200B of FIG. 2B), a decoder (e.g., by process 300A of FIG. 3A or process 300B of FIG. 3B), or one or more software or hardware components of an apparatus (e.g., apparatus 400 of FIG. 4). For example, a processor (e.g., processor 402 of FIG. 4) may perform method 2000. In some embodiments, method 2000 may be implemented by a computer program product embodied in a computer-readable medium including computer-executable instructions, such as program code, for execution by a computer (e.g., apparatus 400 of FIG. 4).

[0139]

[0160] In step 2001, a determination may be made as to whether a coding block contains samples outside a picture boundary. In some embodiments, the picture boundary may be a bottom picture boundary or a right picture boundary. As an example of a coding block that contains samples outside a picture boundary, refer to Figure 17, where coding block 1701 exceeds the right picture boundary of picture 1700, coding block 1705 exceeds the bottom picture boundary of picture 1700, and coding block 1703 exceeds both the bottom and right picture boundaries of picture 1700.

[0140]

[0161] In step 2003, in response to determining that the coding block contains samples outside the picture boundary, the coding block may be split using QT mode. In some embodiments, in response to determining that the coding block contains samples outside the picture boundary, method 2000 may determine that BT mode and TT mode are not allowed to be used to split the coding block. For example, the variables allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer may be determined to be equal to FALSE.

[0141]

[0162] In some embodiments, in response to determining that a coding block contains samples outside a picture boundary, method 2000 may determine that the coding block should be split using QT mode, regardless of whether a QT flag is present in a bitstream containing the coding block. The QT flag indicates whether the coding block should be split using QT mode. For example, when the syntax element split_qt_flag is not present, the value of split_qt_flag may be inferred to be equal to 1 if the coding block contains samples outside a picture boundary and the variables allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are equal to FALSE or allowSplitQt is equal to TRUE.

[0142]

[0163] In some embodiments, in response to determining that a coding block contains samples outside a picture boundary, method 2000 may determine that QT mode is permitted to be used to split the coding block, regardless of a preset constraint on the minimum block size to which QT mode is permitted to apply. For example, a minimum QT size constraint cannot be applied to coding blocks located on a picture boundary.

[0143]

[0164] In some embodiments, the preset constraints may include bitstream compatibility for the coding blocks. The bitstream compatibility may set the minimum block size for which QT mode is allowed to be applied. For example, the minimum block size may be set to be less than or equal to 64. The bitstream compatibility may also set the maximum BT depth or maximum TT depth.

[0144]

[0165] In some embodiments, the method 2000 may include determining that the coding block should be split. For example, the syntax element split_cu_flag may be used to indicate whether the coding block should be split. When the syntax element split_cu_flag is not present, it may be inferred to be equal to 1, indicating that the coding block should be split.

[0145]

[0166] It should be understood that embodiments of the present disclosure may be combined with one another or with some other embodiments.

[0146]

[0167] The embodiments can be further described using the following clauses. 1. A video processing method comprising: determining whether the coding block contains samples outside a picture boundary; In response to determining that the coding block includes samples outside a picture boundary, performing a quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether a quadtree is allowed to be used to partition the coding block; A method comprising: 2. Determining a value of a first flag of the coding block, the first flag indicating whether the coding block is divided into a plurality of sub-blocks; determining values of a second parameter, a third parameter, a fourth parameter, and a fifth parameter of the coding block, the second parameter, the third parameter, the fourth parameter, and the fifth parameter respectively indicating whether a horizontal binary tree, a vertical binary tree, a horizontal ternary tree, and a vertical ternary tree are allowed to be used to partition the coding block; 2. The method of clause 1, further comprising: 3. The method of clause 2, further comprising: setting the value of a second flag of the coding block to 1 in response to the value of the first flag being equal to 1 and the values of the first parameter, the second parameter, the third parameter, the fourth parameter, and the fifth parameter being equal to 0, wherein the second flag indicates whether the coding block is split using a quadtree. 4. The method of clause 2, further comprising setting the value of a second flag of the coding block to 1 in response to the value of the first parameter being equal to 1, the second flag indicating whether the coding block is split using a quadtree. 5. The method of any one of clauses 2 to 4, further comprising setting the value of the first flag to be 1 when it is determined that the coding block contains a sample outside the picture boundary. 6. A video processing device, at least one memory for storing instructions; and at least one processor, the at least one processor comprising: determining whether the coding block contains samples outside a picture boundary; and In response to determining that the coding block includes samples outside a picture boundary, performing a quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether a quadtree is allowed to be used to partition the coding block; 10. An apparatus configured to execute instructions to cause the apparatus to perform: 7. At least one processor: determining a value of a first flag of the coding block, the first flag indicating whether the coding block is divided into a plurality of sub-blocks; determining values of a second parameter, a third parameter, a fourth parameter, and a fifth parameter of the coding block, the second parameter, the third parameter, the fourth parameter, and the fifth parameter respectively indicating whether a horizontal binary tree, a vertical binary tree, a horizontal ternary tree, and a vertical ternary tree are allowed to be used to partition the coding block; 9. The apparatus of clause 6, configured to execute instructions to cause the apparatus to perform the 8. At least one processor: setting a value of a second flag of the coding block to 1 in response to the value of the first flag being equal to 1 and the values of the first parameter, the second parameter, the third parameter, the fourth parameter, and the fifth parameter being equal to 0, wherein the second flag indicates whether the coding block is split using a quadtree. 8. An apparatus as described in clause 7, configured to execute instructions to cause the apparatus to perform 9. At least one processor: setting a value of a second flag of the coding block to 1 in response to the value of the first parameter being equal to 1, the second flag indicating whether the coding block is partitioned using a quadtree; 8. An apparatus as described in clause 7, configured to execute instructions to cause the apparatus to perform 10. At least one processor: setting a value of a first flag to be 1 when it is determined that the coding block contains a sample outside a picture boundary; 10. An apparatus according to any one of clauses 7 to 9, configured to execute instructions to cause the apparatus to perform the 11. A non-transitory computer-readable storage medium storing a set of instructions, the set of instructions comprising: determining whether the coding block contains samples outside a picture boundary; In response to determining that the coding block includes samples outside a picture boundary, performing a quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether a quadtree is allowed to be used to partition the coding block; A non-transitory computer-readable storage medium executable by one or more processing devices to cause a video processing device to perform the method. 12. A set of instructions is determining a value of a first flag of the coding block, the first flag indicating whether the coding block is divided into a plurality of sub-blocks; determining values of a second parameter, a third parameter, a fourth parameter, and a fifth parameter of the coding block, the second parameter, the third parameter, the fourth parameter, and the fifth parameter indicating whether a horizontal binary tree, a vertical binary tree, a horizontal ternary tree, and a vertical ternary tree are allowed to be used to partition the coding block, respectively; 12. The non-transitory computer-readable storage medium of claim 11, executable by one or more processing devices to cause a video processing device to perform the steps of: 13. A set of instructions is setting a value of a second flag of the coding block to 1 in response to the value of the first flag being equal to 1 and the values of the first parameter, the second parameter, the third parameter, the fourth parameter, and the fifth parameter being equal to 0, wherein the second flag indicates whether the coding block is split using a quadtree. 13. The non-transitory computer-readable storage medium of claim 12, executable by one or more processing devices to cause a video processing device to perform the steps of: 14. A set of instructions is setting a value of a second flag of the coding block to 1 in response to the value of the first parameter being equal to 1, the second flag indicating whether the coding block is partitioned using a quadtree; 13. The non-transitory computer-readable storage medium of claim 12, executable by one or more processing devices to cause a video processing device to perform the steps of: 15. In response to determining that the coding block contains samples outside a picture boundary, splitting the coding block using QT mode 15. The non-transitory computer-readable storage medium of any one of clauses 12 to 14, further comprising setting a value of a first flag to be 1 when it is determined that the coding block contains a sample outside a picture boundary. 16. A video processing method comprising: determining whether the coding block contains samples outside a picture boundary; In response to determining that the coding block includes samples outside a picture boundary, splitting the coding block using a quadtree (QT) mode. 17. 17. The method of claim 16, further comprising: determining, in response to determining that the coding block contains samples outside a picture boundary, that binary tree (BT) mode and ternary tree (TT) mode are not allowed to be used to split the coding block. 18. In response to determining that the coding block contains samples outside a picture boundary, splitting the coding block using a quadtree (QT) mode; 18. The method of any one of clauses 16 and 17, comprising splitting the coding block using QT mode regardless of whether a QT flag is present in a bitstream containing the coding block, wherein the QT flag indicates whether the coding block should be split using QT mode. 19. In response to determining that the coding block contains samples outside a picture boundary, splitting the coding block using a quadtree (QT) mode; 17. The method of clause 16, comprising splitting the coding blocks using QT mode regardless of a preset constraint on the minimum block size for which application of QT mode is allowed. 20. The method of clause 19, wherein the preset constraints include a bitstream conformance associated with the coding block, the bitstream conformance setting a minimum block size for which application of QT mode is permitted. 21. The method of clause 20, wherein the minimum block size is set to be less than or equal to 64. 22. The method of any one of clauses 20 and 21, wherein bitstream conformance sets a maximum BT depth or a maximum TT depth. 23. The method of any one of clauses 16 to 22, wherein the picture boundary is a bottom picture boundary or a right picture boundary. 24. A video processing device, at least one memory for storing instructions; and at least one processor, the at least one processor comprising: determining whether the coding block contains samples outside a picture boundary; In response to determining that the coding block includes samples outside a picture boundary, splitting the coding block using a quadtree (QT) mode; 10. An apparatus configured to execute instructions to cause the apparatus to perform: 25. At least one processor: determining, in response to determining that the coding block includes samples outside a picture boundary, that binary tree (BT) mode and ternary tree (TT) mode are not permitted to be used to split the coding block; 25. An apparatus as described in clause 24, configured to execute instructions to cause the apparatus to perform 26. At least one processor: Splitting a coding block using QT mode, regardless of whether a QT flag is present in a bitstream containing the coding block, the QT flag indicating whether the coding block is split using QT mode. 26. An apparatus according to any one of clauses 24 and 25, configured to execute instructions to cause the apparatus to perform 27. At least one processor: Splitting coding blocks using QT mode, regardless of the preset constraint on the minimum block size for which QT mode is allowed to be applied. 25. An apparatus as described in clause 24, configured to execute instructions to cause the apparatus to perform 28. The apparatus of clause 27, wherein the preset constraints include a bitstream conformance associated with the coding block, the bitstream conformance setting a minimum block size for which application of QT mode is permitted. 29. The apparatus of clause 28, wherein the minimum block size is set to be 64 or less. 30. The apparatus of any one of clauses 28 and 29, wherein bitstream compatibility sets a maximum BT depth or a maximum TT depth. 31. The apparatus of any one of clauses 24 to 30, wherein the picture boundary is a bottom picture boundary or a right picture boundary. 32. A non-transitory computer-readable storage medium storing a set of instructions, the set of instructions comprising: determining whether the coding block contains samples outside a picture boundary; In response to determining that the coding block includes samples outside a picture boundary, splitting the coding block using a quadtree (QT) mode; A non-transitory computer-readable storage medium executable by one or more processing devices to cause a video processing device to perform the method. 33. A set of instructions is determining, in response to determining that the coding block includes samples outside a picture boundary, that binary tree (BT) mode and ternary tree (TT) mode are not permitted to be used to split the coding block; 33. The non-transitory computer-readable storage medium of claim 32, executable by one or more processing devices to cause a video processing device to perform the steps of: 34. A set of instructions is Splitting a coding block using QT mode, regardless of whether a QT flag is present in a bitstream containing the coding block, the QT flag indicating whether the coding block should be split using QT mode. 34. A non-transitory computer-readable storage medium according to any one of clauses 32 and 33, executable by one or more processing devices to cause a video processing device to perform the steps of: 35. A set of instructions is Splitting coding blocks using QT mode, regardless of the preset constraint on the minimum block size for which QT mode is allowed to be applied. 33. The non-transitory computer-readable storage medium of claim 32, executable by one or more processing devices to cause a video processing device to perform the steps of: 36. The non-transitory computer-readable storage medium of clause 35, wherein the preset constraints include a bitstream conformance associated with the coding block, the bitstream conformance setting a minimum block size for which application of QT mode is permitted. 37. The non-transitory computer-readable storage medium of clause 36, wherein the minimum block size is set to be 64 or less. 38. The non-transitory computer-readable storage medium of any one of clauses 36 and 37, wherein bitstream conformance sets a maximum BT depth or a maximum TT depth. 39. The non-transitory computer-readable storage medium of any one of clauses 32 to 38, wherein the picture boundary is a bottom picture boundary or a right picture boundary.

[0147]

[0168] Some embodiments also provide a non-transitory computer-readable storage medium containing instructions that can be executed by a device (such as the encoders and decoders of the present disclosure) to perform the methods described above. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, a hard disk, a solid-state drive, a magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM, and EPROM, FLASH-EPROM or any other flash memory, NVRAM, cache, registers, any other memory chip or cartridge, and networked versions thereof. A device may include one or more processors (CPUs), input / output interfaces, a network interface, and / or memory.

[0148]

[0169] It should be noted that relational terms herein, such as "first" and "second," are used merely to distinguish one entity or operation from another, and do not require or imply any actual relationship or order among those entities or operations. Furthermore, the words "comprising," "having," "containing," and "including," and other similar forms, are intended to be equivalent in meaning and to be open-ended in that the element or elements following any of these words are not meant to be an exclusive list of such elements or elements, or to be limited to only the listed element or elements.

[0149]

[0170] As used herein, unless specifically stated otherwise, the term "or" includes all possible combinations unless impracticable. For example, if it is stated that a database may include A or B, then, unless specifically stated otherwise or impracticable, the database may include A, or B, or A and B. As a second example, if it is stated that a database may include A, B, or C, then, unless specifically stated otherwise or impracticable, the database may include A, B, or C, or A and B, A and C, or B and C, or A, B, and C.

[0150]

[0171] It is understood that the above-described embodiments can be implemented by hardware, or software (program code), or a combination of hardware and software. If implemented by software, it can be stored in the above-described computer-readable medium. The software, when executed by a processor, can perform the methods of the present disclosure. The computational units and other functional units described in the present disclosure can be implemented by hardware, or software, or a combination of hardware and software. Those skilled in the art will also understand that multiple of the above-described modules / units can be combined into one module / unit, or that each of the above-described modules / units can be further divided into multiple sub-modules / sub-units.

[0151]

[0172] In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Certain adaptations and modifications of the above-described embodiments may be made. Other embodiments may be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as examples only, with the true scope and spirit of the invention being indicated by the appended claims. It is also intended that the sequences of steps depicted in the figures are for illustrative purposes only and are not intended to be limited to any particular sequence of steps. Thus, one skilled in the art will recognize that these steps may be performed in different orders while implementing the same method.

[0152]

[0173] In the drawings and specification, illustrative embodiments have been disclosed. However, many variations and modifications to these embodiments may be made. Accordingly, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. 1. A video processing method, comprising: determining whether the coding block contains samples outside a picture boundary; in response to determining that the coding block contains samples outside a picture boundary, performing a quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether using the quadtree to partition the coding block is permitted; A method comprising:

2. determining a value of a first flag for the coding block, the first flag indicating whether the coding block is divided into a plurality of sub-blocks; determining values of a second parameter, a third parameter, a fourth parameter, and a fifth parameter of the coding block, the second parameter, the third parameter, the fourth parameter, and the fifth parameter respectively indicating whether a horizontal binary tree, a vertical binary tree, a horizontal ternary tree, and a vertical ternary tree are allowed to be used to partition the coding block; The method of claim 1 further comprising:

3. 3. The method of claim 2, further comprising: setting a value of a second flag of the coding block to 1 in response to the value of the first flag being equal to 1 and the values of the first parameter, the second parameter, the third parameter, the fourth parameter, and the fifth parameter being equal to 0, wherein the second flag indicates whether the coding block is split using the quadtree.

4. 3. The method of claim 2, further comprising: setting a value of a second flag for the coding block to 1 in response to the value of the first parameter being equal to 1, the second flag indicating whether the coding block is split using the quadtree.

5. The method of claim 2 , further comprising: setting the value of the first flag to be 1 when it is determined that the coding block contains samples outside a picture boundary.

6. the size of the coding block; and Multitype tree depth, a second parameter indicating whether a single tree or a dual tree is used to split the coding block; a third parameter indicating whether one or more of an intra mode, an inter mode, and an IBC mode are allowed to code the coding block; and The method of claim 1 , further comprising determining the value of the first parameter based on one or more of:

7. performing a quadtree partitioning of the coding block regardless of a value of a first parameter in response to determining that the coding block includes samples outside a picture boundary; The method of claim 1 , comprising performing quadtree partitioning of the coding blocks regardless of bitstream compatibility associated with the coding blocks.

8. The method of claim 7 , wherein the bitstream conformance sets a minimum block size to which the quadtree partitioning is allowed to be applied.

9. The method of claim 8 , wherein the minimum block size is set to be 64 or less.

10. The method of claim 7 , wherein the bitstream conformance sets a maximum binary tree depth or a maximum ternary tree depth.

11. A video processing device, at least one memory for storing instructions; at least one processor, wherein the at least one processor determining whether the coding block contains samples outside a picture boundary; in response to determining that the coding block includes samples outside a picture boundary, performing a quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether the quadtree is allowed to be used to partition the coding block; an apparatus configured to execute the instructions to cause the apparatus to perform

12. the at least one processor: determining a value of a first flag for the coding block, the first flag indicating whether the coding block is divided into a plurality of sub-blocks; determining values of a second parameter, a third parameter, a fourth parameter, and a fifth parameter of the coding block, the second parameter, the third parameter, the fourth parameter, and the fifth parameter respectively indicating whether a horizontal binary tree, a vertical binary tree, a horizontal ternary tree, and a vertical ternary tree are allowed to be used to partition the coding block; 12. The apparatus of claim 11, configured to execute the instructions to cause the apparatus to perform:

13. the at least one processor: setting a value of a second flag of the coding block to 1 in response to the value of the first flag being equal to 1 and the values of the first parameter, the second parameter, the third parameter, the fourth parameter, and the fifth parameter being equal to 0, wherein the second flag indicates whether the coding block is split using the quadtree.

13. The apparatus of claim 12, configured to execute the instructions to cause the apparatus to perform:

14. the at least one processor: setting a value of a second flag of the coding block to 1 in response to the value of the first parameter being equal to 1, the second flag indicating whether the coding block is split using the quadtree.

13. The apparatus of claim 12, configured to execute the instructions to cause the apparatus to perform:

15. the at least one processor: setting the value of the first flag to be 1 when it is determined that the coding block contains a sample outside a picture boundary.

13. The apparatus of claim 12, configured to execute the instructions to cause the apparatus to perform:

16. 1. A non-transitory computer-readable storage medium storing a set of instructions, the set of instructions comprising: determining whether the coding block contains samples outside a picture boundary; in response to determining that the coding block includes samples outside a picture boundary, performing a quadtree partitioning of the coding block regardless of a value of a first parameter, the first parameter indicating whether the quadtree is allowed to be used to partition the coding block; A non-transitory computer-readable storage medium executable by one or more processing devices to cause a video processing device to perform the method.

17. The set of instructions determining a value of a first flag for the coding block, the first flag indicating whether the coding block is divided into a plurality of sub-blocks; determining values of a second parameter, a third parameter, a fourth parameter, and a fifth parameter of the coding block, the second parameter, the third parameter, the fourth parameter, and the fifth parameter respectively indicating whether a horizontal binary tree, a vertical binary tree, a horizontal ternary tree, and a vertical ternary tree are allowed to be used to partition the coding block; 20. The non-transitory computer-readable storage medium of claim 16, executable by the one or more processing devices to cause the video processing device to perform:

18. The set of instructions setting a value of a second flag of the coding block to 1 in response to the value of the first flag being equal to 1 and the values of the first parameter, the second parameter, the third parameter, the fourth parameter, and the fifth parameter being equal to 0, wherein the second flag indicates whether the coding block is split using the quadtree.

20. The non-transitory computer-readable storage medium of claim 17, executable by the one or more processing devices to cause the video processing device to perform

19. The set of instructions setting a value of a second flag of the coding block to 1 in response to the value of the first parameter being equal to 1, the second flag indicating whether the coding block is split using the quadtree.

20. The non-transitory computer-readable storage medium of claim 17, executable by the one or more processing devices to cause the video processing device to perform

20. In response to determining that the coding block includes samples outside a picture boundary, splitting the coding block using a QT mode; 20. The non-transitory computer-readable storage medium of claim 17, further comprising setting the value of the first flag to be 1 when it is determined that the coding block contains samples outside a picture boundary.

Images