Method and apparatus for block division at picture boundaries

JP7901208B2Active Publication Date: 2026-08-05ALIBABA GROUP HOLDING LTD
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
ALIBABA GROUP HOLDING LTD
Filing Date
2025-05-19
Publication Date
2026-08-05

Smart Images

  • Figure 0007901208000001
    Figure 0007901208000001
  • Figure 0007901208000002
    Figure 0007901208000002
  • Figure 0007901208000003
    Figure 0007901208000003
Patent Text Reader

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
Need to check novelty before this filing date? Find Prior Art

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 on December 17, 2019, which is hereby incorporated by reference in its entirety.

[0002] Technical Field

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

Background Art

[0003] Background

[0003] Video is a set of static pictures (or "frames") that capture visual information. In order to reduce memory and transmission bandwidth, video can be compressed before storage or transmission and restored before display. The compression process is usually referred to as encoding, and the restoration process is usually referred to as decoding. Most commonly, there are various video coding formats that use standardized video coding techniques based on prediction, transformation, quantization, entropy coding, and in-loop filtering. Video coding standards such as the High Efficiency Video Coding (HEVC / H.265) standard, the Versatile Video Coding (VVC / H.266), and the standard AVS standard, which specify a particular video coding format, have been developed by standardization organizations. As evolving video coding techniques are increasingly adopted in video standards, the coding efficiency of new video coding standards is getting higher and higher.

Summary of the Invention

Means for Solving the Problems

[0004] Summary of the Disclosure

[0004] In some embodiments, exemplary image processing methods include determining whether an encoded block contains samples outside the picture boundary, and, depending on whether it is determined that the encoded block contains samples outside the picture boundary, performing a quadtree partition of the encoded block regardless of the value of a first parameter, wherein the first parameter indicates whether it is permitted to use a quadtree to partition the encoded block.

[0005]

[0005] In some embodiments, an exemplary image processing device includes at least one memory for storing instructions and at least one processor. The at least one processor is configured to execute instructions to cause the device to: determine whether an encoded block contains samples outside the picture boundary; and, in response to the determination that the encoded block contains samples outside the picture boundary, perform a quadtree partition of the encoded block regardless of the value of a first parameter, the first parameter indicating whether it is permitted to use a quadtree to partition the encoded block.

[0006]

[0006] In some embodiments, an exemplary non-temporary computer-readable storage medium stores a set of instructions. The set of instructions is executable by one or more processing devices to cause a video processing device to perform the following: determine whether an encoded block contains samples outside the picture boundary, and, depending on whether it is determined that the encoded block contains samples outside the picture boundary, perform a quadtree partition of the encoded block regardless of the value of a first parameter, the first parameter indicating whether it is permitted to use a quadtree to partition the encoded block.

[0007] Brief explanation of the drawing

[0007] Embodiments and various aspects of the present disclosure are illustrated in the following detailed description and accompanying drawings. Various features shown in the drawings are not depicted to scale. [Brief explanation of the drawing]

[0008] [Figure 1]

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

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

[0010] Figure 2B is a schematic diagram showing another exemplary coding process of a hybrid video coding system according to an embodiment of the present disclosure. [Figure 3A]

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

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

[0013] Figure 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] This is a schematic diagram illustrating an example of a multi-type tree partitioning mode according to some embodiments of the present disclosure. [Figure 6]

[0015] This is a schematic diagram illustrating an exemplary signaling mechanism for partitioning information in a quadtree (QT) having a nested multitype tree coding tree structure, according to some embodiments of the present disclosure. [Figure 7]

[0016] Table 1 illustrates exemplary MttSplitMode derivations based on multitype tree syntax elements according to some embodiments of the present disclosure. [Figure 8]

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

[0018] A schematic diagram showing an exemplary block division on a picture boundary, according to some embodiments of the present disclosure. [Figure 10]

[0019] Exemplary Table 2 showing exemplary specifications of parallel ternary tree splitting (parallelTtSplit) based on a two-way split mode (btSplit) and coded block size (cbSize), according to some embodiments of the present disclosure. [Figure 11]

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

[0021] Exemplary Table 4 showing an exemplary coding tree syntax, according to some embodiments of the present disclosure. [Figure 12B]

[0021] Exemplary Table 4 showing an exemplary coding tree syntax, according to some embodiments of the present disclosure. [Figure 12C]

[0021] Exemplary Table 4 showing an exemplary coding tree syntax, according to some embodiments of the present disclosure. [Figure 13]

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

[0023] Exemplary Table 5 showing exemplary specifications of MttSplitMode, according to some embodiments of the present disclosure. [Figure 15]

[0024] Exemplary Table 6 showing an exemplary sequence parameter set RBSP syntax, according to some embodiments of the present disclosure. [Figure 16]

[0025] Exemplary Table 7 showing an exemplary picture header RBSP syntax, according to some embodiments of the present disclosure. [Figure 17]

[0026] This is a schematic diagram illustrating an exemplary block in which none of the QT, TT, or BT partitions are permitted at the picture boundary, according to some embodiments of the present disclosure. [Figure 18]

[0027] This is a schematic diagram showing an exemplary block in which none of the QT, TT, or BT partitions are permitted at the picture boundary, according to some embodiments of the present disclosure. [Figure 19]

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

[0029] A flowchart of an exemplary video processing method according to some embodiments of this disclosure is shown. [Modes for carrying out the invention]

[0009] Detailed explanation

[0030] Next, exemplary embodiments, illustrated in the accompanying drawings, will be described in detail. The following description refers to the accompanying drawings, where the same reference numerals in different drawings represent the same or similar elements unless otherwise indicated. The implementations shown in the following description of exemplary embodiments do not represent all implementations according to the present invention. Rather, they are merely examples of apparatus and methods according to aspects relating to the present invention as enumerated in the accompanying claims. Specific aspects of this disclosure will be described in more detail below. In the event of any conflict between terms and / or definitions incorporated by reference and those provided herein, the terms and definitions provided herein shall prevail.

[0010]

[0031] The Joint Video Experts Team (JVET) of the ITU-T Video Coding Expert Group (ITU-T VCEG) and the ISO / IEC Moving Picture Expert Group (ISO / IEC MPEG) is currently developing the Multipurpose 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 using half the bandwidth.

[0011]

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

[0012]

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

[0013]

[0034] Video is a set of static pictures (or "frames") arranged in chronological order to store visual information. A video capture device (e.g., a camera) can be used to capture and store these pictures in chronological order, and a video playback device (e.g., a television, computer, smartphone, tablet computer, video player, or any end-user terminal with display capabilities) can be used to display such pictures in chronological order. Depending on the application, the 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, conference management, or live broadcasting.

[0014]

[0035] To reduce the memory space and transmission bandwidth required for 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 general-purpose computer processor) or by specialized hardware. The module for compression is generally called an "encoder," and the module for decompression is generally called a "decoder." Encoders and decoders can be collectively called a "codec." Encoders and decoders can be implemented as any of a variety of suitable hardware, software, or combinations thereof. For example, hardware implementations of encoders and decoders can include circuit mechanisms 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 encoders and decoders 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 can be performed using various algorithms or standards, such as MPEG-1, MPEG-2, MPEG-4, H.26x series, or similar. Depending on the application, a codec can decompress video from a first encoding standard and then 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 encoding process can identify and maintain useful information that can be used to reconstruct a picture, while ignoring information that is not important for reconstruction. If the ignored, non-essential information cannot be fully reconstructed, such an encoding process may be called "lossy." Otherwise, it may be called "lossy." Most encoding processes are lossy, which is a trade-off to reduce the required memory space and transmission bandwidth.

[0016]

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

[0017]

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

[0018]

[0039] Figure 1 shows the structure of an exemplary video sequence 100 according to some embodiments of the present disclosure. The video sequence 100 may be live video or captured and archived video. The video 100 may 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 may 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 for receiving video from a video content provider (e.g., a video broadcast transceiver).

[0019]

[0040] As shown in Figure 1, the video sequence 100 may include a series of pictures arranged in time along a timeline, including pictures 102, 104, 106, and 108. Pictures 102-106 are consecutive, with further pictures between pictures 106 and 108. In Figure 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 arrows. Picture 106 is a B picture, and its reference pictures are pictures 104 and 108, as indicated by the arrows. Depending on the embodiment, the reference picture of a picture (e.g., picture 104) may not be immediately before or after that picture. For example, the reference picture of picture 104 may be the picture before picture 102. Please note that the reference pictures 102-106 are merely examples, and this disclosure does not limit the embodiments of the reference pictures to the examples shown in Figure 1.

[0020]

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

[0021]

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

[0022]

[0043] Video encoding 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 be too large for processing and can therefore be further divided into segments referred to in this disclosure as “basic processing subunits.” Depending on the embodiment, a basic processing subunit may be referred to as a “block” in some video encoding standards (e.g., the MPEG family, H.261, H.263, or H.264 / AVC) or as an “encoding unit” (“CU”) in some other video encoding standards (e.g., H.265 / HEVC or H.266 / VVC). A basic processing subunit may be the same size as or smaller than a basic processing unit. Like a basic processing unit, a basic processing subunit is also a logical unit that can contain groups of different types of video data (e.g., Y, Cb, Cr, and associated syntactic elements) stored in computer memory (e.g., in a video frame buffer). Any operation performed on a basic processing subunit can be repeated on each of its luma and chroma components. Note that such divisions can be carried out to further levels as needed for processing. Also note that different stages can divide the basic processing unit using different methods.

[0023]

[0044] For example, during the mode determination phase (an example of which is shown in Figure 2B), the encoder can determine which prediction mode (e.g., intrapicture prediction or interpicture prediction) to use for the 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 subunits (e.g., CUs, as in the case of H.265 / HEVC or H.266 / VVC) and determine the type of prediction for each basic processing subunit.

[0024]

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

[0025]

