Method and apparatus for video decoding performed by a decoder, and method for video encoding performed by an encoder

Abstract

Methods and apparatus, including processing circuitry, for decoding coded information of a coding block (CB) in a picture from a coded video bitstream are provided.SOLUTION: The coded information indicates a width W and a height H of the CB. The processing circuitry partitions the CB into sub-processing units (SPUs) having a width that is the smallest one of W and K and a height that is the smallest one of H and K. At least one of the width W and the height H is larger than the processing data unit size K. The processing circuitry determines a partitioning structure for dividing the SPU based on the width and the height of the SPU and a maximum transform unit (TU) size M. At least one of a width and a height of the SPU is greater than M. The processing circuitry divides each of the SPUs into M * M TUs based on the partitioning structure.SELECTED DRAWING: Figure 7

Description

[Technical Field]

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

[0002] The background description provided herein is intended to generally present the context for the present disclosure. The work of the presently named inventors, to the extent that that work is described in this background section, and any aspect of the description that may not otherwise qualify as prior art at the time of filing, is not admitted expressly or implicitly as prior art to the present disclosure.

[0003] Video coding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a sequence of pictures, each having spatial dimensions of, for example, 1920 x 1080 luminance samples and associated chrominance samples. The sequence of pictures can have a fixed or variable picture rate (commonly known as the frame rate), for example, 60 pictures per second, or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video (1920 x 1080 luminance sample resolution at a 60 Hz frame rate) at 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires over 600 Gbytes of storage space.

[0004] One goal of video coding and decoding can be the reduction of redundancy in an input video signal through compression. Compression can help reduce the bandwidth or storage space requirements by more than two orders of magnitude in some cases. Both lossless and lossy compression, as well as combinations thereof, can be used. Lossless compression refers to a technique in which an exact copy of the original signal can be reconstructed from the compressed original signal. When lossy compression is used, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signal is small enough to make the reconstructed signal useful for the intended application. In the case of video, lossy compression is widely used. The amount of tolerable distortion depends on the application; for example, a user of a particular consumer streaming application may tolerate higher distortion than a user of a television distribution application. The achievable compression ratio can reflect that a higher tolerable / acceptable distortion can result in a higher compression ratio.

[0005] Video encoders and decoders can utilize techniques from several broad categories, including, for example, motion compensation, transform, quantization, and entropy coding.

[0006] Video codec technology can include a technique known as intra-coding. In intra-coding, sample values ​​are represented without reference to samples or other data from a previously reconstructed reference picture. In some video codecs, a picture is spatially subdivided into blocks of samples. If all blocks of samples are coded in intra mode, the picture can be an intra-picture. Intra-pictures and their derivatives, such as independent decoder refresh pictures, can be used to reset the decoder state and can therefore be used as the first picture of a coded video bitstream and video session, or as a still image. Samples of intra-blocks can undergo a transform, and the transform coefficients can be quantized before entropy coding. Intra-prediction can be a technique that minimizes sample values ​​in the pre-transform domain. In some cases, the smaller the DC value and the smaller the AC coefficients after the transform, the fewer bits are required for a given quantization step size to represent the block after entropy coding.

[0007] Conventional intra-coding, for example, as known from MPEG-2 generation coding techniques, does not use intra-prediction. However, newer video compression techniques include techniques that attempt to predict intra-prediction from surrounding sample data and / or metadata obtained during encoding / decoding of spatially adjacent and preceding blocks of data in decoding order. Such techniques are hereinafter referred to as "intra-prediction" techniques. Note that, at least in some cases, intra-prediction uses reference data only from the current picture being reconstructed, and not from reference pictures.

[0008] There may be many different forms of intra-prediction. If more than one such technique can be used in a given video coding technique, the technique in use may be coded as an intra-prediction mode. In certain cases, a mode may have sub-modes and / or parameters, which may be coded independently or included in a mode codeword. Because which codeword to use for a given mode / sub-mode / parameter combination may affect coding efficiency gains through intra-prediction, entropy coding techniques may be used to convert the codeword into a bitstream.

[0009] Certain modes of intra prediction were introduced by H.264, refined in H.265, and further refined in newer coding techniques such as Joint Exploration Model (JEM), Versatile Video Coding (VVC), and Benchmark Set (BMS). Predictor blocks can be formed using neighboring sample values ​​belonging to already available samples. Sample values ​​of neighboring samples are copied into the predictor block according to direction. The reference for the direction in use can be coded in the bitstream or can be predicted itself.

[0010] Referring to FIG. 1A, the bottom right shows a subset of nine known predictor directions from the 33 possible predictor directions in H.265 (corresponding to the 33 angle modes of the 35 intra modes). The point where the arrows converge (101) corresponds to the sample being predicted. The arrow corresponds to the direction in which the sample is predicted. For example, arrow (102) indicates that sample (101) is predicted from one or more samples to the upper right and at an angle of 45 degrees from horizontal. Similarly, arrow (103) indicates that sample (101) is predicted from one or more samples to the lower left and below sample (101) at an angle of 22.5 degrees from horizontal.

[0011] Still referring to FIG. 1A , a square block (104) of 4×4 samples (indicated by a thick dashed line) is depicted at the top left. The square block (104) contains 16 samples, each labeled with “S,” its position in the Y dimension (e.g., row index), and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample (from the top) in the Y dimension and the first sample (from the left) in the X dimension. Similarly, sample S44 is the fourth sample in block (104) in both the Y and X dimensions. Since the block is 4×4 samples in size, S44 is at the bottom right. Also shown are reference samples, which follow a similar numbering scheme. The reference samples are labeled with “R,” their Y position (e.g., row index), and their X position (column index) relative to block (104). In both H.264 and H.265, predicted samples are adjacent to the block being reconstructed, so negative values ​​need not be used.

[0012] Intra-picture prediction can work by copying reference sample values ​​from neighboring samples as needed depending on the signaled prediction direction. For example, suppose the coded video bitstream includes signaling for this block indicating a prediction direction consistent with arrow (102), i.e., that the sample is predicted from one or more prediction samples to the upper right at an angle of 45 degrees from horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Then, sample S44 is predicted from reference sample R08.

[0013] In certain cases, the values ​​of multiple reference samples may be combined, for example through interpolation, to calculate the reference sample, especially when the direction is not equally divisible by 45 degrees.

[0014] The number of possible directions has increased as video coding technology has evolved. In H.264 (2003), nine different directions could be represented. This increased to 33 in H.265 (2013), and JEM / VVC / BMS can support up to 65 directions as of the time of this disclosure. Experiments have been conducted to identify the most likely directions, and specific techniques in entropy coding are used to represent these likely directions with a small number of bits, while accepting a slight penalty for less likely directions. Furthermore, the direction itself can sometimes be predicted from neighboring directions used in neighboring, already decoded blocks.

[0015] FIG. 1B shows a schematic diagram (180) representing 65 intra-prediction directions with JEM to illustrate the increasing number of prediction directions over time.

[0016] The mapping of intra-prediction direction bits in a coded video bitstream to represent directions can vary from video coding technique to technique, ranging, for example, from a simple direct mapping of prediction directions to intra-prediction modes, to codewords, to complex adaptation schemes including most-probable modes, and similar techniques. In all cases, however, there may be certain directions that are statistically less likely to occur in the video content than certain other directions. Since the goal of video compression is to reduce redundancy, these less likely directions will be represented by more bits than more likely directions in a video coding technique that works well.

[0017] Motion compensation can be a lossy compression technique and can refer to a technique used for predicting a newly reconstructed picture or picture portion after blocks of sample data from a previously reconstructed picture or portion thereof (reference picture) are spatially shifted in a direction indicated by a motion vector (hereinafter MV). In some cases, the reference picture can be the same as the picture currently being reconstructed. The MV can have two dimensions X and Y, or three dimensions, with the third dimension being an indication of the reference picture in use (the latter can indirectly be a temporal dimension).

[0018] In some video compression techniques, the MV applicable to a particular area of ​​sample data can be predicted from other MVs, e.g., those related to other areas of sample data spatially adjacent to the area being reconstructed and preceding that MV in decoding order. Doing so can significantly reduce the amount of data required to code the MV, thereby removing redundancy and increasing compression. For example, when coding an input video signal obtained from a camera (known as natural video), MV prediction can work effectively because there is a statistical possibility that areas larger than the area to which a single MV is applicable will move in a similar direction, and therefore, in some cases, can be predicted using similar motion vectors derived from MVs of neighboring areas. As a result, the MV determined for a given area is similar or identical to the MV predicted from surrounding MVs and, after entropy coding, can be represented with fewer bits than would be used to code the MV directly. In some cases, MV prediction can be an example of lossless compression of a signal (i.e., MV) derived from an original signal (i.e., sample stream). In other cases, MV prediction itself can be lossy, for example, due to rounding errors when calculating a predictor from several surrounding MVs.

[0019] Various MV prediction mechanisms are described in H.265 / HEVC (ITU-T Rec. H265, “High Efficiency Video Coding”, December 2016). Among the many MV prediction mechanisms proposed by H.265, a technique hereafter referred to as “spatial merging” is described in this specification.

[0020] Referring to Figure 2, a current block (201) has samples that the encoder finds during the motion search process to be predictable from a spatially shifted previous block of the same size. Instead of directly coding its MV, the MV can be derived from metadata associated with one or more reference pictures, for example, from the most recent reference picture (in decoding order) using the MV associated with any one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (202 to 206, respectively). In H.265, MV prediction can use predictors from the same reference picture used by neighboring blocks. Summary of the Invention

