Method, apparatus and system for encoding and decoding blocks of video samples

Abstract

To provide a system and a method for decoding a coding unit of a coding tree from a coding tree unit of an image frame from a video bitstream.SOLUTION: A coding unit has a first color channel and at least one second color channel. A video decoder determines a coding unit including the first color channel and at least one second color channel according to a decoded division flag of a coding tree unit, decodes a first index for selecting a kernel for the first color channel and a second index for selecting a kernel for the at least one second color channel, and selects a first kernel according to the first index and a second kernel according to the second index. The video decoder applies the first kernel to a residual coefficient of the first color channel, and applies the second kernel to a residual coefficient of the at least one second color channel, thereby decoding the coding unit.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] [Reference to Related Application] This application claims the benefit under 35 U.S.C. § 119 of the filing date of Australian Patent Application No. 2019232801, filed September 17, 2019, the entirety of which is incorporated herein by reference as if fully set forth herein.

[0002] [Technical field] The present invention relates generally to digital video signal processing, and more particularly to a method, apparatus and system for encoding and decoding blocks of video samples. The present invention also relates to a computer program product including a computer-readable medium having recorded thereon a computer program for encoding and decoding blocks of video samples. [Background technology]

[0003] Many applications for video coding currently exist, including applications for the transmission and storage of video data. Many video coding standards have been developed, and others are currently under development. Recent developments in video coding standardization have led to the formation of a group called the "Joint Video Experts Team" (JVET). The JVET (Joint Video Experts Team) includes members of Study Group 16, Question 6 (SG16 / Q6) of the International Telecommunication Union's (ITU) Telecommunications Standardization Sector (ITU-T), also known as the "Video Coding Experts Group" (VCEG), and the International Organization for Standardization / International Electrotechnical Commission Joint Technical Committee 1 / Subcommittee 29 / Working Group 11 (ISO / IEC JTC1 / SC29 / WG11), also known as the Moving Picture Experts Group (MPEG).

[0004] The Joint Video Experts Team (JVET) issued a Call for Proposals (CfP) using responses analyzed during 10 meetings held in San Diego, USA. The submitted responses demonstrated video compression capabilities significantly exceeding those of the current state-of-the-art video compression standard, i.e., "High Efficiency Video Coding" (HEVC). Based on this outperformance, it was decided to initiate a project to develop a new video compression standard, named "Versatile Video Coding" (VVC). VVC is expected to address the ongoing demand for ever-higher compression performance, particularly as video formats increase in capacity (e.g., at higher resolutions and higher frame rates) and address increasing market demand for service delivery over wide-area networks where bandwidth costs are relatively high. Use cases such as immersive video require real-time encoding and decoding of such higher formats. For example, cube-map projection (CMP) may use 8K formats even if the final rendered "viewport" uses a lower resolution. VVC must be implementable in modern silicon processes and offer an acceptable tradeoff between achieved performance and implementation cost. This implementation cost can be considered in terms of, for example, one or more of silicon area, CPU processor load, memory usage, and bandwidth. Higher video formats can be processed by dividing the frame area into sections and processing each section in parallel. A bitstream constructed from multiple sections of a compressed frame that are still suitable for decoding by a "single-core" decoder, i.e., frame-level constraints including bitrate, are allocated to each section according to the needs of the application.

[0005] Video data includes a sequence of frames of image data, each of which includes one or more color channels. Generally, one primary color channel and two secondary color channels are required. The primary color channel is commonly referred to as the "luminance" channel, and the secondary color channel is commonly referred to as the "chroma" channel. Video data is typically represented in the RGB (red-green-blue) color space, which has a high degree of correlation between each of the three components. Video data representations viewed by encoders or decoders often use color spaces such as YCbCr. YCbCr aggregates luminance, mapped to "luminance" according to a transfer function, in the Y (primary) channel and chroma in the Cb and Cr (secondary) channels. Due to the use of decorrelated YCbCr signals, the statistics of the luma channel differ significantly from those of the chroma channel. The main difference is that, after quantization, the chroma channel contains relatively fewer significant coefficients for a given block compared to the coefficients of the corresponding luma channel block. Additionally, the Cb and Cr channels may be spatially sampled (subsampled) at a lower rate compared to the luma channel, e.g., half horizontally and half vertically, known as a "4:2:0 chroma format." This 4:2:0 chroma format is commonly used in "consumer" applications, such as Internet video streaming, broadcast television, and storage on Blu-ray discs. Subsampling the Cb and Cr channels at half the rate horizontally and no vertical subsampling is known as a "4:2:2 chroma format." This 4:2:2 chroma format is typically used in professional applications, including capturing footage for film production and the like. The higher sampling rate of the 4:2:2 chroma format makes the resulting video more resilient to editing operations such as color grading. Before distribution to consumers, 4:2:2 chroma format material is often converted to a 4:2:0 chroma format and then encoded for distribution to consumers. In addition to the chroma format, video is also characterized by its resolution and frame rate.Example resolutions are Ultra High Definition (UHD) with a resolution of 3840x2160, or "8K" with a resolution of 7680x4320, with example frame rates of 60 or 120 Hz. Luminance sample rates may range from approximately 500 megasamples / second to several gigasamples / second. For a 4:2:0 chroma format, the sample rate for each chroma channel is one-quarter the luma sample rate, and for a 4:2:2 chroma format, the sample rate for each chroma channel is one-half the luma sample rate.

[0006] The VVC standard is a "block-based" codec that first divides a frame into a square array of regions known as "coding tree units" (CTUs). CTUs typically occupy a relatively large area, such as 128x128 luma samples. However, CTUs at the right and bottom of each frame may be smaller in area. Each CTU is associated with a "coding tree" for both the luma and chroma channels (a "shared tree"), or with separate trees for the luma and chroma channels. The coding tree defines a decomposition of the CTU's area into a set of blocks, also called "coding blocks" (CBs). When a shared tree is used, a single coding tree specifies blocks for both the luma and chroma channels. In this case, the set of coherent coding blocks is called a "coding unit" (CU), i.e., each CU has a coding block for each color channel. The CBs are processed for encoding or decoding in a specific order. As a result of the use of the 4:2:0 chroma format, a CTU having a luma coding tree for a 128x128 luma sample area has a corresponding chroma coding tree for a 64x64 chroma sample area co-located with the 128x128 luma sample area. When a single coding tree is used for the luma and chroma channels, the collection of co-located blocks for a given area is generally referred to as a "unit," e.g., the CU mentioned above, as well as a "prediction unit" (PU) and a "transform unit" (TU). A single tree with CUs across the color channels of 4:2:0 chroma format video data results in chroma blocks that are half the width and height of the corresponding luma block. When separate coding trees are used for a given area, the CB mentioned above, as well as a "prediction block" (PB) and a "transform block" (TB) are used.

[0007] Notwithstanding the above distinction between "unit" and "block", the term "block" may be used as a general term for an area or region of a frame where an operation is applied to all color channels.

[0008] For each CU, a prediction unit (PU) of the contents (sample values) of the corresponding region of frame data is generated ("prediction unit"). Furthermore, a representation of the difference (or "spatial domain" residual) between the prediction and the contents of the area seen at the input to the encoder is formed. The differences for each color channel may be transformed and coded as a sequence of residual coefficients, forming one or more TUs for a given CU. The applied transform may be a discrete cosine transform (DCT) or other transform applied to each block of residual values. This transform is applied separably, i.e., a second-dimensional transform is performed in two passes. The block is first transformed by applying a first-dimensional transform to each row of samples in the block. Then, the partial results are transformed by applying a first-dimensional transform to each column of the partial results to generate a final block of transform coefficients that substantially decorrelates the residual samples. Transforms of various sizes are supported by the VVC standard, including transforms of rectangular-shaped blocks, where each side dimension is a power of two. The transform coefficients are quantized for entropy coding into the bitstream.

[0009] VVC features intra-frame prediction and inter-frame prediction. Intra-frame prediction involves the use of previously processed samples within a frame to generate a prediction of a current block of samples within the frame. Inter-frame prediction involves using a block of samples from a previously decoded frame to generate a prediction of a current block of samples within a frame. The block of samples from a previously decoded frame is offset from the spatial location of the current block according to a motion vector, often subject to filtering. An intra-frame prediction block can be (i) a uniform sample value ("DC intra-prediction"), (ii) a plane with an offset and horizontal and vertical gradients ("plane intra-prediction"), (iii) a population of blocks with neighboring samples applied in a specific direction ("angular intra-prediction"), or (iv) the result of a matrix multiplication using neighboring samples and selected matrix coefficients. Further discrepancies between a prediction block and its corresponding input sample can be corrected to some extent by encoding a "residual" into the bitstream. This residual is typically transformed from the spatial domain to the frequency domain to form residual coefficients (in a "first transform domain"), which may then be further transformed by application of a "second transform" (to produce residual coefficients in a "second transform domain"). The residual coefficients are quantized according to a quantization parameter, resulting in a loss of accuracy in the reconstruction of the samples produced at the decoder, but at a reduced bitrate for the bitstream. This quantization parameter may vary from frame to frame and within each frame. Varying quantization parameters within frames is typical of "rate-controlled" encoders. Rate-controlled encoders attempt to generate a bitstream with a substantially constant bitrate, regardless of the statistics of the received input samples, such as noise characteristics and the degree of motion. Because the bitstream is typically carried over networks with limited bandwidth, rate control is a common technique for ensuring reliable performance over the network, regardless of variations in the original frames input to the encoder.When a frame is coded in parallel sections, it is desirable to be flexible in the use of rate control, as different sections may have different requirements in terms of desired fidelity. Summary of the Invention

[0010] SUMMARY OF THE INVENTION It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

[0011] One aspect of the present disclosure provides a method for decoding a coding unit of a coding tree from a coding tree unit of an image frame from a video bitstream, the coding unit having a first color channel and at least one second color channel, the method including: determining a coding unit including the first color channel and the at least one second color channel according to a decoded split flag of the coding tree unit; decoding a first index to select a kernel for the first color channel and a second index to select a kernel for the at least one second color channel; selecting the first kernel according to the first index and the second kernel according to the second index; and decoding the coding unit by applying the first kernel to residual coefficients of the first color channel and the second kernel to residual coefficients of the at least one second color channel.

[0012] According to another aspect, the first index or the second index is decoded immediately after decoding the position of the last valid residual coefficient of the coding unit.

[0013] According to another aspect, a single residual coefficient is decoded for multiple second color channels.

[0014] According to another aspect, a single residual coefficient is decoded for a single second color channel.

[0015] According to another aspect, the first index and the second index are independent of each other.

[0016] According to another aspect, the first and second kernels depend on the intra prediction modes for the first and at least one second color channel, respectively.

[0017] According to another aspect, the first and second kernels are associated with a block size of a first channel and a block size of at least one second color channel, respectively.

[0018] According to another aspect, the second kernel is related to the chroma subsampling ratio of the encoded bitstream.

[0019] According to another aspect, each of the kernels implements a non-separable second transformation.

[0020] According to another aspect, the coding unit includes two second color channels, and a separate index is decoded for each of the second color channels.

[0021] Another aspect of the present disclosure provides a method for decoding coding units of a coding tree from a coding tree unit of an image frame from a video bitstream, the coding units having a first color channel and at least one second color channel, the method including: determining a coding unit including the first color channel and the at least one second color channel according to a decoded split flag of the coding unit; selecting a non-separable transform kernel according to a decoded index of the first color channel; applying the selected non-separable transform kernel to a decoded residual of the first color channel to generate second transform coefficients; and decoding the coding unit by applying a separable transform kernel to the second transform coefficients and applying the separable transform kernel to the decoded residual of the at least one second color channel.

[0022] Another aspect of the present disclosure provides a non-transitory computer-readable medium having a computer program stored thereon for implementing a method for decoding a coding unit of a coding tree from a coding tree unit of an image frame from a video bitstream, the coding unit having a first color channel and at least one second color channel, the method including: determining a coding unit including the first color channel and the at least one second color channel according to a decoded split flag of the coding tree unit; decoding a first index to select a kernel for the first color channel and a second index to select a kernel for the at least one second color channel; selecting the first kernel according to the first index and selecting the second kernel according to the second index; and decoding the coding unit by applying the first kernel to residual coefficients of the first color channel and the second kernel to residual coefficients of the at least one second color channel.

[0023] One aspect of the present disclosure provides a video decoder configured to implement a method for decoding a coding unit of a coding tree from a coding tree unit of an image frame from a video bitstream, the coding unit having a first color channel and at least one second color channel, the method including: determining a coding unit including the first color channel and the at least one second color channel according to a decoded split flag of the coding tree unit; decoding a first index to select a kernel for the first color channel and a second index to select a kernel for the at least one second color channel; selecting the first kernel according to the first index and the second kernel according to the second index; and decoding the coding unit by applying the first kernel to residual coefficients of the first color channel and the second kernel to residual coefficients of the at least one second color channel.

[0024] Another aspect of the present disclosure provides a system comprising: a memory; and a processor configured to execute code stored in the memory to implement a method for decoding a coding unit of a coding tree from a coding tree unit of an image frame from a video bitstream, the coding unit having a first color channel and at least one second color channel, the method including: determining a coding unit including the first color channel and the at least one second color channel according to a decoded split flag of the coding tree unit; decoding a first index to select a kernel for the first color channel and a second index to select a kernel for the at least one second color channel; selecting the first kernel according to the first index and selecting the second kernel according to the second index; and decoding the coding unit by applying the first kernel to residual coefficients of the first color channel and the second kernel to residual coefficients of the at least one second color channel.

[0025] Another aspect of the present disclosure provides a method for decoding a plurality of coding units from a bitstream to generate an image frame, the coding units being the result of decomposition of a coding tree unit, the plurality of coding units forming one or more consecutive portions of the bitstream, the method including: determining, for each of the one or more consecutive portions of the bitstream, a subdivision level applicable to the coding units of the respective consecutive portions of the bitstream; decoding a quantization parameter delta for each of a number of areas, each area being based on a quantization parameter delta from a coding tree unit to a coding unit of the respective consecutive portion of the bitstream and its corresponding determined subdivision level; determining a quantization parameter for each area according to the decoded delta quantization parameter for that area and a quantization parameter of a previous coding unit of the image frame; and decoding the plurality of coding units using the determined quantization parameter for each area to generate the image frame.

[0026] According to another aspect, each area is based on a comparison of a subdivision level associated with the coding unit with a subdivision level determined for the corresponding contiguous portion.

[0027] According to another aspect, a quantization parameter delta is determined for each area in which the corresponding coding tree has a subdivision level less than or equal to the subdivision level determined for the corresponding successive portion.

[0028] According to another aspect, a new area is established for any node in the coding tree unit having a subdivision level equal to or lower than the corresponding determined subdivision level.

[0029] According to another aspect, the subdivision levels determined for each successive portion comprise a first subdivision level for the luma coding units and a second subdivision level for the chroma coding units of the successive portion.

[0030] According to another embodiment, the first and second subdivision levels are different.

[0031] According to another aspect, the method further includes decoding a flag indicating that a partition constraint of a sequence parameter set associated with the bitstream can be overridden.

[0032] According to another aspect, the subdivision level determined for each of the one or more contiguous portions comprises a maximum luma coding unit depth for that area.

[0033] According to another aspect, the subdivision level determined for each of the one or more contiguous portions comprises a maximum chroma coding unit depth for the corresponding area.

[0034] According to another aspect, the subdivision level determined for one of the consecutive portions is adjusted to maintain an offset relative to the deepest allowed subdivision level decoded for the partition constraints of the bitstream.

[0035] Another aspect of the present disclosure provides a non-transitory computer-readable medium having a computer program stored thereon for implementing a method for decoding a plurality of coding units from a bitstream to generate an image frame, the coding units being the result of decomposition of a coding tree unit, the plurality of coding units forming one or more consecutive portions of the bitstream, the method including: determining, for each of the one or more consecutive portions of the bitstream, a subdivision level applicable to the coding units of the respective consecutive portions of the bitstream; decoding a quantization parameter delta for each of a number of areas, each area being based on the quantization parameter delta from the coding tree unit to the coding units of the respective consecutive portions of the bitstream and its corresponding determined subdivision level; determining a quantization parameter for each area according to the decoded delta quantization parameter for that area and a quantization parameter of a previous coding unit of the image frame; and decoding the plurality of coding units using the determined quantization parameter for each area to generate the image frame.

[0036] Another aspect of the present disclosure provides a video decoder configured to implement a method for decoding a plurality of coding units from a bitstream to generate an image frame, the coding units being the result of decomposition of a coding tree unit, the plurality of coding units forming one or more consecutive portions of the bitstream, the method including: determining, for each of the one or more consecutive portions of the bitstream, a subdivision level applicable to the coding units of the respective consecutive portions of the bitstream; decoding a quantization parameter delta for each of a number of areas, each area being based on a quantization parameter delta from a coding tree unit to a coding unit of the respective consecutive portion of the bitstream and its corresponding determined subdivision level; determining a quantization parameter for each area according to the decoded delta quantization parameter for that area and a quantization parameter of a previous coding unit of the image frame; and decoding the plurality of coding units using the determined quantization parameter for each area to generate the image frame.

[0037] Another aspect of the present disclosure provides a system comprising: a memory; and a processor configured to execute code stored in the memory to perform a method for decoding a plurality of coding units from a bitstream to generate an image frame, the coding units being the result of decomposition of a coding tree unit, the plurality of coding units forming one or more consecutive portions of the bitstream, the method including: determining, for each of the one or more consecutive portions of the bitstream, a subdivision level applicable to the coding units of the respective consecutive portions of the bitstream; decoding a quantization parameter delta for each of a number of areas, each area being based on a quantization parameter delta from a coding tree unit to a coding unit of the respective consecutive portion of the bitstream and its corresponding determined subdivision level; determining a quantization parameter for each area according to the decoded delta quantization parameter for that area and a quantization parameter of a previous coding unit of the image frame; and decoding the plurality of coding units using the determined quantization parameter for each area to generate the image frame.

[0038] Other aspects are also disclosed. [Brief explanation of the drawings]

[0039] At least one embodiment of the present invention will now be described with reference to the following drawings and appendices.

[0040] [Figure 1] 1 is a schematic block diagram illustrating a video encoding and decoding system.

[0041] [Figure 2A] , and [Figure 2B] 2 is a schematic block diagram of a general-purpose computer system capable of implementing one or both of the video encoding and decoding systems of FIG. 1;

[0042] [Figure 3] 1 is a schematic block diagram illustrating functional modules of a video encoder.

[0043] [Figure 4] FIG. 2 is a schematic block diagram illustrating the functional modules of a video decoder.

[0044] [Figure 5] 1 is a schematic block diagram illustrating possible divisions of a block into one or more blocks in a tree structure of generic video coding.

[0045] [Figure 6] 1 is a schematic diagram of a data flow for achieving a permitted division of a block into one or more blocks in a tree structure for generic video coding.

[0046] [Figure 7A] , and [Figure 7B] FIG. 1 is a diagram showing an example of dividing a coding tree unit (CTU) into several coding units (CUs).

[0047] [Figure 8A] , [Figure 8B] , and [Figure 8C] 10A and 10B are diagrams illustrating the subdivision levels resulting from divisions in the coding tree and their effect on the division of coding tree units into quantization groups.