[0046] As another example, in the transformation stage (an example of which is shown in Figures 2A and 2B), the encoder may perform transformation operations for residual basic processing subunits (e.g., CUs). However, in some cases, the basic processing subunit may still be too large to process. The encoder may further divide the basic processing subunit into smaller segments (e.g., referred to as "transform blocks" or "TBs" in H.265 / HEVC or H.266 / VVC), and transformation operations may be performed at that level. Note that the division method for the same basic processing subunit may differ in the prediction and transformation stages. 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] In the structure 110 of Figure 1, the basic processing unit 112 is further divided into 3x3 basic processing subunits, and their boundaries are shown as dotted lines. Different basic processing units of the same picture may be divided into basic processing subunits in different ways.

[0027]

[0048] Depending on the implementation, a picture can be divided into processing regions to bring parallel processing and error tolerance to video encoding and decoding. This means that the encoding or decoding process does not have to rely on information from any other regions of the picture with respect to a given region of the picture. In other words, each region of the picture can be processed independently. By doing so, the codec can process different regions of the picture in parallel, thus increasing encoding efficiency. Furthermore, if the data in 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 tolerance. Some video encoding standards allow a picture to be divided into different types of regions. For example, H.265 / HEVC and H.266 / VVC offer two types of regions: "slices" and "tiles". It should also be noted that different pictures in video sequence 100 may have different division 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, their boundaries shown as solid lines within structure 110. Region 114 contains four basic processing units. Regions 116 and 118 each contain six basic processing units. Note that the basic processing units, basic processing subunits, and regions of structure 110 in Figure 1 are merely examples, and this disclosure does not limit its embodiments.

[0029]

[0050] Figure 2A shows a schematic diagram of an exemplary encoding process 200A according to an embodiment of the present disclosure. For example, the encoding process 200A may be performed by an encoder. As shown in Figure 2A, the encoder can encode a video sequence 202 into a video bitstream 228 according to process 200A. Similar to video sequence 100 in Figure 1, video sequence 202 may include a set of pictures arranged in chronological order (referred to as “original pictures”). Similar to structure 110 in Figure 1, each original picture in video sequence 202 may be divided by the encoder into a basic processing unit, basic processing subunit, or region for processing. In some embodiments, the encoder may perform process 200A at the level of a basic processing unit 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 a single iteration of process 200A. In some embodiments, the encoder can perform process 200A in parallel for each region of the original picture in the video sequence 202 (e.g., regions 114-118).

[0030]

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

[0031]

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

[0032]

[0053] Referring to process 200A, the encoder can receive a video sequence 202 generated by a video acquisition device (e.g., a camera). As used herein, the term “receive” can mean receiving, inputting, acquiring, obtaining, getting, reading, accessing, or any act in any way for inputting data.

[0033]

[0054] In prediction stage 204, in the current iteration, the encoder receives the original BPU and prediction criterion 224, performs prediction calculations, and can generate prediction data 206 and prediction BPU 208. The prediction criterion 224 may be generated from the reconstruction path of a previous iteration of process 200A. The objective of prediction stage 204 is to reduce information redundancy by extracting prediction data 206, which can be used to reconstruct the original BPU as prediction BPU 208 from the prediction data 206 and prediction criterion 224.

[0034]

[0055] Ideally, the predicted BPU 208 can be identical to the original BPU. However, due to non-ideal prediction and reconstruction operations, the predicted BPU 208 is generally slightly different from the original BPU. To record such differences, after generating the predicted BPU 208, the encoder can subtract it from the original BPU to generate the residual BPU 210. For example, the encoder can subtract the pixel values ​​(e.g., grayscale values ​​or RGB values) of the predicted BPU 208 from the corresponding pixel values ​​of the original BPU. Each pixel of the residual BPU 210 may have a residual value resulting from such a subtraction between the original BPU and the corresponding pixel of the predicted BPU 208. Compared to the original BPU, the predicted data 206 and residual BPU 210 may have fewer bits, but they 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 BPU210, in the transformation step 212, the encoder can reduce the spatial redundancy of the residual BPU210 by decomposing it into a set of two-dimensional "basis patterns," each basis pattern associated with a "transformation coefficient." The basis patterns can have the same size (e.g., the size of the residual BPU210). Each basis pattern can represent the changing frequency components of the residual BPU210 (e.g., the frequency of brightness changes). No basis pattern can be reconstructed from any combination (e.g., a linear combination) of any other basis pattern. In other words, the decomposition can decompose the changes in the residual BPU210 into the frequency domain. Such a decomposition is analogous to the discrete Fourier transform of a function, in which case the basis patterns are analogous to the basis functions of the discrete Fourier transform (e.g., trigonometric functions), and the transformation coefficients are analogous to the coefficients associated with the basis functions.

[0036]

[0057] Different transformation algorithms can use different basis patterns. For example, various transformation algorithms such as discrete cosine transform, discrete sine transform, or similar can be used in transformation stage 212. The transformation in transformation stage 212 is inversely operable. That is, the encoder can recover the residual BPU 210 by the inverse operation of the transformation (referred to as "inverse transform"). For example, to recover the pixels of the residual BPU 210, the inverse transform can be generated by multiplying the values ​​of the corresponding pixels in the basis pattern by their respective associated coefficients, adding the products, and so on. For video coding standards, both the encoder and decoder can use the same transformation algorithm (and therefore the same basis pattern). Therefore, the encoder can record only the transformation coefficients, and the decoder can reconstruct the residual BPU 210 from the transformation coefficients without receiving the basis pattern from the encoder. Compared to the residual BPU 210, the transformation coefficients may have fewer bits, but they can be used to reconstruct the residual BPU 210 without significant quality degradation. Therefore, the residual BPU210 is further compressed.

[0037]

[0058] The encoder can further compress the conversion coefficients in the quantization stage 214. In the conversion process, different basis patterns can represent different change frequencies (e.g., brightness change frequencies). Since the human eye is generally better at recognizing low-frequency changes, the encoder can ignore information about high-frequency changes without causing significant quality degradation in decoding. For example, in the quantization stage 214, the encoder can generate quantization conversion coefficients 216 by dividing each conversion coefficient by an integer value (referred to as a "quantization parameter") and rounding the quotient to its nearest integer. After such an operation, some conversion coefficients of high-frequency basis patterns may be converted to 0, and conversion coefficients of low-frequency basis patterns may be converted to smaller integers. The encoder can ignore quantization conversion coefficients 216 that are 0, thereby further compressing the conversion coefficients. The quantization process is also inversely operable, in which case the quantization conversion coefficients 216 can be reconstructed into conversion coefficients in the inverse operation of quantization (referred to as "inverse quantization").

[0038]

[0059] Because the encoder rounds off the remainder of such divisions, the quantization stage 214 can be irreversible. Typically, the quantization stage 214 can contribute the greatest information loss in process 200A. The greater the information loss, the fewer bits are required for the quantization conversion coefficient 216. To obtain different levels of information loss, the encoder can use different values ​​for the quantization parameters or any other parameters of the quantization process.

[0039]

[0060] In the binary coding stage 226, the encoder may encode the predicted data 206 and the quantization conversion coefficients 216 using a binary coding technique such as 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 predicted data 206 and the quantization conversion coefficients 216, the encoder may encode other information in the binary coding stage 226, such as the prediction mode used in the prediction stage 204, the parameters of the prediction operation, the type of conversion in the conversion stage 212, the parameters of the quantization process (e.g., quantization parameters), the encoder control parameters (e.g., bitrate control parameters), or the like. The encoder may generate a video bitstream 228 using the output data from the binary coding 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 the inverse quantization step 218, the encoder can perform inverse quantization on the quantization transformation coefficients 216 to generate reconstruction transformation coefficients. In the inverse transformation step 220, the encoder can generate reconstruction residual BPU 222 based on the reconstruction transformation coefficients. The encoder can add the reconstruction residual BPU 222 to the prediction BPU 208 to generate a prediction criterion 224, which will be used in the next iteration of process 200A.

[0041]

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

[0042]

[0063] Figure 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 with an encoder compliant with a hybrid video encoding standard (e.g., the H.26x series). Compared to process 200A, the forward path of process 200B additionally includes a mode determination 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 classified 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 criterion 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 criterion 224 in temporal prediction can include encoded pictures. 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 calculations in spatial prediction stage 2042 and temporal prediction stage 2044. For example, in spatial prediction stage 2042, the encoder may perform intra-prediction. For the original BPU of the picture being encoded, the prediction criterion 224 may include one or more neighboring BPUs encoded (within the forward path) and reconstructed (within the reconstruction path) within the same picture. The encoder may generate a prediction BPU 208 by extrapolating neighboring BPUs. The extrapolation technique may include, for example, linear extrapolation or interpolation, polynomial extrapolation or interpolation, or similar. In some embodiments, the encoder may perform extrapolation at the pixel level, for example, by extrapolating the values ​​of the corresponding pixels for each pixel of the prediction BPU 208. The adjacent BPUs used for extrapolation can be positioned 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., to the lower left, lower right, upper left, or upper right of the original BPU), or any direction defined in the video encoding standard used. For intra-prediction, the prediction data 206 may include, for example, the location (e.g., coordinates) of the adjacent BPUs used, the size of the adjacent BPUs used, the extrapolation parameters, the orientation of the adjacent BPUs used relative to the original BPU, or similar.

[0045]

[0066] As another example, in the temporal prediction stage 2044, the encoder may perform interpretation. For the original BPU of the current picture, the prediction criterion 224 may include one or more pictures (referred to as "reference pictures") that have been encoded (in the forward path) and reconstructed (in the reconstruction path). In some embodiments, the reference pictures may be encoded and reconstructed for each BPU. For example, the encoder may add the reconstructed residual BPU 222 to the prediction BPU 208 to generate a reconstructed BPU. When all reconstructed BPUs for the same picture have been generated, the encoder may generate the reconstructed picture as a reference picture. The encoder may perform a "motion estimation" operation to search for matching regions within the range of the reference picture (referred to as the "search window"). 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 have its center in the reference picture at a location with 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 in the search window that is similar to the original BPU (for example, by using a pixel-recursive (pel-recursive) algorithm, a block-matching algorithm, or similar), the encoder can determine such a region to be a matching region. The matching region may have different dimensions from the original BPU (for example, smaller than, equal to, larger than, or of a different shape than the original BPU). Because the reference picture and the current picture are temporally separated in the timeline (for example, as shown in Figure 1), the matching region can be considered to "move" to 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 (for example, as picture 106 in Figure 1), the encoder can search for a 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 for each matching reference picture.