[0021] Aspects of the disclosure provide methods and apparatuses for video encoding / decoding. In some examples, the apparatus for video decoding includes a processing circuit. The processing circuit is configured to decode coded information of a coding block (CB) in a picture from a coded video bitstream. The coded information indicates a width of W samples and a height of H samples of the CB. The processing circuit can divide the CB into sub-processing units (SPUs) having a width that is the smallest one of W and K and a height that is the smallest one of H and K. At least one of the width W and height H of the CB is greater than a processing data unit size K. The processing circuit can determine a partitioning structure for further dividing the SPU based on the width and height of the SPU and a maximum transform unit (TU) size of M samples. At least one of the width and height of the SPU is greater than M. The processing circuit can divide each of the SPUs into M x M TUs based on the determined partitioning structure.

[0022] In an embodiment, the width and height of the SPU are greater than M. The processing circuitry may determine that the partitioning structure is a quadtree partitioning structure. The processing circuitry may divide the SPU into the TUs based on the quadtree partitioning structure.

[0023] In an embodiment, the width of the SPU is greater than M and the height of the SPU is equal to M. The processing circuitry may determine the partitioning structure to be a vertical binary tree partitioning structure. The processing circuitry may divide the SPU into TUs based on the vertical binary tree partitioning structure.

[0024] In an embodiment, the height of the SPU is greater than M, and the width of the SPU is equal to M. The processing circuitry may determine the partitioning structure to be a horizontal binary tree partitioning structure. The processing circuitry may divide the SPU into TUs based on the horizontal binary tree partitioning structure.

[0025] In an embodiment, the processing circuitry may recursively divide one of the SPUs into TUs based on the partitioning structure.

[0026] In an embodiment, the processing circuitry can process the SPUs according to a first scan order and process the TUs in each of the SPUs according to a second scan order. In an example, at least one of the first scan order and the second scan order is one of (i) a raster scan order, (ii) a vertical scan order, (iii) a zigzag order, and (iv) a diagonal scan order. In an example, the first scan order and the second scan order are raster scan orders. In an example, W is 128, H is 64, K is 64, and M is 32. The first scan order is left or right, and the second scan order is raster scan order.

[0027] In an embodiment, the processing data unit size K indicates the size of a virtual pipeline data unit (VPDU). In a picture, a first SPU among the SPUs is included in a first VPDU, and a second SPU among the SPUs is included in a second VPDU. After processing the first VPDU in a first stage of a multi-stage pipeline, the processing circuit can simultaneously process the first VPDU in a second stage of the multi-stage pipeline and the second VPDU in the first stage.

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

[0029] [Figure 1A] FIG. 2 is a schematic diagram of an example subset of intra-prediction modes. [Figure 1B] FIG. 1 is an illustration of an exemplary intra-prediction direction. [Figure 2] FIG. 1 is a schematic diagram of a current block and its surrounding spatial merge candidates in one example. [Figure 3]1 is a schematic block diagram of a communication system (300) according to an embodiment. [Figure 4] 4 is a schematic block diagram of a communication system (400) according to an embodiment. [Figure 5] FIG. 2 is a schematic block diagram of a decoder according to an embodiment. [Figure 6] FIG. 2 is a schematic block diagram of an encoder according to an embodiment. [Figure 7] 10 shows a block diagram of an encoder according to another embodiment. [Figure 8] 10 shows a block diagram of a decoder according to another embodiment. [Figure 9A] A CTU partitioned by a quadtree plus binary tree (QTBT) structure (910) is shown. [Figure 9B] The QTBT structure (920) is shown. [Figure 9C] Shown is a horizontal center-side ternary tree. [Figure 9D] Shows a vertical center-side ternary tree. [Figure 10A] 1 shows the transform core matrix of the 4-point DCT-2 transform. [Figure 10B] 1 shows the transform core matrix of the 8-point DCT-2 transform. [Figure 10C] The transform core matrix of the 16-point DCT-2 transform is shown below. [Figure 10D] The transform core matrix of the 32-point DCT-2 transform is shown below. [Figure 11A] The 64x64 transform core matrix of the 64-point DCT-2 transform is shown. [Figure 11B] Continuing from FIG. 11A. [Figure 11C] Continuation from FIG. 11B. [Figure 11D] Continuing from FIG. 11C. [Figure 11E] Continuation from FIG. 11D. [Figure 12] The transform basis functions of selected discrete sine transform (DST) / discrete cosine transform (DCT) of adaptive multi-transform (AMT) are shown. [Figure 13]A table (1300) showing the mapping relationship between mts_idx values ​​and each horizontal or vertical transform is shown. [Figure 14A] The transform core matrix for the 4-point DST-7 transform is shown below. [Figure 14B] The transform core matrix for the 8-point DST-7 transform is shown below. [Figure 14C] The transform core matrix for the 16-point DST-7 transform is shown below. [Figure 14D] The transform core matrix for the 32-point DST-7 transform is shown below. [Figure 15A] 4 shows the transform core matrix of the 4-point DCT-8 transform. [Figure 15B] Transform core matrix of 8-point DCT-8 transform is shown. [Figure 15C] The transform core matrix of the 16-point DCT-8 transform is shown below. [Figure 15D] The transform core matrix of the 32-point DCT-8 transform is shown below. [Figure 16] Indicates the number of subpartitions depending on the block size. [Figure 17] An example of an intra-subpartition (ISP) is shown below. [Figure 18] Here is an example of an ISP: [Figure 19A] An example of a syntax element (1900) for the ISP coding mode is shown below. [Figure 19B] Continuing from FIG. 19A. [Figure 20A] An example of sub-block transform (SBT) is shown below. [Figure 20B] An example of sub-block transform (SBT) is shown below. [Figure 20C] An example of sub-block transform (SBT) is shown below. [Figure 20D] An example of sub-block transform (SBT) is shown below. [Figure 21A] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21B] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21C]Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21D] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21E] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21F] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21G] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21H] Here is an example of the specification text of a video coding standard when SBT is used: [Figure 21I] Continuation from FIG. 21H. [Figure 22] 1 illustrates various YUV formats used in some embodiments. [Figure 23] Examples of ternary tree (TT) and binary tree (BT) partitioning that are not allowed are given below. [Figure 24] An example of the transformation tree syntax is shown below. [Figure 25] A coding block (2510) with a size of 128x64 samples is shown. [Figure 26A] A coding block (2610A) having a size of 128x32 samples is shown. [Figure 26B] A coding block (2610B) having a size of 128x32 samples is shown. [Figure 27] 27 shows a flowchart illustrating a process (2700) according to an embodiment of the disclosure. [Figure 28] FIG. 1 is a schematic diagram of a computer system according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0030] I. Video Coding Encoders and Decoders Figure 3 illustrates a simplified block diagram of a communication system (300) according to an embodiment of the present disclosure. The communication system (300) includes multiple terminal devices that can communicate with each other, e.g., via a network (350). For example, the communication system (300) includes a first pair of terminal devices (310) and (320) interconnected via the network (350). In Figure 3, the first pair of terminal devices (310) and (320) perform unidirectional transmission of data. For example, the terminal device (310) may code video data (e.g., a stream of video data captured by the terminal device (310)) for transmission to another terminal device (320) via the network (350). The encoded video data may be transmitted in the form of one or more coded video bitstreams. The terminal device (320) may receive the coded video data from the network (350), decode the coded video data to recover video pictures, and display the video pictures according to the recovered video data. One-way data transmission may be common in media serving applications, etc.

[0031] In another example, the communication system 300 includes a second pair of terminal devices 330 and 340 that perform bidirectional transmission of coded video data, such as may occur during a video conference. For the bidirectional transmission of data, in the example, each of the terminal devices 330 and 340 may code video data (e.g., a stream of video pictures captured by that terminal device) for transmission to the other of the terminal devices 330 and 340 over the network 350. Each of the terminal devices 330 and 340 may also receive coded video data transmitted by the other of the terminal devices 330 and 340, decode the coded video data to recover video pictures, and display the video pictures on an accessible display device in accordance with the recovered video data.

[0032] In the example of FIG. 3 , terminal devices 310, 320, 330, and 340 may be represented as a server, a personal computer, and a smartphone, although the principles of the present disclosure may not be so limited. Embodiments of the present disclosure find use with laptop computers, tablet computers, media players, and / or dedicated videoconferencing equipment. Network 350 represents any number of networks that convey coded video data between terminal devices 310, 320, 330, and 340, including, for example, wireline and / or wireless communication networks. Communication network 350 may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this discussion, the architecture and topology of network 350 may be irrelevant to the operation of the present disclosure, unless otherwise described below.

[0033] 4 illustrates the placement of a video encoder and a video decoder in a streaming environment as an example application of the disclosed subject matter, which may be similarly applicable to other video-enabled applications including, for example, video conferencing, digital TV, storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0034] The streaming system may include a capture subsystem (413) that may include, for example, a video source (401), such as a digital camera, that generates a stream of uncompressed video pictures (402). In the example, the stream of video pictures (402) includes samples captured by the digital camera. The stream of video pictures (402) is represented by a bold line to emphasize its high data volume compared to the encoded video data (404) (or coded video bitstream) and may be processed by an electronic device (420) that includes a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter, as described in more detail below. The encoded video data (404) (or coded video bitstream (404)), represented by a thin line to emphasize its lower data volume compared to the stream of video pictures (402), may be stored on a streaming server (405) for future use. One or more streaming client subsystems, such as the client subsystems (406) and (408) of Figure 4, can access the streaming server (405) to retrieve copies (407) and (409) of the encoded video data (404). The client subsystem (406) can include a video decoder (410), for example, in an electronic device (430). The video decoder (410) decodes the incoming copy of the encoded video data (407) and generates an outgoing stream of video pictures (411) that can be rendered on a display (412) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (404), (407), and (409) (e.g., a video bitstream) can be encoded according to a particular video coding / compression standard.An example of such a standard is ITU-T Recommendation H.265. In an example, the video coding standard under development is colloquially known as Versatile Video Coding (VVC). The disclosed subject matter may be used in connection with VVC.

[0035] It is noted that electronic devices 420 and 430 can include other components (not shown). For example, electronic device 420 can include a video decoder (not shown), and electronic device 430 can also include a video encoder (not shown).