[0048] [Figure 9A] , and [Figure 9B] FIG. 2 illustrates a 4×4 transform block scan pattern and associated first and second transform coefficients.

[0049] [Figure 9C] , and [Figure 9D] FIG. 2 illustrates an 8×8 transform block scan pattern and associated first and second transform coefficients.

[0050] [Figure 10] 10A and 10B are diagrams illustrating the application domain of the second transform for transform blocks of various sizes.

[0051] [Figure 11] 1 illustrates the syntax structure of a bitstream having multiple slices, each slice containing multiple coding units.

[0052] [Figure 12] 1 illustrates the syntax structure of a bitstream with a shared tree for luma and chroma coding blocks of a coding tree unit.

[0053] [Figure 13] 1 illustrates a method for encoding a frame into a bitstream that includes one or more slices as a sequence of coding units.

[0054] [Figure 14] 1 illustrates how slice headers are coded into a bitstream.

[0055] [Figure 15] 1 illustrates a method for encoding a coding unit into a bitstream.

[0056] [Figure 16] FIG. 1 illustrates a method for decoding a frame from a bitstream as a sequence of coding units arranged in slices.

[0057] [Figure 17] FIG. 10 illustrates a method for decoding slice headers from a bitstream.

[0058] [Figure 18] 1 illustrates a method for decoding a coding unit from a bitstream.

[0059] [Figure 19A] , and [Figure 19B] 10 shows rules for applying or bypassing a second transform to luma and chroma channels. DETAILED DESCRIPTION OF THE INVENTION

[0060] Where reference is made to steps and / or features in any one or more of the accompanying drawings that have the same reference numerals, those steps and / or features have the same function or operation for the purposes of this description, unless a contrary intention appears.

[0061] A rate-controlled video encoder requires flexibility to adjust quantization parameters with a granularity appropriate to block partitioning constraints. Block partitioning constraints may differ from one part of a frame to another, for example, when multiple video encoders operate in parallel to compress each frame. The granularity of the area where quantization parameter adjustment is required differs accordingly. Furthermore, control of applied transform selection, including the potential application of a second transform, is applied within the prediction signal from which the transformed residual was generated. In particular, for intra-prediction, separate modes are available for luma and chroma blocks, since different intra-prediction modes can be used.

[0062] Some sections of a video contribute more to the fidelity of the rendered viewport than others and can be allocated larger bitrates and greater flexibility in block structure and quantization parameter distribution values. Sections that contribute less to the fidelity of the rendered viewport, such as sections to the side or back of the rendered viewport, may be compressed with simpler block structures and less flexibility in controlling the quantization parameters to reduce encoding effort. Generally, larger values ​​are selected to more coarsely quantize the transform coefficients for lower bitrates. Furthermore, the application of transform selection may be independent between the luma and chroma channels to further simplify the encoding process by avoiding the need to jointly consider luma and chroma for transform selection. In particular, the need to consider intra-prediction modes for luma and chroma separately and then jointly consider luma and chroma for a second transform selection is avoided.

[0063] 1 is a schematic block diagram illustrating the functional modules of a video encoding and decoding system 100. System 100 can vary the areas in which quantization parameters are adjusted in different parts of a frame to accommodate different block partitioning constraints that may be in effect in each part of the frame.

[0064] System 100 includes source device 110 and destination device 130. Communication channel 120 is used to communicate encoded video information from source device 110 to destination device 130. In some configurations, source device 110 and destination device 130 may comprise respective mobile phone handsets or “smartphones,” in which case communication channel 120 is a wireless channel. In other configurations, source device 110 and destination device 130 may comprise video conferencing equipment, in which case communication channel 120 is typically a wired channel, such as an Internet connection. Furthermore, source device 110 and destination device 130 may comprise any of a wide range of devices, including devices that support over-the-air television broadcasts, cable television applications, Internet video applications (including streaming), and applications in which encoded video data is captured on some computer-readable storage medium, such as a hard disk drive in a file server.

[0065] As shown in FIG. 1 , source device 110 includes video source 112, video encoder 114, and transmitter 116. Video source 112 typically comprises a source of captured video frame data (shown as 113), such as an image capture sensor, a previously captured video sequence stored on a non-transitory recording medium, or a video feed from a remote image capture sensor. Video source 112 may also be the output of a computer graphics card, for example, displaying the video output of an operating system or various applications running on a computing device, such as a tablet computer. Examples of source device 110 that may include an image capture sensor as video source 112 include smartphones, video cameras, professional digital video cameras, and network video cameras.

[0066] Video encoder 114 converts (or "encodes") captured frame data (indicated by arrow 113) from video source 112 into a bitstream (indicated by arrow 115), as further described with reference to FIG. 3. Bitstream 115 is transmitted by transmitter 116 over communication channel 120 as coded video data (or "coded video information"). Bitstream 115 may also be stored in non-transitory storage device 122, such as "flash" memory or a hard disk drive, until later transmitted over communication channel 120, or instead of being transmitted over communication channel 120. For example, coded video data may be provided on demand to a customer over a wide area network (WAN) for video streaming applications.

[0067] Destination device 130 includes a receiver 132, a video decoder 134, and a display device 136. Receiver 132 receives encoded video data from communication channel 120 and passes the received video data as a bitstream to video decoder 134 (indicated by arrow 133). Video decoder 134 then outputs decoded frame data (indicated by arrow 135) to display device 136. Decoded frame data 135 has the same chroma format as frame data 113. Examples of display device 136 include a cathode ray tube, a smartphone, a tablet computer, a computer monitor, or a liquid crystal display such as a standalone television set. It is also possible for the functionality of each of source device 110 and destination device 130 to be implemented in a single device, examples of which include a mobile telephone handset and a tablet computer. The decoded frame data may be further transformed before presentation to a user. For example, a "viewport" having a specific latitude and longitude can be rendered from the decoded frame data using a projection format to represent a 360° perspective of a scene.

[0068] Notwithstanding the exemplary devices described above, each of source device 110 and destination device 130 may generally be configured within a general-purpose computing system via a combination of hardware and software components. Figure 2A illustrates such a computer system 200, including a computer module 201, input devices such as a keyboard 202, a mouse pointer device 203, a scanner 226, a camera 227 that may be configured as a video source 112, and a microphone 280, and output devices including a printer 215, a display device 214 that may be configured as a display device 136, and speakers 217. An external modulator-demodulator (modem) transceiver device 216 may be used by computer module 201 to communicate with a communications network 220 via connection 221. Communications network 220, which may represent communications channel 120, may be a WAN such as the Internet, a cellular telecommunications network, or a private WAN. If connection 221 is a telephone line, modem 216 may be a conventional "dial-up" modem. Alternatively, modem 216 may be a broadband modem if connection 221 is a high-capacity (e.g., cable or optical) connection. A wireless modem may also be used for wireless connection to communication network 220. Transceiver device 216 may provide the functionality of transmitter 116 and receiver 132, and communication channel 120 may be embodied within connection 221.

[0069] The computer module 201 typically includes at least one processor unit 205 and a memory unit 206. For example, the memory unit 206 may include semiconductor random access memory (RAM) and semiconductor read-only memory (ROM). The computer module 201 also includes several input / output (I / O) interfaces, including an audio / video interface 207 that couples to a video display 214, speakers 217, and microphone 280; an I / O interface 213 that couples to a keyboard 202, a mouse 203, a scanner 226, a camera 227, and optionally a joystick or other human interface device (not shown); and an interface 208 for an external modem 216 and a printer 215. The signal from the audio / video interface 207 to the computer monitor 214 is typically an output of a computer graphics card. In some implementations, the modem 216 may be integrated into the computer module 201, e.g., within the interface 208. The computer module 201 also has a local network interface 211, which allows coupling of the computer system 200 via a connection 223 to a local area communications network 222, known as a local area network (LAN). As shown in FIG. 2A, the local communications network 222 can also be coupled to a wide network 220 via a connection 224, which typically includes a so-called "firewall" device or similar functionality. The local network interface 211 may comprise an Ethernet circuit card, a Bluetooth wireless configuration, or an IEEE 802.11 wireless configuration, however, numerous other types of interfaces may be implemented for the interface 211. The local network interface 211 may also provide the functionality of the transmitter 116, and the receiver 132 and the communication channel 120 may also be embodied in the local communications network 222.

[0070] I / O interfaces 208 and 213 can provide either or both serial and parallel connections, the former typically implemented according to the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). A storage device 209 is provided and typically includes a hard disk drive (HDD) 210. Other storage devices, such as floppy disk drives and magnetic tape drives (not shown), may also be used. An optical disk drive 212 is typically provided to serve as a non-volatile source of data. Portable memory devices, such as optical disks (e.g., CD-ROMs, DVDs, Blu-ray Discs), USB-RAM, portable, external hard drives, and floppy disks, may be used as suitable data sources for computer system 200. Typically, any of HDD 210, optical drive 212, and networks 220 and 222 may be configured to operate as video source 112 or as a destination for decoded video data to be stored for playback via display 214. Source device 110 and destination device 130 of system 100 may be embodied in computer system 200.

[0071] The components 205 to 213 of the computer module 201 typically communicate via an interconnected bus 204 and in a manner which results in a conventional mode of operation of the computer system 200 known to those skilled in the art. For example, the processor 205 is coupled to the system bus 204 using a connection 218. Similarly, the memory 206 and optical disk drive 212 are coupled to the system bus 204 by a connection 219. Examples of computers on which the described arrangements can be practiced include IBM-PCs and compatibles, SunSPARK stations, Apple Mac™ or alike computer systems.

[0072] If desired, video encoder 114 and video decoder 134, as well as the methods described below, may be implemented using computer system 200. In particular, video encoder 114 and video decoder 134, as well as the methods described below, may be implemented as one or more software application programs 233 executable within computer system 200. In particular, video encoder 114 and video decoder 134, as well as the steps of the methods described, are performed by instructions 231 (see FIG. 2B ) in software 233 executing within computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more specific tasks. The software may also be divided into two separate parts, where a first part and corresponding code modules perform the described methods and a second part and corresponding code modules manage the user interface between the first part and a user.

[0073] The software may be stored on a computer-readable medium, including, for example, the storage devices described below. The software is loaded from the computer-readable medium into computer system 200 and then executed by computer system 200. Such software or a computer-readable medium having a computer program recorded thereon is a computer program product. Use of the computer program product in computer system 200 preferably results in video encoder 114, video decoder 134, and advantageous apparatus for implementing the described methods.

[0074] The software 233 is typically stored on the HDD 210 or the memory 206. The software is loaded into the computer system 200 from a computer-readable medium and then executed by the computer system 200. Thus, for example, the software 233 may be stored on an optically readable disk storage medium (e.g., a CD-ROM) 225 that is read by the optical disk drive 212.

[0075] In some cases, the application program 233 may be supplied to the user encoded on one or more CD-ROMs 225 and read via the corresponding drive 212, or may be read by the user from the network 220 or 222. Furthermore, software may also be read into the computer system 200 from other computer-readable media. A computer-readable storage medium refers to any non-transitory, tangible storage medium that provides recorded instructions and / or data to the computer system 200 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, CD-ROMs, DVDs, Blu-ray™ disks, hard disk drives, ROMs or integrated circuits, USB memory, magneto-optical disks, or computer-readable cards such as PCMCIA cards, etc., whether such devices are internal or external to the computer module 201. Examples of transitory or non-tangible computer-readable transmission media that may also be involved in providing software, application programs, instructions, and / or video data or encoded video data to the computer module 401 include wireless or infrared transmission channels as well as network connections to another computer or networked device, and the Internet or intranet, including email transmissions and information stored on websites and the like.

[0076] A second portion of application program 233 and the corresponding code modules described above may be executed to implement one or more graphical user interfaces (GUIs) that are rendered or otherwise represented on display 214. Typically, through manipulation of keyboard 202 and mouse 203, a user of computer system 200 and applications may manipulate the interface in a functionally adaptable manner to provide control commands and / or input to applications associated with the GUI. Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface that utilizes speech prompts output via speaker 217 and user voice commands input via microphone 280.

[0077] Figure 2B is a detailed schematic block diagram of processor 205 and "memory" 234. Memory 234 represents a logical collection of all memory modules (including HDD 809 and semiconductor memory 206) that can be accessed by computer module 201 of Figure 2A.

[0078] When the computer module 201 is first powered on, it executes a power-on self-test (POST) program 250. The POST program 250 is typically stored in the ROM 249 of the semiconductor memory 206 of FIG. 2A. Hardware devices such as the ROM 249 that store software are sometimes referred to as firmware. The POST program 250 checks the hardware within the computer module 201 to ensure proper functionality and also verifies the processor 205, memory 234 (209, 206), and basic input / output system software (BIOS) module 251, which is typically also stored in the ROM 249, for correct operation. Once the POST program 250 operates correctly, the BIOS 251 boots the hard disk drive 210 of FIG. 2A. Booting the hard disk drive 210 causes a bootstrap loader program 252 resident on the hard disk drive 210 to execute via the processor 205. This loads the operating system 253 into the RAM memory 206, where the operating system 253 begins operation. Operating system 253 is a system-level application executable by processor 205 to implement various high-level functions including processor management, memory management, device management, storage management, software application interface, and general user interface.

[0079] The operating system 253 manages the memory 234 (209, 206) to ensure that each process or application running on the computer module 201 has enough memory to execute without conflicting with memory allocated to another process. Furthermore, the different types of memory available in the system 200 of FIG. 2A must be used appropriately so that each process can operate effectively. Thus, the aggregate memory 234 is not intended to indicate how specific segments of memory are allocated (unless otherwise specified), but rather to provide a general view of the memory accessible by the computer system 200 and how such is used.

[0080] As shown in FIG. 2B, processor 205 includes multiple functional modules, including a control unit 239, an arithmetic logic unit (ALU) 240, and a local or internal memory 248, sometimes referred to as a cache memory. Cache memory 248 typically includes a number of storage registers 244-246 within a register section. One or more internal buses 241 functionally interconnect these functional modules. Processor 205 also typically has one or more interfaces 242 for communicating with external devices via system bus 204 using connection 218. Memory 234 is coupled to bus 204 using connection 219.

[0081] Application program 233 includes a set of instructions 231, which may include conditional branch and loop instructions. Program 233 may also include data 232 used in the execution of program 233. Instructions 231 and data 232 are stored in memory locations 228, 229, 230 and 235, 236, 237, respectively. Depending on the relative sizes of instructions 231 and memory locations 228-230, a particular instruction may be stored in a single memory location, as represented by the instruction shown in memory location 230. Alternatively, the instruction may be segmented into multiple parts, each stored in a separate memory location, as represented by the instruction segments shown in memory locations 228 and 229.

[0082] Generally, the processor 205 is given a set of instructions to execute. The processor 205 awaits subsequent input, to which the processor 205 responds by executing another set of instructions. Each input may come from one or more of several sources, including data generated by one or more of the input devices 202, 203, data received from an external source via one of the networks 220, 202, data retrieved from one of the storage devices 206, 209, or data retrieved from a storage medium 225 inserted into a corresponding reader 212, all depicted in FIG. 2A. Execution of the set of instructions may, in some cases, result in the output of data. Execution may also include storing data or variables to memory 234.

[0083] Video encoder 114, video decoder 134, and the described methods may use input variables 254 stored in corresponding memory locations 255, 256, 257 in memory 234. Video encoder 114, video decoder 134, and the described methods generate output variables 261, which are stored in memory 234 in corresponding memory locations 262, 263, 264. Intermediate variables 258 may be stored in memory locations 259, 260, 266, and 267.

[0084] 2B, registers 244, 245, 246, arithmetic logic unit (ALU) 240, and control unit 239 cooperate to perform the sequence of micro-operations required to perform a "fetch, decode, and execute" cycle for every instruction in the instruction set that makes up program 233. Each fetch, decode, and execute cycle includes: a fetch operation that retrieves or reads an instruction 231 from a memory location 228, 229, 230; a decode operation in which the control unit 239 determines which instruction has been fetched; Execute operations in which the control unit 239 and / or ALU 240 execute instructions.

[0085] Thereafter, a further fetch, decode, and execute cycle for the next instruction may be performed. Similarly, a store cycle may be performed in which control unit 239 stores or writes a value to memory location 232.

[0086] Each step or sub-process in the described methods of Figures 13-18 is associated with one or more segments of program 233 and is typically performed by register sections 244, 245, 247, ALU 240, and control unit 239 within processor 205 operating together to perform the fetch, decode, and execute cycles of each instruction in the instruction set for the noted segment of program 233.