[0046]

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

[0047]

[0068] To generate a predicted BPU 208, the encoder can perform a “motion compensation” operation. Motion compensation can be used to reconstruct the predicted BPU 208 based on prediction data 206 (e.g., motion vectors) and prediction criteria 224. For example, the encoder can move the matching region of a reference picture according to the motion vector, in which case the encoder can predict the original BPU of the current picture. When multiple reference pictures are used (e.g., as picture 106 in Figure 1), the encoder can move the matching region of each reference picture according to its respective 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 can add the weighted sum of the pixel values ​​to the moved matching region.

[0048]

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

[0049]

[0070] Still referring to the forward path of process 200B, after the spatial prediction 2042 and the temporal prediction stage 2044, in the mode determination stage 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 that minimizes the value of a cost function that depends on the bit rate 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 the corresponding prediction BPU 208 and prediction data 206.

[0050]

[0071] If the intra-prediction mode is selected in the forward path within the reconstruction path of process 200B, after generating the prediction criterion 224 (e.g., the current BPU encoded and reconstructed in the current picture), the encoder can directly supply the prediction criterion 224 to the spatial prediction stage 2042 for later use (e.g., for extrapolation of the next BPU of the current picture). If the inter-prediction mode is selected in the forward path, after generating the prediction criterion 224 (e.g., the current picture with all BPUs encoded and reconstructed), the encoder can supply the prediction criterion 224 to the loop filter stage 232, where the encoder can apply a loop filter to the prediction criterion 224 to reduce or eliminate distortions (e.g., blocking artifacts) introduced by inter-prediction. The encoder can apply various loop filtering techniques in the loop filter stage 232, such as deblocking, sample-adaptive offset, adaptive loop filtering, or similar. Loop-filtered reference pictures may be stored in buffer 234 (or “Decoded Picture Buffer”) for later use (e.g., to be used as interprediction reference pictures for future pictures in video sequence 202). The encoder may store one or more reference pictures in 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) together with quantization transformation coefficients 216, prediction data 206, and other information in the binary coding stage 226.

[0051]

[0072] Figure 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 the compression process 200A in Figure 2A. Depending on the embodiment, process 300A may be similar to the reconstruction path of process 200A. The decoder can decode the video bitstream 228 into a video stream 304 according to process 300A. The video stream 304 may be very similar to the video sequence 202. However, due to information loss in the compression and decompression processes (e.g., the quantization stage 214 in Figures 2A-2B), the video stream 304 is generally not identical to the video sequence 202. Similar to processes 200A and 200B in Figures 2A-2B, the decoder may perform process 300A at the level of a basic processing unit (BPU) for each picture encoded within the video bitstream 228. For example, the decoder can perform process 300A in an iterative manner, in which case the decoder can decode the basic processing unit in a single iteration of process 300A. Depending on the embodiment, the decoder can perform process 300A in parallel for each region of picture encoded in the video bitstream 228 (e.g., regions 114-118).

[0052]

[0073] In Figure 3A, the decoder can supply a portion of the video bitstream 228 associated with the basic processing unit of the encoded picture (referred to as the "encoded BPU") to the binary decoding stage 302. In the binary decoding stage 302, the decoder can decode this portion into prediction data 206 and quantization conversion coefficients 216. The decoder can supply the quantization conversion coefficients 216 to the inverse quantization stage 218 and the inverse conversion stage 220 to generate the reconstructed residual BPU 222. The decoder can supply the prediction data 206 to the prediction stage 204 to generate the prediction BPU 208. The decoder can add the reconstructed residual BPU 222 to the prediction BPU 208 to generate the prediction criterion 224. Depending on the embodiment, the prediction criterion 224 can be stored in a buffer (e.g., a decoded picture buffer in computer memory). The decoder can supply the prediction criterion 224 to the prediction stage 204 in order to perform the prediction calculation in the next iteration of process 300A.

[0053]

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

[0054]

[0075] In the binary decoding stage 302, the decoder can 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). Depending on the embodiment, in addition to the prediction data 206 and quantization conversion coefficients 216, the decoder can decode other information in the binary decoding stage 302, such as, for example, the prediction mode, the parameters of the prediction operation, the type of conversion, the parameters of the quantization process (e.g., quantization parameters), the encoder control parameters (e.g., bitrate control parameters), or the like. Depending on the embodiment, if the video bitstream 228 is transmitted in the form of packets over the network, the decoder can depacket the video bitstream 228 before supplying it to the binary decoding stage 302.

[0055]

[0076] Figure 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 with a decoder compliant with a hybrid video coding standard (e.g., the H.26x series). Compared to process 300A, process 300B further divides the prediction stage 204 into a spatial prediction stage 2042 and a temporal prediction stage 2044, and additionally includes a loop filter stage 232 and a buffer 234.

[0056]

[0077] In process 300B, the prediction data 206 decoded by the decoder from binary decoding stage 302 for the encoding base processing unit ("current BPU") of the encoded picture being decoded ("current picture") can include various types of data, depending on which prediction mode was used by the encoder to encode the current BPU. For example, if intra-prediction is used by the encoder to encode the current BPU, the prediction data 206 can include intra-prediction, parameters of the intra-prediction operation, or prediction mode indicators (e.g., flag values) indicating the same. Parameters of the intra-prediction operation can include, for example, the locations (e.g., coordinates) of one or more adjacent BPUs used as reference, the size of the adjacent BPUs, extrapolation parameters, the orientation of the adjacent BPUs relative to the original BPU, or the same. As another example, if inter-prediction is used by the encoder to encode the current BPU, the prediction data 206 can include inter-prediction, parameters of the inter-prediction operation, or prediction mode indicators (e.g., flag values) indicating the same. The parameters for the interpretation calculation may include, for example, the number of reference pictures associated with the current BPU, the weights associated with each reference picture, the locations (e.g., coordinates) of one or more matching regions within each reference picture, one or more motion vectors associated with each matching region, or similar.

[0057]

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

[0058]

[0079] In process 300B, the decoder may supply the prediction criterion 224 to the spatial prediction stage 2042 or the temporal prediction stage 2044 in order to perform the prediction calculation in the next iteration of process 300B. For example, if the current BPU is decoded using intra-prediction in the spatial prediction stage 2042, after generating the prediction criterion 224 (e.g., the decoded current BPU), the decoder may supply the prediction criterion 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 the temporal prediction stage 2044, after generating the prediction criterion 224 (e.g., the reference picture with all BPUs decoded), the encoder may supply the prediction criterion 224 to the loop filter stage 232 to reduce or eliminate distortion (e.g., blocking artifacts). The decoder may apply the loop filter to the prediction criterion 224 in the manner described in Figure 2B. Loop-filtered reference pictures may be stored in buffer 234 (e.g., a decoded picture buffer in computer memory) for later use (e.g., to be used as inter-prediction reference pictures for future encoded pictures of the video bitstream 228). The decoder may store one or more reference pictures in buffer 234 for use in the temporal prediction stage 2044. In some embodiments, the prediction data 206 may further include loop filter parameters (e.g., loop filter strength) when the prediction mode indicator indicates that inter-prediction was used to encode the current BPU.

[0059]

[0080] Figure 4 is a block diagram of an exemplary apparatus 400 for encoding or decoding video according to an embodiment of the present disclosure. As shown in Figure 4, the apparatus 400 may include a processor 402. When the processor 402 executes instructions as described herein, the apparatus 400 can become a specialized machine for video encoding or decoding. The processor 402 may be any kind of circuit mechanism having the ability to manipulate or process information. For example, the processor 402 may include any number and any combination of a central processing unit (or "CPU"), graphics processing unit (or "GPU"), neural processing unit ("NPU"), microcontroller unit ("MCU"), optical processor, programmable logic controller, microcontroller, microprocessor, digital signal processor, intellectual property (IP) core, programmable logic array (PLA), programmable array logic (PAL), generic array logic (GAL), complex programmable logic device (CPLD), field-programmable gate array (FPGA), system on chip (SoC), application-specific integrated circuit (ASIC), or any number of similar components. Depending on the embodiment, the processor 402 may also be a set of processors grouped as a single logical component. For example, as shown in Figure 4, the 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 Figure 4, the stored data may include program instructions (e.g., program instructions for carrying out 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 can access the program instructions and data for processing (e.g., via bus 410), execute the program instructions, and perform arithmetic or operations on the data for processing. The memory 404 may include a high-speed random-access storage device or a non-volatile storage device. Depending on the embodiment, memory 404 may include any number and any 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 similar. Memory 404 may also be a group of memories grouped as a single logical component (not shown in Figure 4).

[0061]

[0082] Bus 410 can be a communication device that transfers data between internal components of the device 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 similar.

[0062]

[0083] To facilitate explanation without creating ambiguity, the processor 402 and other data processing circuits are collectively referred to as “data processing circuits” in this disclosure. The data processing circuits may be implemented entirely as hardware, or as a combination of software, hardware, or firmware. In addition, the data processing circuits may be a single, standalone module, or may be fully or partially combined with any other component of the device 400.

[0063]

[0084] The device 400 may further include a network interface 406 for providing wired or wireless communication to a network (e.g., the Internet, an intranet, a local area network, a mobile communication network, or the same). Depending on the embodiment, the network interface 406 may include any number or any 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 same.

[0064]

[0085] Depending on the embodiment, the apparatus 400 may optionally further include a peripheral interface 408 for providing connectivity to one or more peripheral devices. As shown in Figure 4, the peripheral devices may include, but are not limited to, cursor control devices (e.g., mouse, touchpad, or touchscreen), keyboards, displays (e.g., cathode ray tube displays, liquid crystal displays, or light-emitting diode displays), video input devices (e.g., cameras, or input interfaces coupled to video archives), or similar.

[0065]

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

[0066]

[0087] In quantization and dequantization function blocks (e.g., quantization 214 and dequantization 218 in Figure 2A or 2B, and dequantization 218 in Figure 3A or 3B), a quantization parameter (QP) is used to determine the amount of quantization (and dequantization) applied to the prediction residual. The initial QP value used for encoding 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 the delta QP value transmitted with 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) having nested multitype trees with 2-partition and 3-partition segmentation structures. Figure 5 is a schematic diagram showing examples of multitype tree partitioning modes according to some embodiments of the present disclosure. As shown in Figure 5, the partitioning types in the multitype tree structure may include quadtree partitioning (SPLIT_QT) 501, vertical 2-partitioning (SPLIT_BT_VER) 502, horizontal 2-partitioning (SPLIT_BT_HOR) 503, vertical 3-partitioning (SPLIT_TT_VER) 504, and horizontal 3-partitioning (SPLIT_TT_HOR) 505. The leaf nodes of the multitype tree are referred to as coding units (CUs) and may have either a square or a rectangle.