[0036] 5 shows a block diagram of a video decoder (510) according to an embodiment of the present disclosure. The video decoder (510) may be included in an electronic device (530). The electronic device (530) may include a receiver (531) (e.g., receiving circuitry). The video decoder (510) may be used in place of the video decoder (410) in the example of FIG. 4.

[0037] The receiver (531) may receive one or more coded video sequences to be decoded by the video decoder (510), one coded video sequence at a time, in the same or another embodiment, where decoding of each coded video sequence is independent of other coded video sequences. The coded video sequences may be received from a channel (501), which may be a hardware / software link to a storage device storing the encoded video data. The receiver (531) may receive the encoded video data along with other data, such as coded audio data and / or auxiliary data streams, which may be forwarded to their respective using entities (not shown). The receiver (531) may separate the coded video sequences from other data. To combat network jitter, a buffer memory (515) may be coupled between the receiver (531) and the entropy decoder / parser (520) (hereinafter "parser (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). In others, it can be external to the video decoder (510) (not shown). In still other applications, there can be a buffer memory (not shown) external to the video decoder (510), for example, to combat network jitter, plus another buffer memory (515) within the video decoder (510), for example, to manipulate playback timing. When the receiver (531) is receiving data from a storage / forwarding device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (515) may not be required or may be small. For use with best-effort packet networks such as the Internet, the buffer memory (515) may be required, but can be relatively large and advantageously adaptively sized, and may be implemented at least in part in an operating system or similar element (not shown) external to the video decoder (510).

[0038] The video decoder (510) may include a parser (520) for reconstructing symbols (521) from the coded video sequence. These symbol categories include information used to manage the operation of the video decoder (510) and, potentially, information for controlling a rendering device, such as a render device (512) (e.g., a display screen) that is not an essential part of the electronic device (530) but may be coupled to the electronic device (530) as shown in FIG. 5. Control information for the rendering device may take the form of a Supplementary Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). The parser (520) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow a video coding technique or standard and may follow various principles, including variable length coding, Huffman coding, context-dependent or non-context-dependent arithmetic coding, etc. The parser (520) may extract from the coded video sequence a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder based on at least one parameter corresponding to the group. The subgroup may include a group of pictures (GOP), a picture, a tile, a slice, a macroblock, a coding unit (CU), a block, a transform unit (TU), a prediction unit (PU), etc. The parser (520) may also extract quantization parameter values, motion vectors, etc. from coded video sequence information such as transform coefficients.

[0039] The parser (520) may perform entropy decoding / parsing operations on the video sequence received from the buffer memory (515) to generate symbols (521).

[0040] The reconstruction of the symbols (521) can have a wide variety of units depending on the type of coded video picture or portion thereof (e.g., inter and intra pictures, inter and intra blocks) and other factors. Which units are included and how may be controlled by subgroup control information parsed by the parser (520) from the coded video sequence. The flow of such subgroup control information between the parser (520) and the following units is not shown for clarity.

[0041] Beyond the functional blocks already described, the video decoder (510) may be conceptually subdivided into a number of functional units, which are described below. In an actual implementation operating under commercial constraints, many of these units may interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the following conceptual subdivision into functional units is appropriate.

[0042] The first unit is a scalar / inverse transform unit (551), which receives quantized transform coefficients as symbols (521) from the parser (520), along with control information including the transform to use, block size, quantization coefficients, quantization scaling matrix, etc. The scalar / inverse transform unit (551) can output blocks containing sample values ​​that can be input to an aggregator (555).

[0043] In some cases, the output samples of the scaler / inverse transformer (551) may relate to intra-coded blocks, i.e., blocks that do not use prediction information from a previously reconstructed picture but can use prediction information from a previously reconstructed portion of the current picture. Such prediction information may be provided by an intra-picture prediction unit (552). In some cases, the intra-picture prediction unit (552) generates a block of the same size and shape as the block being reconstructed using surrounding, already reconstructed information fetched from a current picture buffer (558). The current picture buffer (558), for example, buffers a partially reconstructed and / or fully reconstructed current picture. The aggregator (555) may, in some cases, add, on a sample-by-sample basis, the prediction information generated by the intra-prediction unit (552) to the output sample information provided by the scaler / inverse transformer unit (551).

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

[0045] The output samples of the aggregator (555) can be subjected to various loop filtering techniques in a loop filter unit (556). Video compression techniques can include in-loop filter techniques that are controlled by parameters contained in the coded video sequence (also called the coded video bitstream) and made available to the loop filter unit (556) as symbols (521) from the parser (520), but can also respond to meta-information obtained during decoding of previous portions (in decoding order) of the coded picture or coded video sequence, and can also respond to previously constructed loop-filtered sample values.

[0046] The output of the loop filter unit (556) can be a sample stream that can be output to a render device (512) and further stored in a reference picture memory (557) for use in future inter-picture prediction.

[0047] Once a particular coded picture is fully reconstructed, it can be used as a reference picture for future prediction. For example, once a coded picture corresponding to a current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) can become part of the reference picture memory (557), and any unused current picture buffer can be reallocated before beginning reconstruction of a subsequent coded picture.

[0048] The video decoder (510) may perform decoding operations according to a predetermined video compression technique in a standard, such as ITU-T Recommendation H.265. A coded video sequence may conform to the syntax prescribed by the video compression technique or standard in use, in the sense that the coded video sequence conforms to both the syntax of the video compression technique or standard and a profile documented in the video compression technique or standard. Specifically, a profile may select a particular tool from all tools available in the video compression technique or standard as the optimal tool available for use under that profile. Compliance also requires that the complexity of the coded video sequence be within the boundaries defined by the level of the video compression technique or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may, in some cases, be further constrained through a Hypothetical Reference Decoder (HRD) specification and metadata for HRD buffer management signaled in the coded video sequence.

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

[0050] 6 shows a block diagram of a video encoder (603) according to an embodiment of the present disclosure. The video encoder (603) is included in an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmitting circuit). The video encoder (603) may be used in place of the video encoder (403) of the example of FIG. 4.

[0051] The video encoder (603) may receive video samples from a video source (601) (which is not part of the electronic device (620) in the example of FIG. 6) that may capture video images to be coded by the video encoder (603). In other examples, the video source (601) is part of the electronic device (620).

[0052] The video source (601) may provide a source video sequence to be coded by the video encoder (603) in the form of a digital video sample stream, which can be of any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, etc.), any color space (e.g., BT.601 YCrCB, RGB, etc.), and any suitable sampling structure (e.g., YCrCb 4:2:0, YCrCb 4:4:4). In a media serving system, the video source (601) may be a storage device storing previously prepared video. In a video conferencing system, the video source (601) may be a camera capturing local image information as a video sequence. Video data may be provided as multiple individual pictures that, when viewed in sequence, impart motion. The pictures themselves may be organized as a spatial array of pixels, each of which may have one or more samples depending on the sampling structure, color space, etc., in use. Those skilled in the art will readily understand the relationship between pixels and samples. This specification will focus on samples hereafter.

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

[0054] In some embodiments, the video encoder (603) is configured to operate in a coding loop. As an overly simplified description, in an example, the coding loop can include a source coder (630) (e.g., responsible for generating symbols, such as a symbol stream, based on an input picture to be coded and a reference picture) and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to generate sample data in a manner similar to what a (remote) decoder would generate (given that any compression between the symbols and the coded video stream is lossless in the video compression techniques contemplated by the disclosed subject matter). The reconstructed sample stream (sample data) is input to a reference picture memory (634). Because decoding of the symbol stream yields bit-exact results independent of the location (local or remote) of the decoder, the contents of the reference picture memory (634) are also bit-perfect between the local and remote encoders. That is, the prediction part of the encoder "sees" as reference picture samples exactly the same sample values ​​that the decoder will "see" when using the prediction during decoding. This basic principle of reference picture synchronicity (and the resulting drift when synchronicity cannot be maintained, e.g., due to channel errors) is also used in several related technologies.

[0055] The operation of the "local" decoder (633) can be the same as a "remote" decoder, such as the video decoder (510), already described in detail above in conjunction with Figure 5. Referring also momentarily to Figure 5, however, the entropy decoding portion of the video decoder (510), including the buffer memory (515) and parser (520), may not be fully implemented in the local decoder (633), given the availability of symbols and the encoding / decoding of symbols into a coded video sequence by the entropy coder (645) and parser (520) can be lossless.

[0056] An observation that can be made at this point is that any decoder techniques, other than parsing / entropy decoding, that are present in a decoder do not necessarily need to be present in substantially the same functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on the operation of the decoder. Descriptions of encoder techniques may be omitted, as they are the inverse of the decoder techniques that are described generically. Only to certain extents are more detailed descriptions required, which are provided below.

[0057] In operation, the source coder (630) may perform motion-compensated predictive coding, which predictively codes an input picture with reference to one or more previously coded pictures from the video sequence designated as "reference pictures." In this manner, the coding engine (632) codes differences between pixel blocks of the input picture and pixel blocks of the reference pictures that may be selected as predictive references for the input picture.

[0058] The local video decoder (633) may decode coded video data of pictures that may be designated as reference pictures based on symbols generated by the source coder (630). The operation of the coding engine (632) may advantageously be a lossy process. When the coded video data is decoded by a video decoder (not shown in FIG. 6), the reconstructed video sequence may typically be a copy of the source video sequence, with some errors. The local video decoder (633) may replicate the decoding process that may be performed by the video decoder on the reference pictures, causing the reconstructed reference pictures to be stored in a reference picture cache (634). In this way, the video encoder (603) may locally store copies of reconstructed reference pictures that have content in common with reconstructed reference pictures that would be obtained by a far-end video decoder (without transmission errors).

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

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

[0061] The output of all of the above functional units may undergo entropy coding in an entropy coder (645), which converts the symbols produced by the various functional units into a coded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable length coding, or arithmetic coding.