[0087] FIG. 3 is a schematic block diagram illustrating the functional modules of the video encoder 114. FIG. 4 is a schematic block diagram illustrating the functional modules of the video decoder 134. Generally, data passes through the functional modules within the video encoder 114 and the video decoder 134 in groups of samples or coefficients, such as a division of a block into fixed-size sub-blocks, or as an array. The video encoder 114 and the video decoder 134 may be implemented using a general-purpose computer system 200, as shown in FIGS. 2A and 2B, in which various functional modules may be implemented by dedicated hardware within the computer system 200, or by software executable within the computer system 200, such as one or more software code modules of a software application program 233 controlled during its execution by a processor 205. Alternatively, the video encoder 114 and the video decoder 134 may be implemented by a combination of dedicated hardware and software executable within the computer system 200. The video encoder 114, the video decoder 134, and the described methods may alternatively be implemented with dedicated hardware, such as one or more integrated circuits that perform functions or sub-functions of the described methods. Such dedicated hardware may include a graphics processing unit (GPU), a digital signal processor (DSP), an application specific standard product (ASSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or one or more microprocessors and associated memories. Specifically, the video encoder 114 includes modules 310-390, and the video decoder 134 includes modules 420-496, each of which may be implemented as one or more software code modules of the software application program 233.

[0088] The video encoder 114 of FIG. 3 is an example of a generic video coding (VVC) video encoding pipeline, although other video codecs may be used to perform the processing steps described herein. The video encoder 114 receives captured frame data 113, such as a series of frames, each of which includes one or more color channels. The frame data 113 may be in any chroma format, such as 4:0:0, 4:2:0, 4:2:2, or 4:4:4 chroma format. First, the block partitioner 310 divides the frame data 113 into CTUs, which are generally square in shape and are configured to use a specific size for the CTU. The CTU size may be, for example, 64x64, 128x128, or 256x256 luma samples. The block partitioner 310 further divides each CTU into one or more CBs according to the luma coding tree and the chroma coding tree. The luma channel is also referred to as the first chroma channel. Each chroma channel is also referred to as the second chroma channel. CBs may have various sizes and include both square and non-square aspect ratios. The operation of the block partitioner 310 is further described with reference to FIGS. 13-15. However, in the VVC standard, CBs, CUs, PUs, and TUs always have side lengths that are powers of two. Thus, a current CB, denoted as 312, is output from the block partitioner 310 and proceeds by iterating over one or more blocks of the CTU according to the CTU's luma coding tree and chroma coding tree. Options for partitioning a CTU into CBs are further described below with reference to FIGS. 5 and 6. While operations are generally described on a CTU basis, the video encoder 114 and video decoder 134 may operate on smaller sized regions to reduce memory consumption. For example, each CTU may be partitioned into smaller regions known as "virtual pipeline data units" (VPDUs) of size 64x64. This VPDU forms a data granularity amenable to pipelining in the hardware architecture, where the reduced memory footprint reduces silicon area and therefore cost compared to operating on a full CTU.

[0089] The CTUs resulting from the first partition of frame data 113 may be scanned in raster scan order and grouped into one or more "slices." A slice may be an "intra" (or "I") slice. An intra slice (I slice) indicates that all CUs in the slice are intra predicted. Alternatively, a slice may be uni- or bi-predictive ("P" or "B" slice, respectively), indicating the further availability of uni- and bi-prediction in the slice, respectively.

[0090] In an I slice, the coding tree of each CTU can branch below the 64x64 level into two separate coding trees, one for luma and one for chroma. The use of separate trees allows for different block structures between luma and chroma within the luma 64x64 area of ​​a CTU. For example, a large chroma CB may be placed with many small luma CBs, or vice versa. In a P or B slice, a single coding tree for a CTU defines a common block structure for luma and chroma. The resulting blocks of the single tree may be intra-predicted or inter-predicted.

[0091] For each CTU, the video encoder 114 operates in two stages. In the first stage (called the "search" stage), the block partitioner 310 tests various potential configurations of the coding tree. Each potential configuration of the coding tree has an associated "candidate" CB. This first stage involves testing various candidate CBs to select a CB that provides relatively high compression efficiency with relatively low distortion. This testing typically involves Lagrangian optimization, whereby the candidate CBs are evaluated based on a weighted combination of rate (coding cost) and distortion (error with respect to the input frame data 113). The "best" candidate CB (the CB with the lowest evaluated rate / distortion) is selected for subsequent encoding into the bitstream 115. Evaluation of the candidate CBs includes the option of using the CB for a given area or further dividing the area according to various partitioning options, with each resulting smaller area either coded with an additional CB or further dividing the area. Consequently, both the coding tree and the CB itself are selected in the search stage.

[0092] For each CB, e.g., CB 312, the video encoder 114 generates a prediction block (PB), indicated by arrow 320. PB 320 is a prediction of the content of the associated CB 312. Subtractor module 322 generates a difference between PB 320 and CB 312, indicated as 324 (or a "residual," which refers to the difference in the spatial domain). Difference 324 is the block-sized difference between corresponding samples in PB 320 and CB 312. Difference 324 is transformed and quantized, and represented as a transform block (TB), indicated by arrow 336. PB 320 and the associated TB 336 are typically selected from one of many possible candidate CBs, based, for example, on estimated cost or distortion.

[0093] A candidate coding block (CB) is a CB that results from one of the prediction modes available to the video encoder 114 for the associated PB and the resulting residual. When combined with the predicted PB in the video decoder 114, the TB 336 reduces the difference between the decoded CB and the original CB 312, at the expense of additional signal in the bitstream.

[0094] Thus, each candidate coding block (CB), i.e., a prediction block (PB) combined with a transform block (TB), has an associated coding cost (or "rate") and an associated difference (or "distortion"). The distortion of this CB is typically estimated as a sample value difference, such as the sum of absolute differences (SAD) or the sum of squared differences (SSD). The estimate obtained from each candidate PB may be determined by a mode selector 386 using the difference 324 to determine a prediction mode 387. The prediction mode 387 indicates a decision to use a particular prediction mode for the current CB, e.g., intra-frame prediction or inter-frame prediction. Estimating the coding cost associated with each candidate prediction mode and the corresponding residual coding can be performed at a significantly lower cost than entropy coding of the residual. Thus, a large number of candidate modes can be evaluated to determine the optimal mode for rate-distortion detection, even in a real-time video encoder.

[0095] Determining the optimal mode in terms of rate distortion is typically achieved using a variation of Lagrangian optimization.

[0096] A Lagrangian or similar optimization process can be employed to select both the optimal partitioning of the CTUs into CBs (by the block partitioner 310) and the selection of the best prediction mode from multiple possibilities. Through application of the Lagrangian optimization process of the candidate modes in the mode selection module 386, the intra-prediction mode with the lowest cost measure is selected as the "best" mode. This lowest-cost mode is the selected second transform index 388 and is encoded into the bitstream 115 by the entropy encoder 338.

[0097] In the second operation stage of the video encoder 114 (called the "coding" stage), iteration over the determined coding trees of each CTU is performed in the video encoder 114. For a CTU using separate trees, for each 64x64 luma region of the CTU, the luma coding tree is coded first, followed by the chroma coding tree. Only the luma CB is coded in the luma coding tree, and only the chroma CB is coded in the chroma coding tree. For a CTU using a shared tree, a single tree describes the CUs, i.e., the luma CB and the chroma CB, according to the common block structure of the shared tree.

[0098] The entropy encoder 338 supports both variable-length coding of syntax elements and arithmetic coding of syntax elements. Portions of the bitstream, such as "parameter sets," such as the sequence parameter set (SPS) and picture parameter set (PPS), use a combination of fixed-length and variable-length codewords. A slice (also called a contiguous portion) has a slice header that uses variable-length coding, followed by slice data that uses arithmetic coding. The slice header defines parameters specific to the current slice, such as slice-level quantization parameter offsets. This slice data contains syntax elements for each CTU within the slice. The use of variable-length coding and arithmetic coding requires sequential parsing within each portion of the bitstream, which may be delineated using start codes to form "network abstraction layer units" or "NAL units." Arithmetic coding is supported using a context-adaptive binary arithmetic coding process. Arithmetically coded syntax elements consist of a sequence of one or more "bins." Bins, like bits, have values ​​of "0" or "1." However, bins are not coded as discrete bits in the bitstream 115. A bin has an associated predicted (or "likely" or "most likely") value known as a "context" and an associated probability. When the actual bin being coded matches the likely value, a "most probable symbol" (MPS) is coded. Coding the most probable symbol is relatively inexpensive in terms of consumed bits in the bitstream 115, costing less than one discrete bit. When the actual bin being coded does not match the likely value, a "least probable symbol" (LPS) is coded. Coding the least probable symbol has a relatively high cost in terms of consumed bits. The bin coding technique allows for efficient coding of bins with biased "0" vs. "1" probabilities. For syntax elements with two possible values ​​(i.e., flags), a single bin is sufficient.For syntax elements that have many possible values, a sequence of bins is needed.

[0099] The presence of a later bin in the sequence may be determined based on the value of the previous bin in the sequence. Furthermore, each bin may be associated with two or more contexts. The selection of a particular context may depend on the previous bin of the syntax element, the bin values ​​of adjacent syntax elements (i.e., from adjacent blocks), etc. Each time a context coding bin is coded, the context selected for that bin is updated in a manner that reflects the new bin value (if any). In this way, binary arithmetic coding schemes are said to be adaptive.

[0100] Also supported by the video encoder 114 are bins that lack context ("bypass bins"). Bypass bins are coded assuming an equal probability distribution between "0" and "1". Thus, each bin has a coding cost of 1 bit in the bitstream 115. The absence of context saves memory and reduces complexity. Thus, bypass bins are used when the distribution of values ​​for a particular bin is not biased. One example of an entropy coder that uses context and adaptation is known in the art as CABAC (Context-Adaptive Binary Arithmetic Coder), and many variations of this coder are used in video coding.

[0101] The entropy encoder 338 uses a combination of context coding bins and bypass coding bins to encode a quantization parameter 392 and, if used for the current CB, an LFNST index 388. The quantization parameter 392 is coded using a "delta QP." This delta QP is signaled at most once in each area known as a "quantization group." The quantization parameter 392 is applied to the residual coefficients of the luma CB. An adjusted quantization parameter is applied to the residual coefficients of the collocated chroma CB. This adjusted quantization parameter may include a mapping from the luma quantization parameter 392 according to a mapping table and a CU level offset selected from a list of offsets. The second transform index 388 is signaled when the residual associated with the transform block contains residual coefficients that are valid only for those coefficient positions that depend on transformation to the first coefficients by application of a second transform.

[0102] The multiplexer module 384 outputs the PB 320 from the intra-frame prediction module 364 according to a determined best intra-prediction mode selected from the tested prediction modes of each candidate CB. The candidate prediction modes need not include all possible prediction modes supported by the video encoder 114. Intra-prediction is classified into three types: "DC intra-prediction" involves populating the PB with a single value representing the average of nearby reconstructed samples; "planar intra-prediction" involves populating the PB with samples according to a plane, where DC offsets and vertical and horizontal gradients are derived from nearby reconstructed neighboring samples; these nearby reconstructed samples typically include a row of reconstructed samples above the current PB, extending to the right of the PB to some extent, and a column of reconstructed samples to the left of the current PB, extending downward beyond the PB to some extent; "angular intra-prediction" involves populating the PB with reconstructed neighboring samples that have been filtered and propagated in a particular direction (or "angle") across the PB. VVC65 supports rectangular blocks that allow additional angles not available in rectangular blocks, resulting in a total of 87 angles. A fourth type of intra prediction is available for chroma PBs, whereby the PBs are generated from collocated luma reconstruction samples according to a "cross-component linear model" (CCLM) mode. Three different CCLM modes are available, each using a different model derived from adjacent luma and chroma samples. The derived model is used to generate blocks of samples for the chroma PB from collocated luma samples.

[0103] If no previously reconstructed samples are available, for example at the edge of a frame, a default halftone value of half the range of samples is used. For example, for 10-bit video, a value of 512 is used. For a CB placed in the top-left position of the frame, since no previously available samples exist, angular and intraplane prediction modes produce the same output as DC prediction mode, i.e., a plane of samples with halftone values ​​as magnitudes.

[0104] For inter-frame prediction, the prediction block 382 is generated by the motion compensation module 380 using samples from one or two frames preceding the current frame in the coding order frame in the bitstream and output as the PB 320 by the multiplexer module 384. Furthermore, for inter-frame prediction, a single coding tree is typically used for both the luma and chroma channels. The order of coding frames in the bitstream may differ from the order of frames at capture or display. If one frame is used for prediction, the block is said to be "unidirectionally predicted" and has one associated motion vector. If two frames are used for prediction, the block is said to be "bidirectionally predicted" and has two associated motion vectors. For P slices, each CU may be intra-predicted or unidirectionally predicted. For B slices, each CU may be intra-predicted, unidirectionally predicted, or bidirectionally predicted. Frames are typically coded using a "group of pictures" structure, allowing for temporal hierarchy of frames. A frame may be divided into multiple slices, each of which encodes a portion of the frame. The temporal hierarchy of frames allows frames to reference previous and subsequent pictures in the order in which they are displayed: the pictures are coded in the order necessary to ensure the dependencies for decoding each frame.

[0105] Samples are selected according to a motion vector 378 and a reference picture index. The motion vector 378 and the reference picture index apply to all color channels; therefore, inter prediction is primarily described in terms of operation on the PU rather than the PB; i.e., the decomposition of each CTU into one or more inter prediction blocks is described using a single coding tree. Inter prediction methods can differ in the number and precision of motion parameters. The motion parameters typically include a reference frame index indicating which reference frame from a list of reference frames should be used, plus a spatial transformation for each of the reference frames, but may also include more frames, extra frames, or complex affine parameters such as scaling and rotation. Furthermore, a predetermined motion refinement process may be applied to generate a dense motion estimate based on the reference sample block.

[0106] Determining and selecting a PB 320 and subtracting it from the original sample block in a subtractor 322 results in a residual with the lowest coding cost, represented by 324, which undergoes lossy compression. The lossy compression process includes the steps of transform, quantization, and entropy coding. A forward first transform module 326 applies a forward transform to the difference 324, converting it from the spatial domain to the frequency domain and generating first transform coefficients, represented by arrow 328. The maximum first transform size in one dimension is either a 32-point DCT-2 or a 64-point DCT-2 transform. If the CB being coded is larger than the maximum supported first transform size, represented as a block size, i.e., 64x64 or 32x32, the first transform 326 is applied in a tiled manner to transform all samples of the difference 324. Application of the transform 326 results in multiple TBs for the CB. When each application of the transform operates on a TB larger than 32x32, e.g., a 64x64 difference 324, all resulting first transform coefficients 328 outside the top-left 32x32 area of ​​the TB are set to zero, i.e., discarded. The remaining first transform coefficients 328 are passed to a quantizer module 334. The first transform coefficients 328 are quantized according to a quantization parameter 392 associated with the CB to generate first transform coefficients 332. The quantization parameter 392 may be different for the luma CB versus each chroma CB. The first transform coefficients 332 are passed to a forward second transform module 330, which generates transform coefficients represented by arrow 336 by performing a non-separable second transform (NSST) operation or by bypassing the second transform. The forward first transform is typically separable, transforming a set of rows of each TB and then a set of columns of each TB. The forward first transform module 326 uses either a Type II Discrete Cosine Transform (DCT-2) in the horizontal and vertical directions, or a bypass of the horizontal and vertical transforms, or a combination of a Type VII Discrete Sine Transform (DCT-7) and a Type VIII Discrete Cosine Transform (DCT-8) in either the horizontal or vertical directions for luminance TBs not exceeding 16 samples in width and height.The use of a combination of DST-7 and DCT-8 is called a "Multiple Transform Selection Set" (MTS) in the VVC standard.

[0107] The forward second transform of module 330 is generally a non-separable transform, which is applied only to the residual of intra-predicted CUs and may nevertheless be bypassed. The forward second transform operates on either 16 samples (arranged as a 4x4 sub-block in the top-left corner of the first transform coefficients 328) or 48 samples (arranged as three 4x4 sub-blocks in the top-left corner of the first transform coefficients 328) to generate a set of second transform coefficients. The set of second transform coefficients may be smaller in number than the set of first transform coefficients from which they are derived. Application of the second transform to only a set of coefficients that are adjacent to each other and include a DC coefficient is called a "low-frequency non-separable second transform (LFNST)." Furthermore, when an LFNST is applied, all remaining coefficients in the TB must be zero in both the first transform domain and the second transform domain.

[0108] The quantization parameter 392 is constant for a given TB, thus resulting in uniform scaling for the generation of residual coefficients in the first transform domain for the TB. The quantization parameter 392 may vary periodically via a signaled "delta quantization parameter." The delta quantization parameter (delta QP) is signaled once for CUs contained within a predetermined area called a "quantization group." If a CU is larger than the quantization group size, the delta QP is signaled once using one of the TBs of the CU. That is, the delta QP is signaled once by the entropy encoder 338 for the first quantization group of the CU and not for subsequent quantization groups of the CU. Non-uniform scaling is also possible through the application of a "quantization matrix," whereby the scaling factor applied to each residual coefficient is derived from a combination of the quantization parameter 392 and a corresponding entry in the scaling matrix. The scaling matrix can have a size smaller than the TB size, and when applied to the TB, a nearest neighbor approach is used to provide a scaling value for each residual coefficient from a scaling matrix smaller than the TB size. The residual coefficients 336 are provided to an entropy encoder 338 for encoding in the bitstream 115. Typically, the residual coefficients of each TB having at least one valid residual coefficient of a TU are scanned to generate an ordered list of values ​​according to a scan pattern. This scan pattern generally scans the TB as a sequence of 4x4 "subblocks," providing a regular scan operation with a granularity of 4x4 sets of residual coefficients, the configuration of the subblocks depending on the size of the TB. The scan within each subblock, and the progression from one subblock to the next, typically follows a backward diagonal scan pattern. Furthermore, a quantization parameter 392 is encoded into the bitstream 115 using a delta QP syntax element, and a second transform index 388 is encoded in the bitstream 115 under conditions described with reference to Figures 13-15.

[0109] As described above, the video encoder 114 requires access to a frame representation that corresponds to the decoded frame representation seen by the video decoder 134. Accordingly, the residual coefficients 336 are passed through an inverse second transform module 344, which operates according to a second transform index 388, to generate intermediate inverse transform coefficients represented by arrow 342. The intermediate inverse transform coefficients are inverse quantized by an inverse quantization module 340 according to a quantization parameter 392 to generate inverse transform coefficients represented by arrow 346. The intermediate inverse transform coefficients 346 are passed to an inverse first transform module 348 to generate residual samples represented by arrow 350 of the TU. The type of inverse transform performed by the inverse second transform module 344 corresponds to the type of forward transform performed by the forward second transform module 330. The type of inverse transform performed by the inverse first transform module 348 corresponds to the type of first transform performed by the first transform module 326. The summing module 352 sums the residual samples 350 and the PU 320 to generate reconstructed samples (indicated by arrow 354) for the CU.

[0110] The reconstructed samples 354 are passed to a reference sample cache memory 356 and an in-loop filter module 368. The reference sample cache memory 356 is typically implemented using static RAM on the ASIC (thus avoiding costly off-chip memory accesses) and provides the minimum sample storage required to satisfy the dependencies for generating intra-frame PBs for subsequent CUs in the frame. The minimum dependencies typically include a "line buffer" of samples along the bottom of a row of CTUs for use by the CTU's subsequent row and column buffering, the extent of which is set by the CTU's height. The reference sample cache memory 356 provides reference samples (indicated by arrow 358) to a reference sample filter 360. The sample filter 360 applies a smoothing operation to generate filtered reference samples (indicated by arrow 362). The filtered reference samples 362 are used by an intra-frame prediction module 364 to generate an intra-predicted block of samples, represented by arrow 366. For each candidate intra-prediction mode, the intra-frame prediction module 364 generates a block of samples, i.e., 366. The blocks of samples 366 are generated by module 364 using techniques such as DC, planar or intra-angle prediction.

[0111] The in-loop filter module 368 applies several filtering stages to the reconstructed samples 354. These filtering stages include a "deblocking filter" (DBF), which applies smoothing aligned to CU boundaries to reduce artifacts resulting from discontinuities. Another filtering stage present in the in-loop filter module 368 is an "adaptive loop filter," which applies a Wiener-based adaptive filter to further reduce distortion. A further available filtering stage in the in-loop filter module 368 is a "sample adaptive offset" (SAO) filter. This SAO filter operates by first classifying the reconstructed samples into one or more categories and then applying an offset at the sample level according to the assigned category.

[0112] The filtered samples, represented by arrow 370, are output from the in-loop filter module 368. The filtered samples 370 are stored in a frame buffer 372. The frame buffer 372 typically has the capacity to store several pictures (e.g., up to 16) and is therefore stored in the memory 206. The frame buffer 372 is typically not stored using on-chip memory due to its required large memory consumption. Therefore, access to the frame buffer 372 is costly in terms of memory bandwidth. The frame buffer 372 provides reference frames (represented by arrow 374) to a motion estimation module 376 and a motion compensation module 380.

[0113] The motion estimation module 376 estimates several “motion vectors” (denoted as 378), each of which is a Cartesian spatial offset from the location of the current CB and references a block in one of the reference frames in the frame buffer 372. A filtered block of reference samples (denoted as 382) is generated for each motion vector. The filtered reference samples 382 form further candidate modes available for potential selection by the mode selector 386. Furthermore, for a given CU, the PU 320 may be formed using one (“unidirectionally predicted”) reference block or two (“bidirectionally predicted”) reference blocks. For a selected motion vector, the motion compensation module 380 generates the PB 320 according to a filtering process that supports sub-pixel accuracy in motion vectors. Therefore, the motion estimation module 376 (which operates on many candidate motion vectors) may perform a simplified filtering process to reduce computational complexity compared to the motion compensation module 380 (which operates on only the selected candidate). When video encoder 114 selects inter prediction for a CU, motion vector 378 is coded into bitstream 115.

[0114] Although the video encoder 114 of FIG. 3 is described with reference to generic video coding (VVC), other video coding standards or processing stages of modules 310-390 may be used. The frame data 113 (and bitstream 115) may be read from (or written to) memory 206, hard disk drive 210, CD-ROM, Blu-ray Disc, or other computer-readable storage medium. Additionally, the frame data 113 (and bitstream 115) may be received from (or transmitted to) an external source, such as a server connected to a communications network 220 or a radio frequency receiver. The communications network 220 may provide limited bandwidth, necessitating the use of rate control in the video encoder 114 to avoid saturating the network when the frame data 113 is difficult to compress. Furthermore, the bitstream 115 may be constructed from one or more slices representing spatial sections (a collection of CTUs) of the frame data 113, generated by one or more instances of the video encoder 114, operating cooperatively under the control of the processor 205. In the context of this disclosure, slices may also be referred to as "contiguous portions" of a bitstream: slices are contiguous in the bitstream and can be coded or decoded as separate portions, such as when parallel processing is used.

[0115] Video decoder 134 is shown in Figure 4. Video decoder 134 of Figure 4 is an example of a generic video coding (VVC) video decoding pipeline, although other video codecs may be used to perform the processing steps described herein. As shown in Figure 4, a bitstream 133 is input to video decoder 134. Bitstream 133 may be read from memory 206, hard disk drive 210, CD-ROM, Blu-ray Disc, or other non-transitory computer-readable storage medium. Alternatively, bitstream 133 may be received from an external source, such as a server or radio frequency receiver connected to communications network 220.

[0116] The bitstream 133 contains encoded syntax elements representing the captured frame data to be decoded. The bitstream 133 is input to the entropy decoder module 420. The entropy decoder module 420 extracts syntax elements from the bitstream 133 by decoding a sequence of "bins" and passes the values ​​of the syntax elements to other modules in the video decoder 134. The entropy decoder module 420 uses variable-length and fixed-length decoding to decode the SPS, PPS, or slice header of the arithmetic decoding engine and decodes the syntax elements of the slice data as a sequence of one or more bins. Each bin can use one or more "contexts," with the context describing the probability levels used to code the "1" and "0" values ​​of the bin. If multiple contexts are available for a given bin, a "context modeling" or "context selection" process is performed to select one of the available contexts for decoding the bin. The process of decoding the bins sequentially forms a feedback loop, so that each slice can be decoded in its entirety by a given entropy decoder 420 instance. A single (or a few) high-performance entropy decoder 420 instances can decode all slices for a frame from bitstream 115, and multiple low-performance entropy decoder 420 instances can simultaneously decode slices for a frame from bitstream 133.

[0117] The entropy decoder module 420 applies an arithmetic coding algorithm, such as "context-adaptive binary arithmetic coding" (CABAC), to decode syntax elements from the bitstream 133. The decoded syntax elements are used to reconstruct parameters within the video decoder 134. The parameters include residual coefficients (represented by arrow 424), quantization parameters 474, second transform indices 470, and mode selection information such as intra-prediction modes (represented by arrow 458). This mode selection information also includes information such as motion vectors and the division of each CTU into one or more CBs. The parameters are used to generate PBs, typically in combination with sample data from previously decoded CBs.

[0118] The residual coefficients 424 are passed to an inverse second transform module 436, which applies a second transform or performs no operation (bypass) according to the method described with reference to Figures 16-18. The inverse second transform module 436 generates reconstructed transform coefficients 432, i.e., first transform domain coefficients, from the second transform domain coefficients. The reconstructed transform coefficients 432 are input to a dequantizer module 428. The inverse quantizer module 428 performs inverse quantization (or "scaling") on the residual coefficients 432, i.e., in the first transform coefficient domain, according to a quantization parameter 474 to generate reconstructed intermediate transform coefficients represented by arrow 440. If the use of a non-uniform inverse quantization matrix is ​​indicated in the bitstream 133, the video decoder 134 reads the quantization matrix from the bitstream 133 as a sequence of scaling coefficients and arranges the scaling coefficients in the matrix. The inverse scaling uses the quantization matrix in combination with the quantization parameter to generate reconstructed intermediate transform coefficients 440.

[0119] The reconstructed transform coefficients 440 are passed to an inverse first transform module 444, which converts the coefficients 440 from the frequency domain back to the spatial domain. The result of the operation of module 444 is a block of residual samples, represented by arrow 448. The block of residual samples 448 is equal in size to the corresponding CB. The residual samples 448 are provided to an addition module 450, where they are added to the decoded PB (represented as 452) to generate a block of reconstructed samples, represented by arrow 456. The reconstructed samples 456 are provided to a reconstructed sample cache memory 460 and an in-loop filtering module 488, which generates a reconstructed block of frame samples, represented as 492. The frame samples 492 are written to a frame buffer 496.

[0120] The reconstructed sample cache memory 460 operates similarly to the reconstructed sample cache memory 356 of the video encoder 114. The reconstructed sample cache memory 460 provides storage for reconstructed samples needed to intra-predict subsequent CBs without going through the memory 206 (e.g., by substituting the data 232, which is typically on-chip memory). Reference samples, represented by arrow 464, are obtained from the reconstructed sample cache memory 460 and provided to a reference sample filter 468 to generate filtered reference samples, indicated by arrow 472. The filtered reference samples 472 are provided to an intra-frame prediction module 476. The module 476 generates blocks of intra-predicted samples, represented by arrow 480, according to the intra-prediction mode parameter 458 signaled in the bitstream 133 and decoded by the entropy decoder 420. The blocks of samples 480 are generated using modes such as DC, planar, or angular intra prediction.

[0121] When the prediction mode of a CB is indicated to use intra prediction in the bitstream 133, the intra-predicted samples 480 form the decoded PB 452 via a multiplexer module 484. Intra prediction generates a predictive block of samples (PB), i.e., a block in one color component derived using "neighboring samples" in the same color component. These neighboring samples are samples adjacent to the current block and have already been reconstructed by preceding it in block decoding order. When luma and chroma blocks are juxtaposed, the luma and chroma blocks may use different intra prediction modes. However, the two chroma CBs share the same intra prediction mode.

[0122] When the prediction mode of the CB is indicated as inter prediction in the bitstream 133, the motion compensation module 434 uses the motion vector (decoded from the bitstream 133 by the entropy decoder 420) and the reference frame index to select and filter a block of samples 498 from the frame buffer 496 to generate a block of inter predicted samples represented as 438. The block of samples 498 is obtained from a previously decoded frame stored in the frame buffer 496. In the case of bidirectional prediction, two sample blocks are generated and blended together to generate samples for the decoded PB 452. The frame buffer 496 receives filtered block data 492 from the in-loop filtering module 488. Similar to the in-loop filtering module 368 of the video encoder 114, the in-loop filtering module 488 applies any of DBF, ALF, and SAO filtering operations. Generally, motion vectors are applied to both the luma and chroma channels, but the filtering process for sub-sample interpolation in the luma and chroma channels is different.

[0123] 5 is a schematic block diagram illustrating a collection 500 of available partitions or divisions of a region into one or more subregions within a generic video coding tree structure. The partitions shown in collection 500 are available to block partitioner 310 of encoder 114 to partition each CTU into one or more CUs or CBs according to the coding tree, as determined by Lagrangian optimization, as described with reference to FIG.

[0124] Although collection 500 shows only square regions being divided into other, possibly non-square, sub-regions, it should be understood that collection 500 illustrates the potential division of a parent node in the coding tree into child nodes in the coding tree and does not require that the parent node correspond to a square region. If the containing region is non-square, the dimensions of the blocks resulting from the division are scaled according to the aspect ratio of the containing block. When a region is no longer divided, i.e., at a leaf node of the coding tree, a CU occupies the region.

[0125] The process of subdividing a region into subregions must terminate when the resulting subregion reaches a minimum CU size, typically 4x4 luma samples. In addition to constraining CUs to prohibit block regions smaller than a predetermined minimum size, e.g., 16 samples, CUs are constrained to have a minimum width or height of 4. Other minimum values ​​are possible for both width and height, or for both width and height. The process of subdivision may terminate before the deepest level of decomposition, resulting in a CU larger than the minimum CU size. It is possible for no splitting to occur, resulting in a single CU occupying the entire CTU. A single CU occupying the entire CTU is the largest available coding unit size. The use of a subsampled chroma format, such as 4:2:0, allows the video encoder 114 and video decoder 134 configurations to terminate the splitting of regions in the chroma channels earlier than in the luma channel, including in the case of a shared coding tree that defines the block structure for the luma and chroma channels. If separate coding trees are used for luma and chroma, constraints on the available splitting operations guarantee a minimum chroma CB area of ​​16 samples, even if such a CB is co-located with a larger luma area, e.g., 64 luma samples.

[0126] Leaf nodes of the coding tree contain CUs with no further subdivision. For example, leaf node 510 contains one CU. Non-leaf nodes of the coding tree may contain a leaf node split into two or more further nodes, each forming a CU, or a non-leaf node containing further divisions into smaller regions. At each leaf node of the coding tree, there is one coding block for each color channel. A division that ends at the same depth for both luma and chroma results in three juxtaposed CBs. A division that ends at a luma depth deeper than chroma results in multiple luma CBs juxtaposed with the chroma channel CBs.

[0127] Quadtree partitioning 512 divides the inclusion region into four equally sized regions, as shown in Figure 5. Compared to HEVC, generic video coding (VVC) achieves additional flexibility through additional partitioning, including horizontal binary partitioning 514 and vertical binary partitioning 516. Each of partitions 514 and 516 divides the inclusion region into two equally sized regions. This partitioning occurs along either a horizontal boundary (514) or a vertical boundary (516) within the containing block.

[0128] Further flexibility is achieved in versatile video coding with the addition of horizontal ternary partitioning 518 and vertical ternary partitioning 520. Ternary partitioning 518 and 520 divide a block into three regions bounded either horizontally (518) or vertically (520) along ¼ and ¾ of the width or height of the containing region. The combination of quadtrees, binary trees, and ternary trees is called a "QTBTTT." The root of the tree contains zero or more quadtree partitions (the "QT" section of the tree). Once the QT section ends, zero or more binary or ternary partitions (the "multitree" or "MT" section of the tree) arise, eventually terminating in a tree leaf node CB or CU. If the tree describes all color channels, the tree leaf node is a CU. If the tree describes luma or chroma channels, the tree leaf node is a CB.

[0129] Compared to HEVC, which supports only quad-trees and therefore only square blocks, QTBTTT offers many more possible CU sizes, especially considering the possible recursive application of binary and / or ternary tree partitioning. When only quad-tree partitioning is available, each increase in coding tree depth corresponds to a reduction in CU size to one-quarter of the size of the parent area. In VVC, the availability of binary and ternary partitioning means that the coding tree depth no longer directly corresponds to the CU area. The potential for unusual (non-square) block sizes can be reduced by constraining partitioning options to eliminate partitions that would result in block widths or heights that are either less than four samples or are not a multiple of four samples. Generally, this constraint applies when considering luma samples. However, in the described configuration, the constraint can be applied separately to blocks for the chroma channels. Applying the partitioning option to the chroma channels can result in different minimum block sizes for luma and chroma, such as when the frame data is in 4:2:0 chroma format or 4:2:2 chroma format. Each division produces sub-regions whose horizontal dimension remains the same, is halved, or is quartered with respect to this region, and since the CTU size is a power of two, the horizontal dimension of all CUs is also a power of two.

[0130] 6 is a schematic flow diagram illustrating a data flow 600 of the QTBTTT (or "coding tree") structure used in general-purpose video coding. The QTBTTT structure is used for each CTU to define the partitioning of the CTU into one or more CUs. The QTBTTT structure for each CTU is determined by block partitioner 310 in video encoder 114 and encoded into bitstream 115 or decoded from bitstream 133 by entropy decoder 420 in video decoder 134. Data flow 600 further characterizes the permissible combinations available to block partitioner 310 for partitioning the CTU into one or more CUs according to the partitioning shown in FIG. 5.

[0131] Starting from the top level of the hierarchy, i.e., CTU, zero or more quad-tree splits are first performed. Specifically, a quad-tree (QT) split decision 610 is made by the block partitioner 310. A decision at 610 returning a "1" symbol indicates a decision to split the current node into four subnodes according to the quad-tree split 512. This results in four new nodes, such as 620, being generated, and for each new node, a return is made to the QT split decision 610. Each new node is considered in raster (or Z-scan) order. Alternatively, if the QT split decision 610 indicates that no further splits should be performed (returning a "0" symbol), the quad-tree split stops and a multi-tree (MT) split is then considered.

[0132] First, an MT split decision 612 is made by the block partitioner 310. At 612, a decision to perform MT splitting is indicated. Returning a "0" symbol at decision 612 indicates that no further splitting of the node into subnodes is performed. If no further splitting of the node is performed, the node is a leaf node of the coding tree and corresponds to a CU. The leaf node is output at 622. Alternatively, if MT split 612 indicates a decision to perform MT splitting (returning a "1" symbol), the block partitioner 310 proceeds to direction decision 614.

[0133] The direction decision 614 indicates the direction of the MT partition as either horizontal ("H" or "0") or vertical ("V" or "1"). The block partitioner 310 proceeds to decision 616 if decision 614 returns a "0" indicating a horizontal direction. The block partitioner 310 proceeds to decision 618 if decision 614 returns a "1" indicating a vertical direction.

[0134] In each of decisions 616 and 618, the number of partitions for the MT split is indicated as either two (binary split or "BT") or three (ternary split or "TT") for the BT / TT split. That is, BT / TT split decision 616 is made by block partitioner 310 when the indicated direction from 614 is horizontal, and BT / TT split decision 618 is made by block partitioner 310 when the indicated direction from 614 is vertical.

[0135] The BT / TT split decision 616 indicates whether the horizontal split is a binary split 514, indicated by returning a "0," or a ternary split 518, indicated by returning a "1." When the BT / TT split decision 616 indicates a binary split, two nodes are generated by the block partitioner 310 according to the binary horizontal split 514 in an HBT CTU node generation step 625. When the BT / TT split 616 indicates a ternary split, three nodes are generated by the block partitioner 310 according to the ternary horizontal split 518 in an HTT CTU node generation step 626.

[0136] The BT / TT split decision 618 indicates whether the vertical split is a binary split 516, indicated by returning a "0," or a ternary split 520, indicated by returning a "1." When the BT / TT split 618 indicates a binary split, in the generate VBT CTU node step 627, two nodes are generated by the block partitioner 310 according to the vertical binary split 516. When the BT / TT split 618 indicates a ternary split, in the generate VBT CTU node step 628, three nodes are generated by the block partitioner 310 according to the vertical ternary split 520. For each node resulting from steps 625-628, the recursion of the data flow 600 back to the MT split decision 612 is applied in either a left-to-right or top-to-bottom order, depending on the direction 614. As a result, binary tree and ternary tree splitting can be applied to generate CUs of various sizes.

[0137] 7A and 7B provide an example 700 of partitioning a CTU 710 into several CUs or CBs. An example of a CU 712 is shown in FIG. 7A. FIG. 7A shows the spatial organization of CUs in a CTU 710. The example partition 700 is also shown as a coding tree 720 in FIG. 7B.

[0138] For each non-leaf node in CTU 710 in FIG. 7A , e.g., nodes 714, 716, and 718, the contained nodes (which may be further divided or may be CUs) are scanned or traversed in “Z-order” to create a list of nodes, represented as columns in coding tree 720. In the case of a quad-tree split, the Z-order scan is from top-left to top-right, followed by bottom-left to bottom-right. In the case of horizontal and vertical splits, the Z-order scan (traversal) is simplified to a top-to-bottom scan and a left-to-right scan, respectively. Coding tree 720 in FIG. 7B lists all nodes and CUs according to the applied scan order. Each split generates a list of two, three, or four new nodes at the next level of the tree until a leaf node (CU) is reached.

[0139] After decomposing an image into CTUs and then further decomposing them into CUs by block partitioner 310 and using the CUs to generate each residual block (324) as described with reference to FIG. 3, the residual blocks undergo a forward transform and quantization by video encoder 114. The resulting TBs 336 are then scanned to form a sequential list of residual coefficients as part of the operation of entropy coding module 338. An equivalent process is performed within video decoder 134 to obtain the TBs from bitstream 133.

[0140] 8A, 8B, and 8C show the subdivision levels resulting from the division in the coding tree and the corresponding effect on the division of coding tree units into quantization groups. Delta QP (392) informs the TB residual at most once per quantization group. In HEVC, the definition of quantization groups corresponds to the coding tree depth, since that definition results in an area of ​​fixed size. In VVC, that additional division means that the coding tree depth is no longer a good proxy for CTU area. In VVC, "subdivision levels" are defined, with each increment corresponding to half of the contained area.

[0141] FIG. 8A shows a collection 800 of partitions in a coding tree and corresponding subdivision levels. At the root node of the coding tree, the subdivision level is initialized to zero. When a coding tree includes a quadtree partition, e.g., 810, its subdivision level increases by two for any CU contained therein. When a coding tree includes a binary partition, e.g., 812, its subdivision level increases by one for any CU contained therein. When a coding tree includes a ternary partition, e.g., 814, its subdivision level increases by two for the outer two CUs and by one for the inner CU resulting from the ternary partition. As described with reference to FIG. 6, when the coding tree for each CTU is traversed, the subdivision level of each resulting CU is determined according to collection 800.

[0142] Figure 8B shows an example set 840 of CU nodes to illustrate the effect of splitting. An example parent node 820 of set 840 with a subdivision level of zero corresponds to a CTU of size 64x64 in the example of Figure 8B. Parent node 820 is ternary split to generate three child nodes 821, 822, and 823 of sizes 16x64, 32x64, and 16x64, respectively. Child nodes 821, 822, and 823 have subdivision levels of 2, 1, and 2, respectively.

[0143] In the example of Figure 8B, the quantization group threshold is set to 1, corresponding to half of the 64x64 area, i.e., an area of ​​2048 samples. A flag tracks the start of a new QG. The flag tracking a new QG is reset for any node with a subdivision level equal to or less than the quantization group threshold. This flag is set when crossing a parent node 820 with a subdivision level of zero. The center CU 822, which is 32x64, has an area of ​​2048 samples, but the two sibling CUs 821 and 823 have an area of ​​two subdivision levels, i.e., 1024. Therefore, the flag is not reset when crossing the center CU, and the quantization group does not start at the center CU. Instead, the flag starts from the parent node shown at 824 according to the initial flag reset. Effectively, the QP can only change on boundaries aligned to multiples of the quantization group area. The delta QP is signaled along with the residual of the TB associated with the CB. If there are no significant coefficients, there is no opportunity to code the delta QP.

[0144] FIG. 8C shows an example 860 of dividing a CTU 862 into multiple CUs and QGs to illustrate the relationship between subdivision level, QG, and delta QP signals. A vertical binary division divides the CTU 862 into two halves: the left half 870 contains one CU CU0, and the right half 872 contains several CUs (CU1-CU4). The quantization group threshold is set to 2 in the example of FIG. 8C, resulting in quantization groups that typically have an area equal to one-quarter of the area of ​​the CTU. When the parent node, i.e., the root node of the coding tree, has a subdivision level of zero, the QG flag is reset, and a new QG begins with the next coded CU, i.e., the CU at arrow 868. CU0 (870) has coded coefficients, and therefore, the delta QP 864 is coded along with CU0's residual. The right half 872 undergoes a horizontal binary division, further dividing the top and bottom of the right half 872, resulting in CU1-CU4. The coding tree nodes corresponding to the upper (877 including CU1 and CU2) and lower (878 including CU3 and CU4) sections of the right half 872 have a subdivision level of 2. A subdivision level of 2 equals a quantization group threshold of 2, so a new QG starts in each section marked as 874 and 876, respectively. CU1 has no coded coefficients (no residual), and CU2 is a "skipped" CU that also has no coded coefficients. Therefore, no delta QP is coded for the upper section. CU3 is a skipped CU, and CU4 has coded residual, so delta QP 866 is coded with CU4's residual for the QG that includes CU3 and CU4.

[0145] 9A and 9B illustrate a 4x4 transform block scan pattern and associated first and second transform coefficients. The operation of the second transform module 330 on the primary residual coefficients is described with reference to the video encoder 114. The 4x4 TB 900 is scanned according to a backward diagonal scan pattern 910. The scan pattern 910 progresses from the "last significant coefficient" position toward the DC (top-left) coefficient position. For example, when considering scanning in a forward direction, residual coefficients located after the last significant coefficient position are implicitly invalid, and all coefficient positions not scanned are invalid. When a second transform is used, all remaining coefficients are invalid. That is, all second-domain residual coefficients that do not undergo the second transform are invalid, and all first-domain residual coefficients that are not input by the application of the second transform are required to be invalid. Furthermore, after application of the forward second transform by the module 330, there may be fewer second transform coefficients than the number of first transform coefficients processed by the second transform module 330. For example, FIG. 9B illustrates a set of blocks 920. In FIG. 9B , 16 primary coefficients are arranged as a 4×4 sub-block, 924 of the 4×4 TB 920. The primary residual coefficients can be subjected to a second transform to generate a second transform block 926 in the example of FIG. 9B . The second transform block 926 includes eight second transform coefficients 928. The eight second transform coefficients 928 are packed forward from the DC coefficient position and stored in the TB according to scan pattern 910. The remaining coefficient positions of the 4×4 sub-block, shown as area 930, contain quantized residual coefficients from the first transform and are all required to be invalid for the second transform to be applied. Thus, the last significant coefficient position of the 4×4 TB, which specifies a coefficient in one of the first eight scan positions of the TB 920, indicates either (i) the application of the second transform or (ii) the output of the first transform after quantization, and has no significant coefficients beyond the eighth scan position of the TB 920.

[0146] If a second transform can be performed on the TB, a second transform index, i.e., 388, is coded to indicate the possible application of the second transform. The second transform index may also indicate which kernel to apply as the second transform in module 330 where multiple transform kernels are available. Correspondingly, video decoder 134 decodes second transform index 470 when the last significant coefficient position is located at one of the scan positions reserved for holding the second transformed coefficient, e.g., 928.

[0147] Although a second transform kernel that maps 16 primary coefficients to 8 secondary coefficients has been described, different kernels are possible, including kernels that map to a different number of second transform coefficients. The number of second transformed coefficients may be the same as the number of first transformed coefficients, e.g., 16. For TBs with a width greater than 4 and a height greater than 4, the behavior described for the 4×4 TB case is applied to the top sub-block of the TB. Other sub-blocks of the TB have zero-valued residual coefficients when the second transform is applied. For TBs with a width greater than 4 and a height equal to 4, the behavior described for the 4×4 TB case is applied to the left-most sub-block of the TB, and other sub-blocks of the TB have zero-valued residual coefficients, allowing the last significant coefficient position to be used to determine whether a second transform index needs to be decoded.

[0148] 9C and 9D illustrate examples of 8x8 transform block scan patterns and associated first and second transform coefficients. FIG. 9C illustrates a 4x4 sub-block-based back diagonal scan pattern 950 for an 8x8 TB 940. The 8x8 TB 940 is scanned with the 4x4 sub-block-based back diagonal scan pattern 950. FIG. 9D illustrates a set 960 illustrating the effect of the second transform operation. The scan 950 returns from the last significant coefficient position to the DC (upper left) coefficient position. Application of the forward second transform kernel to the 48 primary coefficients, shown as area 962 of 940, is possible when the remaining 16 first coefficients, shown as 964, are zero-valued. Applying the second transform to area 962 results in 16 second transform coefficients, shown as 966. The other coefficient positions of the TB are zero-valued and are marked as 968. If the last valid position of the 8x8 TB 940 indicates that the second transformed coefficient is within 966, then the second transform index 388 is coded to indicate application of a particular transform kernel (or bypassing the kernel) by module 330. Video decoder 134 uses the last valid position of the TB to determine whether to decode the second transform index, i.e., index 470. For transform blocks greater than 8 samples in width or height, the approach of Figures 9C and 9D is applied to the top-left 8x8 region, i.e., the top-left 2x2 sub-block of the TB.

[0149] As shown in Figures 9A-9D, two sizes of second transform kernels are available. One size of the second transform kernel is for transform blocks with a width or height of 4, and the other size of the second transform kernel is for transform blocks with a width and height greater than 4. Within each kernel size, multiple sets of second transform kernels (e.g., four) are available. A set is selected based on the intra-prediction mode for the block, which may differ between luma blocks and chroma blocks. Within the selected set, one or two kernels can be used. The use of one kernel in the selected set, or bypassing the second transform, is signaled independently for luma blocks and chroma blocks in a coding unit belonging to a shared tree of coding tree units via a second transform index. In other words, the index used for the luma channel and the index used for the chroma channel are independent of each other.

[0150] Figure 10 shows a set 1000 of transform blocks available in the Universal Video Coding (VVC) standard. Figure 10 also shows the application of a second transform to a subset of residual coefficients from the transform blocks of set 1000. Figure 10 shows TBs ranging in width and height from 4 to 32. However, TBs with widths and / or heights of 64 are possible but are not shown for ease of reference.

[0151] A 16-point second transform 1052 (shown with darker shading) is applied to 4x4 sets of coefficients. The 16-point second transform 1052 is applied to TBs having a width or height of 4, e.g., 4x4 TB 1010, 8x4 TB 1012, 16x4 TB 1014, 32x4 TB 1016, 4x8 TB 1020, 4x16 TB 1030, and 4x32 TB 1040. If a 64-point first transform is available, the 16-point second transform 1052 is applied to TBs of size 4x64 and 64x4 (not shown in Figure 10). For TBs with a width or height of 4 but more than 16 first coefficients, the 16-point second transform is applied only to the top-left 4x4 sub-block of the TB; other sub-blocks are required to have zero-valued coefficients in order for the second transform to be applied. Generally, applying a 16-point second transform results in 16 second transform coefficients, which are packed into a TB for encoding into the sub-block from which the 16 first transform coefficients of the original were obtained. The second transform kernel may result in the generation of fewer second transform coefficients than the number of first transform coefficients to which the second transform was applied, as described with reference to FIG. 9B, for example.

[0152] For transform sizes with width and height greater than 4, a 48-point second transform 1050 (shown with lighter shading) is available to apply to three 4x4 sub-blocks of residual coefficients in the upper left 8x8 region of the transform block, as shown in Figure 10. The 48-point second transform 1050 is applied to an 8x8 transform block 1022, a 16x8 transform block 1024, a 32x8 transform block 1026, an 8x16 transform block 1032, a 16x16 transform block 1034, a 32x16 transform block 1036, an 8x32 transform block 1042, a 16x32 transform block 1044, and a 32x32 transform block 1046, in the regions shown with light shading and dashed outlines, in each case. If a 64-point first transform is available, the 48-point second transform 1050 can also be applied to TBs (not shown) of sizes 8x64, 16x64, 32x64, 64x64, 64x32, 64x16, and 64x8. Applying a 48-point second transform kernel generally generates fewer than 48 second transform coefficients. For example, 8 or 16 second transform coefficients can be generated. The second transform coefficients are stored in a transform block in the upper-left region; for example, eight second transform coefficients are shown in FIG. 9D . First transform coefficients that do not undergo the second transform ("first-only coefficients"), such as coefficient 1066 of TB 1034 (similar to 964 in FIG. 9D ), are required to be zero-valued in order for the second transform to be applied. After applying the 48-point second transform 1050 forward, the region that can contain significant coefficients is reduced from 48 coefficients to 16 coefficients, further reducing the number of coefficient positions that can contain significant coefficients. For example, 968 contains only non-significant coefficients. In the case of the inverse second transform, decoded significant coefficients present only in TB 966, for example, are transformed to generate coefficients that may be significant within a region such as 962, and then these coefficients undergo a first inverse transform. When the second transform reduces one or more sub-blocks to a set of 16 second transform coefficients, only the top-left 4x4 sub-block may contain significant coefficients. The last significant coefficient position, located at any coefficient position where a second transform coefficient may be stored, indicates that either the second transform or only the first transform has been applied. However, after quantization, the resulting significant coefficients are within the same region as if the second transform kernel had been applied.

[0153] If the last significant coefficient position indicates a second transform coefficient position within the TB (e.g., 922 or 962), a signaled second transform index is needed to distinguish whether to apply the second transform kernel or bypass the second transform. While FIG. 10 describes the application of the second transform to TBs of various sizes from the perspective of the video encoder 114, the corresponding inverse process is performed in the video decoder 134. The video decoder 134 first decodes the last significant coefficient position. If the decoded last significant coefficient position indicates the potential application of the second transform, i.e., the position is within 928 or 966 for a second transform kernel that generates 8 or 16 second transform coefficients, respectively, the second transform index is decoded to determine whether to apply or bypass the inverse second transform.

[0154] FIG. 11 shows a syntax structure 1100 for a bitstream 1101 having multiple slices. Each slice includes multiple coding units. The bitstream 1101 may be generated by a video encoder 114, e.g., as bitstream 115, or parsed by a video decoder 134, e.g., as bitstream 133. The bitstream 1101 is divided into portions, e.g., network abstraction layer (NAL) units, and each NAL unit is delineated by preceding it with a NAL unit header, e.g., 1108. A sequence parameter set 1110 defines sequence-level parameters, such as a profile (a set of tools) used to encode and decode the bitstream, chroma format, sample bit depth, and frame resolution. Parameters are also included in set 1110 that constrain the application of different types of partitioning in the coding tree for each CTU. The coding of the parameters that constrain the type of partitioning may be optimized for more compact representation, e.g., using a log2 basis for block size constraints and expressing the parameters relative to other parameters, such as the minimum CTU size. Some of the parameters coded in SPS1110 are: log2_CTU_size_minus5 specifies the CTU size. Coded values ​​0, 1, and 2 specify CTU sizes of 32x32, 64x64, and 128x128, respectively. partition_constraints_override_enabled_flag enables the ability to apply slice-level overrides of several parameters called partition constraint parameters 1130 . Log2_min_luma_coding_block_size_minus2 specifies the minimum coding block size (in luma samples). Values ​​are 0, 1, 2... specifying minimum luma CB sizes of 4x4, 8x8, 16x16... The maximum coding value is constrained by the specified CTU size, i.e. log2_min_luma_coding_block_size_minus2 <= log2_CTU_size_minus5+3. The dimensions of the available chroma blocks correspond to the dimensions of the available luma blocks scaled according to the chroma channel subsampling of the chroma format in use. sps_max_mtt_hierarchy_depth_inter_slice specifies the maximum hierarchical depth of coding units in the coding tree for multi-tree type splitting (i.e., binary and ternary splitting) relative to a quad-tree node in the coding tree (i.e., where the quad-tree splitting stops in the coding tree) for inter (P or B) slices, and is one of parameters 1130. sps_max_mtt_hierarchy_depth_intra_slice_luma specifies the maximum hierarchical depth of a coding unit in the coding tree for multi-tree type splitting (i.e., binary number and ternary number) compared to the quad-tree nodes in the coding tree for intra (I) slices (i.e., once the quad-tree splitting in the coding tree stops), and is one of the parameters 1130. · partition_constraints_override_flag: The parameter is signaled in the slice header when partition_constraints_override_enabled_flag of the SPS is equal to 1, indicating that the partition constraints signaled in the SPS are overridden for the corresponding slice.

[0155] The Picture Parameter Set (PPS) 1112 defines a set of parameters applicable to zero or more frames. The parameters included in the PPS 1112 include parameters for dividing a frame into one or more "tiles" and / or "bricks." The parameters in the PPS 1112 may also include a list of CU chroma QP offsets, one of which may be applied at the CU level to derive a quantization parameter for use by a chroma block from the quantization parameter of the collocated luma CB.

[0156] A sequence of slices that form one picture is known as an access unit (AU), such as AU 0 1114. AU 0 1114 contains three slices, such as slices 0-2. Slice 1 is marked as 1116. Like the other slices, slice 1 (1116) contains a slice header 1118 and slice data 1120.

[0157] The slice header contains parameters grouped as 1134. Group 1134 contains the following: slice_max_mtt_hierarchy_depth_luma is signaled in the slice header 1118 when the slice header's partition_constraints_override_flag is equal to 1, and overrides the value derived from SPS. For I slices, slice_max_mtt_hierarchy_depth_luma is used instead of using sps_max_mtt_hierarchy_depth_intra_slice_luma to set MaxMttDepth in 1134. For P or B slices, slice_max_mtt_hierarchy_depth_luma is used instead of using sps_max_mtt_hierarchy_depth_inter_slice. The variable MinQtLog2SizeIntraY (not shown) is derived from the syntax element SPS_log2_diff_min_qt_min_cb_intra_slice_luma decoded from SPS 1110 and specifies the minimum coding block size resulting from zero or more quad-tree splits of I slices (i.e., no further MTT splits occur in the coding tree). The variable MinQtLog2SizeInterY (not shown) is derived from the syntax element SPS_log2_diff_min_qt_min_cb_inter_slice decoded from SPS 1110. The variable MinQtLog2SizeInterY specifies the minimum coding block size resulting from zero or more quad-tree splits of P slices and B slices (i.e., no further MTT splits occur in the coding tree). Because the CUs resulting from quad-tree splits are powers, the variables MinQtLog2SizeIntraY and MinQtLog2SizeInterY each specify both the width and height (as the log2 of the CU width / height).

[0158] The parameter cu_QP_delta_subdiv can be optionally signaled in the slice header 1118 and indicates the maximum subdivision level at which delta QP is signaled in the coding tree, for the shared tree or luma branch in a separate tree slice. For an I slice, the range of cu_qp_delta_subdiv is 0 to 2*(log2_ctu_size_minus5 + 5 - MinQtLog2SizeIntraY + MaxMttDepthY 1134). For a P or B slice, the range of cu_qp_delta_subdiv is 0 to 2*(log2_ctu_size_minus5 + 5 - MinQtLog2SizeInterY + MaxMttDepthY 1134). There are no parsing issues because the range of cu_qp_delta_subdiv depends on the value MaxMttDepthY 1134, which is derived from the partition constraint obtained from the SPS 1110 or slice header 1118.

[0159] The parameter cu_chroma_QP_offset_subdiv can optionally be signaled in the slice header 1118 and indicates the maximum subdivision level at which the chroma CU QP offset is signaled, either in the shared tree or in the chroma branch in a separate tree slice. The range constraint for cu_chroma_qp_offset_subdiv for an I or P / B slice is the same as the corresponding range constraint for cu_qp_delta_subdiv.

[0160] A subdivision level 1136 is derived for the CTU of slice 1120 and is designated as cu_qp_delta_subdiv for luma CB and cu_chroma_qp_offset_subdiv for chroma CB. This subdivision level is used to establish the level at which points are coded in the CTU delta QP syntax element, as described with reference to Figures 8A-C. For chroma CB, the chroma CU level offset enable (and index, if enabled) is signaled using the approach of Figures 8A-C.

[0161] 12 shows a syntax structure 1200 for slice data 1120 of bitstream 1101 (e.g., 115 or 133), with a shared tree for luma and chroma coding blocks of coding tree units such as CTU 1210. CTU 1210 includes one or more CUs, an example of which is denoted as CU 1214. CU 1214 includes signal prediction mode 1216a followed by transform tree 1216b. If the size of CU 1214 does not exceed the maximum transform size (either 32x32 or 64x64), transform tree 1216b includes one transform unit, denoted as TU 1218.

[0162] If the prediction mode 1216a indicates the use of intra prediction for the CU 1214, a luma intra prediction mode and a chroma intra prediction mode are specified. For the luma CB of the CU 1214, the first transform type is signaled as either (i) horizontally and vertically as DCT-2, (ii) horizontally and vertically as transform skip, or (iii) horizontally and vertically as a combination of DCT-7 and DCT-8. If the signaled luma transform type is horizontally and vertically DCT-2 (option (i)), an additional luma second transform type 1220, also known as a "low-frequency non-separable transform" (LFNST) index, is signaled in the bitstream under conditions as described with reference to Figures 9A-D. A chroma second transform type 1221 is also signaled. This chroma second transform type 1221 is signaled regardless of whether the luma first transform type is DCT-2 or not.

[0163] The use of a shared coding tree results in a TU 1218 that includes a TB for each color channel, denoted as a luma TB Y 1222, a first chroma TB Cb 1224, and a second chroma TB Cr 1226. A coding mode is available in which a single chroma TB is sent to specify the chroma residual for both the Cb and Cr channels, known as a "joint CbCr" coding mode. When the joint CbCr coding mode is enabled, a single chroma TB is coded.

[0164] Regardless of color channel, each TB includes a last position 1228. This last position 1228 indicates the last valid residual coefficient position in the TB when considering coefficients in a diagonal scan pattern used to serialize the array of coefficients of the TB in a forward direction (i.e., forward from the DC coefficient). If the last position 1228 of the TB indicates that only coefficients in the second transform domain are valid, i.e., all remaining coefficients undergo only the first transform, then the second transform index is signaled to specify whether or not to apply the second transform.

[0165] When a second transform is applied and multiple second transform kernels are available, the second transform index indicates which kernel is selected. Typically, one kernel is available, or two kernels are available in a "candidate set." This candidate set is determined from the intra prediction mode of the block. Typically, there are four candidate sets, but there may be fewer. As mentioned above, the use of the second transform for luma and chroma, and therefore the selected kernel, depends on the intra prediction mode for the luma and chroma channels, respectively. This kernel also depends on the block size of the corresponding luma and chroma TB. The kernel selected for chroma also depends on the chroma subsampling of the bitstream. If only one kernel is available, the signaling is limited to apply or not apply the second transform (index range 0-1). If two kernels are available, the index value is 0 (not apply), 1 (apply the first kernel), or 2 (apply the second kernel). For chroma, the same second transform kernel is applied to each chroma channel; therefore, the residuals of Cb block 1224 and Cr block 1226 only need to include significant coefficients at positions that undergo the second transform, as described with reference to Figures 9A-D. When joint CbCr coding is used, the resulting Cb and Cr residuals only include significant coefficients at positions that correspond to significant coefficients in the jointly coded TBs, so the requirement to include only significant coefficients at positions that undergo the second transform is only applicable to a single coding chroma TB. If the applicable color channels of a given second index are described by a single TB (a single last position, e.g., 1228), i.e., if luma always requires only one TB and chroma always requires one TB when joint CbCr coding is used, the second transform index may be coded immediately after coding the last position instead of after the TU, i.e., as index 1230 instead of 1220 (or 1221).By signaling the second transform earlier in the bitstream, video decoder 134 can begin applying the second transform as each residual coefficient of residual coefficients 1232 is decoded, reducing latency in system 100.

[0166] In the configuration of the video encoder 114 and the video decoder 134, when joint CbCr coding is not used, a separate second transform index is signaled for each chroma TB, i.e., 1224 and 1226, resulting in independent control of the second transform for each color channel. When each TB is controlled independently, the second transform index for each TB may be signaled immediately after the last position of the corresponding TB for luma and chroma (regardless of the application of the joint CbCr mode).

[0167] FIG. 13 illustrates a method 1300 for encoding frame data 113 into a bitstream 115, where the bitstream 115 includes one or more slices as a sequence of coding tree units. Method 1300 may be implemented by a device such as an FPGA, ASIC, or ASSP configured. Furthermore, method 1300 may be performed by video encoder 114 under the execution of processor 205. Due to the workload of encoding a frame, the steps of method 1300 may be executed on different processors to share the workload, e.g., using modern multi-core processors, where different slices are encoded by different processors. Furthermore, partitioning constraints and quantization group definitions may differ for each slice, as may be beneficial for rate control purposes when encoding each portion (slice) of bitstream 115. For further flexibility in encoding the residual of each coding unit, not only may the subdivision level of the quantization group differ for each slice, but the application of the second transform may be independently controllable for luma and chroma. As such, method 1300 may be stored in a computer-readable storage medium and / or in memory 206.

[0168] The method 1300 begins with an encoding SPS / PPS step 1310. In step 1310, the video encoder 114 encodes the SPS 1110 and the PPS 1112 as sequences of fixed-length and variable-length coding parameters into the bitstream 115. A partition_constraints_override_enabled_flag is encoded as part of the SPS 1110 and indicates that partition constraints can be overridden in the slice header (1118) of each slice (e.g., 1116). Default partition constraints are also encoded by the video encoder 114 as part of the SPS 1110.

[0169] Method 1300 continues from step 1310 with step 1320, which involves dividing the frame into slices. In performing step 1320, processor 205 divides frame data 113 into one or more slices or consecutive portions. If parallelism is desired, separate instances of video encoder 114 encode each slice somewhat independently. A single video encoder 114 may process each slice sequentially, or some intermediate degree of parallelism may be implemented. Typically, the division of a frame into slices (consecutive portions) is aligned with boundaries of the division of the frame into regions known as "subpictures," tiles, etc.

[0170] Method 1300 continues from step 1320 with a coding slice header step 1330. In step 1330, entropy encoder 338 encodes slice header 1118 into bitstream 115. An example of step 1330 is provided below with reference to FIG.

[0171] Method 1300 continues from step 1330 with a slice division into CTUs step 1340. In performing step 1340, video encoder 114 divides slice 1116 into a sequence of CTUs. Slice boundaries are aligned with CTU boundaries, and CTUs within a slice are ordered according to CTU scan order, typically raster scan order. The division of a slice into CTUs establishes which portions of frame data 113 should be processed by video encoder 113 when encoding the current slice.

[0172] Method 1300 continues from step 1340 to coding tree determination step 1350. In step 1350, video encoder 114 determines the coding tree for the currently selected CTU in the slice. Method 1300 starts with the first CTU in slice 1116 on the first invocation of step 1350 and progresses to subsequent CTUs in slice 1116 on subsequent invocations. In determining the coding tree for the CTU, various combinations of quadtree, binary, and ternary partitioning are generated and tested by block partition partitioner 310.

[0173] Method 1300 continues from step 1350 to coding unit determination step 1360. In step 1360, video encoder 114 performs a known method to determine the "optimal" encoding of the CU resulting from the various coding trees under evaluation. Determining the optimal encoding includes determining a prediction mode (e.g., intra prediction with a specific mode or inter prediction with motion vectors) and a transform selection (a first transform type and an optional second transform type). If the first transform type for the luma TB is determined to be DCT-2 or any quantized first transform coefficients that do not undergo a forward second transform are valid, the second transform index for the luma TB is subject to application of the second transform. Otherwise, the second transform index for luma indicates bypass of the second transform. For the luma channel, the first transform type is determined to be one of DCT-2, transform skip, or an MTS option for the chroma channel, with DCT-2 being an available transform type. Determining the second transform type is further described with reference to Figures 19A and 19B. Determining the encoding may also include determining a quantization parameter that can change the QP at a quantization group boundary. When determining each coding unit, an optimal coding tree is also jointly determined. If the coding unit is coded using intra prediction, a luma intra prediction mode and a chroma intra prediction mode are determined.

[0174] The coding unit determination process 1360 may inhibit application of the second transform test if there are no "AC" (coefficients at locations other than the top-left position of the transform block) residual coefficients present in the first-domain residual resulting from application of the DCT-2 first transform. Coding gain is observed when the second transform application is tested on a transform block containing only DC coefficients (the last location indicates that only the top-left coefficient of the transform block is valid). The inhibition of testing the second transform when only DC primary coefficients are present extends to blocks to which the second transform index is applied when a single index is coded, i.e., Y, Cb, and Cr for a shared tree (which only has a Y channel when the Cb and Cr blocks are two samples wide or high). Although residuals with only DC coefficients have a lower coding cost compared to residuals with at least one AC coefficient, applying the second transform even to residuals with only a valid DC coefficient results in a further reduction in the magnitude of the final coded DC coefficient. Even after further quantization and / or rounding operations before coding, the other (AC) coefficients have insufficient magnitude to result in valid coding residual coefficient(s) in the bitstream after the second transform. In a shared or separate tree coding tree, video encoder 114 tests for selection of a non-zero second transform index value (i.e., application of the second transform) if there is at least one valid first coefficient within the range of application of the second transform index, even if only the DC coefficient of the respective transform block is present.

[0175] Method 1300 continues from step 1360 with coding unit encoding step 1370. In step 1370, video encoder 114 encodes the coding unit determined in step 1360 into bitstream 115. An example of how a coding unit is encoded is described in more detail with reference to FIG.

[0176] Method 1300 continues from step 1370 to last coding unit test step 1380. In step 1380, processor 205 tests whether the current coding unit is the last coding unit in a CTU. If not ("NO" at step 1380), processor 205 passes control to coding unit determination step 1360. Otherwise, if the current coding unit is the last coding unit in processor 205 ("YES" at step 1380), control passes to last CTU test step 1390.

[0177] In last CTU test step 1390, processor 205 tests whether the current CTU is the last CTU in slice 1116. If it is not the last CTU in slice 1116, control in processor 205 returns to coding tree determination step 1350. Otherwise, if the current CTU is the last ("YES" at step 1390), control in processor 205 proceeds to last slice test step 13100.

[0178] In a last slice test step 13100, processor 205 tests whether the current slice being coded is the last slice in the frame. If it is not the last slice ("NO" at step 13100), processor 205 control passes to slice header coding step 1330. Otherwise, if the current slice is the last and all slices (consecutive portions) have been coded ("YES" at step 13100), method 1300 ends.

[0179] 14 shows a method 1400 for encoding the slice header 1118 into the bitstream 115, as performed in step 1330. The method 1400 may be implemented by an apparatus such as a configured FPGA, ASIC, or ASSP. Furthermore, the method 1400 may be performed by the video encoder 114 under execution by the processor 205. As such, the method 1400 may be stored in a computer-readable storage medium and / or in the memory 206.

[0180] Method 1400 begins with partition constraint override enable test step 1410. At step 1410, processor 205 tests whether the partition constraint, as encoded in SPS 1110, overrides the enable flag, indicating that the partition constraint may be overridden at the slice level. If the partition constraint may be overridden at the slice level (“YES” at step 1410), processor 205 control passes to partition constraint determination step 1420. Otherwise, if the partition constraint may not be overridden at the slice level (“NO” at step 1410), processor 205 control passes to other parameter encoding step 1480.

[0181] In a partition constraint determination step 1420, the processor 205 determines a partition constraint (e.g., a maximum MTT partition depth) appropriate for the current slice 1116. In one example, the frame data 310 includes a 360-degree view projection of a scene mapped to a 2D frame and divided into several subpictures. Depending on the selected viewport, some slices may require higher fidelity, while other slices may require lower fidelity. The partition constraint for a given slice may be set based on the fidelity requirements of that portion of the frame data 310 encoded by the slice (e.g., according to step 1340). If lower fidelity is deemed acceptable, a shallower coding tree with larger CUs may be acceptable, and the maximum MTT depth may be set to a lower value accordingly. The subdivision level 1136, signaled using the flag cu_qp_delta_subdiv, is determined accordingly, at least to the extent derived from the determined maximum MTT depth 1134. The corresponding chroma subdivision level is also determined and signaled.

[0182] From step 1420, method 1400 continues with partition constraint override flag encoding step 1430. In step 1430, entropy encoder 338 encodes into bitstream 115 a flag indicating whether the partition constraints signaled in SPS 1110 should be overridden for slice 1116. If partition constraints specific to the current slice were derived in step 1420, the flag value indicates use of the partition constraint override function. If the constraints determined in step 1420 match those already encoded in SPS 1110, there is no need to overwrite the partition constraints, as there are no changes to signal and the flag value is encoded accordingly.

[0183] From step 1430, method 1400 continues with a partition constraint overwrite test step 1440. At step 1440, processor 205 tests the flag value encoded at step 1430. If the flag indicates that the partition constraint is to be overwritten (“YES” at step 1440), control of processor 205 passes to a slice partition constraint encoding step 1450. Otherwise, if the partition constraint is not to be overwritten (“NO” at step 1440), control of processor 205 passes to an other parameter encoding step 1480.

[0184] From step 1440, the method 1400 continues with a slice partition constraint encoding step 1450. In performing step 1450, the entropy encoder 338 encodes the partition constraints determined for the slice into the bitstream 115. The partition constraints for the slice include "slice_max_mtt_hierarchy_depth_luma," from which MaxMttDepthY 1134 is derived.

[0185] From step 1450, the method 1400 continues with a QP subdivision level encoding step 1460. In step 1460, the entropy encoder 338 encodes the subdivision level of luma CB using the "cu_qp_delta_subdiv" syntax element, as described with reference to FIG.

[0186] From step 1460, method 1400 continues with chroma QP subdivision level encoding step 1470. In step 1470, entropy encoder 338 encodes the subdivision level for signaling the CU chroma QP offset using the "cu_chroma_qp_offset_subdiv" syntax element, as described with reference to FIG.

[0187] Steps 1460 and 1470 operate to encode the overall QP subdivision level of a slice (contiguous portion) of a frame. This overall subdivision level includes both the subdivision level of the luma coding unit and the subdivision level of the chroma coding unit of the slice. For example, the chroma and luma subdivision levels may be different due to the use of separate coding trees for luma and chroma in an I slice.

[0188] From step 1470, method 1400 continues with other parameter encoding step 1480. In step 1480, entropy encoder 338 encodes other parameters, such as those required to control specific tools like deblocking (for non-uniform application of quantization parameters to transform blocks), adaptive loop filters, and any selection of scaling lists, from those previously signaled into slice header 1118. Method 1400 ends upon execution of step 1480.

[0189] Figure 15 shows a method 1500 for encoding a coding unit into a bitstream 115, corresponding to step 1370 of Figure 13. Method 1500 may be implemented by an apparatus such as a configured FPGA, ASIC, or ASSP. Furthermore, method 1500 may be performed by video encoder 114 under execution by processor 205. Accordingly, method 1500 may be stored in a computer-readable storage medium and / or memory 206.

[0190] Method 1500 begins with prediction mode encoding step 1510. In step 1510, entropy encoder 338 encodes the prediction mode of the coding unit determined in step 1360 into bitstream 115. A "pred_mode" syntax element is encoded to distinguish between the use of intra prediction, inter prediction, or another prediction mode for the coding unit. If intra prediction is used for the coding unit, a luma intra prediction mode is encoded, and a chroma intra prediction mode is encoded. If inter prediction is used for the coding unit, a "merge index" may be encoded to select a motion vector from an adjacent coding unit to be used by this coding unit, and a motion vector delta may be encoded to introduce an offset to a motion vector derived from a spatially adjacent block. A first transform type is encoded to select the use of DCT-2 horizontally and vertically, transform skip horizontally and vertically, or a combination of DCT-8 and DST-7 horizontally and vertically for the luma TB of the coding unit.

[0191] Method 1500 continues from step 1510 with coding residual test step 1520. At step 1520, processor 205 determines whether a residual needs to be coded for the coding unit. If there are valid residual coefficients to be coded for the coding unit (“YES” at step 1520), control of processor 205 passes to new QG test step 1530. Otherwise, if there are no valid residual coefficients for coding (“NO” at step 1520), method 1500 ends because all information necessary to decode the coding unit is present in bitstream 115.

[0192] In new QG test step 1530, processor 205 determines whether the coding unit corresponds to a new quantization group. If the coding unit corresponds to a new quantization group in processor 205 (“YES” at step 1530), control proceeds to delta QP encoding step 1540. Otherwise, if the coding unit is not associated with a new quantization group in processor 205 (“NO” at step 1530), control proceeds to perform first conversion step 1550. When encoding each coding unit, the nodes of the coding tree of the CTU are traversed in step 1530. If any of the child nodes of the current node have a subdivision level less than or equal to subdivision level 1136 for the current slice, as determined from “cu_qp_delta_subdiv,” a new quantization group begins in the region of the CTU corresponding to the node, and step 1530 returns “YES.” The first CU of the quantization group containing the coded residual also contains the coded delta QP, signaling any changes to the quantization parameters applicable to the residual coefficients of this quantization group.

[0193] In delta QP encoding step 1540, the entropy encoder 338 encodes the delta QP into the bitstream 115. The delta QP encodes the difference between a predicted QP and the intended QP for use in the current quantization group. This predicted QP is derived by averaging the QPs of adjacent, earlier (above and to the left) quantization groups. When the subdivision level is lower, the quantization groups are larger, and the delta QP is coded less frequently. Coding the delta QP less frequently results in lower overhead for signaling changes in QP, but also less flexibility in rate control. The selection of the quantization parameter for each quantization group is performed by the QP control module 390, which typically implements a rate control algorithm to target a specific bitrate for the bitstream 115 somewhat independently of changes in the statistics of the underlying frame data 113. Method 1500 continues from step 1540 to performing a first transform step 1550.

[0194] In a perform first transform step 1550, the forward first transform module 326 performs a first transform according to a first transform type of the coding unit, resulting in first transform coefficients 328. The first transform is performed on each color channel, first on the luma channel (Y), and then on the Cb and Cr TBs in subsequent invocations of step 1550 for the current TU. The first transform type (DCT-2, transform skip, MTS option) is performed for the luma channel, and DCT-2 is performed for the chroma channels.

[0195] The method 1500 continues from step 1550 with a first transform coefficient quantization step 1560. In step 1560, the quantization module 334 quantizes the first transform coefficients 328 according to the quantization parameter 392 to generate quantized first transform coefficients 332. A delta QP, if present, is used to encode the transform coefficients 328.

[0196] Method 1500 continues from step 1560 with a second transform step 1570. In step 1570, second transform module 330 performs a second transform on quantized first transform coefficients 332 according to second transform indexes 388 for the current transform block, generating second transform coefficients 336. Although the second transform is performed after quantization, first transform coefficients 328 may retain greater precision compared to the final intended quantization step size of quantization parameter 392; for example, the magnitude may be 16 times larger than would result directly from application of quantization parameter 392, i.e., 4 additional bits of precision would be retained. Retaining the additional precision bits in quantized first transform coefficients 332 allows second transform module 330 to operate with greater precision on coefficients in the primary coefficient domain. After application of the second transform, a final scaling (e.g., a right shift by 4 bits) in step 1560 results in quantization of quantization parameter 392 to the intended quantization step size. The application of the "scaling list" is performed on the first transform coefficients corresponding to known transform basis functions (DCT-2, DCT-8, DST-7) rather than operating on the second transform coefficients resulting from a trained second transform kernel. If the second transform index 388 for a transform block does not indicate the application of the second transform (index value equal to zero), the second transform is bypassed. That is, the first transform coefficients 332 are propagated unchanged through the second transform module 330 to become the second transform coefficients 336. The luma second transform index, in conjunction with the luma intra prediction mode, is used to select the second transform kernel to apply to the luma TB. The chroma second transform index, in conjunction with the chroma intra prediction mode, is used to select the second transform kernel to apply to the chroma TB.

[0197] From step 1570, the method 1500 continues with a last position encoding step 1580. In step 1580, the entropy encoder 338 encodes the position of the last significant coefficient in the second transform coefficients 336 for the current transform block into the bitstream 115. During the first invocation of step 1580, the luma TB is considered, and subsequent invocations consider the Cb and then Cr TBs.

[0198] In a configuration in which the second transform index 388 is coded immediately after the last position, method 1500 proceeds to LFNST index coding step 1590. At step 1590, if the entropy encoder 338 did not infer that the second transform index was zero based on the last position coded at step 1580, it uses a truncated unary codeword to code the second transform index 338 into the bitstream 115 as “lfnst_index.” Each CU has one luma TB, allowing step 1590 to be performed for the luma block; when the “joint” coding mode is used for chroma, a single chroma TB is coded, and thus step 1590 may be performed for chroma. Knowledge of the second transform index before decoding each residual coefficient allows the second transform to be applied to each coefficient as the coefficients are decoded, e.g., using multiplication and accumulation logic. Method 1500 continues from step 1590 to subblock coding step 15100.

[0199] If the second transform index 388 is not coded immediately after the last position, the method 1500 proceeds from step 1580 to a sub-block coding step 15100, where the residual coefficients of the current transform block (336) are coded into the bitstream 115 as a series of sub-blocks. The residual coefficients are coded proceeding from the sub-block containing the last significant coefficient position towards the sub-block containing the DC residual coefficient.

[0200] From step 15100, method 1500 continues to a last TB test step 15110, in which processor 205 tests whether the current transform block is the last one in a progression through the color channels, i.e., Y, Cb, and Cr. If the transform block just coded is for the Cr TB ("YES" at step 15110), control in processor 205 passes to a luma LFNST index coding step 15120. Otherwise, if the current TB is not the last ("YES" at 15110), control of processor 205 returns to perform first transform step 1550, where the next TB (Cb or Cr is selected) is selected.

[0201] Steps 1550-15110 are described with reference to an example where the prediction mode is intra prediction and a shared coding tree structure uses DCT-2. Operations of steps such as performing a first transform (1550), quantizing first transform coefficients (1560), and encoding the last position (1590) can be performed for inter prediction modes or for intra prediction modes other than a shared coding tree structure using known methods. Steps 1510-1540 can be performed regardless of the prediction mode or coding tree structure.

[0202] From step 15110, method 1500 continues with step 15120, which involves encoding the luma LFNST index. In step 15120, the second transform index applied to the luma TB is coded into the bitstream 115 by the entropy encoder 338 if it is not predicted to be zero (if no second transform is applied). The luma second transform index is predicted to be zero if the last valid position of the luma TB indicates a valid first-only residual coefficient or if a first transform other than DCT-2 is performed. In addition, the second transform index applied to the luma TB is coded into the bitstream only for coding units using intra prediction and a shared coding tree structure. The second transform index applied to the luma TB is coded using flag 1220 (or flag 1230 for joint CbCr mode).

[0203] Method 1500 continues from step 15120 to chroma LFNST index encoding step 15130. In step 1530, the second transform index applied to the chroma TB is coded into the bitstream 115 by the entropy encoder 338 if the chroma second transform index is not inferred to be zero (if no second transform is applied). If the last valid position of any chroma TB indicates a valid first-only residual coefficient, the chroma second transform index is inferred to be zero. Method 1500 ends upon execution of step 15130, and control within processor 205 returns to method 1300. The second transform index applied to the chroma TB is coded into the bitstream for the coding unit only using intra prediction and a shared coding tree structure. The second transform index applied to the chroma TB is coded using flag 1221 (or flag 1230 for joint CbCr mode).

[0204] 16 shows a method 1600 for decoding a frame from a bitstream as a sequence of coding units arranged into slices. Method 1600 may be implemented by an apparatus such as an configured FPGA, ASIC, or ASSP. Furthermore, method 1600 may be performed by video decoder 134 during execution by processor 205. As such, method 1600 may be stored in a computer-readable storage medium and / or memory 206.

[0205] Method 1600 decodes a bitstream coded using method 1300 in which the partitioning constraints and quantization group definitions may vary from slice to slice as deemed beneficial for rate control purposes in coding each portion (slice) of bitstream 115. Not only may the subdivision level of the quantization groups vary from slice to slice, but the application of the second transform is independently controllable for luma and chroma.

[0206] Method 1600 begins with SPS / PPS decoding step 1610. In performing step 1610, video decoder 134 decodes SPS 1110 and PPS 1112 from bitstream 133 as sequences of fixed-length and variable-length parameters. A partition_constraints_override_enabled_flag is decoded as part of SPS 1110 and indicates whether partition constraints can be overridden in the slice header (e.g., 1118) of each slice (e.g., 1116). Default (i.e., signaled in SPS 1110 and used in subsequent slices without overrides) partition constraint parameters 1130 are also decoded by video decoder 134 as part of SPS 1110.

[0207] Method 1600 continues from step 1610 with slice boundary determination step 1620. In performing step 1620, processor 205 determines the location of slices within the current access unit in bitstream 133. Typically, slices are identified by determining NAL unit boundaries (by detecting a "start code") and, for each NAL unit, reading the NAL unit header, which contains a "NAL unit type." A particular NAL unit type identifies a slice type, such as an "I slice," "P slice," or "B slice." Once slice boundaries are identified, application 233 can distribute the performance of subsequent steps of method 1600 across different processors, e.g., in a multiprocessor architecture, for parallel decoding. Different slices may be decoded by each processor in a multiprocessor system for higher decoding throughput.

[0208] Method 1600 continues from step 1610 with a slice header decoding step 1630. At step 1630, entropy decoder 420 decodes slice header 1118 from bitstream 133. An exemplary method for decoding slice header 1118 from bitstream 133, as performed at step 1630, is described below with reference to FIG.

[0209] Method 1600 continues from step 1630 with a slice division into CTUs step 1640. In step 1640, video decoder 134 divides slice 1116 into a sequence of CTUs. Slice boundaries are aligned with CTU boundaries, and CTUs within a slice are ordered according to a CTU scan order, which is typically a raster scan order. The division of a slice into CTUs establishes which portions of frame data 113 should be processed by video decoder 134 when decoding the current slice.

[0210] Method 1600 continues from step 1640 with coding tree decoding step 1650. In performing step 1650, video decoder 133 decodes the coding tree of a current CTU in a slice from bitstream 133, starting with the first CTU in slice 1116 on the first invocation of step 1650. The coding tree of the CTU is decoded by decoding the split flag according to FIG. 6. In subsequent iterations of step 1650 for the CTU, decoding is performed for subsequent CTUs in slice 1116. If the coding tree was coded using an intra-prediction mode and a shared coding tree structure, the coding unit has a first color channel (luminance or Y) and at least one second color channel (chroma, Cb and Cr, or CbCr). In this case, decoding the coding tree involves decoding coding units that include the first color channel and at least one second color channel according to the coding tree unit's split flag.

[0211] Method 1600 continues from step 1660 with coding unit decoding step 1670. At step 1670, video decoder 134 decodes the coding unit from bitstream 133. An exemplary method for decoding a coding unit as performed at step 1670 is described below with reference to FIG.

[0212] Method 1600 continues from step 1610 to last coding unit test step 1680. In step 1680, processor 205 tests whether the current coding unit is the last coding unit in the CTU. If it is not the last coding unit (“NO” at step 1680), control of processor 205 returns to decode coding unit step 1670 to decode the next coding unit in the coding tree unit. If the current coding unit is the last coding unit (“YES” at step 1680), control of processor 205 proceeds to last CTU test step 1690.

[0213] In last CTU test step 1690, processor 205 tests whether the current CTU is the last CTU in slice 1116. If it is not the last CTU in the slice (“NO” at step 1690), control in processor 205 returns to coding tree decoding step 1650 to decode the next coding tree unit in slice 1116. If the current CTU is the last CTU in slice 1116 (“YES” at step 1690), control of processor 205 proceeds to last slice test step 16100.

[0214] In last slice test step 16100, processor 205 tests whether the current slice being decoded is the last slice in the frame. If it is not the last slice in the frame ("NO" at step 16100), processor 205 control returns to slice header decoding step 1630, which operates to decode the slice header of the next slice in the frame (e.g., "Slice 2" at FIG. 11). If the current slice is the last slice in the frame ("YES" at step 1600), method 1600 ends.

[0215] Method 1600 operates on multiple coding units to generate image frames as described in connection with device 130 in FIG.

[0216] 17 shows a method 1700 for decoding slice headers into a bitstream, as performed in step 1630. Method 1700 may be implemented by an apparatus such as a configured FPGA, ASIC, or ASSP. Furthermore, method 1700 may be performed by video decoder 134 under execution by processor 205. As such, method 1700 may be stored in a computer-readable storage medium and / or in memory 206.

[0217] Similar to method 1500, method 1700 is performed for a current slice or contiguous portion (1116) within a frame, e.g., frame 1101. Method 1700 begins with partition constraint override enable test step 1710. At step 1710, processor 205 tests whether the partition constraint override enable flag, as decoded from SPS 1110, indicates that the partition constraint may be overridden at the slice level. If the partition constraint may be overridden by slice-level control within processor 205 (“YES” at step 1710), the method proceeds to decode partition constraint override flag step 1720. Otherwise, if the partition constraint override enable flag indicates that the constraint may not be overridden by slice-level control within processor 205 (“NO” at step 1710), the method proceeds to decode other parameters step 1770.

[0218] In a partition constraint override flag decoding step 1720, the entropy decoder 420 decodes the partition constraint override flag from the bitstream 133. The decoded flag indicates whether to override the partition constraint indicated in the SPS 1110 for the current slice 1116.

[0219] From step 1720, method 1700 continues with a partition constraint overwrite test step 1730. In performing step 1730, processor 205 tests the flag value decoded at step 1720. If the decoded flag indicates that the partition constraint should be overwritten ("YES" at step 1730), control in processor 205 passes to a decode slice partition constraint step 1740. Otherwise, if the decoded flag indicates that the partition constraint should not be overwritten ("NO" at step 1730), control in processor 205 passes to a decode slice partition constraint step 1770, which decodes other parameters.

[0220] In a decode slice partition constraints step 1740, the entropy decoder 420 decodes the partition constraints determined for the slice from the bitstream 133. The partition constraints for the slice include "slice_max_mtt_hierarchy_depth_luma," from which MaxMttDepthY 1134 is derived.

[0221] From step 1740, the method 1700 continues with a QP subdivision level decoding step 1750. In step 1720, the entropy decoder 420 decodes the subdivision level for luma CB using the syntax element cu_qp_delta_subdiv, as described with reference to FIG.

[0222] Method 1700 continues from step 1750 with chroma QP subdivision level decoding step 1760. At step 1760, entropy decoder 420 decodes the subdivision level for signaling the CU chroma QP offset using the syntax element cu_chroma_qp_offset_subdiv, as described with reference to FIG.

[0223] Steps 1750 and 1760 operate to determine the subdivision level for a particular continuous portion (slice) of the bitstream. Repeated iterations between steps 1630 and 16100 operate to determine the subdivision level for each continuous portion (slice) in the bitstream. As described below, each subdivision level is applicable to the coding units of the corresponding slice (continuous portion).

[0224] Method 1700 continues from step 1760 with step 1770 of decoding other parameters. In step 1770, entropy decoder 420 decodes other parameters, such as parameters required for controlling specific tools like deblocking (for non-uniform application of quantization parameters to transform blocks), adaptive loop filters, and any selection of scaling lists, from those previously signaled in slice header 1118. Method 1700 ends upon execution of step 1770.

[0225] 18 shows a method 1800 for decoding a coding unit from a bitstream. Method 1800 may be implemented by an apparatus such as an configured FPGA, ASIC, or ASSP. Furthermore, method 1800 may be performed by video decoder 134 under execution by processor 205. As such, method 1800 may be stored in a computer-readable storage medium and / or in memory 206.

[0226] Method 1800 is performed on a current coding unit of a current CTU (e.g., CTU0 of slice 1116). Method 1800 begins with a prediction mode decoding step 1810. At step 1800, entropy decoder 420 decodes the prediction mode of the coding unit determined at step 1360 of Figure 13 from bitstream 133. At step 1810, a "pred_mode" syntax element is decoded to distinguish between the use of intra-prediction, inter-prediction, or other prediction modes for the coding unit.

[0227] If intra prediction is used for the coding unit, the luma intra prediction mode and the chroma intra prediction mode are also decoded in step 1810. If inter prediction is used for the coding unit, a "merge index" may be decoded in step 1810 to determine motion vectors from adjacent coding units used by this coding unit, and a motion vector delta may be decoded to introduce offsets to motion vectors derived from spatially adjacent blocks. A first transform type is decoded in step 1810 to select the use of DCT-2 horizontally and vertically, select transform skip horizontally and vertically, or select a combination of DCT-8 and DST-7 horizontally and vertically for the luma TB of the coding unit.

[0228] Method 1800 continues from step 1810 with a residual test coding step 1820. In performing step 1820, processor 205 determines whether a residual needs to be decoded for a coding unit by decoding the coding unit's "root coding block flag" using entropy decoder 420. If there are valid residual coefficients to be decoded for the coding unit ("YES" at step 1820), control of processor 205 passes to new QG test step 1830. Otherwise, if there are no residual coefficients to be decoded ("NO" at step 1820), method 1800 ends because all information necessary to decode the coding unit is available in bitstream 115. Once method 1800 ends, subsequent steps, such as PB generation and application of in-loop filtering, are performed to generate decoded samples, as described with reference to FIG. 4.

[0229] In new QG test step 1830, processor 205 determines whether the coding unit corresponds to a new quantization group. If the coding unit corresponds to a new quantization group ("YES" at step 1830), processor 205 control passes to decode delta QP step 1840. Otherwise, if the coding unit does not correspond to a new quantization group ("NO" at step 1830), processor 205 control passes to decode end position step 1850. The new quantization group is associated with the current mode or subdivision level of the coding unit. When decoding each coding unit, the nodes of the coding tree of the CTU are traversed. If any of the child nodes of the current node have a subdivision level equal to or less than the subdivision level 1136 of the current slice, i.e., as determined from "cu_qp_delta_subdiv," a new quantization group is started in the region of the CTU corresponding to the node. The first CU of a quantization group containing coded residual coefficients also contains a coded delta QP, signaling any changes to the quantization parameters applicable to the residual coefficients of this quantization group. In practice, one (at most one) quantization parameter delta is decoded for each area (quantization group). As explained in connection with Figures 8A-8C, each area (quantization group) is based on the decomposition of the coding tree units of each slice and the corresponding subdivision level (e.g., encoded in steps 1460 and 1470). In other words, each area or quantization group is based on a comparison of the subdivision level associated with the coding unit with the subdivision level determined for the corresponding contiguous portion.

[0230] In a delta QP decoding step 1840, the entropy decoder 420 decodes the delta QP from the bitstream 133. The delta QP encodes the difference between a predicted QP and the intended QP to use for the current quantization group. This predicted QP is derived by averaging the QPs of the neighboring (upper-left) quantization group.

[0231] From step 1840, method 1800 continues with a last position decoding step 1850. In performing step 1850, the entropy decoder 420 decodes from the bitstream 133 the position of the last significant coefficient in the second transform coefficient set 424 for the current transform block. The first time step 1850 is called, it is performed for the luma TB. In subsequent invocations of step 1850 for the current CU, it is performed for the Cb TB. If the last position indicates a significant coefficient outside the second transform coefficient set for the luma or chroma block (i.e., outside 928 or 966), the second transform index for the luma or chroma channel, respectively, is inferred to be zero. This step is performed for the Cr TB after the iteration for Cb.

[0232] As described in connection with step 1590 of FIG. 15 , in some configurations, the second transform index 470 is coded immediately after the last significant coefficient position of the coding unit. When decoding the same coding unit, if the second transform index 470 is not estimated to be zero based on the location of the last position of the TB decoded in step 1840, the second transform index 470 is decoded immediately after decoding the location of the last significant residual coefficient of the coding unit. In configurations in which the second transform index 470 is decoded immediately after the last significant coefficient position of the coding unit, method 1800 continues from step 1850 to LFNST index decoding step 1860. In performing step 1860, the entropy decoder 420 decodes the second transform index 470 from the bitstream 133 as “lfnst_index” using a truncated unary codeword when all significant coefficients have undergone a secondary inverse transform (e.g., within 928 or 966). The second transform index 470 can be decoded for luma TB or chroma when joint coding of the chroma TB is performed using a single transform block. From step 1860, the method 1800 continues with a sub-block decoding step 1870.

[0233] If the second transform index 470 is not decoded immediately after the last significant position of the coding unit, the method 1800 continues from step 1850 to a sub-block decoding step 1870. At step 1870, the residual coefficients of the current transform block, i.e., 424, are decoded from the bitstream 133 as a series of sub-blocks, starting from the sub-block containing the last significant coefficient position back to the sub-block containing the DC residual coefficient.

[0234] From step 1870, method 1800 continues with a last TB test step 1880. In performing step 1880, processor 205 tests whether the current transform block is the last transform block in a progression through the color channels, i.e., Y, Cb, and Cr. If the just-decoded (current) transform block is for the Cr TB, control within processor 205 indicates that all TBs have been decoded ("YES" at step 1880), and method 1800 proceeds to a luma LFNST index decode step 1890. Otherwise, if no TBs have been decoded ("NO" at step 1880), control of processor 205 returns to last position decode step 1850. The next TB (following the order Y, Cb, Cr) is selected for decoding in this iteration of step 1850.

[0235] From step 1880, method 1800 continues with step 1890, which involves decoding a luma LFNST index. In performing step 1890, if the last position of the luma TB is within the set of coefficients undergoing a secondary inverse transform (e.g., 928 or 966) and the luma TB uses DCT-2 horizontally and vertically as the first transform, the second transform index 470 to be applied to the luma TB is decoded from the bitstream 133 by the entropy decoder 420. If the last valid position of the luma TB indicates that a valid first coefficient exists outside the set of coefficients undergoing the second inverse transform (e.g., outside 928 or 966), the luma second transform index is inferred to be zero (no second transform is applied). The second transform index decoded in step 1890 is shown as 1220 in FIG. 12 (or 1230 in joint CbCr mode).

[0236] From step 1890, method 1800 continues with chroma LFNST index decoding step 1895. In step 1895, if the last position of each chroma TB is within the set of coefficients that undergo the second inverse transform (e.g., 928 or 966), the second transform index 470 to be applied to the chroma TB is decoded from the bitstream 133 by the entropy decoder 420. If the last valid position of any chroma TB indicates the presence of a valid first coefficient outside the set of coefficients that undergo the second inverse transform (e.g., outside 928 or 966), the chroma second transform index is inferred to be zero (no second transform is applied). The second transform index decoded in step 1895 is shown as 1221 in FIG. 12 (or 1230 in joint CbCr mode). When decoding separate indices for luma and chroma, a separate arithmetic context for each truncated unary codeword may be used, or the context may be shared such that the nth bin of each of the luma and chroma truncated unary codewords shares the same context.

[0237] Essentially, steps 1890 and 1895 involve decoding a first index (e.g., 1220) to select a kernel for the luma (primary color) channel and decoding a second index (e.g., 1221) to select a kernel for at least one chroma (second color channel), respectively.

[0238] The method 1800 continues from step 1895 by performing an inverse second transform step 18100. In this step, the inverse second transform module 436 performs an inverse second transform on the current transform block on the decoded residual transform coefficients 424 according to the second transform index 470 to generate second transform coefficients 432. The second transform index decoded in step 1890 is applied to the luma TB, and the second transform index decoded in step 1895 is applied to the chroma TB. The kernel selection for luma and chroma also depends on the luma intra prediction mode and the chroma intra prediction mode (respectively decoded in step 1810), respectively. In step 18100, a kernel is selected according to the luma LFNST index and a kernel is selected according to the chroma LFNST index.

[0239] Method 1800 continues from step 18100 with a first transform coefficient inverse quantization step 18110. In step 18110, the inverse quantizer module 428 inverse quantizes the second transform coefficient 432 in accordance with the quantization parameter 474 to produce the inverse quantized first transform coefficient 440. If the delta QP was decoded in step 1840, the entropy decoder 420 determines its quantization parameter in accordance with the delta QP of the quantization group (area) and the quantization parameter of the previous coding unit of the image frame. As mentioned above, this previous coding unit typically relates to the adjacent upper-left coding unit.

[0240] Method 1800 continues from step 1870 and proceeds to perform first transform step 18120. In step 1820, inverse first transform module 444 performs an inverse first transform in accordance with the first transform type of the coding unit, resulting in transform coefficients 440 being converted to spatial-domain residual samples 448. The inverse first transform is performed on each color channel, first on the luma channel (Y), and then on the Cb and Cr TBs in subsequent invocations of step 1650 for the current TU. Steps 18100-18120 operate to substantially decode the current coding unit by applying a kernel selected in accordance with the LFNST index for luma in step 1890 to the decoded residual coefficients of the luma channel, and by applying a kernel selected in accordance with the LFNST index for chroma in step 1890 to the decoded residual coefficients for at least one chroma channel.

[0241] The method 1800 ends upon execution of step 18120 and control within the processor 205 returns to the method 1600.

[0242] Steps 1850-18120 are described with reference to an example of a shared coding tree structure in which the prediction mode is intra prediction and the transform is DCT-2. For example, a second transform index applied to the luma TB is decoded from the bitstream only for coding units using intra prediction and the shared coding tree structure (1890). Similarly, a second transform index applied to the chroma TB is decoded from the bitstream only for coding units using intra prediction and the shared coding tree structure (1895). Operations of steps such as decoding subblocks (1870), dequantizing first transform coefficients (18110), and performing the first transform can be performed for inter prediction modes or for intra prediction modes other than for the shared coding tree structure using known methods. Steps 1810-1840 are performed in the described manner regardless of the prediction mode or structure.

[0243] Upon completion of the method 1800, subsequent steps are performed to decode the coding unit, including generating intra-prediction samples 480 by module 476, summing the decoded residual samples 448 with the prediction block 452 by module 450, and applying an in-loop filter module 488 to generate filtered samples 492, which are output as frame data 135.

[0244] 19A and 19B show rules for applying or bypassing the second transform to the luma and chroma channels. Figure 19A shows a table 1900 illustrating conditions for applying the second transform to the luma and chroma channels in a CU resulting from a shared coding tree.

[0245] Condition 1901 exists if the last significant coefficient position of the luma TB indicates a decoded significant coefficient that did not result from a forward second transform and therefore does not undergo an inverse second transform. Condition 1902 exists if the last significant coefficient position of the luma TB indicates a decoded significant coefficient that resulted from a forward second transform and therefore undergoes an inverse second transform. Furthermore, for the luma channel, the first transform type must be DCT-2 for condition 1902 to exist; otherwise, condition 1901 exists.

[0246] Condition 1910 exists if the last significant coefficient position of one or two chroma TBs indicates a decoded significant coefficient that did not result from a forward second transform and therefore does not undergo an inverse second transform. Condition 1911 exists if the last significant coefficient position of one or two chroma TBs indicates a decoded significant coefficient that resulted from a forward second transform and therefore does undergo an inverse second transform. Furthermore, the width and height of the chroma block must be at least four samples for condition 1911 to exist (e.g., chroma subsampling when a 4:2:0 or 4:2:2 chroma format is used can result in a width or height of two samples).

[0247] If conditions 1901 and 1910 exist, no second transform index is signaled (independently or together) and is not applied in luma or chroma (i.e., 1920). If conditions 1901 and 1911 exist, one second transform index is signaled, indicating application of a selected kernel or bypassing only the luma channel, i.e., 1921. If conditions 1902 and 1910 exist, one second transform index is signaled, indicating application of a selected kernel or bypassing only the chroma channel, i.e., 1922. If conditions 1911 and 1902 exist, the configuration with independent signaling signals is two second transform indexes, i.e., one for luma TB and one for chroma TB, i.e., 1923. A configuration with a single signaled second transform index uses one index to control the selection of luma and chroma when conditions 1902 and 1911 exist, but this selected kernel also depends on the luma and chroma intra prediction modes, which may be different. The ability to apply the second transform to either luma or chroma (i.e., 1921 and 1922) results in coding efficiency gains.

[0248] FIG. 19B shows a table 1950 of search options available to the video encoder 114 in step 1360. The luma (1952) and chroma (1953) second transform indices are shown as 1952 and 1953, respectively. An index value of 0 indicates that the second transform is bypassed, while index values ​​of 1 and 2 indicate which of two kernels from the candidate set derived from the luma or chroma intra-prediction mode is used. There are nine resulting search spaces (from "0,0" to "2,2"), which may be constrained depending on the constraints described with reference to FIG. 19A. Compared to searching all allowable combinations, a simplified search of three combinations (1951) can test only combinations in which the luma and chroma second transform indices are the same, subject to the condition that the last significant coefficient position has a zero index for the channel indicating the presence of a first-order only coefficient. For example, if condition 1921 exists, the options "1,1" and "2,2" become "0,1" and "0,2," respectively (i.e., 1954). If condition 1922 exists, the options "1,1" and "2,2" become "1,0" and "2,0," respectively (i.e., 1955). If condition 1920 exists, there is no need to signal a second transform index, and option "0,0" is used. In effect, conditions 1921 and 1922 allow the options "0,1," "0,2," "1,0," and "2,0" in the shared tree CU, resulting in higher compression efficiency. If these options were prohibited, either condition 1901 or 1910 would lead to condition 1920, i.e., the options "1,1" and "2,2" would be prohibited, leading to the use of "0,0" (see 1956).

[0249] Signaling quantization group subdivision levels in the slice header provides a finer granularity of control below the picture level. The finer granularity of control is advantageous in applications where coding fidelity requirements vary from one part of an image to another, particularly when multiple encoders need to operate somewhat independently to provide real-time processing capabilities. Signaling quantization group subdivision levels in the slice header also coincides with signaling partition override settings and scaling list application settings in the slice header.

[0250] In one configuration of video encoder 114 and video decoder 134, the second transform index of a chroma intra-predicted block is always set to zero, i.e., no second transform is applied to the chroma intra-predicted block. In this case, there is no need to signal the chroma second transform index, and therefore steps 15130 and 1895 can be omitted, thus simplifying steps 1360, 1570, and 18100.

[0251] If a node in a coding tree in the shared tree has an area of ​​64 luma samples, further partitioning with binary or quadtree partitioning results in smaller luma CBs, such as 4x4 blocks, but not smaller chroma CBs. Instead, there is a single chroma CB of a size corresponding to the area of ​​64 luma samples, such as a 4x4 chroma CB. Similarly, a coding tree node having an area of ​​128 luma samples and undergoing ternary partitioning results in a set of smaller luma CBs and one chroma CB. Each luma CB has a corresponding luma second transform index, and the chroma CB has a chroma second transform index.

[0252] If a node in the coding tree has an area of ​​64 and a further partition is signaled, or an area of ​​128 luma samples and a ternary partition is signaled, the partition is applied to the luma channel only, and the resulting CBs (several luma CBs and one chroma CB for each chroma channel) are all intra predicted or all inter predicted. If a CU has a width or height of four luma samples and includes one CB for each of the color channels (Y, CB, and Cr), the chroma CB of that CU has a width or height of two samples. A CB with a width or height of two samples does not operate with a 16-point or 48-point LFNST kernel and therefore does not require a second transform. For blocks with a width or height of two samples, steps 15130, 1895, 1360, 1570, and 18100 do not need to be performed.

[0253] In another configuration of the video encoder 114 and the video decoder 134, a single second transform index is signaled when one or both of the luma and chroma TBs contain only ineffective residual coefficients within the region of the respective TBs that undergo only the first transform. If the luma TB contains effective residual coefficients in a non-second transform region of the decoded residual (e.g., 1066, 968) or indicates that DCT-2 is not used as the first transform, the indicated second transform kernel (or second transform bypass) is applied only to the chroma TB. If any chroma TB contains effective residual coefficients in a non-second transform region of the decoded residual, the indicated second transform kernel (or second transform bypass) is applied only to the luma TB. Even if application of the second transform is not possible for the chroma TB, it is possible for the luma TB, and vice versa, providing a coding efficiency gain compared to requiring the last positions of all TBs of a CU to be in the second coefficient domain before any TB of the CU can undergo the second transform. Furthermore, only one second transform index is required for a CU in a shared coding tree. If the luma first transform is DCT-2, then the second transform can be inferred to be invalid for chroma as well as luma.

[0254] In another configuration of the video encoder 114 and the video decoder 134, the second transform is applied only to the luma TB of the CU (by modules 330 and 436, respectively), and not to any chroma TB of the CU. The absence of second transform logic for the chroma channels results in less complexity, e.g., less execution time or reduced silicon area. The absence of second transform logic for the chroma channels results in the need to signal only one second transform index, which may be signaled after the last position of the luma TB. That is, steps 1590 and 1860 are performed on the luma TB instead of steps 15120 and 1890. In this case, steps 15130 and 1895 are omitted.

[0255] In another configuration of the video encoder 114 and the video decoder 134, syntax elements defining the quantization group size (i.e., cu_chroma_qp_offset_subdiv and cu_qp_delta_subdiv) are signaled to the PPS 1112. Even if the partition constraint is overridden in the slice header 1118, the range of values ​​for the subdivision level is defined according to the partition constraint indicated in the SPS 1110. For example, the range of cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv is defined as 0 to 2 × (log2_ctu_size_minus5 + 5 - (MinQtLog2SizeInterY or MinQtLog2SizeIntraY) + MaxMttDepthY_SPS). This value, MaxMttDepthY, is derived from the SPS 1110. That is, MaxMttDepthY is set equal to sps_max_mtt_hierarchy_depth_intra_slice_luma if the current slice is an I slice, and equal to sps_max_mtt_hierarchy_depth_inter_slice if the current slice is a P or B slice. For slices with partition constraints overridden to be shallower than the depth signaled in SPS 1110, if the quantization group subdivision level determined from PPS 1112 is higher (deeper) than the highest achievable subdivision level under the shallower coding tree depth determined from the slice header, the quantization group subdivision level of the lp slice is clipped to be equal to the highest achievable subdivision level of that slice. For example, the cu_qp_delta_subdiv and cu_chroma_qp_offset_subdiv for a particular slice are clipped from 0 to 2*(log2_ctu_size_minus5 + 5 - (MinQtLog2SizeInterY or MinQtLog2SizeIntraY) + MaxMttDepthY_slice_header) and this clipped value is used for the slice.This value MaxMttDepthY_slice_header is derived from the slice header 1118, ie, MaxMttDepthY_slice_header is set equal to slice_max_mtt_hierarchy_depth_luma.

[0256] In yet another configuration of the video encoder 114 and the video decoder 134, to derive the luma and chroma subdivision levels, the subdivision level is determined from cu_chroma_qp_offset_subdiv and cu_qp_delta_subdiv decoded from the PPS 1112. When the partition constraint decoded from the slice header 1118 results in a different range of subdivision levels for the slice, the subdivision level applied to the slice is adjusted to maintain the same offset relative to the deepest allowed subdivision level according to the partition constraint decoded from the SPS 1110. For example, if the SPS 1110 indicates a maximum subdivision level of 4, the PPS 1112 indicates a subdivision level of 3, and the slice header 1118 reduces the maximum value to 3, the subdivision level applied within the slice is set to 2 (maintaining an offset of 1 relative to the maximum allowed subdivision level). Adjusting the quantization group area to accommodate changes in partition constraints for a particular slice allows for less frequent signaling of the subdivision level (i.e., at the PPS level) while providing the granularity to accommodate changes in slice-level partitioning constraints. A configuration in which the subdivision level is signaled in the PPS 1112 uses ranges defined according to the partitioning constraints decoded from the SPS 1110, allows for later adjustment based on overridden partition constraints decoded from the slice header 1118, and avoids problems dependent on parsing PPS syntax elements according to the partition constraints finalized in the slice header 1118.

[0257] [Industrial Applicability] The described arrangements are applicable to the computer and data processing industry, especially digital signal processing for decoding of signals such as video and image signals, to achieve high compression efficiency.

[0258] The arrangements described herein increase the flexibility afforded to video encoders in generating highly compressed bitstreams from input video data. Quantization of different regions or sub-pictures within a frame can be controlled with varying granularity, and with different granularity from one region to another, reducing the amount of coded residual data. Thus, higher granularity can be achieved, if desired, for example, for 360-degree images as described above.

[0259] In some configurations, the application of the second transform can be controlled independently for luma and chroma, as described in connection with steps 15120 and 15130 (and corresponding steps 1890 and 1895), to achieve further reduction of the coded residual data. A video decoder is described with the functionality necessary to decode a bitstream produced by such a video encoder.

[0260] The above describes only some embodiments of the present invention, and modifications and / or variations can be made to the present invention without departing from the scope and spirit of the invention; the embodiments are illustrative and not limiting.

Claims

1. 1. A method performed by a decoding device for decoding a coding unit in a coding tree unit of an image from a bitstream, the coding tree unit having a luma channel and a chroma channel, the method comprising: determining the coding unit including the luma channel and the chroma channel according to one or more split flags for the coding tree unit; decoding from the bitstream an index for selecting a non-separable transform kernel for the luma channel; selecting the non-separable transform kernel according to the index; decoding, from the bitstream, coefficients of a luma transform block for the luma channel in the coding unit and coefficients of a chroma transform block for the chroma channel in the coding unit; applying the selected non-separable transform kernel to perform a non-separable transform on the coefficients of the luma transform block to derive non-separable transformed coefficients of the luma transform block; performing a separable transform on the non-separable transformed coefficients of the luma transform block and the coefficients of the chroma transform block, and decoding the coding unit; the coding unit is one of one or more coding units obtained from one or more divisions of the coding tree unit, the one or more divisions including a vertical ternary division; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are the same, the non-separable transform is only performed on the coefficients of the luma transform block in the coding unit, and the non-separable transform is not performed on the coefficients of the chroma transform block in the coding unit, and both the width and height of the chroma transform block are greater than or equal to 4; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are separate, a region in the coding tree unit is divided into a plurality of luma coding blocks, and a chroma coding block corresponding to the region exists, the index for selecting the non-separable transform kernel for the luma channel can exist separately for each of the plurality of luma coding blocks, and an index for selecting a non-separable transform kernel for the chroma channel can exist for the chroma coding block corresponding to the region; When the non-separable transform is performed on the luminance transform block whose width and height are each equal to or greater than 8, the number of coefficients of the luminance transform block output in the non-separable transform is 48; wherein the number of coefficients of the luma transform block output in the non-separable transform is 16 when the non-separable transform is performed on the luma transform block whose width and / or height are less than 8.

2. The method of claim 1 , wherein the non-separable transform is a LFNST.

3. 2. The method of claim 1, wherein the non-separable transform is not performed if intra-prediction is not used.

4. 1. A method performed by an encoding device for encoding coding units in a coding tree unit of an image into a bitstream, the coding tree unit having a luma channel and a chroma channel, the method comprising: determining the coding unit in the coding tree unit, the coding unit including the luma channel and the chroma channel; performing a separable transform on coefficients of the luma transform block for the luma channel in the coding unit to derive separable transformed coefficients of the luma transform block for the luma channel in the coding unit; performing a separable transform on coefficients of the saturation transform block for the saturation channel in the coding unit to derive separable transformed coefficients of the saturation transform block for the saturation channel in the coding unit; selecting a non-separable transform kernel for the luminance channel; performing a non-separable transform on the separable transformed coefficients of the luma transform block by applying the selected non-separable transform kernel; encoding an index for selecting the non-separable transform kernel for the luma channel into the bitstream; the coding unit is one of one or more coding units obtained from one or more divisions of the coding tree unit, the one or more divisions including a vertical ternary division; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are the same, the non-separable transform is only performed on the separable transformed coefficients of the luma transform block in the coding unit, and the non-separable transform is not performed on the separable transformed coefficients of the chroma transform block in the coding unit, and both the width and height of the chroma transform block are greater than or equal to 4; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are separate, a region in the coding tree unit is divided into a plurality of luma coding blocks, and a chroma coding block corresponding to the region exists, the index for selecting the non-separable transform kernel for the luma channel can exist separately for each of the plurality of luma coding blocks, and an index for selecting a non-separable transform kernel for the chroma channel can exist for the chroma coding block corresponding to the region; When the non-separable transform is performed on the luminance transform block whose width and height are each equal to or greater than 8, the number of coefficients of the luminance transform block output in the non-separable transform is 48; wherein the number of coefficients of the luma transform block output in the non-separable transform is 16 when the non-separable transform is performed on the luma transform block whose width and / or height are less than 8.

5. 5. The method of claim 4, wherein the non-separable transform is a LFNST.

6. 5. The method of claim 4, wherein the non-separable transform is not performed if intra-prediction is not used.

7. 1. A decoding device for decoding a coding unit in a coding tree unit of an image from a bitstream, the coding tree unit having a luma channel and a chroma channel, the decoding device comprising: determining means for determining the coding unit including the luma channel and the chroma channel according to one or more split flags for the coding tree unit; first decoding means for decoding from the bitstream an index for selecting a non-separable transform kernel for the luminance channel; a selection means for selecting the non-separable transformation kernel according to the index; second decoding means for decoding, from the bitstream, coefficients of a luma transform block for the luma channel in the coding unit and coefficients of a saturation transform block for the saturation channel in the coding unit; transform means for applying the selected non-separable transform kernel to perform a non-separable transform on the coefficients of the luma transform block to derive non-separable transformed coefficients of the luma transform block; and third decoding means for performing a separable transform on the non-separable transformed coefficients of the luma transform block and the coefficients of the chroma transform block to decode the coding unit; the coding unit is one of one or more coding units obtained from one or more divisions of the coding tree unit, the one or more divisions including a vertical ternary division; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are the same, the non-separable transform is only performed on the coefficients of the luma transform block in the coding unit, and the non-separable transform is not performed on the coefficients of the chroma transform block in the coding unit, and both the width and height of the chroma transform block are greater than or equal to 4; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are separate, a region in the coding tree unit is divided into a plurality of luma coding blocks, and a chroma coding block corresponding to the region exists, the index for selecting the non-separable transform kernel for the luma channel can exist separately for each of the plurality of luma coding blocks, and an index for selecting a non-separable transform kernel for the chroma channel can exist for the chroma coding block corresponding to the region; When the non-separable transform is performed on the luminance transform block whose width and height are each equal to or greater than 8, the number of coefficients of the luminance transform block output in the non-separable transform is 48; A decoding device characterized in that, when the non-separable transform is performed on the luminance transform block whose width and / or height are smaller than 8, the number of coefficients of the luminance transform block output in the non-separable transform is 16.

8. 1. An encoding device for encoding a coding unit in a coding tree unit of an image into a bitstream, the coding tree unit having a luma channel and a chroma channel, the encoding device comprising: determining means for determining the coding unit including the luma channel and the chroma channel in the coding tree unit; performing a separable transform on coefficients of the luma transform block for the luma channel in the coding unit to derive separable transformed coefficients of the luma transform block for the luma channel in the coding unit; first transform means for performing a separable transform on coefficients of the saturation transform block for the saturation channel in the coding unit to derive separable transformed coefficients of the saturation transform block for the saturation channel in the coding unit; a selection means for selecting a non-separable transform kernel for the luminance channel; second transform means for performing a non-separable transform on the separable transformed coefficients of the luminance transform block by applying the selected non-separable transform kernel; encoding means for encoding an index for selecting the non-separable transform kernel for the luminance channel into the bitstream; the coding unit is one of one or more coding units obtained from one or more divisions of the coding tree unit, the one or more divisions including a vertical ternary division; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are the same, the non-separable transform is only performed on the separable transformed coefficients of the luma transform block in the coding unit, and the non-separable transform is not performed on the separable transformed coefficients of the chroma transform block in the coding unit, and both the width and height of the chroma transform block are greater than or equal to 4; when the coding tree for the luma channel in the coding tree unit and the coding tree for the chroma channel in the coding tree unit are separate, a region in the coding tree unit is divided into a plurality of luma coding blocks, and a chroma coding block corresponding to the region exists, the index for selecting the non-separable transform kernel for the luma channel can exist separately for each of the plurality of luma coding blocks, and an index for selecting a non-separable transform kernel for the chroma channel can exist for the chroma coding block corresponding to the region; when the non-separable transform is performed on the luminance transform block whose width and height are each equal to or greater than 8, the number of coefficients of the luminance transform block output in the non-separable transform is 48; When the non-separable transform is performed on the luminance transform block whose width and / or height are smaller than 8, the number of coefficients of the luminance transform block output in the non-separable transform is 16.

9. A computer program for causing a computer to function as an apparatus for carrying out the method according to any one of claims 1 to 3.

10. A computer program for causing a computer to function as an apparatus for carrying out the method according to any one of claims 4 to 6.

Images