[0068]

[0089] Figure 6 is a schematic diagram illustrating an exemplary signaling mechanism for partitioning information in a quadtree having a nested multitype tree coding tree structure, according to some embodiments of the present disclosure. As shown in Figure 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) 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 direction of the partition, and then a third flag (e.g., mtt_split_cu_binary_flag) is signaled to indicate whether the partition 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 multi-type tree splitting mode (MttSplitMode) of the CU can be derived. Figure 7 shows exemplary Table 1, illustrating exemplary MttSplitMode derivations based on multi-type tree syntax elements according to some embodiments of the present disclosure.

[0069]

[0090] A vertical pipelined data unit (VPDU) is defined as a non-overlapping unit within a picture. In a hardware decoder, consecutive VPDUs are processed simultaneously by multiple pipeline stages. 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 can be set to 64 × 64 luma samples. However, in some embodiments, tertiary (TT) and binary (BT) partitioning can lead to an increase in VPDU size. In accordance with this disclosure, certain standard partitioning restrictions may be applied to maintain the VPDU size as 64 × 64 luma samples. Figure 8 shows examples of unallowed TT and BT partitioning in some embodiments of this disclosure. As shown in Figure 8, TT partitioning is not permitted for blocks that have either a width or height equal to 128, or both a width and height equal to 128. For N ≤ 64, horizontal BT is not permitted for CUs of size 128 × N (e.g., width equal to 128 and height less than 128). For N ≤ 64, vertical BT is not permitted for CUs of size N × 128 (e.g., height equal to 128 and width less than 128).

[0070]

[0091] In HEVC, if a portion of a tree node block crosses the lower or right picture boundary, the tree node block is forcibly partitioned until all samples of every encoded CU are located inside the picture boundary. The following partitioning rules apply in VVC Draft 7. - If part of a tree node block extends beyond both the bottom and right picture boundaries, - If a block is a QT node and its size is greater than the minimum QT size, the block is forced to be partitioned in QT partitioning mode. - Otherwise, the block is forcibly split in SPLIT_BT_HOR mode. - Otherwise, if part of the tree node block extends beyond the lower picture boundary, - If a block is a QT node, and its size is greater than the minimum QT size, and its size is greater than the maximum BT size, the block is forced to be partitioned in QT partitioning mode. - Otherwise, if a block is a QT node, and the block size is greater than the minimum QT size and less than or equal to the maximum BT size, the block is forcibly split in either QT splitting mode or SPLIT_BT_HOR mode. - Otherwise (the block is a BT node or the block size is less than or equal to the minimum QT size), the block is forcibly split in SPLIT_BT_HOR mode. - Otherwise, if part of the tree node block extends beyond the right picture boundary, - If a block is a QT node, and its size is greater than the minimum QT size, and its size is greater than the maximum BT size, the block is forced to be partitioned in QT partitioning mode. - Otherwise, if a block is a QT node, and the block size is greater than the minimum QT size and less than or equal to the maximum BT size, the block is forcibly split in either QT splitting mode or SPLIT_BT_VER mode. - Otherwise (for example, if the block is a BT node or the block size is less than or equal to the minimum QT size), the block is forcibly split in SPLIT_BT_VER mode.

[0071]

[0092] Figure 9 shows exemplary block divisions on a picture boundary according to some embodiments of the present disclosure. As shown in Figure 9, for CTU911, either SPLIT_QT or SPLIT_BT_VER may be executed. For CTU913, if SPLIT_QT is permitted, SPLIT_QT may be executed. If SPLIT_QT is not permitted, SPLIT_BT_HOR may be executed. For CTU915, either SPLIT_QT or SPLIT_BT_HOR may be executed.

[0072]

[0093] VVC Draft 7 has two sections related to block partitioning. The first is Section 6.4, which defines whether a block can be partitioned using a quadtree, binary tree, or ternary tree. The output of Section 6.4 is 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 partitioning flags (indicated 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 the following: 6.4 Availability Process 6.4.1 Permitted 4-part process The inputs for this process are as follows: - Encoded block size in Luma sample cbSize - Multi-type tree depth mttDepth - The variable `treeType` specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the encoding tree nodes, and, if a dual tree is used, whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently being processed. - The variable `modeType` specifies whether intra-encoding mode (MODE_INTRA), IBC-encoding mode (MODE_IBC), and inter-encoding mode can be used for the encoding units inside the encoding tree node (MODE_TYPE_ALL), or whether only intra-encoding mode and IBC-encoding mode can be used (MODE_TYPE_INTRA), or only inter-encoding mode can be used (MODE_TYPE_INTER).

[0074]

[0095] The output of this process is the variable allowSplitQt. The variable allowSplitQt is derived as follows: - If one or more of the following conditions are true, allowSplitQt is set to 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 4 or less. - treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA. - Otherwise, allowSplitQt is set to equal to TRUE.

[0075]

[0096] Section 6.4.2 of VVC Draft 7 states the following: 6.4.2 Permitted 2-part processes The inputs for this process are as follows: - 2-split mode btSplit - Encoded block width cbWidth within Luma sample - Encoded block height in Luma sample cbHeight - The position (x0, y0) of the top-left luma sample of a possible encoded block relative to the top-left luma sample of the picture. - Multi-type tree depth mttDepth - Maximum multi-type tree depth with offset maxMttDepth - Maximum 2-way tree size maxBtSize - Minimum quad tree size minQtSize - Partition index partIdx - The variable `treeType` specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the encoding tree nodes, and, if a dual tree is used, whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently being processed. - The variable `modeType` specifies whether intra-encoding mode (MODE_INTRA), IBC-encoding mode (MODE_IBC), and inter-encoding mode can be used for the encoding units inside the encoding tree node (MODE_TYPE_ALL), or whether only intra-encoding mode and IBC-encoding mode can be used (MODE_TYPE_INTRA), or only inter-encoding mode can be used (MODE_TYPE_INTER).

[0076]

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

[0077]

[0098] The variable allowBtSplit is derived as follows: - If one or more of the following conditions are true, allowBtSplit is set to equal to FALSE. - 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. - The treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) × (cbHeight / SubHeightC) is 16 or less. - 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 × 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 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 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 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 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 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 to FALSE. - mttDepth is greater than 0. - partIdx is equal to 1. - MttSplitMode[x0][y0][mttDepth-1] is equal to parallelTtSplit. - Otherwise, if all of the following conditions are true, allowBtSplit is set to FALSE. - btSplit is equal to SPLIT_BT_VER. - cbWidth is 64 or less. - cbHeight is greater than 64. - Otherwise, if all of the following conditions are true, allowBtSplit is set to FALSE. - btSplit is equal to SPLIT_BT_HOR. - cbWidth is greater than 64. - cbHeight is 64 or less. - Otherwise, allowBtSplit is set to equal TRUE.

[0078]

[0099] Section 6.4.3 of VVC Draft 7 is written as follows: 6.4.3 Permitted 3-part process The inputs for this process are as follows: - 3-way split mode ttSplit - Encoded block width cbWidth within Luma sample - Encoded block height in Luma sample cbHeight - The position (x0, y0) of the top-left luma sample of a possible encoded block relative to the top-left luma sample of the picture. - Multi-type tree depth mttDepth - Maximum multi-type tree depth with offset maxMttDepth - Maximum 3-minute tree size maxTtSize - The variable `treeType` specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the encoding tree nodes, and, if a dual tree is used, whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently being processed. - The variable `modeType` specifies whether intra-encoding mode (MODE_INTRA), IBC-encoding mode (MODE_IBC), and inter-encoding mode can be used for the encoding units inside the encoding tree node (MODE_TYPE_ALL), or whether only intra-encoding mode and IBC-encoding mode can be used (MODE_TYPE_INTRA), or only inter-encoding mode can be used (MODE_TYPE_INTER).

[0079]

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

[0080]

[0101] The variable allowTtSplit is derived as follows: - If one or more of the following conditions are true, allowTtSplit is set to equal to FALSE. - 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. - The treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC) × (cbHeight / SubHeightC) is 32 or less. - 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 × cbHeight is equal to 64, and modeType is equal to MODE_TYPE_INTER. - Otherwise, allowTtSplit is set to equal TRUE.

[0081]