[0062] The transmitter (640) may buffer the coded video sequence produced by the entropy coder (645) to prepare it for transmission over a communication channel (660), which may be a hardware / software link to a storage device that stores the encoded video data. The transmitter (640) may merge the coded video data from the video coder (603) with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown).

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

[0064] An Intra Picture (I-picture) may be a picture that can be coded and decoded without using any other picture in a sequence as a source of prediction. Some video codecs allow various types of Intra pictures, including, for example, Independent Decoder Refresh (IDR) pictures. Those skilled in the art are aware of such variations of I-pictures and their respective applications and characteristics.

[0065] A Predictive Picture (P-picture) may be a picture that can be coded and decoded by intra-prediction or inter-prediction using at most one motion vector and reference index to predict the sample values ​​of each block.

[0066] A Bi-directionally Predictive Picture (B-picture) may be a picture that can be coded and decoded by intra- or inter-prediction using at most two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple-predictive pictures can use more than two reference pictures and associated metadata for the reconstruction of a single block.

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

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

[0069] In embodiments, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include such data as part of the coded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other types of redundant data such as redundant pictures and slices, SEI messages or VUI parameter set fragments, etc.

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

[0071] In some embodiments, bi-prediction techniques may be used in inter-picture prediction. According to bi-prediction techniques, two reference pictures are used, e.g., a first reference picture and a second reference picture, both of which precede the current picture in decoding order (but may be past and future, respectively, in display order) in the video. A block in the current picture may be coded with a first motion vector that points to a first reference block in the first reference picture and a second motion vector that points to a second reference block in the second reference picture. The block is predictable by a combination of the first and second reference blocks.

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

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

[0074] 7 shows a diagram of a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) may be configured to receive a processed block of sample values ​​(e.g., a predictive block) in a current video picture included in a sequence of video pictures and encode the processed block into a coded picture that is part of a coded video sequence. In an example, the video encoder (703) is used in place of the video encoder (403) of the example of FIG. 4.

[0075] In an HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as a prediction block of 8x8 samples. The video encoder (703) determines, for example, using rate-distortion optimization, whether the processing block is best coded in intra-mode, inter-mode, or bi-prediction mode. If the processing block is to be coded in intra-mode, the video encoder (703) may use intra-prediction techniques to encode the processing block into a coded picture; if the processing block is to be coded in inter-mode or bi-prediction mode, the video encoder (703) may use inter-prediction or bi-prediction techniques, respectively, to encode the processing block into a coded picture. In certain video coding techniques, the merge mode can be an inter-picture prediction sub-mode in which a motion vector is derived from one or more motion vector predictors without the benefit of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the current block. In examples, the video encoder (703) includes other components, such as a mode decision module (not shown) that determines the mode of the processing blocks.

[0076] In the example of Figure 7, the video encoder (703) includes an inter-encoder (730), an intra-encoder (722), a residual calculation unit (723), a switch (726), a residual encoder (724), a general controller (721), and an entropy encoder (725), coupled as shown in Figure 7.

[0077] The inter-encoder (730) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks in a reference picture (e.g., blocks in a previous picture and a subsequent picture), generate inter-prediction information (e.g., a description of residual information according to an inter-encoding technique, motion vectors, merge mode information), and calculate an inter-prediction result (e.g., a prediction block) based on the inter-prediction information using any suitable technique. In some examples, the reference picture is a decoded reference picture that is being decoded based on encoded video information.

[0078] The intra encoder (722) is configured to receive samples of a current block (e.g., a processing block), in some cases compare the block to previously coded blocks in the same picture, and generate transformed quantized coefficients and, in some cases, intra prediction information (e.g., intra prediction direction information according to one or more intra encoding techniques). In examples, the intra encoder (722) also calculates intra prediction results (e.g., prediction blocks) based on the intra prediction information and reference blocks in the same picture.

[0079] The general-purpose controller (721) is configured to determine general-purpose control data and control other components of the video encoder (703) based on the general-purpose control data. In an example, the general-purpose controller (721) determines the mode of the block and provides a control signal to the switch (726) based on the mode. For example, if the mode is intra mode, the general-purpose controller (721) controls the switch (726) to select intra-mode results for use by the residual calculator (723) and controls the entropy encoder (725) to select intra-prediction information and include the intra-prediction information in the bitstream. If the mode is inter mode, the general-purpose controller (721) controls the switch (726) to select inter-prediction results for use by the residual calculator (723) and controls the entropy encoder (725) to select inter-prediction information and include the inter-prediction information in the bitstream.

[0080] The residual calculation unit (723) is configured to calculate the difference (residual data) between the received block and a prediction result selected from the intra-encoder (722) or the inter-encoder (730). The residual encoder (724) is configured to operate on the residual data to encode the residual data to generate transform coefficients. In an example, the residual encoder (724) is configured to transform the residual data from the spatial domain to the frequency domain to generate transform coefficients. The transform coefficients then undergo a quantization process to obtain quantized transform coefficients. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data can be used by the intra-encoder (722) and the inter-encoder (730) as appropriate. For example, the inter-encoder (730) can generate decoded blocks based on the decoded residual data and inter-prediction information, and the intra-encoder (722) can generate decoded blocks based on the decoded residual data and intra-prediction information. The decoded blocks are processed appropriately to generate decoded pictures, which can be buffered in a memory circuit (not shown) and used as reference pictures in some examples.

[0081] The entropy encoder (725) is configured to format the bitstream to include the encoded block. The entropy encoder (725) is configured to include various information in accordance with an appropriate standard, such as the HEVC standard. In an example, the entropy encoder (725) is configured to include general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information in the bitstream. Note that, in accordance with the disclosed subject matter, when coding a block in a merged sub-mode of either an inter mode or a bi-prediction mode, the residual information is not present.

[0082] 8 shows a diagram of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is configured to receive coded pictures that are part of a coded video sequence and decode the coded pictures to generate reconstructed pictures. In an example, the video decoder (810) is used in place of the video decoder (410) of the example of FIG. 4.

[0083] In the example of Figure 8, the video decoder (810) includes an entropy decoder (871), an inter-decoder (880), a residual decoder (873), a reconstruction module (874), and an intra-decoder (872), coupled as shown in Figure 8.

[0084] The entropy decoder (871) may be configured to reconstruct, from a coded picture, specific symbols representing syntax elements from which the coded picture is constructed. Such symbols may include, for example, prediction information (e.g., intra-prediction information or inter-prediction information) that can identify the mode in which the block is coded (e.g., intra-mode, or inter-mode or bi-prediction mode in merged or other submodes), specific samples or metadata used for prediction by the intra decoder (872) or inter decoder (880), respectively, residual information in the form of, for example, quantized transform coefficients, etc. In an example, if the prediction mode is an inter- or bi-prediction mode, the inter-prediction information is provided to the inter decoder (880), and if the prediction type is an intra-prediction type, the intra-prediction information is provided to the intra decoder (872). The residual information may undergo inverse quantization and be provided to the residual decoder (873).

[0085] The inter decoder (880) is configured to receive the inter prediction information and generate an inter prediction result based on the inter prediction information.

[0086] The intra decoder (872) is configured to receive the intra prediction information and generate a prediction result based on the intra prediction information.

[0087] The residual decoder (873) is configured to perform inverse quantization to retrieve dequantized transform coefficients and process the dequantized transform coefficients to transform the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require certain control information (to include quantization parameters (QPs)), which may be provided by the entropy decoder (871) (datapath not shown as this is only low-volume control information).

[0088] The reconstruction module (874) is configured to combine the residual output by the residual decoder (873) and the prediction result (possibly output by an inter- or intra-prediction module) in the spatial domain to form a reconstructed block. The reconstructed block may be part of a reconstructed picture, which in turn may be part of a reconstructed video. It is noted that other appropriate operations, such as a deblocking operation, may be performed to improve visual quality.

[0089] It is understood that the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using any suitable technology. In some embodiments, the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using one or more integrated circuits. In other embodiments, the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using one or more processors executing software instructions.

[0090] [II. Conversion Processing Technology] [1. Block partitioning structures including quad-tree partitioning] The block partitioning structure may be called a coding tree. In some embodiments, by using a quadtree structure, a coding tree unit (CTU) is divided into coding units (CUs) to adapt to various local characteristics. The discussion on whether to code a picture area using inter-picture (temporal) or intra-picture (spatial) prediction is made at the CU level. Each CU may be further divided into one, two, or four prediction units (PUs) according to the PU partition type. Within one PU, the same prediction process is applied, and related information is sent to the decoder on a PU-by-PU basis.

[0091] After obtaining the residual block by applying a prediction process based on the PU partition type, the CU may be divided into transform units (TUs) according to another quad-tree structure. Obviously, there are many partition concepts, including CU, PU, ​​and TU. In some embodiments, a CU or TU can only be square-shaped, while a PU can be square or rectangular-shaped. In some embodiments, one coding block may be further divided into four square sub-blocks, and a transform is performed on each block, i.e., a TU. Each TU may be further divided recursively into smaller TUs using a quad-tree structure called a Residual Quad-Tree (RQT).

[0092] At picture boundaries, in some embodiments, implicit quadtree partitioning may be used, whereby blocks continue to be quadtree partitioned until their size fits the picture boundary.

[0093] 2. Quad-tree plus binary tree (QTBT) block partitioning structure In some embodiments, a Quad-Tree plus Binary Tree (QTBT) structure is used. The QTBT structure removes the concept of multiple partition types (CT, PU, ​​and TU concepts) and supports more flexibility for CU partition shapes. In the QTBT block structure, CUs can have either square or rectangular shapes.