[0102] Figure 12 shows an exemplary Table 4 illustrating the coding tree syntax (italicized and shadowed) of Section 7.3.9.4 of the 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 permitted as specified in Clause 6.4.1 is invoked with the encoded block size cbSize set to cbWidth, the current multitype tree depth mttDepth, treeTypeCurr, and modeTypeCurr as inputs, 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 to be equal to MinQtSizeC, MaxBtSizeC, MaxTtSizeC, and MaxMttDepthC+depthOffset, respectively. - Otherwise, minQtSize, maxBtSize, maxTtSize, and maxMttDepth are set to be equal to MinQtSizeY, MaxBtSizeY, MaxTtSizeY, and MaxMttDepthY+depthOffset, respectively. - A split process permitted as specified in Clause 6.4.2 is invoked with the split mode SPLIT_BT_VER, encoded block width cbWidth, encoded block height cbHeight, position (x0,y0), current multitype tree depth mttDepth, maximum multitype tree depth with offset maxMttDepth, maximum binary tree size maxBtSize, minimum quadtree size minQtSize, current partition index partIdx, treeTypeCurr, and modeTypeCurr as input, and the output is assigned to allowSplitBtVer. - A split process permitted as specified in Clause 6.4.2 is invoked with the split mode SPLIT_BT_HOR, encoded block height cbHeight, encoded block width cbWidth, position (x0,y0), current multitype tree depth mttDepth, maximum multitype tree depth with offset maxMttDepth, maximum binary tree size maxBtSize, minimum quadtree size minQtSize, current partition index partIdx, treeTypeCurr, and modeTypeCurr as input, and the output is assigned to allowSplitBtHor. - A three-partition process permitted as specified in Clause 6.4.3 is invoked with the three-partition mode SPLIT_TT_VER, encoded block width cbWidth, encoded block height cbHeight, position (x0,y0), current multitype tree depth mttDepth, maximum multitype tree depth with offset maxMttDepth, maximum three-part tree size maxTtSize, treeTypeCurr, and modeTypeCurr as inputs, and the output is assigned to allowSplitTtVer. - A three-partition process permitted as specified in Clause 6.4.3 is invoked with the three-partition mode SPLIT_TT_HOR, encoded block height cbHeight, encoded block width cbWidth, position (x0,y0), current multitype tree depth mttDepth, maximum multitype tree depth with offset maxMttDepth, maximum three-part tree size maxTtSize, treeTypeCurr, and modeTypeCurr as inputs, and the output is assigned to allowSplitTtHor.

[0083]

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

[0084]

[0105] When the syntactic element split_cu_flag does not exist, the value of split_cu_flag is inferred as follows: - If one or more of the following conditions are true, the value of split_cu_flag is presumed to be equal to 1. - 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 assumed to be equal to 0.

[0085]

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

[0086]

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

[0087]

[0108] A syntax element mtt_split_cu_vertical_flag equal to 0 specifies that the coding unit is split horizontally. A syntax element mtt_split_cu_vertical_flag equal to 1 specifies that the coding unit is split vertically.

[0088]

[0109] When the syntactic element mtt_split_cu_vertical_flag does not exist, 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 assumed to be equal to 0. - Otherwise, the value of mtt_split_cu_vertical_flag is assumed to be equal to 1.

[0089]

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

[0090]

[0111] When the syntactic element mtt_split_cu_binary_flag does not exist, 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 presumed 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 presumed 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 presumed 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 presumed to be equal to mtt_split_cu_vertical_flag.

[0091]

[0112] Figure 14 shows an exemplary Table 5 illustrating an exemplary specification of MttSplitMode according to some embodiments of the present disclosure. The variable MttSplitMode[x][y][mttDepth] is derived from the value of the syntactic element mtt_split_cu_vertical_flag and the value of the syntactic 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 horizontal 2-split, vertical 2-split, horizontal 3-split, and vertical 3-split of an encoding unit in a multitype tree. The array indices x0, y0 specify the position (x0, y0) of the top-left luma sample of a possible encoding block relative to the top-left luma sample of a picture. Figure 13 shows examples of multitype tree splitting modes represented by MttSplitMode according to some embodiments of the present disclosure. As shown in Figure 13, the multitype tree splitting modes may include vertical 2-split (SPLIT_BT_VER)1301, horizontal 2-split (SPLIT_BT_HOR)1302, vertical 3-split (SPLIT_TT_VER)1303, and horizontal 3-split (SPLIT_TT_HOR)1304.

[0093]

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

[0094]

[0115] Figure 15 shows an exemplary Table 6 illustrating the exemplary sequence parameter set RBSP syntax of Section 7.3.2.3 of the VVC Draft 7 according to some embodiments of the present disclosure. Figure 16 shows an exemplary Table 7 illustrating the exemplary picture header RBSP syntax of Section 7.3.2.6 of the 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 crosses the lower or right picture boundary, the tree node block is forced to split until all samples of any encoded block are located inside the picture boundary. However, not all tree splitting modes are permitted for blocks that contain samples that are located at and cross the picture boundary. Figure 17 shows exemplary blocks in which none of the QT, TT, or BT splitting are permitted at the picture boundary, according to some embodiments of the present disclosure. For example, Figure 17 shows CTU1701, CTU1703, and CTU1705 at a picture boundary where none of the QT, TT, or BT splitting are permitted.

[0096]

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

[0097]

[0118] The variable allowSplitQt is set to false due to the following conditions (emphasized in italics): 6.4.1 Permitted 4-part process ... - If one or more of the following conditions are true, allowSplitQt is set to 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. ...

[0098]

[0119] The variable allowSplitBtHor is set to false due to the following conditions (emphasized in italics): 6.4.2 Permitted 2-part processes ... - Otherwise, if all of the following conditions are true, allowBtSplit is set 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 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 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 (emphasized in italics): 6.4.2 Permitted 2-part processes ... - Otherwise, if all of the following conditions are true, allowBtSplit is set 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 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 Permitted 3-part process ... - If one or more of the following conditions are true, allowTtSplit is set to equal to FALSE. - 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 of these variables are set to false, the split flag may not be signaled at the CU level. The syntax element split_cu_flag is presumed to be 1, the syntax element split_qt_flag is presumed to be 0, the syntax element mtt_split_cu_vertical_flag is presumed to be 1, and the syntax element mtt_split_cu_binary_flag is presumed to be 0. In this case, the block may be split using SPLIT_TT_VER, which may violate the constraints of VPDU.

[0102]

[0123] As a second exemplary case where all tree splitting modes are not permitted, all tree splitting is not permitted for blocks that contain samples located at a picture boundary and that extend beyond 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, all variables allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are set to false.

[0103]

[0124] Figure 18 shows exemplary blocks in which no QT, BT, or BT split is permitted at the picture boundary, according to some embodiments of the present disclosure. CTU (e.g., CTU1801, CTU1803, or CTU1805) is a first split using a quadtree that divides into four 64x64 blocks. Each of the 64x64 blocks can then not be further split. However, the portion of the block shown in gray extends beyond the right and / or below picture boundary, which is not permitted in the VVC design. For the block shown in gray, the variable allowSplitQt is set to false due to the following conditions (highlighted in italics): 6.4.1 Permitted 4-part process ... - If one or more of the following conditions are true, allowSplitQt is set to 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. ...

[0104]

[0125] For the blocks shown in gray, the variables allowSplitBtHor and allowSplitBtVer are set to false due to the following conditions (highlighted in italics): 6.4.2 Permitted 2-part processes ...

[0105]

[0126] The variable allowBtSplit is derived as follows: - If one or more of the following conditions are true, allowBtSplit is set to equal to FALSE. - 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 gray, the variables allowSplitTtHor and allowSplitTtVer are set to false due to the following conditions (highlighted in italics): 6.4.3 Permitted 3-part process ...

[0107]

[0128] The variable allowTtSplit is derived as follows: - If one or more of the following conditions are true, allowTtSplit is set to equal to FALSE. - 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 described in the first exemplary case where not all tree partitioning modes are permitted, in the current VVC draft 7, a CU may contain samples outside the picture boundary, but under certain conditions, the CU cannot be further partitioned. Depending on the embodiments of the present disclosure, the QT partitioning conditions in the VVC may be modified. In some embodiments, for blocks containing 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, depending on the embodiment, QT partitioning may also be used when the minimum QT size is equal to N (e.g., 128). In other embodiments, using QT partitioning may be simpler than using BT or TT partitioning. Figure 19 is a schematic diagram showing examples of using BT and TT partitioning according to some embodiments of the present disclosure. Multiple steps may be required to partition a block. Furthermore, partitioning may differ for blocks located at different positions, which can be complex. For example, for block 1903, SPLIT_BT_HOR, SPLIT_BT_HOR, SPLIT_TT_VER, SPLIT_TT_VER, and SPLIT_TT_VER are executed sequentially.

[0109]

[0130] In some embodiments, when no block partitioning is permitted, a quadtree partitioning can be used, and the syntactic element split_qt_flag may be presumed to be 1. The syntactic element split_qt_flag specifies whether the coding unit is split into coding units having half the horizontal and vertical sizes.

[0110]

[0131] If the syntax element split_qt_flag does not exist, the following (emphasized in italics) is applied. - If all of the following conditions are true, then split_qt_flag is presumed to be equal to 1. - 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 assumed to be equal to 1. - Otherwise, the value of split_qt_flag is assumed to be equal to 0.

[0111]

[0132] In some embodiments, the minimum QT size constraint cannot be applied to blocks located at picture boundaries. When a portion of a block extends beyond the lower or right picture boundary, the block may be partitioned using a quadtree. The permitted quadtree partitioning processes are described below. 6.4.1 Permitted 4-part process The inputs for this process are as follows: - Encoded block size in Luma sample cbSize - Multi-type tree depth mttDepth - The variable `treeType` specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the encoding tree nodes, and, if a dual tree is used, whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently being processed. - The variable `modeType` specifies whether intra-encoding mode (MODE_INTRA), IBC-encoding mode (MODE_IBC), and inter-encoding mode can be used for the encoding units inside the encoding tree node (MODE_TYPE_ALL), or whether only intra-encoding mode and IBC-encoding mode can be used (MODE_TYPE_INTRA), or only inter-encoding mode can be used (MODE_TYPE_INTER). The output of this process is the variable `allowSplitQt`.

[0112]