[0094] Figure 9A shows a CTU (910) that is partitioned using the QTBT structure (920) shown in Figure 9B. The CTU (910) is first partitioned using a quadtree structure. The quadtree leaf nodes are further partitioned using a binary tree structure or a quadtree structure. There are two types of binary tree partitioning: symmetric horizontal partitioning and symmetric vertical partitioning. The binary tree leaf nodes are called CUs, which can be used for prediction and transform processing without further partitioning. Therefore, CUs, PUs, and TUs have the same block size in the QTBT coding block structure.

[0095] In some embodiments, a CU may include coding blocks (CBs) of different color components. For example, one CU may include one luma CB and two chroma CBs for P and B slices in 4:2:0 chroma format. A CU may include a CB of a single color component. For example, one CU may include only one luma CB or only two chroma CBs for an I slice.

[0096] The following parameters are defined for the QTBT partitioning scheme in some embodiments: CTUsize: The root node size of the quadtree, e.g. the same concept as seen in HEVC. · MinQTSize: The minimum allowed quadtree leaf node size. · MaxBTSize: Maximum allowed binary tree root node size. · MaxBTDepth: Maximum allowed binary tree depth. ·MinBTSize: The minimum allowed binary tree leaf node size.

[0097] In one example of a QTBT partitioning structure, CTUsize is set as 128x128 luma samples along with two corresponding 64x64 blocks of chroma samples, and MinQTSize is set as 16x16. MaxBTSize is set as 64x64, MinBTSize (for both width and height) is set as 4x4, and MaxBTDepth is set as 4. Quad-tree partitioning is first applied to the CTU to generate quad-tree leaf nodes. The quad-tree leaf nodes can have sizes from 16x16 (i.e., MinQTSize) to 128x128 (i.e., CTUsize). If the quad-tree leaf node is 128x128, it will not be further split by the binary tree because its size exceeds MaxBTSize (i.e., 64x64). Otherwise, the quad-tree leaf node may be further split by the binary tree. Therefore, a quadtree leaf node is also the root node for the binary tree, which has a binary tree depth of 0.

[0098] When the binary tree depth reaches MaxBTSize (i.e., 4), no further splits are considered. If a binary tree node has a width equal to MinBTSize (i.e., 4), no further horizontal splits are considered. Similarly, if a binary tree node has a height equal to MinBTSize, no further vertical splits are considered. Leaf nodes of the binary tree are further processed by the prediction and transform process without further splits. In an embodiment, the maximum CTU size is 256x256 luma samples.

[0099] 9A and 9B, solid lines indicate quadtree partitioning, and dashed lines indicate binary tree partitioning. At each partition (i.e., non-leaf) node of the binary tree, a flag is signaled to indicate which partition type (i.e., horizontal or vertical) is used. For example, 0 indicates horizontal partitioning, and 1 indicates vertical partitioning. For quadtree partitioning, there is no need to indicate the partition type because quadtree partitioning always divides a block both horizontally and vertically to generate four sub-blocks of equal size.

[0100] In some embodiments, the QTBT scheme supports the flexibility for luma and chroma to have separate QTBT structures. For example, for P and B slices, the luma and chroma blocks in one CTU share the same QTBT structure. However, for an I slice, the luma CTU is divided into CUs by a QTBT structure, and the chroma blocks are divided into chroma CUs by another QTBT structure. Thus, a CU in an I slice consists of a coding block of a luma component or a coding block of two chroma components, and a CU in a P or B slice consists of coding blocks of all three color components.

[0101] In some embodiments, inter prediction for small blocks is limited to reduce motion compensation memory accesses, e.g., bi-prediction is not supported for 4x8 and 8x4 blocks, and inter prediction is not supported for 4x4 blocks.

[0102] [3. Ternary Tree (TT) Block Partitioning Structure] In some embodiments, a Multi-Type-Tree (MTT) structure is used to partition pictures. The MTT structure is a more flexible tree structure than the QTBT structure. In addition to quadtrees and binary trees, MTT uses horizontal center-side ternary trees and vertical center-side ternary trees, as shown in Figures 9C and 9D, respectively. Ternary tree partitioning can complement quadtree and binary tree partitioning. For example, ternary tree partitioning can capture objects located at block centers, while quadtrees and binary trees can partition across block centers. The width and height of ternary tree partitions are powers of two, so no additional transform partitions are required.

[0103] In the example, the design of the two-level tree is primarily motivated by reduced complexity. For example, the complexity of traversing the tree is T D where T represents the number of split types and D is the depth of the tree.

[0104] [4. Example of linear transformation] In some embodiments, for example, as found in HEVC, 4-point, 8-point, 16-point, and 32-point DCT-2 transforms are used as primary transforms. Figures 10A-10D show the transform core matrices of the 4-point, 8-point, 16-point, and 32-point DCT-2, respectively. The elements of these transform core matrices are representable using 8-bit integers, and thus these transform core matrices are referred to as 8-bit transform cores. As shown, the transform core matrix of the smaller DCT-2 is a fraction of that of the larger DCT-2.

[0105] The DCT-2 core matrix exhibits symmetric / antisymmetric characteristics. Therefore, a so-called "partial butterfly" implementation can be supported to reduce the number of operation counts (multiplications, additions / subtractions, shifts). The same result of a matrix multiplication can be obtained using a partial butterfly implementation.

[0106] [5. Further examples of linear transformations] In some embodiments, in addition to the 4-point, 8-point, 16-point, and 32-point DCT-2 transforms described above, additional 2-point and 64-point DCT-2 transforms are used. Figures 11A-11E show the 64x64 transform core matrix for a 64-point DCT-2 transform.

[0107] In some embodiments, in addition to the DCT-2 and 4x4 DST-7 transforms, the Adaptive Multiple Transform (AMT) (also known as the Enhanced Multiple Transform (EMT) or Multiple Transform Selection (MTS)) is used for residual coding of both inter- and inter-coded blocks. The AMT uses the transform core matrices of multiple selected transforms from the Discrete Cosine Transform (DCT) / Discrete Sine Transform (DST) family, e.g., the DS-7 or DCT-8 transform, in addition to the DCT-2 transform. Figure 12 shows the transform basis functions of selected DST / DCT transforms.

[0108] In some embodiments, the DST / DCT transform core matrix used in AMT is represented in 8-bit representation. In some embodiments, AMT is applied to CUs whose width and height are both less than or equal to 32. Whether AMT should be applied may be controlled by a flag (e.g., mts_flag). For example, when mts_flag is equal to 0, only DCT-2 is applied to code the residual block. When mts_flag is equal to 1, an index (e.g., mts_idx) may be further signaled using two bins to specify the horizontal and vertical transform to be used.

[0109] FIG. 13 shows a table (1300) that represents the mapping relationship between the value of the index (e.g., mts_idx) and each horizontal or vertical transform. The row (1301) where the value of mts_idx is -1 corresponds to a scenario where the flag (e.g., mts_flag) is equal to 0, and the DCT-2 transform is used. The rows (1302) to (1305) where the value of mts_idx is 0, 1, 2, or 3 correspond to a scenario where mts_flag is equal to 1. In the right two columns of the table (1300), 0 represents the transform type of DCT-2, 1 represents the transform type of DCT-7, and 2 represents the transform type of DCT-8.

[0110] 14A to 14D show the transform core matrix of the DST-7 transform, and 15A to 15D show the transform core matrix of the DCT-8.

[0111] [6. Intra-Subpartition (ISP) Coding Mode] In some embodiments, an Intra Sub-Partition (ISP) coding mode is used. In the ISP coding mode, a luma intra-prediction block may be divided into two or four sub-partitions vertically or horizontally. The number of sub-partitions may depend on the size of the block. Figure 16 shows the number of sub-partitions depending on the block size. Figure 17 shows an example in which a 4x8 or 8x4 block is divided into two sub-partitions. Figure 18 shows an example in which a block with a size larger than 4x8 or 8x4 is divided into four sub-partitions. In the example, all sub-partitions satisfy the condition that they have at least 16 samples. In the example, ISP is not applied to the chroma components.

[0112] In an example, for each subpartition divided from a coding block, a residual signal is generated by entropy decoding each coefficient sent from the encoder, then inverse quantizing and inverse transforming them. A first subpartition among the subpartitions is then intra-predicted to generate a prediction signal. The prediction signal is added to each residual signal of the first subpartition to obtain a corresponding reconstructed sample. The reconstructed sample values ​​of the first subpartition can then be used to generate a prediction for a second subpartition among the subpartitions. This process can be repeated subpartition by subpartition until all subpartitions from the coding block are reconstructed. In an example, all subpartitions share the same intra-mode.

[0113] In an embodiment, the ISP coding modes are only tested by the intra modes that are part of the Most Probable Mode (MPM) list. Therefore, if a block uses an ISP, the MPM flag can be inferred to be 1. Furthermore, when an ISP is used for a particular block, then the respective MPM lists will be modified to prioritize horizontal intra modes for ISP horizontal splitting and vertical intra modes for ISP vertical splitting, except for DC mode.

[0114] In the ISP coding mode, each subpartition can be considered as a TU, since the transformation and reconstruction are performed separately for each subpartition.

[0115] 19A-19B show examples of syntax elements (1900) signaled for ISP coding mode. As shown in box (1910), a syntax element, such as intra_subpartitions_mode_flag, indicates whether ISP is used. A syntax element, such as intra_subpartitions_split_flag, indicates the partition direction (vertical or horizontal).

[0116] [7. Sub-Block Transform (SBT)] In some embodiments, a Sub-Block Transform (SBT), also known as a Spatially Varying Transform (SVT), is used. The SBT may be applied to inter-prediction residuals. In some examples, the residual block is contained in a coding block and is smaller than the coding block. Thus, the transform size in the SBT is smaller than the coding block size. For areas not covered by the residual block, a zero residual may be assumed, and thus no transform processing is performed.

[0117] 20A-20D show the sub-block types (SVT-H, SVT-V) (e.g., horizontal or vertical split), sizes, and partitions (e.g., left half, left quarter, right half, right quarter, top half, top quarter, bottom half, bottom quarter) supported by SBT. The shaded areas denoted by letter "A" are residual blocks with transform, and the remaining areas are assumed to be zero residual without transform.

[0118] 21A-21I show, as an example, changes to the specification text of a video coding standard (e.g., VVC) when SBT is used. The added text is shown in boxes (2101) through (2113). As shown, additional syntax elements, such as additional overhead bits cu_sbt_flag, cu_sbt_quad_flag, cu_sbt_horizontal_flag, and cu_sbt_pos_flag, may be signaled to indicate the sub-block type (horizontal or vertical), size (half or quarter), and position (left, right, top, or bottom), respectively.

[0119] [8. YUV Format] FIG. 22 illustrates various YUV formats (e.g., 4:4:4, 4:2:2, 4:1:1, and 4:2:0) used in some embodiments. In an example, cross-component linear model intra prediction is used for the 4:2:0 format. A 6-tap interpolation filter may be applied to the downsampled luma samples corresponding to the chroma samples, as shown in FIG. 22. In an example, the downsampled luma samples Rec'L[x,y] are interpolated by the nearest reconstructed luma samples (Rec'L[x,y]) as follows: L [x,y].) can be calculated from:

number

[0120] 9. Virtual Pipeline Data Unit (VPDU) Virtual Pipeline Data Units (VPDUs) may be defined as non-overlapping MxM-Luma (L) / NxN-Chroma (C) units within a picture. In some hardware decoder implementations, consecutive VPDUs are processed simultaneously by multiple pipeline stages. Different stages process different VPDUs simultaneously. The VPDU size may be roughly proportional to the buffer size in the pipeline stages, so it is desirable to keep the VPDUs to a specific size (e.g., 64x64 or less). In certain decoders, the VPDU size is set to the maximum transform unit (TU) size. Widening the maximum TU size from 32x32-L / 16x16-C in HEVC to 64x64-L / 32x32-C in the current VVC can result in coding gains, which is expected to quadruple the VPDU size compared to HEVC. However, to achieve further coding gain, the BT and TT structures adopted in VVC can be recursively applied to the 128x128-L / 64x64-C coding tree block, resulting in a 16x larger VPDU size (128x128-L / 64x64-C) compared to HEVC.

[0121] FIG. 23 shows the specific TT and BT partitioning that is not recognized.

[0122] To keep the VPDU size at 64x64 luma samples, certain partition restrictions (with syntax signaling changes) are applied in some embodiments: · TT division is not allowed for CUs with either width or height, or both width and height, equal to 128. For 128×N CUs (width equal to 128 and height less than 128) with N≦64, horizontal BT is not allowed. · For N×128 CUs (height equal to 128 and width less than 128) where N≦64, vertical BT is not allowed.

[0123] III. Transform Block Partitioning and Processing Techniques In some embodiments, a fixed maximum allowable transform unit (TU) size or maximum TU size (e.g., 64x64 pixels or samples) is used. In some embodiments, a controllable or configurable maximum TU size is used because the maximum TU size can affect the hardware complexity (e.g., pipeline intermediate buffer size, number of multipliers, etc.), for example, for an encoder implementation. For example, in addition to a size of 64x64 samples, the maximum TU size can be other sizes, such as 32x32 samples, 16x16 samples, etc.

[0124] In a particular video standard, SBT and ISP may be used. For example, in SBT, an SPS flag, e.g., sps_sbt_max_size_64_flag, is signaled to indicate whether the maximum SBT size is 32 points or 64 points. When sps_sbt_max_size_64_flag is true (i.e., the maximum SBT size is 64 points) and the maximum TU size is 32 points, an encoder crash may be triggered. In general, L-length or L-point refers to the maximum dimension of a CU, TU, CB, TB, VPDU, etc. For example, when the maximum TU size is 32 points or 32 points, the width and height of the TU are less than or equal to 32.

[0125] In some embodiments, ISP mode is allowed for various CU sizes, but when the maximum TU size is set smaller than 64, a conflict may occur between whether implicit transform splitting is performed or explicit transform splitting using ISP via signaling. For example, when the maximum TU size is 16, for example, for a 64x16 CU, without ISP, the CU may be implicitly split into four 16x16 TUs. With ISP, the 64x16 CU may be split by vertical ISP and thus into four 16x16 TUs, but using signaling.

[0126] When the maximum TU is smaller than 64x64, the TU processing order is required to align with the implementation of VPDUs.

[0127] The embodiments described herein may be used separately or combined in any order. Furthermore, the embodiments may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits), such as an encoder or decoder. In one example, one or more processors execute a program stored on a non-transitory computer-readable medium.

[0128] In this disclosure, a High-Level Syntax (HLS) element may refer to a video parameter set (VPS), a sequence parameter set (SPS), a picture parameter set (PPS), a slice header, a tile header, a tile group header, etc. A CTU header may refer to syntax elements signaled for a CUT, for example, as header information. In an example, the CTU size is the maximum CU size.

[0129] In general, when the luma size (represented by luma samples) of a particular unit (e.g., TU, CU) is known, the corresponding chroma size specified by the number of chroma samples can be obtained. In an example, a 4:2:0 YUV format is used, and a CU has a CU size of 64x64 luma samples (i.e., 64x64-L). Therefore, a CU has a CU size of 32x32 chroma samples (i.e., 32x32-C). The CU size may be referred to as 64x64-L, 32x32-C, or 64x64-L / 32x32-C. Similarly, a TU has a TU size of 64x64 luma samples (i.e., 64x64-L). Therefore, a TU has a TU size of 32x32 chroma samples (i.e., 32x32-C). The TU size may be referred to as 64x64-L, 32x32-C, or 64x64-L / 32x32-C. For example, a TU includes one luma transform block (TB) and two chroma TBs. The luma TB has a size of 64x64-L, and each of the chroma TBs has a size of 32x32-C. In general, embodiments and methods described for a CU or a TU may be appropriately adapted to the CB and TB, respectively.

[0130] A CU can include a 64x64-L luma block and two 32x32-C chroma blocks. In the following description, TU size is expressed in terms of luma samples within a TU. For example, a maximum TU size of M samples refers to a maximum TU size of M luma samples. Similarly, other sizes, such as VPDU size and CU size, are also expressed in terms of each luma sample within the corresponding unit, such as a VPDU and a CU, respectively. Naturally, TU size, VPDU size, CU size, etc. can be expressed in terms of chroma samples or a combination of luma and chroma samples.

[0131] The unit size may refer to the width, height, or area of ​​the unit. For example, the maximum TU size may refer to the width, height, or area of ​​the largest TU. In general, a TU, CU, VPDU, etc. may have any suitable shape, including a rectangular shape, a square shape, an 'L' shape, or any suitable shape. When the shape of the unit is irregular, such as an 'L' shape, the unit size may specify the area of ​​the unit.

[0132] In some embodiments, the VPDU size and / or maximum TU size may be signaled in the coded video bitstream, e.g., in the SPS and PPS. As described above, the VPDU size and / or maximum TU size may be signaled in terms of luma samples. Alternatively, the VPDU size and / or maximum TU size may be signaled in terms of chroma samples.

[0133] In some embodiments, the VPDU size and / or maximum TU size may be stored in the encoder and / or decoder, and therefore the VPDU size and / or maximum TU size are not signaled. In one example, the VPDU size and / or maximum TU size may be stored in a profile and / or level definition. The VPDU size and / or maximum TU size may be stored with respect to luma or chroma samples.

[0134] In some embodiments, VPDUs may share the same size but have different shapes. For example, when the VPDU size is 4096 in terms of luma samples, the VPDU may have a 64x64 square shape or a 32x128 rectangular shape. The VPDU may also have other shapes, such as an L-shape, as long as the VPDU size is 4096 in terms of luma samples. The above description is also applicable to specific TUs.

[0135] [1. Example A] According to aspects of the disclosure, the maximum allowable TU size (also referred to as maximum TU size) is M samples (e.g., a size of M×M samples). In an example, the maximum width and height of a TU is M. In an example, the maximum area of ​​a TU is M×M. The processing data unit size (e.g., a VPDU size) is K samples (e.g., a size of K×K samples). In an example, the maximum width and height of the processing data unit size is K. In an example, the maximum area of ​​the processing data unit size is K×K. A W×H CU has a width of W samples and a height of H samples. A CU may be divided into multiple sub-units called sub-processing units (SPUs) based on the CU size and the processing data unit size K. A CU may be divided into SPUs using any suitable partitioning structure, such as QTBT, QT, BT, TT, or a combination thereof, or any combination of suitable partitioning structures. The SPUs may have the same size or different sizes.

[0136] In an embodiment, a CU is split into SPUs if its width W or height H is greater than K. In an example, the SPUs have the same size (i.e., SPU size), and each SPU has a size of Min(W, K) x Min(H, K) samples. Thus, the width of each SPU is the smallest of W and K, and the height of that SPU is the smallest of H and K. In some examples, before splitting a CU, whether to split the CU may be determined based on the size of the CU and the processing data unit size K.

[0137] An SPU in a CU may be further divided into TUs, e.g., having a size of M×M samples. In some examples, an SPU may be divided into TUs having a size of Min(W,K,M)×Min(H,K,M). In some examples, before dividing an SPU, whether to divide the SPU may be determined based on the size of the SPU and a maximum TU size M. An SPU may be divided using any suitable partitioning structure, such as QTBT, QT, BT, TT, or a combination thereof, or a combination of any suitable partitioning structures. In accordance with aspects of the disclosure, one or more partitioning structures for dividing an SPU may be determined based on the size of the SPU and the maximum TU size M. In examples, an SPU may be recursively divided into TUs using the determined one or more partitioning structures.

[0138] In an example, when the width and height of an SPU are greater than the maximum TU size M, the SPU is partitioned into MxM TUs using a quadtree partitioning structure. The SPU may be recursively partitioned into TUs using the quadtree partitioning structure.