[0133] The variable `allowSplitQt` is derived as follows (emphasized in italics): - If all of the following conditions are true, allowSplitQt is set to equal TRUE. - treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA. - cbSize is equal to 128. - MinQtSizeY is equal to 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 to TRUE. - treeType is equal to DUAL_TREE_CHROMA. - CbSize / SubWidthC is equal to 128. - MinQtSizeC is equal to 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 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 4 or less. - treeType is equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA. - Otherwise, allowSplitQt is set to equal to TRUE.

[0113]

[0134] Depending on the embodiment, bitstream compatibility may be added to the minimum QT size syntax. It may be required that the minimum QT size 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 leaf blocks resulting from the quadtree partitioning of a CTU and the base-2 logarithm of the minimum coded block size in luma samples for a luma CU 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 (including both ends). The base-2 logarithm of the minimum size of luma samples in luma leaf 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 a luma residual block 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 the 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 a luma residual block 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 of 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 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_chroma present in the PH that refers to 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 of the luma 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] In 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 the luma sample of luma luma blocks resulting from a quadtree partition of the CTU and the base-2 logarithm of the minimum encoded block size in the luma sample for luma CU of slices with slice_type equal to 2(I) associated with the PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_luma is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (inclusive). If it does not exist, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is assumed to be equal to the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma. Depending on the embodiment, the value of (1 << (pic_log2_diff_min_qt_min_cb_intra_slice_luma + MinCbLog2SizeY)) being less than or equal to Min(64,CtbSizeY) may be a requirement for bitstream compatibility.

[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 the luma sample of a luma luma block resulting from a quadtree partition of the CTU, and the base-2 logarithm of the minimum luma coded block size in the luma sample for the luma CU of a slice having a slice_type equal to 0(B) or 1(P) associated with the PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_inter_slice is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (including both ends). If it does not exist, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is assumed to be equal to the syntax element sps_log2_diff_min_qt_min_cb_inter_slice. Depending on the embodiment, the value of (1 << (pic_log2_diff_min_qt_min_cb_inter_slice + MinCbLog2SizeY)) being less than or equal to Min(64,CtbSizeY) may be a requirement for bitstream compatibility.

[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 the luma sample of a chroma leaf block resulting from a quadtree split of chroma CTU with treeType equal to DUAL_TREE_CHROMA, and the base-2 logarithm of the minimum encoded block size in the luma sample for chroma CU with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) associated with 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 it does not exist, the value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma is presumed to be equal to the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma. Depending on the embodiment, the bitstream compatibility requirement may be that the value of (1 << (pic_log2_diff_min_qt_min_cb_intra_slice_chroma + MinCbLog2SizeY)) is less than or equal to Min(64, CtbSizeY).

[0123]

[0144] In some embodiments, in the second exemplary case described above where all tree splitting modes are not permitted, if none of the block splitting modes are permitted, a quadtree splitting may be used, and the syntactic element split_qt_flag may be presumed to be 1.

[0124]

[0145] The syntax element split_qt_flag specifies whether the encoded unit is split into encoded units having half the horizontal and vertical size. If the syntax element split_qt_flag is not present, the following (emphasized in italics) applies. - If all of the following conditions are true, then split_qt_flag is presumed to be equal to 1. - 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 assumed to be equal to 1. - Otherwise, the value of split_qt_flag is assumed to be equal to 0.

[0125]

[0146] In some embodiments, in the second exemplary case described above, where not all tree splitting modes are permitted, bitstream conformance may be added to the syntax for 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 luma-leaf blocks resulting from a quadtree partition of the CTU, and the base-2 logarithm of the minimum encoded block size in luma samples for luma CUs of slices with slice_type equal to 2(I) referencing 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 referencing the SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_luma is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (inclusive). The base-2 logarithm of the minimum size in the luma sample of the luma block resulting from the quadtree partition of CTU is derived as follows (emphasized 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 multitype 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 may be overridden by the syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma present in the PH that references an SPS. The value of the syntax element sps_max_mtt_hierarchy_depth_intra_slice_luma is in the range of 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY) (inclusive). Depending on the embodiment, a requirement for bitstream compatibility 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 luma-leaf blocks resulting from a quadtree partition of the CTU and the base-2 logarithm of the minimum luma-encoded block size in luma samples for luma CUs of slices with slice_type equal to 0(B) or 1(P) that reference 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 SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_inter_slice is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (including both ends). The base-2 logarithm of the minimum size in luma samples of luma-leaf blocks resulting from a quadtree partition of the 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 quadtree leaves in a slice having a 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 may be overridden by the syntax element pic_max_mtt_hierarchy_depth_inter_slice, which resides in a PH that references an SPS. The value of the syntax element sps_max_mtt_hierarchy_depth_inter_slice is in the range of 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY) (inclusive). In some embodiments, the value of (MinQtLog2SizeInterY - sps_max_mtt_hierarchy_depth_inter_slice / 2) may be less than or equal to MinCbLog2SizeY as a bitstream compatibility requirement.

[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 chroma leaf blocks resulting from a quadtree partition of chroma CTU with treeType equal to DUAL_TREE_CHROMA, and the base-2 logarithm of the minimum encoded block size in luma samples for chroma CU with treeType equal to DUAL_TREE_CHROMA, which has slice_type equal to 2(I) referencing 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 PH referencing SPS. The value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (inclusive). If it does not exist, the value of the syntax element sps_log2_diff_min_qt_min_cb_intra_slice_chroma is assumed to be equal to 0. The base 2 logarithm of the minimum size in the luma sample of a luma block resulting from a quadtree partition 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 chroma coding units resulting from a multi-type tree partition of chroma quadtree leaves with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) referencing an SPS. When the syntax element partition_constraints_override_enabled_flag is equal to 1, the default maximum hierarchy depth may be overridden by the syntax element pic_max_mtt_hierarchy_depth_chroma present in the PH referencing an SPS. The value of the syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma is in the range of 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY) (inclusive). If it does not exist, the value of the syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma is assumed to be equal to 0. Depending on the embodiment, a requirement for bitstream compatibility 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 the luma sample of luma luma blocks resulting from a quadtree partition of CTU and the base-2 logarithm of the minimum encoded block size in the luma sample for luma CU in slices with slice_type equal to 2(I) associated with PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_luma is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (inclusive). If it does not exist, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is assumed 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 multitype tree split of quadtree leaves in a slice with a slice_type equal to 2(I) associated with PH. The value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma is in the range of 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY) (inclusive). If it does not exist, the value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_luma is assumed to be equal to the syntax element sps_max_mtt_hierarchy_depth_intra_slice_luma. Depending on the embodiment, a requirement for bitstream compatibility 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 the luma sample of a luma luma block resulting from a quadtree partition of the CTU, and the base-2 logarithm of the minimum luma coded block size in the luma sample for the luma CU of a slice having a slice_type equal to 0(B) or 1(P) associated with the PH. The value of the syntax element pic_log2_diff_min_qt_min_cb_inter_slice is in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY (including both ends). If it does not exist, the value of the syntax element pic_log2_diff_min_qt_min_cb_luma is assumed 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 hierarchical depth for coding units resulting from a multi-type tree split of quadtree leaves in a slice having a 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 is in the range of 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY) (inclusive). If it does not exist, the value of the syntax element pic_max_mtt_hierarchy_depth_inter_slice is presumed to be equal to the syntax element sps_max_mtt_hierarchy_depth_inter_slice. Depending on the embodiment, a requirement for bitstream compatibility 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 the luma sample of a chroma leaf block resulting from a quadtree split of chroma CTU with treeType equal to DUAL_TREE_CHROMA, and the base-2 logarithm of the minimum encoded block size in the luma sample for chroma CU with treeType equal to DUAL_TREE_CHROMA in a slice with slice_type equal to 2(I) associated with 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 it does not exist, the value of the syntax element pic_log2_diff_min_qt_min_cb_intra_slice_chroma is presumed 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 hierarchical depth for chroma coding units resulting from a multi-type tree split of chroma quadtree leaves with treeType equal to DUAL_TREE_CHROMA 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_chroma is in the range of 0 to 2 × (CtbLog2SizeY - MinCbLog2SizeY) (inclusive). If it does not exist, the value of the syntax element pic_max_mtt_hierarchy_depth_intra_slice_chroma is presumed to be equal to the syntax element sps_max_mtt_hierarchy_depth_intra_slice_chroma. Depending on the embodiment, a requirement for bitstream compatibility 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] Figure 20 shows a flowchart of an exemplary image processing method 2000 according to some embodiments of the present disclosure. Method 2000 may be performed by an encoder (e.g., by process 200A in Figure 2A or process 200B in Figure 2B), a decoder (e.g., by process 300A in Figure 3A or process 300B in Figure 3B), or by one or more software or hardware components of an apparatus (e.g., apparatus 400 in Figure 4). For example, a processor (e.g., processor 402 in Figure 4) may perform method 2000. In some embodiments, method 2000 may be performed by a computer program product, which is embodied in a computer-readable medium containing computer-executable instructions such as program code, and is executed by a computer (e.g., apparatus 400 in Figure 4).

[0139]

[0160] In step 2001, a decision may be made as to whether the encoded block contains samples outside the picture boundary. Depending on the embodiment, the picture boundary may be the lower picture boundary or the right picture boundary. Referring to Figure 17 as an example of encoded blocks containing samples outside the picture boundary, encoded block 1701 extends beyond the right picture boundary of picture 1700, encoded block 1705 extends beyond the lower picture boundary of picture 1700, and encoded block 1703 extends beyond both the lower and right picture boundaries of picture 1700.

[0140]

[0161] Depending on whether it is determined in step 2003 that the encoded block contains samples outside the picture boundary, the encoded block may be split using QT mode. Depending on the embodiment, depending on whether it is determined that the encoded block contains samples outside the picture boundary, method 2000 may determine that BT mode and TT mode are not permitted to be used to split the encoded block. For example, the variables allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer may be determined to be equal to FALSE.

[0141]