[0139] In an example, when the width of an SPU is greater than M and the height of the SPU is equal to M, the SPU is partitioned into M×M TUs using a vertical binary tree partitioning structure. For example, M is 32, and the SPU has a size of 64×32. Thus, the width of the SPU is 64 and the height of the SPU is 32. Therefore, a vertical binary tree partitioning structure may be used to partition the SPU into two TUs of 32×32. The SPU may be recursively partitioned into TUs using the vertical binary tree partitioning structure.

[0140] In an example, when the width of an SPU is greater than M and the height of the SPU is less than M, the SPU may be partitioned into TUs using a vertical binary tree partitioning structure, where the width of the TU is M and the height of the TU is equal to the height of the SPU.

[0141] In an example, when the height of an SPU is greater than M and the width of the SPU is equal to M, the SPU is partitioned into M x M TUs using a horizontal binary tree partitioning structure. The SPU may be recursively partitioned into TUs using the horizontal binary tree partitioning structure. For example, M is 32, and the SPU has a size of 32 x 64. Thus, the width of the SPU is 32, and the height of the SPU is 64. Therefore, the horizontal binary tree partitioning structure may be used to partition the SPU into two 32 x 32 TUs.

[0142] In an example, when the height of an SPU is greater than M and the width of the SPU is less than M, the SPU may be partitioned into TUs using a horizontal binary tree partitioning structure, where the height of the TU is M and the width of the TU is equal to the width of the SPU.

[0143] The transform tree syntax in FIG. 24 shows an example of the division of SPUs and the processing order used to process TUs.

[0144] In the example, a W×H CU may be divided in two steps: in the first step, the CU is divided into SPUs, where each SPU has a size of Min(W,K)×Min(H,K), and then in the second step, each SPU is further divided into TUs, where each TU has a size of M×M.

[0145] When processing TUs within a CU, the SPUs within the CU may be scanned and processed in a first scan order (also referred to as first order). Additionally, within each SPU, the TUs may be scanned and processed in a second scan order (also referred to as second order).

[0146] In various embodiments, the first order for processing the SPUs can be a raster scan order, a vertical scan order (e.g., scanning the SPUs column by column from left to right or vice versa), a zigzag order, a diagonal scan order, etc.

[0147] In various embodiments, the second order for processing TUs within each SPU can be a raster scan order, a vertical scan order (e.g., scanning TUs column by column from left to right or vice versa), a zigzag order, a diagonal scan order, etc.

[0148] The first order and the second order can be the same or different in different embodiments, for example, the first order for processing the SPUs and the second order for processing the TUs within each SPU are both raster scan order in one embodiment.

[0149] [2.Example B] Figure 25 shows a CU (2510) having a size of W x H samples, where W = 128 and H = 64. The maximum TU size M is 32 samples. The processing data unit size K, such as the VPDU size, is 64 samples. The CU (2510) is first divided into a first 64 x 64 SPU (2520) and a second 64 x 64 SPU (2530). The first SPU (2520) and the second SPU (2530) can then be further divided into TUs 0 to 7, each having a size of M x M samples. TUs 0 to 3 are included in the first SPU (2520), and TUs 4 x 7 are included in the second SPU (2530).

[0150] According to the first order, the first SPU (2520) may be processed first, followed by the second SPU (2530). The second order used to process TUs 0-3 or 4-7 within the first SPU (2520) or second SPU (2530) is the raster scan order. Thus, TUs 0-7 are processed according to the order indicated by the arrow (2551). The first order and / or the second order may be determined explicitly (e.g., via signaling from the encoder to the decoder) or implicitly.

[0151] In some examples, as described above, dividing a CU into SPUs, with each SPU further including a TU, improves coding efficiency. Referring to FIG. 25 , in an example, the first SPU (2520) is a first VPDU, and the second SPU (2530) is a second VPDU. The first VPDU (or the first SPU (2520)) and the second VPDU (or the second SPU (2530)) can sequentially pass through a multi-stage pipeline including a first stage (e.g., entropy decoding), a second stage (e.g., inverse quantization), a third stage (inverse transform), and / or the like. According to the first order shown in FIG. 25 , the first SPU (2520) should be processed before the second SPU (2530), so the first SPU (2520) is processed by the first stage and then proceeds to the second stage. In the example, when the first SPU (2520) is processed by the second stage, the second SPU (2530) is processed by the first stage to improve coding efficiency. Subsequently, the first SPU (2520) can proceed to the third stage, and the second SPU (2530) can move to the second stage. When the first SPU (2520) is processed by the third stage, the second SPU (2530) can be processed by the second stage. The above description is given using a VPDU and a multi-stage pipeline as an example and may be appropriately adapted to other architectures or video coding methods. The above description may be adapted to the case where the first SPU (2520) is included in the first VPDU and the second SPU (2530) is included in the second VPDU. At least some of the processing of the SPUs in different stages is performed simultaneously.

[0152] As described above, when the SPU size is larger than the TU size, multiple TUs within a CU may be grouped into processing data units such as SPUs (or VPDUs), and the SPUs may be processed in a multi-stage pipeline that enables parallel (or simultaneous) processing of consecutive SPUs. In some examples, the description may be modified as follows: a CU is divided into first units. Each of the first units may be further divided into second units. Each of the second units may be divided into third units. In examples, the first unit size is larger than the size of the second units, and the size of the second units is larger than the size of the third units. Such partitioning may be advantageous when a first multi-stage pipeline is nested within a second multi-stage pipeline.

[0153] [3.Example C] Figure 26A shows a CU (2610A) with a size of W x H samples, where W = 128 and H = 32. The maximum TU size M is 16 samples. The processing data unit size K, such as the VPDU size, is 64 samples. The minimum of W and K is 64, while the minimum of H and K is 32. Thus, the size of the SPU may be determined to be, for example, 64 x 32 samples to align the transform block with the VPDU. The CU (2610A) may be divided into a left SPU (2620A) and a right SPU (2630A), each with a size of 64 x 32 samples. The two SPUs (2620A) and (2630A) may be scanned and processed in left-to-right order.

[0154] Each of the two SPUs (2620A) and (2630A) may be further divided into TUs, each with a maximum TU size of 16x16 samples. As shown, the left SPU (2620A) is divided into TUs 0-7, while the right SPU (2630A) is divided into TUs 8-15. In SPU (2620A), TUs 0-7 may be processed in raster scan order. In SPU (2630A), TUs 8-15 may be processed in raster scan order. Thus, TUs 0-15 may be scanned and processed in the order indicated by arrow (2651A), with TU 0 processed first and TU 15 processed after TUs 0-15 have been processed.

[0155] [4.Example D] FIG. 26B shows a CU (2610B) having a size of W×H samples, where W=128 and H=32. The maximum TU size M is 16 samples. The processing data unit size K, such as the VPDU size, is 64 samples. In a manner similar to the example of FIG. 25, the CU (2610B) may be divided into two SPUs (2620B) and (2630B), and each SPU may be further divided into TUs. The SPUs (2620B) and (2630B) may be processed from left to right in the same order as in FIG. 25. However, unlike the example of FIG. 25, TUs 0-7 in SPU (2620B) are processed in zigzag order, and TUs 8-15 in SPU (2630B) are processed in zigzag order.

[0156] [5.Example E] FIG. 27 shows a flowchart illustrating a transform block partitioning and processing process (2700) according to an embodiment of the disclosure. The process (2700) may be used in the reconstruction of blocks coded in intra-mode or inter-mode. In various embodiments, the process (2700) is performed by a processing circuit, such as a processing circuit within the terminal devices (210), (220), (230), and (240), a processing circuit performing the functions of the video encoder (403), a processing circuit performing the functions of the video decoder (510), a processing circuit performing the functions of the video decoder (410), a processing circuit performing the functions of the video encoder (603), or the like. In some embodiments, the process (2700) is implemented by software instructions, such that the processing circuit performs the process (2700) when the processing circuit executes the software instructions. The process starts at (S2701) and proceeds to (S2710).

[0157] At (S2710), coded information for a CU in a picture may be decoded from the coded video bitstream. The coded information may indicate a width of W samples and a height of H samples for the CU.

[0158] At (S2720), for example, when at least one of the width W and height H of a CU is larger than the processing data unit size K, as described with reference to FIGS. 24 to 26, the CU may be divided into SPUs. The size of the SPU may be determined based on the processing data unit size K and the size of the CU. The width of the SPU may be the smallest of W and K, and the height of the SPU may be the smallest of H and K. Thus, the CU may be divided into SPUs each having the determined width and height. For example, if W is 128, H is 64, and K is 64, the CU may be divided into a first 64x64 SPU and a second 64x64 SPU. For example, the processing data unit is a VPDU, and therefore, K may be the VPDU size.

[0159] At (S2730), one or more partitioning structures for dividing each of the SPUs may be determined, for example, based on one or a combination of the width and height of the SPU and the maximum TU size of M samples. In an example, at least one of the width and height of the SPU is greater than M.

[0160] As described above, any suitable partitioning structure may be used to partition or divide each of the SPUs. In an example, when the width and height of an SPU are greater than M, one or more partitioning structures are determined to be quadtree partitioning structures. In an example, when the width of an SPU is greater than M and the height of an SPU is not greater than M, one or more partitioning structures are determined to be vertical binary tree partitioning structures. In an example, when the height of an SPU is greater than M and the width of an SPU is not greater than M, one or more partitioning structures are determined to be horizontal binary tree partitioning structures.

[0161] At (S2740), each of the SPUs may be partitioned into TUs based on the determined one or more partitioning structures. In an example, each SPU may be recursively partitioned into TUs using the determined one or more partitioning structures.

[0162] At (S2750), the TUs of the SPUs are processed according to a processing order. For example, as described above, the SPUs may be processed according to a first order, and the TUs in each of the SPUs may be processed according to a second order. The residual data of each TU may be determined by various decoding operations (e.g., entropy decoding of transform coefficients, inverse quantization or dequantization, inverse transform, and / or the like). The process (2700) may proceed to (S2799) and end.

[0163] The process (2700) is described using a CU as an example. The process (2700) can be appropriately adapted to CBs such as luma blocks, chroma blocks, etc. For brevity, the description of CBs is omitted.

[0164] Process 2700 may be adapted as appropriate. For example, one or more steps may be modified, omitted, or combined. For example, steps S2730 and S2740 may be combined into a single step. Additional steps may also be added. The order in which process 2700 is performed may also be changed.

[0165] [IV. Computer Systems] The techniques described above can be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 28 illustrates a computer system (2800) suitable for implementing certain embodiments of the disclosed subject matter.

[0166] Computer software can be coded in any suitable machine code or computer language that can be subjected to mechanisms such as assembly, compilation, linking, etc. to produce code containing instructions that can be executed by one or more central processing units (CPUs), graphics processing units (GPUs), etc., directly or through interpretation, microcode execution, etc.

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

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

[0169] The computer system 2800 may include certain human interface input devices. Such human interface input devices may respond to input by one or more users through, for example, tactile input (e.g., keyboard, swipe, dataglove motion), audio input (e.g., voice, claps), visual input (e.g., gestures), or olfactory input (not shown). The human interface devices may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (e.g., speech, music, ambient sounds), images (e.g., scanned images, photographic images obtained from a still camera), and video (e.g., two-dimensional video, three-dimensional video, including stereoscopic video).

[0170] The input human interface devices may include one or more of a keyboard (2801), a mouse (2802), a trackpad (2803), a touchscreen (2810), a data glove (not shown), a joystick (2805), a microphone (2806), a scanner (2807), and a camera (2808) (only one of each is shown).

[0171] The computer system 2800 may also include certain human interface output devices that may stimulate one or more of the user's senses through, for example, tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touchscreen (2810), data gloves (not shown), or joystick (2805), although haptic feedback devices that do not function as input devices may also exist), audio output devices (e.g., speakers (2809), headphones (not shown)), visual output devices (e.g., screens (2810) including CRT screens, LCD screens, plasma screens, OLED screens, each with or without touchscreen input capability, each with or without haptic feedback capability, some of which are capable of outputting two-dimensional visual output or output in more than three dimensions by means of stereoscopic output, virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0172] The computer system (2800) may also include human-accessible storage devices and their associated media, such as CD / DVD ROM / RW (2820) along with CD / DVD or similar media (2821), thumb drives (2822), removable hard disks or solid state drives (2823), legacy magnetic media such as tape and floppy disks (not shown), dedicated ROM / ASIC / PLD-based devices such as security dongles (not shown), and the like.

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

[0174] The computer system 2800 may also include interfaces to one or more communication networks. Networks may be, for example, wireless, wireline, or optical. Networks may further be local, wide-area, metropolitan, vehicular, and industrial, real-time, delay-tolerant, and the like. Examples of networks include local area networks such as Ethernet; wireless LANs; cellular networks including GSM, 3G, 4G, 5G, LTE, and the like; TV wireline or wireless wide-area digital networks including cable TV, satellite TV, and terrestrial broadcast TV; and vehicle and factory networks including CAN bus. Certain networks generally require an external network interface adapter attached to a particular general-purpose digital port or peripheral bus 2849 (e.g., a USB port on the computer system 2800). Others are generally integrated into the core of the computer system 2800 by attachment to a system bus, as described below (e.g., an Ethernet network interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system 2800 can communicate with other entities. Such communication may be one-way receive-only (e.g., broadcast TV) or one-way transmit-only (e.g., a CAN bus to a particular CAN bus device), or may be two-way to other computer systems, for example, using local or wide area digital networks. Specific protocols or protocol stacks may be used with each of the networks and network interfaces described above.

[0175] The above-mentioned human interface devices, human-accessible storage devices, and network interfaces may be attached to the core 2840 of the computer system 2800.

[0176] The cores 2840 may include one or more central processing units (CPUs) 2841, graphics processing units (GPUs) 2842, dedicated programmable processing units in the form of field programmable gate arrays (FPGAs) 2843, hardware accelerators 2844 for specific tasks, etc. These devices may be connected through a system bus 2848, along with read-only memory (ROM) 2845, random access memory (RAM) 2846, internal mass storage devices such as internal non-user-accessible hard drives, SSDs, etc. 2847. In some computer systems, the system bus 2848 may be accessible in the form of one or more physical plugs, allowing expansion with additional CPUs, GPUs, etc. Peripheral devices may be attached to the core's system bus 2848 directly or through a peripheral bus 2849. Architectures for peripheral buses include PCI, USB, etc.

[0177] The CPU (2841), GPU (2842), FPGA (2843), and accelerator (2844) can execute specific instructions that, in combination, can constitute the above-mentioned computer code. The computer code can be stored in ROM (2845) or RAM (2846). Temporary data can also be stored in RAM (2846), while persistent data can be stored, for example, in an internal mass storage device (2847). Rapid storage and retrieval from any of the memory devices can be enabled through the use of cache memory. Cache memory can be closely associated with one or more of the CPU (2841), GPU (2842), mass storage device (2847), ROM (2845), RAM (2846), etc.

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

[0179] By way of example, and not limitation, a computer system having the architecture (2800), and in particular the core (2840), can provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media can be media associated with the user-accessible mass storage devices introduced above, in addition to specific storage of the core (2840) that is non-transitory in nature, such as the core's internal mass storage device (2847) or ROM (2845). Software implementing various embodiments of the present disclosure can be stored on such devices and executable by the core (2840). The computer-readable media can include one or more memory devices or chips, depending on particular needs. Software can cause the cores (2840), and specifically the processors (including CPUs, GPUs, FPGAs, etc.) therein, to perform particular processes or portions of particular processes described herein, including defining data structures stored in RAM (2846) and modifying such data structures according to software-defined processes. Additionally or alternatively, the computer system can provide functionality as a result of logic (e.g., accelerators (2844)) implemented by hardware or otherwise embodied in circuitry that can operate in place of or in conjunction with software to perform particular processes or portions of particular processes described herein. References to software can encompass logic, where appropriate, and vice versa. References to computer-readable media can encompass circuitry (e.g., integrated circuits (ICs)) storing software for execution, circuitry embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0180] Appendix A: Acronyms ASIC:Application-Specific Integrated Circuit BMS:benchmark set CANBus:Controller Area Network Bus CBF:Coded Block Flag CD:Compact Disc CPU:Central Processing Unit(s) CRT:Cathode Ray Tube CTB:Coding Tree Block(s) CTU:Coding Tree Unit(s) CU:Coding Unit DVD:Digital Video Disc FPGA:Field Programmable Gate Area(s) GOP:Group of Picture(s) GPU:Graphics Processing Unit(s) GSM:Global System for Mobile communications HEVC:High Efficiency Video Coding HRD:Hypothetical Reference Decoder ISP:Intra Sub-Partitions IC:Integrated Circuit JEM:Joint Exploration Model LAN:Local Area Network LCD:Liquid-Crystal Display LTE:Long-Term Evolution MPM:Most Probable Mode MV:Motion Vector OLED:Organic Light-Emitting Diode PB: Prediction Block(s) PCI:Peripheral Component Interconnect PLD: Programmable Logic Device PU: Prediction Unit(s) RAM: Random Access Memory ROM: Read-Only Memory SBT: Sub-Block Transform SEI:Supplementary Enhancement Information SNR: Signal-to-Noise Ratio SSD: Solid-State Drive TU: Transform Unit(s) USB: Universal Serial Bus VPDU:Virtual Pipeline Data Unit VUI:Video Usability Information VVC: Versatile Video Coding

[0181] While this disclosure has described several exemplary embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. It will thus be apparent to those skilled in the art that numerous systems and methods will be possible which embody the principles of the present disclosure and are therefore within its spirit and scope, even if not explicitly shown or described herein.

[0182] [Incorporated by reference] This disclosure claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 822,787, filed March 22, 2019, entitled "Modified VPDU Compatible Max Transform Control," which in turn claims the benefit of priority to U.S. Patent Application No. 16 / 823,831, filed March 19, 2020, entitled "Method and Apparatus for Video Coding," the entire disclosures of which are incorporated herein by reference in their entirety.

Claims

[Claim 1] 1. A method for video decoding performed by a decoder, comprising: decoding coded information of a coding block (CB) in a picture from a coded video bitstream, the coded information indicating a width of the CB as W samples and a height of the CB as H samples; determining a maximum transform unit (TU) size M based on whether at least one of the width W of the CB or the height H of the CB is greater than 64, wherein the maximum TU size M is equal to 64 if the at least one of the width W of the CB or the height H of the CB is greater than 64, and is equal to a maximum CB size if the width W of the CB and the height H of the CB are less than or equal to 64; determining a width parameter based on whether the width W of the CB is greater than the maximum TU size M, wherein the width parameter is equal to half the width W of the CB if the width W of the CB is greater than the maximum TU size M, and is equal to the width W of the CB if the width W of the CB is less than or equal to the maximum TU size M; determining a height parameter based on whether the height H of the CB is greater than the maximum TU size M, wherein the height parameter is equal to half the height H of the CB if the height H of the CB is greater than the maximum TU size M, and is equal to the height H of the CB if the height H of the CB is less than or equal to the maximum TU size M; determining, based on the width W of the CB, the height H of the CB, and the maximum TU size M, which partitioning structure among a plurality of partitioning structures is selected to divide the CB, wherein the selected partitioning structure divides the CB based on the determined width parameter and height parameter, and the plurality of partitioning structures include a vertical binary tree partitioning structure and a horizontal binary tree partitioning structure; repeatedly dividing the CB into a plurality of TUs based on the partitioning structure determined to be selected from the plurality of partitioning structures until the size of each TU is equal to or smaller than M×M; A method having the following.

Images