[0162] Depending on the embodiment, depending on whether it is determined that the encoded block contains samples outside the picture boundary, Method 2000 may determine that the encoded block should be split using QT mode, regardless of whether a QT flag exists in the bitstream containing the encoded block. The QT flag indicates whether the encoded block should be split using QT mode. For example, when the syntactic element split_qt_flag is absent, the value of split_qt_flag can be inferred to be equal to 1 if the encoded block contains samples outside the picture boundary and the variables allowSplitQt, allowSplitBtHor, allowSplitBtVer, allowSplitTtHor, and allowSplitTtVer are equal to FALSE, or allowSplitQt is equal to TRUE.

[0142]

[0163] Depending on the embodiment, depending on whether it is determined that the encoded block contains samples outside the picture boundary, Method 2000 may determine that QT mode is permitted to be used to partition the encoded block, regardless of the preset constraints on the minimum block size to which QT mode is permitted to be applied. For example, the minimum QT size constraint cannot be applied to encoded blocks located at the picture boundary.

[0143]

[0164] Depending on the embodiment, the preset constraints may include bitstream compatibility for the encoded blocks. Bitstream compatibility may set the minimum block size for which QT mode is permitted. For example, the minimum block size may be set to 64 or less. Bitstream compatibility may also set the maximum BT depth or maximum TT depth.

[0144]

[0165] Depending on the embodiment, method 2000 may include determining whether an encoded block should be split. For example, the syntactic element split_cu_flag may be used to indicate whether an encoded block should be split. When the syntactic element split_cu_flag is absent, it can be presumed to be equal to 1, indicating that an encoded block should be split.

[0145]

[0166] It should be understood that embodiments of this disclosure may be combined with other embodiments or several other embodiments.

[0146]

[0167] Embodiments can be further described using the following clauses. 1. A video processing method, Determining whether the encoded block contains samples outside the picture boundary, In response to the determination that the coded block contains samples outside the picture boundary, a quadtree partition of the coded block is performed regardless of the value of the first parameter, wherein the first parameter indicates whether it is permissible to use a quadtree to partition the coded block. Methods that include... 2. Determining the value of the first flag of the coding block, wherein the first flag indicates whether the coding block is divided into multiple subblocks, Determining the values ​​of the second, third, fourth, and fifth parameters of the coding block, wherein the second, third, fourth, and fifth parameters indicate whether the use of horizontal binary trees, vertical binary trees, horizontal trinities, and vertical trinities to partition the coding block is permitted, The method described in Clause 1, further including the method described in Clause 1. 3. The method according to Clause 2, wherein the value of the second flag of the coded block is set to 1, in accordance with the fact that the value of the first flag is equal to 1 and the values ​​of the first, second, third, fourth, and fifth parameters are equal to 0, the second flag further comprising indicating whether the coded block is partitioned using a quadtree. 4. The method according to clause 2, wherein the value of a second flag of a coding block is set to 1 in accordance with the value of the first parameter being equal to 1, the second flag further comprising indicating whether the coding block is partitioned using a quadtree. 5. The method of any one of the clauses 2 to 4, further comprising setting the value of the first flag to 1 when it is determined that the encoded block contains samples outside the picture boundary. 6. Image processing device, At least one memory for storing instructions, It comprises at least one processor, and at least one processor is Determining whether the encoded block contains samples outside the picture boundary, and In response to the determination that the coded block contains samples outside the picture boundary, a quadtree partition of the coded block is performed regardless of the value of the first parameter, wherein the first parameter indicates whether it is permissible to use a quadtree to partition the coded block. A device configured to execute instructions in order to cause the device to perform an action. 7. At least one processor, The value of the first flag of the coding block is determined, and the first flag indicates whether the coding block is divided into multiple subblocks. Determining the values ​​of the second, third, fourth, and fifth parameters of the coding block, wherein the second, third, fourth, and fifth parameters indicate whether the use of horizontal binary trees, vertical binary trees, horizontal trinities, and vertical trinities to partition the coding block is permitted, The apparatus described in Clause 6, configured to execute instructions in order to cause the apparatus to perform the following actions. 8. At least one processor, The second flag of the coded block is set to 1, depending on whether the value of the first flag is equal to 1, and whether the values ​​of the first, second, third, fourth, and fifth parameters are equal to 0, wherein the second flag indicates whether the coded block is partitioned using a quadtree. The apparatus described in Clause 7, configured to execute instructions in order to cause the apparatus to perform the following actions. 9. At least one processor, The value of the second flag of the coding block is set to 1 depending on whether the value of the first parameter is equal to 1, and the second flag indicates whether the coding block is partitioned using a quadtree. The apparatus described in Clause 7, configured to execute instructions in order to cause the apparatus to perform the following actions. 10. At least one processor, When it is determined that the encoded block contains samples outside the picture boundary, set the value of the first flag to 1. A device as described in any one of clauses 7 to 9, configured to execute instructions in order to cause the device to perform the following. 11. A non-temporary computer-readable storage medium for storing a set of instructions, wherein the set of instructions is Determining whether the encoded block contains samples outside the picture boundary, In response to the determination that the coded block contains samples outside the picture boundary, a quadtree partition of the coded block is performed regardless of the value of the first parameter, wherein the first parameter indicates whether it is permissible to use a quadtree to partition the coded block. A non-temporary computer-readable storage medium that can be executed by one or more processing devices in order to cause a video processing device to perform the following. 12. The set of instructions is Determining the value of a first flag in a coded block, where the first flag indicates whether the coded block is divided into multiple subblocks, Determining the values ​​of the second, third, fourth, and fifth parameters of the coding block, which indicate whether the second, third, fourth, and fifth parameters are permitted to use horizontal binary trees, vertical binary trees, horizontal trinities, and vertical trinities to partition the coding block, respectively. A non-temporary computer-readable storage medium as described in Clause 11, which can be executed by one or more processing devices to cause the video processing device to perform the following. 13. The set of instructions is The second flag of the coded block is set to 1, depending on whether the value of the first flag is equal to 1, and whether the values ​​of the first, second, third, fourth, and fifth parameters are equal to 0, wherein the second flag indicates whether the coded block is partitioned using a quadtree. A non-temporary computer-readable storage medium as described in Clause 12, which can be executed by one or more processing devices in order to cause a video processing device to perform the following. 14. The set of instructions is The value of the second flag of the coding block is set to 1 depending on whether the value of the first parameter is equal to 1, and the second flag indicates whether the coding block is partitioned using a quadtree. A non-temporary computer-readable storage medium as described in Clause 12, which can be executed by one or more processing devices in order to cause a video processing device to perform the following. 15. Depending on whether it is determined that the encoded block contains samples outside the picture boundary, the encoded block may be divided using QT mode. A non-temporary computer-readable storage medium as described in any one of clauses 12 to 14, comprising setting the value of a first flag to 1 when it is determined that an encoded block contains samples outside the picture boundary. 16. A video processing method, Determining whether the encoded block contains samples outside the picture boundary, A method comprising: partitioning an encoded block using a quadtree (QT) mode, depending on whether it is determined that the encoded block contains samples outside the picture boundary. 17. The method according to Clause 16, further comprising determining that binary tree (BT) mode and ternary tree (TT) mode are not permitted to be used to partition an encoded block, depending on whether it is determined that the encoded block contains samples outside the picture boundary. 18. Depending on whether it is determined that the encoded block contains samples outside the picture boundary, the encoded block may be partitioned using quadtree (QT) mode. The method according to any one of clauses 16 and 17, wherein a coded block is split using QT mode, regardless of whether a QT flag is present in the bitstream containing the coded block, the QT flag being an indication of whether the coded block should be split using QT mode. 19. Depending on whether it is determined that the encoded block contains samples outside the picture boundary, the encoded block may be partitioned using quadtree (QT) mode. The method according to clause 16, which includes dividing an encoded block using QT mode, regardless of the preset constraints on the minimum block size for which QT mode is permitted. 20. The method according to clause 19, wherein the preset constraints include bitstream conformance associated with the encoding block, and the bitstream conformance sets the minimum block size for which QT mode is permitted. 21. The method according to clause 20, wherein the minimum block size is set to 64 or less. 22. The method described in either of the clauses 20 and 21, wherein bitstream compliance sets the maximum BT depth or maximum TT depth. 23. The method according to any one of the clauses 16 to 22, wherein the picture boundary is the bottom picture boundary or the right picture boundary. 24. Image processing device, At least one memory for storing instructions, It comprises at least one processor, and at least one processor is Determining whether the encoded block contains samples outside the picture boundary, Depending on whether the encoded block is determined to contain samples outside the picture boundary, the encoded block is partitioned using a quadtree (QT) mode, A device configured to execute instructions in order to cause the device to perform an action. 25. At least one processor, Depending on whether the encoded block is determined to contain samples outside the picture boundary, it is determined that binary tree (BT) mode and ternary tree (TT) mode are not permitted to be used to partition the encoded block. The apparatus described in Clause 24, configured to execute instructions in order to cause the apparatus to perform the following actions. 26. At least one processor, The method of splitting an encoded block using QT mode, regardless of whether the QT flag is present in the bitstream containing the encoded block, wherein the QT flag indicates whether the encoded block is to be split using QT mode. The apparatus described in either paragraph 24 or 25, configured to execute instructions in order to cause the apparatus to perform the following. 27. At least one processor, Dividing coded blocks using QT mode, regardless of the preset constraints on the minimum block size for which QT mode is permitted. The apparatus described in Clause 24, configured to execute instructions in order to cause the apparatus to perform the following actions. 28. The apparatus described in Clause 27, wherein the preset constraints include bitstream conformance associated with the encoding block, and the bitstream conformance sets the minimum block size for which QT mode is permitted. 29. The apparatus described in Clause 28, wherein the minimum block size is set to 64 or less. 30. The device described in either clause 28 or 29, wherein bitstream compatibility sets the maximum BT depth or maximum TT depth. 31. The apparatus described in any one of the clauses 24 to 30, wherein the picture boundary is the lower picture boundary or the right picture boundary. 32. A non-temporary computer-readable storage medium for storing a set of instructions, wherein the set of instructions is Determining whether the encoded block contains samples outside the picture boundary, Depending on whether the encoded block is determined to contain samples outside the picture boundary, the encoded block is partitioned using a quadtree (QT) mode, A non-temporary computer-readable storage medium that can be executed by one or more processing devices in order to cause a video processing device to perform the following. 33. The set of instructions is Depending on whether the encoded block is determined to contain samples outside the picture boundary, it is determined that binary tree (BT) mode and ternary tree (TT) mode are not permitted to be used to partition the encoded block. A non-temporary computer-readable storage medium as described in Clause 32, which is executable by one or more processing devices in order to cause a video processing device to perform the following. 34. The set of instructions is The method of splitting an encoded block using QT mode, regardless of whether the QT flag is present in the bitstream containing the encoded block, wherein the QT flag indicates whether the encoded block should be split using QT mode. A non-temporary computer-readable storage medium as described in either paragraph 32 or 33, which can be executed by one or more processing devices in order to cause a video processing device to perform the following. 35. A set of instructions, Dividing coded blocks using QT mode, regardless of the preset constraints on the minimum block size for which QT mode is permitted. A non-temporary computer-readable storage medium as described in Clause 32, which is executable by one or more processing devices in order to cause a video processing device to perform the following. 36. A non-temporary computer-readable storage medium as described in Clause 35, wherein the preset constraints include bitstream conformance associated with the encoded block, and the bitstream conformance sets the minimum block size for which QT mode is permitted to be applied. 37. A non-temporary computer-readable storage medium as described in Clause 36, wherein the minimum block size is set to 64 or less. 38. A non-temporary computer-readable storage medium as described in either clause 36 or 37, wherein bitstream compatibility sets the maximum BT depth or maximum TT depth. 39. A non-temporary computer-readable storage medium as described in any one of clauses 32 to 38, wherein the picture boundary is the lower picture boundary or the right picture boundary.

[0147]

[0168] Depending on the embodiment, a non-temporary computer-readable storage medium containing instructions may also be provided, which may be executed by a device (such as an encoder and decoder of the Disclosure) to carry out the methods described above. Common forms of non-temporary media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media having a pattern of holes, RAM, PROMs, and EPROMs, FLASH®-EPROMs, or any other flash memory, NVRAMs, caches, registers, any other memory chips or cartridges, and networked versions thereof. A device may include one or more processors (CPUs), input / output interfaces, network interfaces, and / or memory.

[0148]

[0169] It should be noted that relational terms in this specification, such as "first" and "second," are used merely to distinguish one entity or action from another, and do not imply or require any actual relationship or order between these entities or actions. Furthermore, the words "comprising," "having," "containing," and "including," as well as other similar forms, are intended to be open-ended in that they are equivalent in meaning, and the elements or groups of elements that follow any of these words are not meant to be an exhaustive enumeration of such elements or groups of elements, nor are they meant to be limited to only the enumerated elements or groups of elements.

[0149]

[0170] As used herein, unless otherwise specified, the term "or" encompasses all possible combinations, except in cases where it is not feasible. For example, if it is stated that a database may contain A or B, then unless otherwise specified or it is not feasible, the database may contain A, or B, or A and B. As a second example, if it is stated that a database may contain A, B, or C, then unless otherwise specified or it is not feasible, the database may contain A, B, or C, or A and B, A and C, or B and C, or A and B and C.

[0150]

[0171] It will be understood that the embodiments described above may be implemented by hardware, software (program code), or a combination of hardware and software. When implemented by software, it may be stored in the computer-readable medium described above. The software can perform the methods of this disclosure when executed by a processor. The computing units and other functional units described in this disclosure may be implemented by hardware, software, or a combination of hardware and software. Those skilled in the art will also understand that some of the above modules / units may be combined into a single module / unit, and each of the above modules / units may be further divided into some submodules / subunits.

[0151]

[0172] In the above-described specification, embodiments have been described with reference to numerous specific details that may differ depending on the implementation. Specific adaptations and modifications of the above-described embodiments can be made. Other embodiments may become apparent to those skilled in the art from the considerations herein and the implementations of the invention disclosed herein. The specification and examples are intended to be considered as examples only, and the true scope and spirit of the invention are indicated by the appended claims. Furthermore, the arrangement of steps shown in the figures is for illustrative purposes only and is not intended to limit the invention to any particular arrangement of steps. Therefore, those skilled in the art will understand that these steps may be performed in different orders while carrying out the same method.

[0152]

[0173] Exemplary embodiments are disclosed in the drawings and specification. However, many variations and modifications can be made to these embodiments. Therefore, where certain terms are used, they are merely for general descriptive purposes and not for limiting purposes.

Claims

1. A video decoding method, Determining the value of the first parameter of the interslice, wherein the first parameter indicates the minimum size in the luma sample of the luma-leaf block resulting from the quadtree partition of the coding tree unit, The value of the second parameter is determined such that the second parameter represents the minimum Luma coding block size. Determining the size of the target coding unit, The process involves determining whether the target encoding unit contains samples outside the picture boundary, The method includes decoding the target coding unit based on the values ​​of the first and second parameters, the size of the target coding unit, and whether the target coding unit includes samples outside the picture boundary. The aforementioned decoding process The method involves dividing the target coding unit into a plurality of coding units, such that the first parameter, the second parameter, and the size of the target coding unit are all equal to a first value, and the target coding unit includes samples outside the picture boundary, each of which has half the horizontal size and half the vertical size of the target coding unit. Methods that include...

2. The method according to claim 1, comprising determining that a first flag signaled in a bitstream has a second value, depending on that the first parameter, the second parameter, and the size of the target coding unit are all equal to the first value, and that the target coding unit includes samples outside the picture boundary, wherein the first flag being equal to the second value indicates that each of the plurality of coding units has half the horizontal size and half the vertical size of the target coding unit.

3. The method according to claim 2, wherein the second value is 1.

4. The method according to claim 2, wherein the first flag includes split_qt_flag.

5. The method according to claim 1, further comprising determining the values ​​of a third, fourth, fifth, sixth, and seventh parameter associated with the target coding unit, the third, fourth, fifth, sixth, and seventh parameters respectively indicating whether it is permitted to use a quad, horizontal 2, vertical 2, horizontal 3, and vertical 3 division to divide the target coding unit.

6. The method according to claim 5, further comprising determining that the values ​​of the third parameter, the fourth parameter, the fifth parameter, the sixth parameter, and the seventh parameter are all equal to the third value, in accordance with the fact that the first parameter, the second parameter, and the size of the target coding unit are all equal to the first value.

7. The method according to claim 5, wherein the values ​​of the third parameter, the fourth parameter, the fifth parameter, the sixth parameter, and the seventh parameter are all equal to the third value, indicating that none of the four divisions, horizontal two divisions, vertical two divisions, horizontal three divisions, or vertical three divisions are permitted to be used to divide the target coding unit.

8. The method according to claim 1, further comprising determining that the target encoding unit is divided into the plurality of encoding units based on the value of a first flag signaled in the bitstream.

9. The method according to claim 8, wherein the value of the first flag is equal to 1.

10. The method according to claim 8, wherein the first flag includes split_cu_flag.

11. A video encoding method, Setting the value of the first parameter of the interslice, wherein the first parameter indicates the minimum size in the luma sample of the luma-leaf block resulting from the quadtree partition of the coding tree unit, The value of the second parameter is determined such that the second parameter represents the minimum Luma coding block size. Determining the size of the target coding unit, The process involves determining whether the target encoding unit contains samples outside the picture boundary, The method includes encoding the target encoding unit based on the values ​​of the first and second parameters, the size of the target encoding unit, and whether the target encoding unit includes samples outside the picture boundary. The above encoding is The method involves dividing the target coding unit into a plurality of coding units, such that the first parameter, the second parameter, and the size of the target coding unit are all equal to a first value, and the target coding unit includes samples outside the picture boundary, each of which has half the horizontal size and half the vertical size of the target coding unit. Methods that include...

12. A method for storing a video bitstream, Setting the value of the first parameter of the interslice, wherein the first parameter indicates the minimum size in the luma sample of the luma-leaf block resulting from the quadtree partition of the coding tree unit, The value of the second parameter is determined such that the second parameter represents the minimum Luma coding block size. Determining the size of the target coding unit, The process involves determining whether the target encoding unit contains samples outside the picture boundary, A bitstream is generated based on the values ​​of the first and second parameters, the size of the target encoding unit, and whether the target encoding unit includes samples outside the picture boundary. This includes storing the bitstream in a non-temporary computer-readable storage medium, The generation of the bitstream is The method involves dividing the target coding unit into a plurality of coding units, such that the first parameter, the second parameter, and the size of the target coding unit are all equal to a first value, and the target coding unit includes samples outside the picture boundary, each of which has half the horizontal size and half the vertical size of the target coding unit. Methods that include...

13. The bitstream includes a first flag, and the bitstream is This is for processing according to determining that the first flag has a second value, depending on that the first parameter, the second parameter, and the size of the target coding unit are all equal to a first value, and that the target coding unit includes samples outside the picture boundary. The method according to claim 12, wherein the first flag being equal to the second value indicates that each of the plurality of coding units has half the horizontal size and half the vertical size of the target coding unit.

14. The method according to claim 13, wherein the second value is 1.

15. The method according to claim 13, wherein the first flag includes split_qt_flag.

16. The method according to claim 12, further comprising determining the values ​​of a third, fourth, fifth, sixth, and seventh parameter associated with the target coding unit, and indicating whether the third, fourth, fifth, sixth, and seventh parameters permit the use of quadration, horizontal 2-part division, vertical 2-part division, horizontal 3-part division, and vertical 3-part division to divide the target coding unit, respectively.

17. The method according to claim 16, further comprising determining that the values ​​of the third parameter, the fourth parameter, the fifth parameter, the sixth parameter, and the seventh parameter are all equal to the third value, in accordance with the fact that the first parameter, the second parameter, and the size of the target coding unit are all equal to the first value.