Method, apparatus, and program for decoding and encoding an encoding unit.

Abstract

To provide a method for decoding an encoded tree unit of an image frame from a video bit stream into an encoded unit of the encoded tree.SOLUTION: In a method for decoding an encoded unit from a bit stream, the encoded unit is divided from an encoded tree unit of an image by the use of a tree structure, and the encoded unit can have a luma component and a chroma component, which includes a Cb component and a Cr component. The method includes: a first decoding step of decoding a luma conversion skip flag for the luma component from the bit stream when the encoded unit has the luma component; a second decoding step of decoding a first chroma conversion skip flag for the Cb component and a second chroma conversion skip flag for the Cr component from the bit stream when the encoded unit has the chroma component; and a determination step of determining an LFNST index for LFNST processing.SELECTED DRAWING: Figure 16

Description

Technical Field

[0001] Reference to Related Applications This application claims the benefit of the filing date under 35 U.S.C. § 119 of Australian Patent Application No. 2019275553, filed on Dec. 3, 2019, which is hereby incorporated by reference in its entirety as if fully set forth herein.

[0002] The present invention generally relates to digital video signal processing, and more particularly, to methods, apparatuses, and systems 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 Art

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

[0004] The Joint Video Expert Team (JVET) issued a Call for Proposals (CfP) and analyzed the responses at its 10th meeting held in San Diego, USA. The submitted proposals demonstrated video compression capabilities that significantly surpassed the current state-of-the-art video compression standard, High Efficiency Video Coding (HEVC). As a result, it was decided to launch a development project for a new video compression standard, Multipurpose Video Coding (VVC). VVC requires higher compression performance than ever before, driven by the increasing sophistication of video formats (higher resolution, higher frame rates) and the growing market demand for service delivery over WANs where bandwidth costs are relatively high. Use cases such as immersive video require real-time encoding and decoding of such high-resolution formats; for example, cubemap projection (CMP) may use the 8K format even if the final rendered "viewport" is low resolution. VVC must be implementable with modern silicon processes and must offer an acceptable trade-off between the performance achieved and the implementation cost. Implementation costs can be considered from one or more perspectives, for example, silicon area, CPU processor load, memory utilization, and bandwidth. Higher-order video formats can be processed by dividing the frame region into multiple sections and processing each section in parallel. A bitstream constructed from multiple sections of a compressed frame, suitable for decoding by a "single-core" decoder (i.e., frame-level constraints including bitrate), is allocated to each section according to the application's needs.

[0005] Video data consists of a sequence of multiple frames of image data, each containing one or more color channels. Generally, one primary color channel and two secondary color channels are required. The primary color channel is commonly called the "luma" channel, and the secondary color channels are commonly called the "chroma" channels. Video data is usually displayed in the RGB (red-green-blue) color space, which has a high degree of correlation between its three components. The representation of video data seen by encoders and decoders often uses a color space such as YCbCr. YCbCr aggregates luminance, mapped to "luma" by a transfer function, into the Y (primary) channel, and chroma into the Cb and Cr (secondary) channels. Because it uses uncorrelated 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 has relatively few significant coefficients in a given block compared to the coefficients of the corresponding luma channel block. Furthermore, Cb and Cr channels may be spatially sampled (subsampled) at a lower rate than the chroma channels, for example, half horizontally and half vertically. This is known as the "4:2:0 chroma format." The 4:2:0 chroma format is used in consumer applications such as internet video streaming, television broadcasting, and storage on Blu-ray discs. A method in which Cb and Cr channels are subsampled horizontally at half rate, but not vertically, is known as the "4:2:2 chroma format." The 4:2:2 chroma format is often used for professional applications, such as shooting video for filmmaking. Because of its high sampling rate, the 4:2:2 chroma format produces video that is robust for editing tasks such as color grading. 4:2:2 chroma format material is often converted to the 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.Resolutions include ultra-high definition (UHD) of 3840x2160 and "8K" of 7680x4320, and frame rates include 60Hz and 120Hz. Luma sample rates range from approximately 500 megasamples / second to several gigasamples / second. In the 4:2:0 chroma format, the sample rate of each chroma channel is 1 / 4 of the luma sample rate, and in the 4:2:2 chroma format, the sample rate of each chroma channel is 1 / 2 of the luma sample rate.

[0006] The VVC standard is a "block-based" codec where a frame is first divided into a series of square regions known as "encoded tree units" (CTUs). If a frame cannot be integer-divided into multiple CTUs, multiple CTUs along the left and bottom edges may be truncated to fit the frame size. CTUs typically occupy relatively large areas, such as 128x128 luma samples. However, CTUs at the right or bottom edges of a frame may be smaller in area. The "encoded tree" associated with each CTU may be a single tree ("shared tree") for both luma and chroma channels, or it may contain "forks" in separate trees ("dual trees") for each of the luma and chroma channels. The encoding tree defines the decomposition of the CTU region into a set of blocks called "encoded units" (CUs). CBs are processed for encoding or decoding in a specific order. The separate encoding trees for luma and chroma generally start at a luma sample granularity of 64x64, beyond which the shared tree exists. Because the 4:2:0 chroma format is used, individual coding tree structures starting with a 64x64 luma sample granularity contain chroma coding trees with 32x32 chroma sample regions. A "unit" indicates that it applies to all color channels of the coding tree from which the block originates. A single coding tree becomes a coding unit with one luma coding block and two chroma coding blocks. A luma branch of another coding tree each yields a coding unit with one luma coding block, and a chroma branch of another coding tree each yields a coding unit with a pair of chroma blocks. The CUs mentioned above are also associated with "prediction units" (PUs) and "transformation units" (TUs), each of which applies to all color channels of the coding tree from which the CU is derived. Similarly, coding blocks are associated with prediction blocks (PBs) and transformation blocks (TBs), each applying to a single color channel. A single tree with CUs spanning the color channels of 4:2:0 chroma format video data results in chroma coding blocks having half the width and height of their corresponding luma coding blocks.

[0007] Regardless of the above distinction between "units" and "blocks," the term "block" can be used as a general term for an area or region of a frame to which calculations are applied across all color channels.

[0008] For each CU, a prediction unit (PU) is generated for the content (sample value) of the corresponding area of ​​the frame data. Furthermore, a representation of the difference (or "spatial domain" residual) between the predicted value and the content of the region seen at input to the encoder is formed. The difference for each color channel is transformed and encoded as a sequence of residual coefficients, which can form one or more TUs for a given CU. The transformation applied may be a discrete cosine transform (DCT) or other transformation applied to each block of residual values. This transformation is applied in separate steps, and a two-dimensional transformation is performed in two passes. First, the block is transformed by applying a one-dimensional transformation to each row of samples within the block. Next, the partial result is transformed by applying a one-dimensional transformation to each column of the partial result, generating a final block of transformation coefficients that substantially correlates the residual samples. The VVC standard supports transformations of various sizes, including transformations of rectangular blocks where each side is a power of 2. The transformation coefficients are quantized for entropy coding to the bitstream. Additionally, an inseparable transformation stage may be applied. Finally, the application of transformations may be bypassed.

[0009] The features of VVC are intra-frame prediction and inter-frame prediction. Intra-frame prediction generates a prediction for the current sample block in a frame using previously processed samples within the frame. Inter-frame prediction involves generating a prediction for the current block of samples in a frame using a block of samples obtained from a previously decoded frame. The block of samples obtained from the previously decoded frame is offset from the spatial position of the current block according to a motion vector and is often filtered. The intra-frame predicted block can be (i) a uniform sample value ("DC intra-prediction"), (ii) a plane with offsets and horizontal and vertical slopes ("plane intra-prediction"), (iii) a set of neighboring samples and blocks applied in a particular direction ("angle intra-prediction"), or (iv) the result of a matrix product with neighboring samples and selected matrix coefficients. Further discrepancies between the predicted block and the corresponding input sample can be corrected to some extent by encoding "residuals" into the bitstream. Residuals are generally transformed from the spatial domain to the frequency domain (in the "first-order transformation" domain) to form residual coefficients, and may be further transformed by the application of a "second-order transformation" (to generate residual coefficients in the "second-order transformation" domain). The residual coefficients are quantized according to the quantization parameters, resulting in a loss of accuracy in the reconstruction of the samples generated by the decoder, but a decrease in the bitrate of the bitstream.

[0010] Quantization parameters can vary between frames and within each frame. Varying quantization parameters within a frame is a typical example of a "rate-controlled" encoder. A rate-controlled encoder attempts to produce a bitstream at a substantially constant bit rate, regardless of the statistics of the received input samples, such as noise characteristics and degree of motion. Since bitstreams are typically transmitted over networks with limited bandwidth, rate control is a widely used technique to ensure reliable performance on the network regardless of variations in the original frames fed into the encoder. When frames are encoded in parallel sections, flexibility is required in using rate control because different sections require different levels of fidelity.

[0011] Furthermore, implementation costs such as memory usage, accuracy, and communication efficiency are also important. [Overview of the project]

[0012] The object of the present invention is to substantially overcome, or at least improve upon, one or more drawbacks of existing devices.

[0013] One aspect of the present disclosure is a method for decoding an encoding unit of an encoding tree from an encoding tree unit of an image frame from a video bitstream, wherein the encoding unit has one lumina color channel and at least one chroma color channel, and the method is For the Luma conversion block of the encoding unit, the Luma conversion skip flag is decoded from the video bitstream. Decoding at least one chroma transformation skip flag from the video bitstream, wherein each of the decoded chroma transformation skip flags corresponds to one of at least one chroma transformation blocks of the encoding unit. The purpose of determining the quadratic transformation index is to determine the following: When both the luma conversion skip flag and the chroma conversion skip flag indicate that the conversion of the respective conversion block will be skipped, the secondary conversion index is determined to indicate that the secondary conversion will not be applied. When both the luma conversion skip flag and the chroma conversion skip flag indicate that the conversion of each conversion block will not be skipped, the secondary conversion index is decoded from the video bitstream. Including the above determination, To provide residual samples of each transformation block of the encoding unit, the luma transformation block and the at least one chroma transformation block are transformed according to the decoded luma transformation skip flag, the at least one chroma transformation skip flag, and the determined secondary transformation index. Decoding the coding unit by combining the residual samples of each transformation block of the coding unit with the prediction blocks of each block of the coding unit, wherein each prediction block is generated according to the prediction mode of the coding unit. This provides a method that includes [something].

[0014] Another aspect of the present disclosure is a non-temporary computer-readable medium storing a computer program for carrying out a method for decoding encoding units from encoding tree units of image frames from a video bitstream, wherein the encoding units have one lumina color channel and at least one chroma color channel, and the method For the Luma conversion block of the encoding unit, the Luma conversion skip flag is decoded from the video bitstream. Decoding at least one chroma transformation skip flag from the video bitstream, wherein each of the decoded chroma transformation skip flags corresponds to one of at least one chroma transformation blocks of the encoding unit. The purpose of determining the quadratic transformation index is to determine the following: When both the luma conversion skip flag and the chroma conversion skip flag indicate that the conversion of the respective conversion block will be skipped, the secondary conversion index is determined to indicate that the secondary conversion will not be applied. When both the luma conversion skip flag and the chroma conversion skip flag indicate that the conversion of each conversion block will not be skipped, the secondary conversion index is decoded from the video bitstream. Including the above determination, To provide residual samples of each transformation block of the encoding unit, the luma transformation block and the at least one chroma transformation block are transformed according to the decoded luma transformation skip flag, the at least one chroma transformation skip flag, and the determined secondary transformation index. Decoding the coding unit by combining the residual samples of each transformation block of the coding unit with the prediction blocks of each block of the coding unit, wherein each prediction block is generated according to the prediction mode of the coding unit. It provides a non-temporary computer-readable medium that includes [the specified element].

[0015] Another aspect of this disclosure provides a system including memory,

[0016] A processor, the processor is configured to execute code stored in memory to perform a method of decoding an encoding unit from an encoding tree unit of an image frame from a video bitstream, the encoding unit having at least one chroma color channel, the processor and The method includes, For the Luma conversion block of the encoding unit, the Luma conversion skip flag is decoded from the video bitstream. Decoding at least one chroma transform skip flag from the video bitstream, each of the decoded chroma transform skip flags corresponding to one of at least one chroma transform block of the encoding unit, the decoding, Determining a secondary transform index, the determining comprising: Determining the secondary transform index such that when all of the luma transform skip flag and the chroma transform skip flag indicate that the transforms of their respective transform blocks are skipped, the secondary transform is not applied; When all of the luma transform skip flag and the chroma transform skip flag indicate that the transforms of their respective transform blocks are not skipped, decoding the secondary transform index from the video bitstream; Including the determining; Transforming the luma transform block and the at least one chroma transform block according to the decoded luma transform skip flag, the at least one chroma transform skip flag, and the determined secondary transform index to provide residual samples of each transform block of the encoding unit; Decoding the encoding unit by combining the residual samples of each transform block of the encoding unit and the prediction block of each block of the encoding unit, each prediction block being generated according to the prediction mode of the encoding unit, the decoding; Providing a system including.

[0017] Another aspect of the present disclosure is a video decoder, comprising: Receiving an image frame from a video bitstream; Determining an encoding unit of an encoding tree from an encoding tree unit of the image frame, the encoding unit having one luma color channel and at least one chroma color channel; Decoding a luma transform skip flag from the video bitstream for a luma transform block of the encoding unit; Decoding at least one chroma transform skip flag from the video bitstream, each of the decoded chroma transform skip flags corresponding to one of at least one chroma transform block of the encoding unit, Determining a secondary transform index, the determination comprising: Determining the secondary transform index such that when all of the luma transform skip flag and the chroma transform skip flag indicate that the transform of each respective transform block is skipped, the secondary transform is not applied; Decoding the secondary transform index from the video bitstream when all of the luma transform skip flag and the chroma transform skip flag indicate that the transform of each respective transform block is not skipped; comprising: Transforming the luma transform block and the at least one chroma transform block according to the decoded luma transform skip flag, the at least one chroma transform skip flag, and the determined secondary transform index to provide residual samples of each transform block of the encoding unit; Decoding the encoding unit by combining the residual samples of each transform block of the encoding unit and a prediction block of each block of the encoding unit, each prediction block being generated according to a prediction mode of the encoding unit; A video decoder configured as described above is provided.

[0018] One aspect of the present invention is a method of decoding an encoding unit from an encoding tree unit of an image frame from a video bitstream, the method comprising: Determining a scan pattern for a transform block of the coding unit, wherein the scan pattern traverses the transform block by progressing through a plurality of non-overlapping collections of subblocks of residual coefficients, and after completing the scan of the current collection, the scan pattern progresses from the current collection to the next collection of the plurality of collections; Decoding the residual coefficients from the video bitstream according to the determined scan pattern, Determining a multiple transformation selection index for the coding unit, wherein the determination involves, Decoding the multiple transformation selection index from the video bitstream when the last significant coefficient encountered along the scan pattern is orthogonal to the threshold position of the transformation block or within that range, When the position of the last significant residual coefficient of the transformation block along the scan pattern is outside the threshold orthogonal position, the multiple transformation selection index is determined to indicate that multiple transformation selection is not being used. Including the above determination, In order to decode the encoding unit, the decoded residual coefficients are transformed by applying a transformation according to the multiple transformation selection index, This provides a method that includes [something].

[0019] In another embodiment, the selected scan pattern scans multiple residual coefficients of each subblock in a backward oblique manner.

[0020] In another embodiment, the selected scan pattern scans multiple subblocks of each collection in a rearward-oblique manner.

[0021] In another embodiment, the selected scan pattern scans the plurality of collections in a rearward oblique manner.

[0022] In another embodiment, the selected scan pattern scans the plurality of collections in a backraster manner.

[0023] In another embodiment, the fact that the multiple transformation selection index is zero indicates the application of the inverse transformation of DCT-2 in the horizontal and vertical directions.

[0024] In another embodiment, a multiple transformation selection index greater than zero indicates that either the inverse DST-7 or DCT-8 transformation is applied horizontally, and either the inverse DST-7 or DCT-8 transformation is applied vertically.

[0025] In another embodiment, each collection is a two-dimensional array of multiple subblocks, each having a width and height of up to four subblocks.

[0026] Another aspect of the present invention is a non-temporary computer-readable medium storing a computer program for carrying out a method for decoding encoding units from encoding tree units of image frames from a video bitstream, wherein the method is Determining a scan pattern for a transform block of the coding unit, wherein the scan pattern traverses the transform block by progressing through a plurality of non-overlapping collections of subblocks of residual coefficients, and after completing the scan of the current collection, the scan pattern progresses from the current collection to the next collection of the plurality of collections; Decoding the residual coefficients from the video bitstream according to the determined scan pattern, Determining a multiple transformation selection index for the coding unit, wherein the determination involves, Decoding the multiple transformation selection index from the video bitstream when the last significant coefficient encountered along the scan pattern is orthogonal to the threshold position of the transformation block or within that range, When the position of the last significant residual coefficient of the transformation block along the scan pattern is outside the threshold orthogonal position, the multiple transformation selection index is determined to indicate that multiple transformation selection is not being used. Including the above determination, In order to decode the encoding unit, the decoded residual coefficients are transformed by applying a transformation according to the multiple transformation selection index, It provides a non-temporary computer-readable medium that includes [the specified element].

[0027] Another aspect of the present invention is a system, Memory and A processor, wherein the processor is configured to execute code stored in memory to perform a method of decoding encoding units from encoding tree units of image frames from a video bitstream, The method includes, Determining a scan pattern for a transform block of the coding unit, wherein the scan pattern traverses the transform block by progressing through a plurality of non-overlapping collections of subblocks of residual coefficients, and after completing the scan of the current collection, the scan pattern progresses from the current collection to the next collection of the plurality of collections; Decoding the residual coefficients from the video bitstream according to the determined scan pattern, Determining a multiple transformation selection index for the coding unit, wherein the determination involves, Decoding the multiple transformation selection index from the video bitstream when the last significant coefficient encountered along the scan pattern is orthogonal to the threshold position of the transformation block or within that range, When the position of the last significant residual coefficient of the transformation block along the scan pattern is outside the threshold orthogonal position, the multiple transformation selection index is determined to indicate that multiple transformation selection is not being used. Including the above determination, In order to decode the encoding unit, the decoded residual coefficients are transformed by applying a transformation according to the multiple transformation selection index, We provide a system that includes this.

[0028] Another aspect of the present invention is a video decoder, Receive image frames from a video bitstream, The encoding units of the encoding tree are determined from the encoding tree units of the aforementioned image frame. Determine a scan pattern for the transformation block of the coding unit, where the scan pattern traverses the transformation block by proceeding through multiple non-overlapping collections of subblocks of residual coefficients, and after completing the scan of the current collection, the scan pattern proceeds from the current collection to the next collection of the multiple collections. The residual coefficients are decoded from the video bitstream according to the determined scan pattern. The multiple transformation selection index for the encoding unit is determined, and this determination is: Decoding the multiple transformation selection index from the video bitstream when the last significant coefficient encountered along the scan pattern is orthogonal to the threshold position of the transformation block or within that range, When the position of the last significant residual coefficient of the transformation block along the scan pattern is outside the threshold orthogonal position, the multiple transformation selection index is determined to indicate that multiple transformation selection is not being used. Includes, To decode the encoding unit, the decoded residual coefficients are transformed by applying a transformation according to the multiple transformation selection index. A video decoder configured in such a way is provided.

[0029] Another aspect of the present invention is a method for decoding an encoding unit of an encoding tree from an encoding tree unit of an image frame from a video bitstream, wherein the encoding unit has one lumina color channel and at least one chroma color channel, and the method is For the Luma conversion block of the encoding unit, the Luma conversion skip flag is decoded from the video bitstream. Decoding at least one chroma transformation skip flag from the video bitstream, wherein each of the decoded chroma transformation skip flags corresponds to one of at least one chroma transformation blocks of the encoding unit. The purpose of determining the quadratic transformation index is to determine the following: When at least one of the chroma conversion skip flag and the at least one chroma conversion skip flag indicates that the conversion of each conversion block is not skipped, the secondary conversion index is decoded from the video bitstream. When all of the luma conversion skip flags and at least one chroma conversion skip flags indicate that the conversion of each conversion block is skipped, the secondary conversion index is determined to indicate that the secondary conversion is not applied. Including the above determination, To decode the encoding unit, the luma transform block and the at least one chroma transform block are transformed according to the decoded luma transform skip flag, the at least one chroma transform skip flag, and the determined secondary transform index. This provides a method that includes [something].

[0030] Another aspect of the present invention is a method for decoding an encoding tree from an encoding tree unit of an image frame from a video bitstream, wherein the encoding unit has at least one chroma color channel, and the method is Decoding at least one chroma transformation skip flag from the video bitstream, wherein each chroma transformation skip flag corresponds to one of at least one chroma transformation blocks of the encoding unit, Determining the secondary transformation index of the encoding unit for at least one chroma transformation block, wherein the determination involves When any of the at least one of the chroma transformation skip flags indicates that a transformation is applied to each chroma transformation block, the secondary transformation index is decoded from the video bitstream. When all of the aforementioned chroma transformation skip flags indicate that the transformation of each transformation block is skipped, the secondary transformation index is determined to indicate that the secondary transformation is not applied. Including the above determination, To decode the encoding unit, each of the at least one chroma transformation blocks is transformed according to its respective chroma transformation skip flag and the determined secondary transformation index. This provides a method that includes [something].

[0031] Another aspect of the present invention is a non-temporary computer-readable medium storing a computer program for carrying out a method for decoding coding units of a coding tree from coding tree units of an image frame from a video bitstream, wherein the coding unit has one lumina color channel and at least one chroma color channel, and the method is For the Luma conversion block of the encoding unit, the Luma conversion skip flag is decoded from the video bitstream. Decoding at least one chroma transformation skip flag from the video bitstream, wherein each of the decoded chroma transformation skip flags corresponds to one of at least one chroma transformation blocks of the encoding unit. The purpose of determining the quadratic transformation index is to determine the following: When at least one of the chroma conversion skip flag and the at least one chroma conversion skip flag indicates that the conversion of each conversion block is not skipped, the secondary conversion index is decoded from the video bitstream. When all of the luma conversion skip flags and at least one chroma conversion skip flags indicate that the conversion of each conversion block is skipped, the secondary conversion index is determined to indicate that the secondary conversion is not applied. Including the above determination, To decode the encoding unit, the luma transform block and the at least one chroma transform block are transformed according to the decoded luma transform skip flag, the at least one chroma transform skip flag, and the determined secondary transform index. It provides a non-temporary computer-readable medium that includes [the specified element].

[0032] Another aspect of the present invention is a system, Memory and A processor, the processor is configured to execute code stored in memory to perform a method of decoding an encoding tree from an encoding tree unit of an image frame from a video bitstream, the encoding unit having at least one chroma color channel, the processor and The method includes, Decoding at least one chroma transformation skip flag from the video bitstream, wherein each chroma transformation skip flag corresponds to one of at least one chroma transformation blocks of the encoding unit, Determining the secondary transformation index of the encoding unit for at least one chroma transformation block, wherein the determination involves When any of the at least one of the chroma transformation skip flags indicates that a transformation is applied to each chroma transformation block, the secondary transformation index is decoded from the video bitstream. When all of the aforementioned at least one chroma transformation skip flags indicate that the transformation of each transformation block is skipped, the secondary transformation index is determined to indicate that the secondary transformation is not applied, Including the above determination, To decode the encoding unit, each of the at least one chroma transformation blocks is transformed according to its respective chroma transformation skip flag and the determined secondary transformation index. We provide a system that includes this.

[0033] Another aspect of the present invention is a video decoder, Receive image frames from a video bitstream, The encoding unit of the encoding tree is determined from the encoding tree unit of the image frame, and the encoding unit has one luma color channel and at least one chroma color channel. For the Luma transform block of the encoding unit, decode the Luma transform skip flag from the video bitstream, Decode at least one chroma transformation skip flag from the video bitstream, and each of the decoded chroma transformation skip flags corresponds to one of at least one chroma transformation blocks of the encoding unit. The secondary transformation index is determined, and this determination is: When at least one of the chroma conversion skip flag and the at least one chroma conversion skip flag indicates that the conversion of each conversion block is not skipped, the secondary conversion index is decoded from the video bitstream. When all of the luma conversion skip flags and at least one chroma conversion skip flags indicate that the conversion of each conversion block is skipped, the secondary conversion index is determined to indicate that the secondary conversion is not applied. Includes, To decode the encoding unit, the luma transform block and the at least one chroma transform block are transformed according to the decoded luma transform skip flag, the at least one chroma transform skip flag, and the determined secondary transform index. A video decoder configured in such a way is provided.

[0034] Other aspects are also disclosed. [Brief explanation of the drawing]

[0035] Hereinafter, at least one embodiment of the present invention will be described with reference to the following drawings and appendices.

[0036] [Figure 1] Figure 1 is a schematic block diagram showing a video encoding and decoding system.

[0037] [Figure 2A] Figure 2A is a schematic block diagram of a general-purpose computer system in which either or both of the video encoding and decoding systems of Figure 1 may be implemented. [Figure 2B] Figure 2B is a schematic block diagram of a general-purpose computer system in which either or both of the video encoding and decoding systems of Figure 1 may be implemented.

[0038] [Figure 3] Figure 3 is a schematic block diagram showing the functional modules of the video encoder.

[0039] [Figure 4] Figure 4 is a schematic block diagram showing the functional modules of the video decoder.

[0040] [Figure 5] Figure 5 is a schematic block diagram showing the tree structure of a multipurpose video encoding, illustrating the possible division of a single block into one or more blocks.

[0041] [Figure 6] Figure 6 is a schematic diagram illustrating the data flow for enabling the permitted partitioning of a single block into one or more blocks in the tree structure of a multipurpose video encoding.

[0042] [Figure 7A] Figure 7A shows an example of dividing a coding tree unit (CTU) into multiple coding units (CUs). [Figure 7B] Figure 7B shows an example of dividing a coding tree unit (CTU) into multiple coding units (CUs).

[0043] [Figure 8A] Figure 8A shows inseparable forward and reverse quadratic transformations performed according to transformation blocks of different sizes. [Figure 8B] Figure 8B shows inseparable forward and reverse quadratic transformations performed according to transformation blocks of different sizes. [Figure 8C] Figure 8C shows inseparable forward and reverse quadratic transformations performed according to transformation blocks of different sizes. [Figure 8D] Figure 8D shows inseparable forward and reverse quadratic transformations performed according to transformation blocks of different sizes.

[0044] [Figure 9] Figure 9 shows a set of application domains for quadratic transformations on transformation blocks of various sizes.

[0045] [Figure 10] Figure 10 shows the syntax structure of a bitstream having multiple slices, each slice containing multiple coding units.

[0046] [Figure 11] Figure 11 shows the syntax structure of a bitstream with a shared tree of lumar and chromar coding units in the coding tree unit.

[0047] [Figure 12] Figure 12 shows the syntax structure of a bitstream where the luminous coding unit and the chroma coding unit of the coding tree unit are treated as separate trees.

[0048] [Figure 13] Figure 13 shows how to encode a frame into a bitstream containing one or more slices as a sequence of encoding units.

[0049] [Figure 14] Figure 14 shows a method for encoding an encoding unit into a bitstream.

[0050] [Figure 15] Figure 15 shows how to decode a frame from a bitstream, as a sequence of coding units arranged in a slice.

[0051] [Figure 16] Figure 16 shows how to decode the encoding unit from the bitstream.

[0052] [Figure 17] Figure 17 shows a conventional scan pattern for a 32x32TB case.

[0053] [Figure 18] Figure 18 shows an example of a 32x32TB scan pattern used in the device described.

[0054] [Figure 19]Figure 19 shows an 8 × 32 TB divided into collections for the apparatus described.

[0055] [Figure 20] Figure 20 shows scan patterns for different examples of 32×32TB used in the described device. [Modes for carrying out the invention]

[0056] Where any step and / or feature having the same reference numeral is referenced in one or more of the attached drawings, those steps and / or feature shall have the same function(s) or operation(s) for the purposes of this specification, unless otherwise indicated.

[0057] The syntax of a video compression standard's bitstream format is defined as a hierarchical structure of "syntax structures." Each syntax structure defines a set of syntax elements, some of which may be conditional on other elements. The syntax improves compression efficiency by only allowing combinations of syntax elements that correspond to useful combinations of tools. Furthermore, complexity is reduced by prohibiting combinations of syntax elements where, even if implementation is possible, the compression benefits are considered insufficient to outweigh the resulting implementation costs.

[0058] Figure 1 is a schematic block diagram showing the functional modules of the video encoding and decoding system 100. System 100 signals primary and secondary transformation parameters so that a compression efficiency gain is achieved.

[0059] System 100 includes a source device 110 and a destination device 130. A communication channel 120 is used to communicate encoded video information from the source device 110 to the destination device 130. In some arrangements, either or both of the source device 110 and the destination device 130 may constitute a mobile phone handset or “smartphone,” in which case the communication channel 120 is a wireless channel. In other configurations, the source device 110 and the destination device 130 may constitute a video conferencing device, in which case the communication channel 120 is typically a wired channel, such as an internet connection. Furthermore, the source device 110 and the destination device 130 may constitute any of a wide range of devices, including devices that support over-the-air television broadcasting, 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.

[0060] As shown in Figure 1, the source device 110 includes a video source 112, a video encoder 114, and a transmitter 116. The video source 112 typically constitutes a source (shown as 113) of captured video frame data, such as an image capture sensor, a previously captured video sequence stored in a non-temporary storage medium, or a video feed from a remote image capture sensor. The 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 devices 110 that can include an image capture sensor as the video source 112 include smartphones, video camcorders, professional video cameras, and network video cameras.

[0061] The video encoder 114 converts (or "encodes") the captured frame data from the video source 112 (indicated by arrow 113) into a bitstream (indicated by arrow 115), as further explained with reference to Figure 3. The bitstream 115 is transmitted by the transmitter 116 over the communication channel 120 as encoded video data (or "encoded video information"). Alternatively, the bitstream 115 may be stored in a non-temporary storage device 122, such as "flash" memory or a hard disk drive, until it is later transmitted over the communication channel 120, or instead of being transmitted over the communication channel 120. For example, the encoded video data may be provided to customers on request over a wide area network (WAN) for video streaming applications.

[0062] The destination device 130 includes a receiver 132, a video decoder 134, and a display device 136. The receiver 132 receives encoded video data from the communication channel 120 and passes the received video data as a bitstream (indicated by arrow 133) to the video decoder 134. The video decoder 134 then outputs the decoded frame data (indicated by arrow 135) to the display device 136. The decoded frame data 135 has the same chroma format as the frame data 113. Examples of the display device 136 include a cathode ray tube, a smartphone or tablet computer, a computer monitor, or a liquid crystal display such as those found in standalone televisions. It is also possible for the functions of the source device 110 and the destination device 130 to be embodied in a single device, such as a mobile phone terminal or a tablet computer. The decoded frame data may be further transformed before being presented to the user. For example, a "viewport" with a specific latitude and longitude can be used to view the 360-degree scene. o To represent the view, it can be rendered from decoded frame data using a projection format.

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

[0064] The computer module 201 typically includes at least one processor unit 205 and a memory unit 206. For example, the memory unit 206 may have semiconductor random access memory (RAM) and semiconductor read-only memory (ROM). The computer module 201 also includes numerous input / output (I / O) interfaces, including an audio-video interface 207 coupled to a video display 214, a loudspeaker 217, and a microphone 280; an I / O interface 213 coupled 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 generally the output of a computer graphics card. In some implementations, the modem 216 may be integrated into the computer module 201, for example, within interface 208. Computer module 201 also has a local network interface 211, which enables the connection of computer system 200 via connection 223 to a local area communication network 222 known as a local area network (LAN). As shown in Figure 2A, the local communication network 222 may also be connected to a wide area network 220 via connection 224, which would typically include a so-called "firewall" device or a device with similar functionality. The local network interface 211 may consist of an Ethernet® circuit card, a Bluetooth® radio device, or an IEEE 802.11 radio device, but many other types of interfaces may be implemented for interface 211. The local network interface 211 may also provide transmitter 116 and receiver 132 functionality, and communication channels 120 may also be embodied in the local communication network 222.

[0065] I / O interfaces 208 and 213 may 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). Storage device 209 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. Optical disk drive 212 is typically provided to function as a non-volatile source of data. Portable memory devices such as optical disks (e.g., CD-ROM, DVD, Blu-ray Disc®), USB-RAM, portable external hard drives, and floppy disks may be used as suitable data sources to the computer system 200. Typically, any of the HDD 210, optical drive 212, and networks 220 and 222 may also be configured to act as a video source 112 or as a destination for decoded video data stored for playback via the display 214. The source device 110 and destination device 130 of system 100 may be embodied in a computer system 200.

[0066] Components 205–213 of computer module 201 typically communicate via an interconnected bus 204 in a manner that brings about a conventional mode of operation of computer system 200 known to the relevant technicians. For example, processor 205 is coupled to system bus 204 using connection 218. Similarly, memory 206 and optical disc drive 212 are coupled to system bus 204 by connection 219. Examples of computers capable of implementing the described apparatus include IBM-PC and compatible machines, Sun SPARC stations, Apple Mac® or similar computer systems.

[0067] Where appropriate or desired, the video encoder 114 and video decoder 134, and the method described below, can be implemented using a computer system 200. In particular, the video encoder 114, video decoder 134, and the method described may be implemented as one or more software application programs 233 executable within the computer system 200. Specifically, the steps of the video encoder 114, video decoder 134, and the method described are enforced by instructions 231 (see Figure 2B) in the software 233 executed within the computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more specific tasks. Alternatively, the software may be divided into two separate parts, in which case the first part and its corresponding code modules perform the method described, and the second part and its corresponding code modules manage the user interface between the first part and the user.

[0068] The software may be stored on a computer-readable medium, for example, including a storage device as described below. The software is loaded from the computer-readable medium into the computer system 200 and then executed by the computer system 200. Such a computer-readable medium on which software or a computer program is recorded is a computer program product. The use of the computer program product in the computer system 200 preferably results in a video encoder 114, a video decoder 134, and other advantageous apparatus for carrying out the described method.

[0069] The software 233 is typically stored on the HDD 210 or in memory 206. The software is loaded from a computer-readable medium into the computer system 200 and executed by the computer system 200. 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 an optical disk drive 212.

[0070] In some examples, the application program 233 may be encoded on one or more CD-ROMs 225 and supplied to the user, and read via the corresponding drive 212, or alternatively, read by the user from a network 220 or 222. Furthermore, the software may also be loaded into the computer system 200 from other computer-readable media. Computer-readable storage media means any non-temporary 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 Discs (trademarks), hard disk drives, ROMs or integrated circuits, USB memory sticks, magneto-optical disks, or computer-readable cards such as PCMCIA cards, whether such devices are inside or outside the computer module 201. Examples of temporary or intangible computer-readable transmission media that may also participate in providing software, application programs, instructions, and / or video data or encoded video data to the computer module 401 include wireless or infrared transmission lines, network connections with other computers or network devices, and the internet or intranets, including the transmission of emails and information recorded on websites, etc.

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

[0072] Figure 2B is a detailed schematic block diagram of the processor 205 and “memory” 234. Memory 234 represents a logical aggregation of all memory modules (including HDD 209 and semiconductor memory 206) accessible by the computer module 201 in Figure 2A.

[0073] When the computer module 201 is initially powered on, a power-on self-test (POST) program 250 is executed. The POST program 250 is typically stored in the ROM 249 of the semiconductor memory 206 shown in Figure 2A. Hardware devices that store software, such as ROM 249, are sometimes called firmware. The POST program 250 checks the hardware within the computer module 201 to ensure correct functionality, typically checking the processor 205, memory 234 (209, 206), and the Basic Input / Output System Software (BIOS) module 251, also typically stored in ROM 249. If the POST program 250 executes successfully, the BIOS 251 starts the hard disk drive 210 shown in Figure 2A. The startup of the hard disk drive 210 causes the bootstrap loader program 252, which resides on the hard disk drive 210, to be executed via the processor 205. This loads the operating system 253 into the RAM memory 206, thereby initiating the operation of the operating system 253. Operating System 253 is a system-level application runnable by Processor 205, performing various high-level functions including processor management, memory management, device management, storage management, software application interface, and general-purpose user interface.

[0074] The operating system 253 manages memory 234 (209, 206) so that each process or application running on computer module 201 has enough memory to run without conflicting with memory allocated to other processes. Furthermore, each process must make appropriate use of the different types of memory available in computer system 200 in Figure 2A so that it can run effectively. Therefore, the aggregated memory 234 is not intended to describe how specific segments of memory are allocated (unless otherwise noted), but rather to provide a general view of the memory accessible by computer system 200 and how such memory is used.

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

[0076] The application program 233 includes a set of instructions 231 that may include conditional branch instructions and loop instructions. The program 233 may also include data 232 used in the execution of the program 233. The instructions 231 and data 232 are stored in memory locations 228, 229, 230, and 235, 236, and 237, respectively. Depending on the relative size of the instructions 231 and memory locations 228-230, a particular instruction may be stored in a single memory location, as depicted by the instruction shown at memory location 230. Alternatively, the instruction may be segmented into several parts, each stored in a different memory location, as depicted by the instruction segments shown at memory locations 228 and 229.

[0077] Generally, the processor 205 is given a set of instructions to be executed within it. The processor 205 awaits subsequent inputs and responds by executing another set of instructions. Each input may be provided from one or more of a number of 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 obtained from one of the storage devices 206, 209, or data obtained from a storage medium 225 inserted into the corresponding reader 212, all of which are depicted in Figure 2A. The execution of a series of instructions may, in some cases, involve the output of data. The execution may also include storing data or variables in memory 234.

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

[0079] Referring to processor 205 in Figure 2B, registers 244, 245, 246, arithmetic logic unit (ALU) 240, and control unit 239 cooperate to perform the sequence of microoperations necessary to execute a “fetch, decode, and execute” cycle for all instructions in the instruction set that make up program 233. Each fetch, decode, and execute cycle includes: A fetch operation to fetch or read instruction 231 from memory locations 228, 229, and 230. Decoding operation in which the control unit 239 determines which instruction has been fetched, and The execution operation in which the control unit 239 and / or ALU 240 execute instructions.

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

[0081] Each step or subprocess in the methods shown in Figures 13 to 16, which will be described below, is associated with one or more segments of program 233 and is typically executed by the cooperation of register sections 244, 245, 247, ALU 240, and control section 239 in the processor 205 to perform fetch, decode, and execute cycles for all instructions in the instruction set for the indicated segment of program 233.

[0082] Figure 3 is a schematic block diagram showing the functional modules of the video encoder 114. Figure 4 is a schematic block diagram showing the functional modules of the video decoder 134. Generally, data passes between the functional modules in the video encoder 114 and the functional modules in the video decoder 134 as groups of samples or coefficients, or as arrays, where blocks are divided into fixed-size subblocks. The video encoder 114 and video decoder 134 may be implemented using a general-purpose computer system 200, as shown in Figures 2A and 2B, where the various functional modules are implemented by dedicated hardware within the computer system 200 and by software executable within the computer system 200, such as one or more software code modules of a software application program 233 residing on a hard disk drive 205, and their execution may be controlled by a processor 205. Alternatively, the video encoder 114 and 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 method may, alternatively, be implemented in dedicated hardware such as one or more integrated circuits that perform the functions or subfunctions of the described method. 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 memory. In particular, the video encoder 114 may include modules 310-386, and the video decoder 134 may include modules 420-496, each of which may be implemented as one or more software code modules of the software application program 233.

[0083] The video encoder 114 in Figure 3 is an example of a video encoding pipeline for multipurpose video coding (VVC), but other video codecs can also be used to perform the processing stages described herein. The video encoder 114 receives captured frame data 113, such as a series of frames, each frame containing one or more color channels. The frame data 113 contains a two-dimensional array of luma ("luma channels") and chroma ("chroma channels") samples arranged in a "chroma format," such as chroma formats such as 4:0:0, 4:2:0, 4:2:2, or 4:4:4. The block partitioner 310 first divides the frame data 113 into CTUs, which are generally square in shape and configured so that a specific size is used for the CTUs. The size of the CTUs may be, for example, 64×64, 128×128, or 256×256 luma samples.

[0084] The block partitioner 310 further divides each CTU into one or more CUs at the point where the shared coding tree branches into a luma branch and a chroma branch, according to either the shared coding tree or the luma and chroma coding tree. A luma channel is sometimes also called a primary color channel. Each chroma channel is sometimes called a secondary color channel. CUs can be of various sizes and may include both square and non-square aspect ratios. The operation of the block partitioner 310 is further described with reference to Figures 13 and 14. However, in the VVC standard, CU / CB, PU / PB, and TU / TB always have side lengths that are powers of 2. Thus, the current CU, represented as 312, proceeds according to the shared coding tree or the luma and chroma coding tree of the CTU, following iterations of one or more blocks of the CTU, and is output from the block partitioner 310. Options for partitioning the CTU into CBs are further described below with reference to Figures 5 and 6.

[0085] The CTUs obtained from the first split of frame data 113 may be scanned in raster scan order and may be grouped into one or more “slice.” The slices may be “intra” (or “I”) slices. An intra slice (I slice) does not contain interpredicted CUs, and for example, only intrapredictions are used. Alternatively, the slices may be one-way or two-way predictors (“P” or “B” slices, respectively), indicating the additional availability of one or two reference blocks for predicting CUs, known as “one-way predictors” and “two-way predictors,” respectively.

[0086] In an I-slice, the coding tree for each CTU may branch into two coding trees, one for luma and one for chroma, at 64x64 levels or less. By using separate trees, different block structures can exist for luma and chroma within the 64x64 luma region of a CTU. For example, a large chroma CB may contain many small luma CBs, or vice versa. In a P or B-slice, a single coding tree for a CTU defines a block structure common to both luma and chroma. The resulting blocks from a single tree may be intra-predictive or inter-predictive.

[0087] 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” CU. In the first stage, various candidate CUs are tested to select a CU that provides relatively low distortion and relatively high compression efficiency. This test generally involves Lagrangian optimization, thereby evaluating candidate CUs based on a weighted combination of rate (coding cost) and distortion (error relative to the input frame data 113). The “best” candidate CU (the CU with the smallest evaluated rate / distortion) is selected for encoding to the subsequent bitstream 115. The evaluation of candidate CUs includes the option of using the CU for a given region, or further dividing the region according to various partitioning options, and then encoding each of the resulting smaller regions with another CU, or further dividing the region. As a result, both the coding tree and the CUs themselves are selected in the search stage.

[0088] The video encoder 114 generates a prediction block (PU) indicated by arrow 320 for each CU, e.g., CU312. The PU320 is a prediction of the content of the associated CU312. The subtractor module 322 generates a difference between PB320 and CB312, indicated as 324 (or "residual," referring to the difference being in the spatial domain). The difference 324 is the difference in block size between the corresponding samples of PU320 and CU312. The difference 324 is a block-sized array of the differences between the corresponding samples of PU320 and CU312, generated for each color channel of CU312. If a linear and (optionally) quadratic transform are performed, the difference 324 is transformed in modules 326 and 330 and passed to the quantization module 334 for quantization via multiplexing 333. If the transformation is skipped, the difference 324 is passed directly to the quantization module 334 for quantization via multiplexing 333. The choice between conversion and conversion skipping is made independently for each TB associated with CU312. The resulting quantized residual coefficients are represented as TBs (for each color channel of CU312) indicated by arrow 336. PU320 and its associated TB336 are typically selected from one of many possible candidate CUs, for example, based on the evaluated cost or distortion.

[0089] The candidate CU is the CU obtained 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 addition of TB336 after the inverse transformation to the spatial domain reduces the difference between the decoded CU and the original CU312 at the expense of additional signaling in the bitstream.

[0090] Each candidate coding block (CU), i.e., a prediction block (PU) combined with a single transform block (TB), therefore has an associated coding cost (or "rate") and an associated difference (or "distortion"). The distortion of a CU is estimated as the difference in sample values, e.g., the sum of absolute differences (SAD) or the sum of squared differences (SSD). The estimates obtained from each candidate PU may be used by the mode selector 386 to determine the intra-prediction mode using the difference 324. The prediction mode 387 indicates a decision to use a particular prediction mode for the current CU, e.g., intra-frame prediction or inter-frame prediction. For intra-prediction CUs belonging to a shared coding tree, independent intra-prediction modes are specified for the luma PB versus chroma PB. For intra-prediction CUs belonging to the luma branch or chroma branch of a dual coding tree, one intra-prediction mode is applied to the luma PB or chroma PB, respectively. 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 residuals. Therefore, even in real-time video encoders, it is possible to evaluate numerous candidate modes and determine the optimal mode in terms of rate-distortion.

[0091] Lagrangian or similar optimization processes can be employed for both selecting the optimal partitioning of the CTU to the CB (by the block partitioner 310) and selecting the best prediction mode from multiple possible prediction modes. By applying the Lagrangian optimization process to the candidate modes in the mode selector module 386, the intra-prediction mode 387, the quadratic transformation index 388, the primary transformation type 389, and the transformation skip flag 390 (one for each TB) that provide the smallest cost measurement are selected.

[0092] In the second stage of operation of the video encoder 114 (called the "encoding" stage), the video encoder 114 performs iterations on the determined encoding tree (or more) for each CTU. For CTUs using separate trees, for each 64x64 luma region of the CTU, the luma encoding tree is encoded first, followed by the chroma encoding tree. Within the luma encoding tree, only luma CBs are encoded, and within the chroma encoding tree, only chroma CBs are encoded. In a CTU using a shared tree, the CUs, i.e., luma CBs and chroma CBs, are described in a single tree according to the common block structure of the shared tree.

[0093] The entropy encoder 338 supports both variable-length coding and arithmetic coding of syntax elements. Parts of the bitstream, such as "parameter sets" (e.g., sequence parameter sets (SPS), picture parameter sets (PPS), and picture headers (PH)), use a combination of fixed-length and variable-length codewords. A slice (also called a continuum) has a slice header using variable-length coding and slice data using arithmetic coding. The picture header defines parameters specific to the current slice, such as picture-level quantization parameter offsets. The slice data contains the syntax elements of each CTU within the slice. When using variable-length coding and arithmetic coding, sequential parsing is required within each part of the bitstream. These parts may be separated by start codes to form "network abstraction layer units" or "NAL units." Arithmetic coding is supported using a context-adaptive binary arithmetic coding process. Arithmetic coded syntax elements consist of a sequence of one or more "bins." Bins, like bits, have a value of "0" or "1". However, bins are not encoded as individual bits within bitstream 115. Each bin has an associated predicted value (or "likely" or "most likely") and associated probability, called a "context." If the actual bin to be encoded matches the predicted value, the "most likely symbol" (MPS) is encoded. Encoding the most likely symbol is relatively inexpensive in terms of the bits consumed within bitstream 115, including the cost equivalent to less than 1 discrete bits. If the actual bin to be encoded does not match the most likely value, the "least likely symbol" (LPS) is encoded. Encoding the least likely symbol is relatively expensive in terms of the number of bits consumed. Bin coding techniques can efficiently encode bins where the probabilities of "0" and "1" are skewed. For syntax elements with two possible values ​​(i.e., "flags"), one bin is sufficient. For syntax elements with many possible values, a series of bins are required.

[0094] The existence of a later bin in a sequence may be determined based on the value of a 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 a syntax element, the bin values ​​of adjacent syntax elements (i.e., those from adjacent blocks), and so on. Each time a context-encoded bin is encoded, the context selected for that bin (if any) is updated in a way that reflects the value of the new bin. Thus, binary arithmetic coding schemes are said to be adaptive.

[0095] Furthermore, the video encoder 114 supports contextless bins ("bypass bins"). Bypass bins are encoded assuming an equally probable distribution between "0" and "1". Thus, each bin encodes the cost of one bit of the bitstream 115. The absence of context saves memory and reduces complexity, and therefore bypass bins are used where the distribution of values ​​for a particular bin is not skewed. An example of an entropy encoder that employs context and adaptation is known in the art as CABAC (Context Adaptive Binary Arithmetic Coder), and many variations of this encoder are employed in video encoding.

[0096] The entropy encoder 338 encodes the quadratic transform index 388 using the linear transform type 389, one transform skip flag for each TB of the current CU (i.e., 390), and, if applicable to the current CU, a combination of context coding and bypass coding bins, and the intra-prediction mode 387. The quadratic transform index 388 is signaled if the residuals associated with the transform block contain residual coefficients that are significant only at those coefficient positions that are subject to transformation to linear coefficients by the application of the quadratic transform.

[0097] The multiplexing module 384 outputs the PB320 from the intra-frame prediction module 364 according to the determined best intra-prediction mode selected from the tested prediction modes of each candidate CB. The candidate prediction modes do not need to include all possible prediction modes supported by the video encoder 114. Intra-predictions are classified into three types: "DC intra-prediction" involves populating the PB with a single value representing the mean of the neighboring reconstructed samples. "Plane intra-prediction" involves populating the PB with samples according to a plane, from which the DC offset and vertical and horizontal slopes are derived from the neighboring reconstructed samples. The neighboring reconstructed samples typically include a row of reconstructed samples that are above the current PB and spread to some extent to the right of the PB, and a column of reconstructed samples that are to the left of the current PB and spread to some extent below the PB. "Angular intra-prediction" involves populating the PB with reconstructed neighboring samples that are filtered and propagated across the PB in a particular direction (or "angle"). VVC supports 65 angles, and rectangular blocks can utilize additional angles not available in square blocks, allowing for a total of 87 angles to be generated. ChromaPB, as a fourth intra-prediction, allows for the generation of PB from the collocation of luma-reconstructed samples via the Cross-Component Linear Model (CCLM) mode. There are three different CCLM modes, each using a different model derived from adjacent luma and chroma samples. This model is used to generate the sample blocks for ChromaPB from the placed luma samples.

[0098] If previously reconstructed samples are unavailable, such as at the edge of a frame, half of the sample range is used as the default halftone value. For example, for 10-bit video, a value of 512 is used. For a CB located at the top left of the frame, since no previously available samples exist, the angle and plane intra-prediction modes produce the same output as the DC prediction mode, i.e., a plane of samples with the halftone value as its magnitude.

[0099] In interframe 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 encoded order of the frames in the bitstream, and is output as PB320 by the multiplexing module 384. Furthermore, in interframe prediction, a single encoded tree is typically used for both the luma channel and the chroma channel. The order of encoded frames in the bitstream may differ from the order of frames at capture or display. When one frame is used for prediction, the block is called a "one-way prediction" and has one associated motion vector. When two frames are used for prediction, the block is called a "two-way prediction" and has two associated motion vectors. For P slices, each CU is either intra-predicted or one-way predicted. For B slices, each CU is either intra-predicted, one-way predicted, or two-way predicted. Frames are typically encoded using a "picture group" structure, allowing for temporal layering of frames. Multiple frames may be divided into multiple slices, each slice encoding a portion of the frame. The temporal hierarchical arrangement of frames allows each frame to reference preceding and succeeding images in the order in which the frames are displayed. Images are encoded in the order necessary to ensure that dependencies for decoding each frame are met.

[0100] Samples are selected according to motion vector 378 and reference picture index. Motion vector 378 and reference picture index are applied to all color channels, and therefore interpretation is described primarily in terms of operation on PU rather than PB, i.e., the decomposition of each CTU into one or more interpretation blocks is described using a single coding tree. Interpretation may differ in the number and precision of motion parameters. Motion parameters typically consist of a reference frame index indicating which reference frame to use from a list of reference frames, and spatial transformations for each reference frame, but may include more frames, special frames, or complex affine parameters such as scaling and rotation. Furthermore, a predetermined motion refinement process may be applied to generate dense motion estimates based on the referenced sample blocks.

[0101] After determining and selecting PU320 and subtracting PU320 from the original sample block using subtractor 322, the residual with the lowest encoding cost, represented as 324, is obtained and subjected to lossy compression. The lossy compression process consists of the steps of transformation, quantization, and entropy coding. The forward linear transformation module 326 applies a forward transformation to the difference 324, transforming the difference 324 from the time domain to the frequency domain and generating linear transformation coefficients represented by arrows 328 according to the linear transformation type 389. The maximum linear transformation size in one dimension is either a 32-point DCT-2 transformation or a 64-point DCT-2 transformation. If the CB to be encoded is greater than the maximum supported linear transformation size, represented as the block size, i.e., 64×64 or 32×32, the linear transformation 326 is applied tile-wise to transform all samples of the difference 324. If each application of the transformation operates on a TB larger than 32×32, for example, on a TB with a difference of 324 of 64×64, all resulting primary transformation coefficients 328 outside the upper left 32×32 region of the TB are set to zero, i.e., discarded. For TBs up to 32×32 in size, the primary transformation type 389 can indicate the application of a combination of DST-7 and DCT-8 transformations in the horizontal and vertical directions. The remaining primary transformation coefficients 328 are passed to the forward secondary transformation module 330.

[0102] The quadratic transformation module 330 generates quadratic transformation coefficients 332 according to the quadratic transformation index 388. The quadratic transformation coefficients 332 are quantized by module 334 according to the quantization parameters associated with CB, generating residual coefficients 336. When the transformation skip flag 390 indicates that transformation skipping is effective for TB, the difference 324 is passed to the quantizer 334 via the multiplexer 333.

[0103] The forward linear transform of module 326 is typically separable, transforming the set of rows for each TB, and then the set of columns. The forward linear transform module 326 uses either a Type II Discrete Cosine Transform (DCT-2) horizontally and vertically, or, for Luma TBSs, a combination of Type VII Discrete Sine Transform (DST-7) and Type VIII Discrete Cosine Transform (DCT-8) horizontally or vertically, according to the linear transform type 389. The use of a combination of DST-7 and DCT-8 is referred to as a "Multi-Transform Selection Set" (MTS) in the VVC standard. When using DCT-2, the maximum TB size is 32x32 or 64x64, configurable in the video encoder 114 and signaled in the bitstream 115. Regardless of the configured maximum DCT-2 transform size, only the coefficients of the upper left 32x32 region of the TB are encoded in the bitstream 115. Significant coefficients outside the top-left 32x32 region of the TB are discarded (or "zeroed out") and not encoded in bitstream 115. MTS is only available for CUs of a maximum size of 32x32, and only the coefficients in the top-left 16x16 region of the associated Luma TB are encoded. Individual TBs of a CU are either transformed or bypassed according to the corresponding transformation skip flag 390.

[0104] The forward quadratic transform of module 330 is generally a non-separable transform, applied only to the residuals of the intra-predicted CU, and may nevertheless be bypassed. The forward quadratic transform operates on either 16 samples (arranged as a 4x4 subblock above left of the 328 linear transform coefficients) or 48 samples (arranged as three 4x4 subblocks above left of the 8x8 linear transform coefficients) to generate a set of quadratic transform coefficients. The set of quadratic transform coefficients may be smaller than the set of linear transform coefficients from which they are derived. Because the quadratic transform is applied only to sets of coefficients that are adjacent to each other and contain DC coefficients, the quadratic transform is referred to as a "low-frequency non-separable transform" (LFNST).

[0105] The residual coefficients 336 are fed to the entropy encoder 338 for encoding within the bitstream 115. Typically, the residual coefficients of each TB having at least one significant residual coefficient of the TU are scanned according to a scan pattern to generate an ordered list of values. The scan pattern generally scans the TB as a sequence of 4x4 "subblocks," providing regular scanning behavior with a granularity of 4x4 sets of residual coefficients, where the arrangement of the subblocks depends on the size of the TB. The scan within each subblock and the progression from one subblock to the next typically follow a backward oblique scan pattern.

[0106] As described above, the video encoder 114 requires access to a frame representation corresponding to the decoded frame representation seen in the video decoder 134. Therefore, the residual coefficient 336 is passed to the dequantizer 340 to produce the dequantized residual coefficient 342. The dequantized residual coefficient 342 is passed to the inverse quadratic transform module 344, which operates according to the quadratic transform index 388 to produce the intermediate inverse transform coefficient 346, represented by the arrow 346. The intermediate inverse transform coefficient 346 is passed to the inverse linear transform module 348 to produce the residual sample 399, represented by the arrow TU. The quantized residual coefficient 342 is output by the multiplexer 349 as the residual sample 350 if the transform skip 390 indicates that a transform bypass is performed. Otherwise, the multiplexer 349 outputs the residual sample 399 as the residual sample 350.

[0107] The type of inverse transformation performed by the inverse quadratic transformation module 344 corresponds to the type of forward transformation performed by the forward quadratic transformation module 330. The type of inverse transformation performed by the inverse linear transformation module 348 corresponds to the type of linear transformation performed by the linear transformation module 326. The summation module 352 adds the residual sample 350 and the PU 320 to generate a reconstructed sample of CU (indicated by arrow 354).

[0108] The reconstructed sample 354 is passed to the reference sample cache 356 and the in-loop filter module 368. The reference sample cache 356 is typically implemented using static RAM on the ASIC (thus avoiding costly off-chip memory access) and provides the minimum sample storage necessary to satisfy dependencies for generating in-frame PBs for subsequent CUs in the frame. Minimal dependencies include a "line buffer" of samples along the bottom of the row of CTUs for use in the next row of CTUs, and a column buffer set by the height of the CTU. The reference sample cache 356 feeds the reference sample (indicated by arrow 358) to the reference sample filter 360. The sample filter 360 applies a smoothing operation to generate filtered reference samples (indicated by arrow 362). The filtered reference sample 362 is used by the intra-frame prediction module 364 to generate an intra-prediction block of samples indicated by arrow 366. For each candidate intra-prediction mode, the intra-frame prediction module 364 generates a block 366 of samples. Sample block 366 is generated by module 364 using techniques such as DC, planar, or angular intra-prediction, according to intra-prediction mode 387.

[0109] The in-loop filter module 368 applies several filtering stages to the reconstructed sample 354. These filtering stages include a “deblocking filter” (DBF) that applies smoothing aligned to the CU boundary to reduce artifacts arising from discontinuities. Another filtering stage present in the in-loop filter module 368 is an “adaptive loop filter” (ALF), which applies a Wiener-based adaptive filter to further reduce distortion. Another filtering stage present in the in-loop filter module 368 is a “sample-adaptive offset” (SAO) filter. The SAO filter works by first classifying the reconstructed sample into one or more categories and then applying an offset at the sample level according to the assigned category.

[0110] The filtered sample, represented by arrow 370, is output from the in-loop filter module 368. The filtered sample 370 is stored in the frame buffer 372. The frame buffer 372 typically has the capacity to store multiple (e.g., up to 16) pictures and is therefore stored in memory 206. Because the frame buffer 372 requires a large amount of memory, it is not typically stored using on-chip memory. Therefore, accessing the frame buffer 372 is costly in terms of memory bandwidth. The frame buffer 372 provides a reference frame (represented by arrow 374) to the motion estimation module 376 and the motion compensation module 380.

[0111] The motion estimation module 376 references one block of reference frames in the frame buffer 372 to estimate a number of “motion vectors” (indicated as 378), each of which is a Cartesian space offset from the position of the current CB. A filtered block of reference samples (indicated 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 reference block ("one-way prediction") or using two reference blocks ("two-way prediction"). For the selected motion vectors, the motion compensation module 380 generates the PB 320 according to a filtering process that supports the sub-pixel accuracy of the motion vectors. In this way, the motion estimation module 376 (operating with many candidate motion vectors) can achieve reduced computational complexity by performing a simplified filtering process compared to the filtering process of the motion compensation module 380 (operating only with selected candidates). When the video encoder 114 selects an interpretation for the CU, the motion vector 378 is encoded into the bitstream 115.

[0112] The video encoder 114 in Figure 3 is described with reference to multipurpose video coding (VVC), but other video coding standards or implementations may also employ the processing stages of modules 310-386. Furthermore, 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 (trademark), or other computer-readable storage media. Additionally, the frame data 113 (and bitstream 115) may be received from (or transmitted to) external sources such as servers or radio frequency receivers connected to the communication network 220.

[0113] The video decoder 134 is shown in Figure 4. The video decoder 134 in Figure 4 is an example of a versatile video coding (VVC) video decoding pipeline, but other video codecs can also be used to perform the processing stages described herein. As shown in Figure 4, the video decoder 134 is input with a bitstream 133. The bitstream 133 may be read from memory 206, a hard disk drive 210, a CD-ROM, a Blu-ray disc (trademark), or other non-temporary computer-readable storage medium. Alternatively, the bitstream 133 may be received from an external source such as a server or radio frequency receiver connected to a communication network 220. The bitstream 133 contains encoded syntax elements representing the captured frame data to be decoded.

[0114] Bitstream 133 is input to the entropy decoder module 420. The entropy decoder module 420 extracts syntax elements from bitstream 133 by decoding a sequence of “bins” and passes the values ​​of the syntax elements to other modules of the video decoder 134. The entropy decoder module 420 uses variable-length and fixed-length decoding to decode the syntax elements of the slice data as a sequence of one or more bins by decoding the SPS, PPS, or slice header arithmetic decoding engine. Each bin can use one or more “contexts,” which describe 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” step is performed to select one of the available contexts to decode the bin.

[0115] 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 in the video decoder 134. These parameters include residual coefficients (represented by arrow 424), quantization parameters (not shown), quadratic transformation index 474, and mode selection information such as intra-predictive modes (represented by arrow 458). The mode selection information also includes information such as motion vectors and the division of each CTU into one or more CUs. The parameters are typically used in combination with sample data from previously decoded CBs to generate PBs.

[0116] The residual coefficients 424 are passed to the inverse quantization module 428. The inverse quantization module 428 performs inverse quantization (or "scaling") on the residual coefficients 424 (i.e., the first-order transformation coefficient domain) to create reconstructed transformation coefficients, represented by arrow 432, according to the quantization parameters. The reconstructed transformation coefficients 432 are passed to the inverse quadratic transformation module 436. The inverse quadratic transformation module 436 either applies a quadratic transformation or performs no operation (bypasses) according to the quadratic transformation type 474 decoded from the bitstream 113 by the entropy decoder 420 in the manner described with reference to Figures 15 and 16. The inverse quadratic transformation module 436 generates reconstructed transformation coefficients 440 (i.e., the first-order transformation domain coefficients).

[0117] The reconstructed conversion coefficients 440 are passed to the inverse linear transformation module 444. Module 444 inversely transforms the coefficients 440 from the frequency domain to the spatial domain according to the linear transformation type 476 (or "mts_idx") decoded from the bitstream 133 by the entropy decoder 420. The result of the operation of module 444 is a block of residual samples represented by arrows 499. If the transformation skip flag 478 for a given TB of the CU indicates a bypass of the transformation, the multiplexer 449 outputs the reconstructed conversion coefficients 432 as residual sample 488 to the summation module 450. Otherwise, the multiplexer 449 outputs residual sample 499 as residual sample 488. The residual sample 448 is equal in size to the corresponding CB. The residual sample 448 is supplied to the summation module 450. In the summation module 450, the residual sample 448 is added to the decoded PB (represented as 452) to generate a reconstructed sample block represented by arrow 456. The reconstructed sample 456 is supplied to the reconstructed sample cache 460 and the in-loop filtering module 488. The in-loop filtering module 488 generates a reconstructed block of frame samples represented by 492. The frame sample 492 is written to the frame buffer 496, from which the frame data 135 is subsequently output.

[0118] The reconfigured sample cache 460 operates similarly to the reconfigured sample cache 356 of the video encoder 114. The reconfigured sample cache 460 provides storage for the reconfigured samples necessary for intra-predicting subsequent CBs without relying on access to memory 206 (for example, by using data 232, which is typical on-chip memory, instead). The reference sample indicated by arrow 464 is obtained from the reconfigured sample cache 460 and fed to the reference sample filter 468 to generate the filtered reference sample indicated by arrow 472. The filtered reference sample 472 is fed to the intra-frame prediction module 476. The module 476 generates a block of intra-prediction samples indicated by arrow 480 according to the intra-prediction mode parameter 458 signaled to the bitstream 133, which is then decoded by the entropy decoder 420.

[0119] If the CB's prediction mode is instructed to use intra-prediction in bitstream 133, the intra-predicted sample 480 forms a PB 452 decoded via the multiplexing module 484. Intra-prediction generates a predicted block (PB) of a sample, i.e., a block in one color component derived using "neighboring samples" in the same color component. Neighboring samples are samples adjacent to the current block and have already been reconstructed by preceding it in the block decoding order. If luminous and chroma blocks are present, the luminous and chroma blocks may use different intra-prediction modes. However, two chroma CBs share the same intra-prediction mode.

[0120] If the prediction mode of the CB is indicated to be inter-prediction in bitstream 133, the motion compensation module 434 generates a block of inter-predicted samples, represented as 438, using the motion vector (decoded from bitstream 133 by the entropy decoder 420) and reference frame index to select and filter a block of samples 498 from the frame buffer 496. The block of samples 498 is obtained from a previously decoded frame stored in the frame buffer 496. For bidirectional prediction, two blocks of samples are generated and blended together to generate samples for the decoded PB 452. The frame buffer 496 is input with 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 one of the DBF, ALF, or SAO filtering operations. Generally, the motion vector is applied to both the luminous and chroma channels, but the filtering process for subsample interpolation in the luminous and chroma channels differs.

[0121] Figure 5 is a schematic block diagram showing the available partitions or collections of partitions 500 at each node of the coding tree structure of the multipurpose video coding, which divide one region into one or more subregions. The partitions shown in collection 500 are available to the block partitioner 310 of the encoder 114 to divide each CTU into one or more CUs or CBs according to the coding tree, as determined by Lagrangian optimization as described with reference to Figure 3.

[0122] Collection 500 only shows that a square region can be divided into other, possibly non-square, sub-regions, but it should be understood that Collection 500 also shows that a parent node of a coding tree can be divided into child nodes of the coding tree, and that the parent node does not need to correspond to a square region. If the region to be included is non-square, the size of the resulting block is scaled according to the aspect ratio of the block to be included. If a region is not further divided, i.e., a leaf node of the coding tree, the CU occupies that region.

[0123] The process of subdividing a region into subregions terminates when the resulting subregions reach the minimum CU size (typically 4x4 luma samples). CUs are constrained to have a minimum width or height of 4, in addition to prohibiting block regions smaller than a predetermined minimum size (e.g., 16 samples). It is also possible to set minimum values ​​for both width and height, or both. The subdivision process may terminate before the deepest level of decomposition, resulting in CUs larger than the minimum CU size. It is also possible that no subdivision occurs, and a single CU occupies the entire CTU. A single CU occupying the entire CTU represents the largest available coding unit size. The use of subsample chroma formats such as 4:2:0 allows the arrangement of the video encoder 114 and video decoder 134 to terminate the subdivision of the chroma channel region earlier than the luma channel, including in the case of a shared coding tree defining the block structure of the luma and chroma channels. When separate coding trees are used for luma and chroma, constraints on available partitioning operations ensure that the minimum chroma CU region is 16 samples, even if such a CU is co-located with a larger luma region, e.g., 64 luma samples.

[0124] A CU exists at each leaf node of the coding tree. For example, leaf node 510 contains one CU. A non-leaf node of the coding tree may have a division into two or more further nodes, each of which may contain a leaf node forming one CU, or a non-leaf node containing a further division into a smaller region. At each leaf node of the coding tree, there is one CB for each color channel of the coding tree. A division that terminates at the same depth for both the luma and chroma of the shared tree will have one CU with three conjugate CBs.

[0125] The quad-tree partition 512 divides the containing region into four equally sized regions, as shown in Figure 5. Compared to HEVC, the Versatile Video Coding (VVC) achieves greater flexibility with additional partitions, including horizontal 2-part partitions 514 and vertical 2-part partitions 516. Each of the partitions 514 and 516 divides the containing region into two equally sized regions. The partitions are performed along the horizontal boundary (514) or vertical boundary (516) within the containing block.

[0126] For versatile video coding, further flexibility is gained by adding 3-part horizontal partitioning 518 and 3-part vertical partitioning 520. 3-part partitioning 518 and 520 divide a block into three regions bounded either horizontally (518) or vertically (520) along 1 / 4 and 3 / 4 of the width or height of the containing region. The combination of quadtree, binary tree, and ternary tree is called "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 2-part or 3-part partitions occur (the "multitree" or "MT" section of the tree), finally ending with CB or CU at the leaf nodes of the tree. If the tree describes all color channels, the leaf nodes of the tree are CU. If the tree describes luma channels or chroma channels, the leaf nodes of the tree are CB.

[0127] Compared to HEVC, which only supports quadtrees and therefore only square blocks, QTBTTT results in more possible CU sizes, especially considering the possibility of recursively applying binary and / or ternary tree partitions. When only quadtree partitions are available, each increase in the depth of the coding tree corresponds to a reduction in CU size to 1 / 4 of the parent area. In VVC, binary and ternary tree partitions are possible, so the depth of the coding tree no longer directly corresponds to the CU area. The possibility of non-square block sizes can be reduced by restricting partition options to eliminate partitions where the block width or height is less than 4 samples or not a multiple of 4 samples. The possibility of unusual (non-square) block sizes can be reduced by restricting partition options to eliminate partitions where the block width or height is less than 4 samples or not a multiple of 4 samples.

[0128] Figure 6 is a schematic flowchart showing the data flow 600 of the QTBTTT (or “encoding tree”) structure used in multipurpose video coding. The QTBTTT structure is used for each CTU to define the partitioning of the CTU into one or more ECUs. The QTBTTT structure for each CTU is determined by the block partitioner 310 in the video encoder 114 and encoded into bitstream 115 or decoded from bitstream 133 by the entropy decoder 420 in the video decoder 134. The data flow 600 further features acceptable combinations that the block partitioner 310 can use to partition the CTU into one or more CUs according to the partitioning shown in Figure 5.

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

[0130] First, the block partitioner 310 performs the MT partitioning decision 612. 612 indicates whether or not to perform an MT partition. Returning a "0" symbol in decision 612 indicates that no further partitioning of the node into subnodes will be performed. If no further partitioning of the node is performed, that node is a leaf node in the coding tree and corresponds to a CU. The leaf node is output in 622. Alternatively, if MT partitioning 612 indicates a decision to perform an MT partition (returning a "1" symbol), the block partitioner 310 proceeds to the direction decision 614.

[0131] Direction determination 614 indicates the direction of the MT partition as either horizontal ("H" or "0") or vertical ("V" or "1"). If determination 614 returns "0", indicating the horizontal direction, the block partitioner 310 proceeds to determination 616. If determination 614 returns "1", indicating the vertical direction, the block partitioner 310 proceeds to determination 618.

[0132] In decisions 616 and 618, the number of divisions for MT partitioning is either two (two divisions or "BT" nodes) or three (three divisions or "TT") for BT / TT partitioning. That is, if the direction of instruction from 614 is horizontal, the block partitioner 310 performs BT / TT partitioning decision 616, and if the direction of instruction from 614 is vertical, the block partitioner 310 performs BT / TT partitioning decision 618.

[0133] The BT / TT partitioning decision 616 indicates whether the horizontal partitioning is a 2-part partitioning 514, indicated by returning "0", or a 3-part partitioning 518, indicated by returning "1". If the BT / TT partitioning decision 616 indicates a 2-part partitioning, in the HBT CTU node generation step 625, the block partitioner 310 generates two nodes according to the horizontal 2-part partitioning 514. If the BT / TT partitioning 616 indicates a 3-part partitioning, in the HTT_CTU node generation step 626, the block partitioner 310 generates three nodes according to the horizontal 3-part partitioning 518.

[0134] The BT / TT partition decision 618 indicates whether the vertical partition is a 2-part partition 516, indicated by returning "0", or a 3-part partition 520, indicated by returning "1". If the BT / TT partition 618 indicates a 2-part partition, in the VBT_CTU node generation step 627, the block partitioner 310 generates two nodes according to the vertical 2-part partition 516. If the BT / TT partition 618 indicates a 3-part partition, in the VTT_CTU node generation step 628, the block partitioner 310 generates three nodes according to the vertical 3-part partition 520. For each node obtained from steps 625-628, a recursion of the data flow 600 is applied, returning to the MT partition decision 612 in the order of left to right or top to bottom, depending on the direction 614. As a result, binary and ternary tree partitions can be applied to generate CUs of various sizes.

[0135] Figures 7A and 7B provide an example 700 in which the CTU 710 is divided into a number of CUs or CBs. Figure 7A shows an exemplary CU 712. Figure 7A shows the spatial arrangement of CUs in the CTU 710. The exemplary division 700 is also shown as an encoded tree 720 in Figure 7B.

[0136] In Figure 7A, at each non-leaf node of the CTU 710, for example nodes 714, 716, and 718, the contained nodes (which may be further divided or CUs) are scanned or traversed in "Z-order" to create a list of nodes that are represented as columns in the coding tree 720. In the case of a quadtree partition, the Z-order scan is performed from top left to right, followed by bottom left to right. In the case of horizontal and vertical partitions, the Z-order scan (traversal) is simplified to a top-down scan and a left-to-right scan, respectively. The coding tree 720 in Figure 7B lists all nodes and CUs arranged according to the Z-order scan of the coding tree. Each partition generates a list of two, three, or four new nodes at the next level of the tree until a leaf node (CU) is reached.

[0137] The image is decomposed into CTUs by the block partitioner 310, and further decomposed into CUs. After generating each residual block (324) using the CUs as described with reference to Figure 3, the residual blocks are subjected to forward transformation and quantization by the video encoder 114. The resulting TB 336 is then scanned to form a sequential list of residual coefficients as part of the operation of the entropy coding module 338. A similar process is performed in the video decoder 134 to obtain the TB from the bitstream 133.

[0138] Figures 8A, 8B, 8C, and 8D show examples of forward and inverse non-separable quadratic transformations performed according to transformation blocks (TBs) of different sizes. Figure 8A shows a set of relationships 800 between the linear transformation coefficients 802 and the quadratic transformation coefficients 804 for a 4×4TB size. The linear transformation coefficients 802 consist of 4×4 coefficients, and the quadratic transformation coefficients 804 consist of 8 coefficients. The 8 quadratic transformation coefficients are arranged in pattern 806. Pattern 806 corresponds to 8 positions adjacent in a backward oblique scan of the TB, including the DC (top left) position. The remaining 8 positions in the backward oblique scan shown in Figure 8A remain at zero values ​​because they are not input by performing the forward quadratic transformation. Thus, the forward non-separable quadratic transformation 810 for 4×4TB receives 16 linear transformation coefficients and produces 8 quadratic transformation coefficients as outputs. Thus, the forward quadratic transformation 810 for 4×4TB can be represented by an 8×16 matrix of weights. Similarly, the inverse quadratic transformation 812 can be represented by a 16x8 matrix of weights.

[0139] Figure 8B shows a set of relationships 818 between linear and quadratic transform coefficients for 4×N and N×4 TB sizes (where N is greater than 4), in both cases the upper left 4×4 subblock 820 of the linear coefficients is associated with the upper left 4×4 subblock 824 of the quadratic transform coefficients. In the video encoder 114, the forward unseparated quadratic transform 830 takes 16 linear transform coefficients and produces 16 quadratic transform coefficients as output. The remaining linear transform coefficients 822 are not input by the forward quadratic transform and therefore remain at zero. After the forward unseparated quadratic transform 830 is performed, the coefficient position 826 is associated with coefficient 822, is not input, and therefore remains at zero.

[0140] The forward quadratic transformation 830 of 4×N or N×4 TB can be represented by a 16×16 weight matrix. The matrix representing the forward quadratic transformation 830 is defined as A. Similarly, the corresponding inverse quadratic transformation 832 can be represented by a 16×16 weight matrix. The matrix representing the inverse quadratic transformation 832 is defined as B.

[0141] The storage requirements for the non-separated translation kernel are further reduced by reusing a portion of A for the forward quadratic translation 810 and the inverse quadratic translation 812 for 4 x 4 TB. The first 8 rows of A are used for the forward quadratic translation 810, and the transpose of the first 8 rows of A is used for the inverse quadratic translation 812.

[0142] Figure 8C shows the relationship between the linear and quadratic transformation coefficients 840 and 842 for an 8x8 TB. The linear transformation coefficients 840 consist of 8x8 coefficients, and the quadratic transformation coefficients 842 consist of 8 transformation coefficients. The 8 quadratic transformation coefficients 842 are arranged in a pattern corresponding to 8 consecutive positions in a backward oblique scan of the TB, where the 8 consecutive positions include the DC (top-left) coefficient of the TB. The remaining quadratic transformation coefficients of the TB are all zero and therefore do not need to be scanned. The forward undivided quadratic transformation 850 for an 8x8 TB takes 48 linear transformation coefficients corresponding to 3 4x4 subblocks as input and generates 8 quadratic transformation coefficients. The forward quadratic transformation 850 for an 8x8 TB can be represented by an 8x48 matrix of weights. The corresponding inverse quadratic transformation 852 for an 8x8 TB can also be represented by a 48x8 matrix of weights.

[0143] Figure 8D shows the relationship 875 between the linear transformation coefficients 860 and the quadratic transformation coefficients 862 for TBs of size 8x8 or larger. The upper left 8x8 block of the linear transformation coefficients 860 (arranged as four 4x4 subblocks) is associated with the upper left 4x4 subblock of the quadratic transformation coefficients 862. In the video encoder 114, the forward unseparated quadratic transformation 870 calculates 48 linear transformation coefficients to generate 16 quadratic transformation coefficients. The remaining linear transformation coefficients 864 are set to zero. The quadratic transformation coefficient positions 866 outside the upper left 4x4 subblock of the quadratic transformation coefficients 862 are not input and remain zero.

[0144] A forward quadratic transformation 870 of a TB larger than 8x8 can be represented by a 16x48 matrix of weights. The matrix representing the forward quadratic transformation 870 is defined as F. Similarly, the corresponding inverse quadratic transformation 832 can be represented by a 48x16 matrix of weights. The matrix representing the inverse quadratic transformation 872 is defined as G. As described above with reference to matrices A, B, and F, they preferably have the property of orthogonality. The property of orthogonality is G = F T Only F needs to be stored in the video encoder 114 and the video decoder 134. An orthogonal matrix can be described as a matrix whose rows are orthogonal.

[0145] By reusing a portion of F, the storage requirements for the non-separated translation kernel are further reduced. F is for the 8x8TB forward quadratic translation 850 and inverse quadratic translation 852. The first 8 rows of F are transposed and used for the forward quadratic translation 810. F is used for the inverse quadratic translation 812.

[0146] The non-separable quadratic transform can sparsify two-dimensional features of the residual signal, such as angular features, thus achieving coding improvements compared to using only the separable linear transform. Since angular features in the residual signal may depend on the type of intra-prediction mode 387 selected, it is advantageous for the non-separable quadratic transform matrix to be adaptively selected according to the intra-prediction mode. As described above, the intra-prediction modes consist of the "intra-DC" mode, the "intra-planar" mode, the "intra-angle" mode, and the "matrix intra-prediction" mode. The intra-prediction mode parameter 458 takes a value of 0 when intra-DC prediction is used. The intra-prediction mode parameter 458 takes a value of 1 when intra-planar prediction is used. The intra-prediction mode parameter 458 takes a value between 2 and 66 when intra-angular prediction on a square TB is used.

[0147] Figure 9 shows a set of 900 transformation blocks available in the Multipurpose Video Coding (VVC) standard. Figure 9 also shows the application of a quadratic transformation to a subset of residual coefficients from the transformation blocks of set 900. Figure 9 shows several TBs with widths and heights ranging from 4 to 32. However, TBs with a width and / or height of 64 are possible but are not shown for ease of reference.

[0148] For a 4x4 set of coefficients, a 16-point quadratic transformation 952 (shown in dark shading) is applied. The 16-point quadratic transformation 952 is applied to TBs with a width or height of 4, such as 4x4TB910, 8x4TB912, 16x4TB914, 32x4TB916, 4x8TB920, 4x16TB930, and 4x32TB940. The 16-point quadratic transformation 952 is also applied to TBs of size 4x64 and 64x4 (not shown in Figure 9). For TBs with a width or height of 4 and a linear coefficient of 16 or more, the 16-point quadratic transformation is applied only to the top-left 4x4 subblock of the TB, and the coefficients of the other subblocks must be 0 in order to apply the quadratic transformation. In general, applying a 16-point quadratic transformation results in 8 or 16 quadratic transformation coefficients, as explained with reference to Figures 8 to 8D. The quadratic transformation coefficients are packed into the TB for encoding into the upper-left subblock of the TB.

[0149] For transformation sizes where the width and height are greater than 4, a 48-point quadratic transformation 950 (shown in light shading) is available for application to the three 4x4 subblocks of the residual coefficient in the upper left 8x8 region of the transformation block, as shown in Figure 9. The 48-point quadratic transformation 950 is applied to the 8x8 transformation block 922, 16x8 transformation block 924, 32x8 transformation block 926, 8x16 transformation block 932, 16x16 transformation block 934, 32x16 transformation block 936, 8x32 transformation block 942, 16x32 transformation block 944, and 32x32 transformation block 946, in the areas shown in light shading and dashed lines, respectively. The 48-point quadratic transformation 950 is also applicable to TB (not shown) of sizes 8x64, 16x64, 32x64, 64x64, 64x32, 64x16, and 64x8. Applying a 48-point quadratic transform kernel generally results in fewer than 48 quadratic transform coefficients. For example, as illustrated with reference to Figures 8B-8D, 8 or 16 quadratic transform coefficients may be generated. Linear transform coefficients that are not subject to quadratic transform ("linear-only coefficients"), such as coefficient 966 in TB934, are required to be zero for the quadratic transform to be applied. After applying the 48-point quadratic transform 950 forward, the region that may contain significant coefficients is reduced from 48 coefficients to 16 coefficients, further reducing the number of coefficient locations that may contain significant coefficients. In the inverse quadratic transform, the decoded significant coefficients are transformed to generate coefficients that may be significant in the region subject to the inverse linear transform. When the quadratic transform reduces one or more subblocks to a set of 16 quadratic transform coefficients, only the top-left 4x4 subblock can contain significant coefficients. The position of the last significant coefficient at any coefficient location where a quadratic transform coefficient may be stored indicates whether a quadratic transform or only a linear transform was applied.

[0150] When the last significant coefficient position indicates a quadratic transformation coefficient position within the TB, a signaled quadratic transformation index (i.e., 388 or 474) is needed to distinguish whether to apply the quadratic transformation kernel or bypass the quadratic transformation. The application of the quadratic transformation to TBs of various sizes in Figure 9 has been described from the perspective of the video encoder 114, but the corresponding inverse processing is performed in the video decoder 134. The video decoder 134 first decodes the position of the last significant coefficient. If the decoded last significant coefficient position indicates the applicability of the quadratic transformation, the quadratic transformation index 474 is decoded to determine whether to apply or bypass the inverse quadratic transformation.

[0151] Figure 10 shows the syntax structure 0100 of a bitstream 1001 having multiple slices. Each slice contains multiple coding units. Bitstream 1001 may be generated by the video encoder 114 as, for example, bitstream 115, or parsed by the video decoder 134 as, for example, bitstream 133. Bitstream 1001 is divided into parts such as network abstraction layer (NAL) units, and the division is achieved by preceding each NAL unit with a NAL unit header such as 1008. The sequence parameter set (SPS) 1010 defines sequence-level parameters such as the profile (set of tools), chroma format, sample bit depth, and frame resolution used for coding and decoding the bitstream. The parameters are also included in set 1010 which constrain the application of different types of divisions in the coding tree of each CTU.

[0152] The Picture Parameter Set (PPS) 1012 defines a set of parameters that apply to zero or more frames. The Picture Header (PH) 1015 defines the parameters that apply to the current frame. The parameters in PH 1015 may include a list of CU chroma QP offsets, one of which is applied at the CU level and can derive quantization parameters for use by the chroma block from the quantization parameters of the co-occurring chroma CB.

[0153] A slice sequence that forms a picture header 1015 and a single picture is known as an AU (Access Unit), such as AU0_0114. AU0_1014 contains three slices, such as slices 0 through 2, with slice 1 designated as 1016. Like the other slices, slice 1 (1016) contains slice header 0118 and slice data 1020.

[0154] Figure 11 shows the syntax structure 1100 of slice data (e.g., 115 and 133) of bitstream 1001 (e.g., 1120 corresponding slice data 1104) by a shared coding tree of lumar coding units and chromar coding units of coding tree units such as CTU1110. CTU1110 contains one or more CUs. One example is labeled as CU1114. CU1114 contains a signaled prediction mode 1116 followed by a transformation tree 1118. When the size of CU1114 does not exceed the maximum transformation size (either 32x32 or 64x64 of the lumar channels), the transformation tree 1118 contains one transformation unit, indicated as TU1124. When a 4:2:0 chroma format is used, the corresponding maximum chroma transformation size is half the maximum lumar transformation size in each direction. In other words, if the maximum luma conversion size is 32x32 or 64x64, the maximum chroma conversion size will be 16x16 or 32x32, respectively. For a 4:4:4 chroma format, the maximum chroma conversion size will be the same as the maximum luma conversion size. For a 4:2:2 chroma format, the maximum chroma conversion size will be half horizontally and the same vertically as the maximum luma conversion size. That is, if the maximum luma conversion size is 32x32 and 64x64, the maximum chroma conversion size will be 16x32 and 32x64, respectively.

[0155] If prediction mode 1116 indicates the use of intra-prediction for CU1114, then luma intra-prediction mode and chroma intra-prediction mode are specified. Furthermore, for the luma CB of CU1114, according to the MTS index 1122, the primary transform type is signaled to be one of the following: (i) DCT-2 horizontally and vertically, (ii) transform skip horizontally and vertically, or (iii) a combination of DST-7 and DCT-8 horizontally and vertically. If the signaled luma transform type is DCT-2 horizontal and vertical (option (i)), an additional luma secondary transform index 1120, also known as the "Low-Frequency Non-Separated Transform" (LFNST) index, is signaled to the bitstream under the conditions described with reference to Figures 8A-8D and 13-16.

[0156] By using a shared coding tree, TU1124 will contain TBs for each color channel, indicated as luma TB_Y_1128, first chroma TB_Cb_1132, and second chroma TB_Cr_1136. Whether each TB exists depends on one of the corresponding “coding block flags” (CBFs), i.e., coding block flags 1123. When a TB exists, the corresponding CBF is equal to 1, and at least one residual coefficient in the TB is non-zero. When a TB does not exist, the corresponding CBF is equal to 0, and all residual coefficients in the TB are zero. Luma TB1128, first chroma TB1134, and second chroma TB1136 may use conversion skips, as indicated by conversion skip flags 1126, 1130, and 1134, respectively. The coding mode in which a single chroma TB is sent to specify chroma residuals for both Cb and Cr channels is known as the “joint CbCr” coding mode and is available. When joint CbCr coding mode is enabled, a single chroma TB is coded.

[0157] Regardless of the color channel, each encoded TB includes one or more residual coefficients following the final position. For example, the ruma TB 1128 includes the final position 1140 and residual coefficient 1144. The final position 1140 indicates the position of the last significant residual coefficient in the TB when the coefficients of the oblique scanning pattern used to serialize the array of coefficients in the TB are considered in the forward direction (i.e., from the DC coefficients first). The two TBs for the chroma channel, 1132 and 1136, each have a corresponding final position syntax element used in a similar manner to that described for the ruma TB 1128. If the final positions of the TBs for the CU, i.e., 1128, 1132, and 1136, indicate that for each TB of the CU, only the coefficients in the quadratic transformation region are significant, and all remaining coefficients that would only undergo a linear transformation are zero, then the quadratic transformation index 1120 may be signaled to specify whether or not to apply the quadratic transformation. Further conditions regarding the signaling of the quadratic transformation index 1120 are described with reference to Figures 14 and 16.

[0158] When a quadratic transformation is applied, the quadratic transformation index 1120 indicates which kernel is selected. Generally, two kernels are available in the kernel "candidate set". Generally, there are four candidate sets, and one candidate set is selected using the block intra-prediction mode. The luma intra-prediction mode is used to select the candidate set for luma blocks, and the chroma intra-prediction mode is used to select the candidate sets for two chroma blocks. As explained with reference to Figures 8A to 8D, the selected kernel also depends on the TB size, with different kernels used for 4x4, 4xN / Nx4, and other TB sizes. When a 4:2:0 chroma format is used, the chroma TB is generally half the width and height of the corresponding luma TB, and as a result, if a luma TB with a width or height of 8 is used, a different selected kernel will occur for the chroma block. For luma blocks of sizes 4x4, 4x8, and 8x4, the one-to-one correspondence between luma blocks and chroma blocks in the shared coding tree is changed so that smaller chroma blocks such as 2x2, 2x4, and 4x2 do not exist.

[0159] The quadratic transformation index 1120 represents, for example, the following: index value 0 (not applied), 1 (apply the first kernel of the candidate set), 2 (apply the second kernel of the candidate set). For chromas, a selected quadratic transformation kernel from the candidate set, derived considering the chroma TB size and chroma intra-prediction mode, is applied to each chroma channel. Therefore, the residuals of Cb block 1224 and Cr block 1226 must contain only significant coefficients at the positions subject to the quadratic transformation, as explained with reference to Figures 8A to 8D. When joint CbCr coding is used, the resulting Cb and Cr residuals only contain significant coefficients at the positions corresponding to significant coefficients in the jointly coded TB; therefore, the requirement that the positions subject to the quadratic transformation contain significant coefficients is only applicable to single-coded chroma TBs.

[0160] Figure 12 shows the syntax structure 1200 of slice data 1204 (e.g., 1020) of a bitstream (e.g., 115, 133) where the coding tree units of the luma coding unit and chroma coding unit have separate coding trees. The separate coding trees are available for an "I-slice". The slice data 1204 contains one or more CTUs, such as CTU 1210. CTU 1210 is typically a luma sample size of 128 × 128 and begins with a shared tree containing one quad-tree division common to luma and chroma. In each of the resulting 64 × 64 nodes, separate coding trees begin for luma and chroma. Figure 12 shows an example of node 1214. Node 1214 has a luma node 1214a and a chroma node 1214b. The luma tree begins with luma node 1214a and the chroma tree begins with chroma node 1214b. The trees starting from nodes 1214a and 1214b are independent of the luma and chroma, allowing for different partitioning options to generate the resulting CU. The luma CU 1220 belongs to the luma coding tree and includes the luma prediction mode 1221, the luma transformation tree 1222, and the secondary transformation index 1224. The luma transformation tree 1222 includes the TU 1230. Since the luma coding tree encodes only samples of the luma channel, the TU 1230 includes the luma TB 1234, with the luma transformation skip flag 1232 indicating whether the luma residual should be transformed or not. The luma TB 1234 includes the final position 1236 and the residual coefficient 1238.

[0161] Chroma CU1250 belongs to the chroma coding tree and includes chroma prediction mode 1251, chroma transformation tree 1252, and secondary transformation index 1254. Chroma transformation tree 1252 includes TU1260. Since the chroma tree contains chroma blocks, TU1260 includes Cb_TB1264 and Cr_TB1268. The application of transformation bypasses to Cb_TB1264 and Cr_TB1268 is signaled by Cb transformation skip flag 1262 and Cr transformation skip flag 1266, respectively. Each TB includes the final position and residual coefficients; for example, the final position 1270 and residual coefficient 1272 are associated with Cb_TB1264. The 254 signaling of secondary transformation index 1 applied to the chroma TBs of the chroma tree is described with reference to Figures 14 and 16.

[0162] Figure 17 shows a 32x32 TB1700. It is shown that the conventional scan pattern 1710 is applied to the TB1700. The scan pattern 1710 proceeds diagonally backward across the TB1700, starting from the last significant coefficient position and proceeding towards the DC (upper left) coefficient position. This progression divides the TB1700 into 4x4 subblocks. Each subblock is scanned diagonally backward within several subblocks of the TB1700, for example, as shown in subblock 1750. Other subblocks are scanned in the same manner. However, in Figure 17, for ease of reference, a limited number of subblocks are shown in full scan. Progression from one 4x4 subblock to the next also follows a diagonal backward scan across the entire TB1700.

[0163] When using MTS, only the coefficients in the upper left 16x16 portion 1740 of TB1700 may be important. The upper left 16x16 portion forms or lies within a threshold orthogonal position (in this example, (15,15)) to which MTS can be applied. If the last significant coefficient lies outside the threshold orthogonal position at either the X or Y coordinate, MTS cannot be applied. That is, if either the X or Y coordinate of the position of the last significant coefficient exceeds 15, MTS cannot be applied and DCT-2 is applied (or the transformation is skipped). The position of the last significant coefficient is expressed in orthogonal coordinates relative to the position of the DC coefficient in TB1700. For example, the position of the last significant coefficient 1730 is 15,15. A scan pattern 1710 starting from position 1730 and progressing toward the DC coefficient results in scan subblocks 1720 and 1721 (identified in shading) being zeroed out in video encoder 114 when MTS is applied and not used by video decoder 134. The video decoder 134 needs to decode the residual coefficients of subblocks 1720 and 1721 because 1720 and 1721 are included in the scan, but the decoded residual coefficients of subblocks 1720 and 1721 are not used when MTS is applied. At a minimum, the residual coefficient of subblock 1720 may be required to be zero for MTS to be applied, which reduces the associated coding cost and prevents the bitstream from encoding significant residual coefficients of subblocks when MTS is applied. That is, the analysis of the "mts_idx" syntax element may be conditional not only on the last significant position being within subblock 1740, but also on subblocks 1720 and 1721 containing only zero-value residual coefficients.

[0164] Figure 18 shows a scan pattern 1810 of a 32x32 TB1800 using the described configuration. The scan pattern 1810 groups 4x4 subblocks into several "collections," such as collection 1840.

[0165] In the context of this disclosure, in relation to the scan pattern, the collection provides a non-overlapping set of subblocks that (i) form an area or region of an MTS-applicable size, or (ii) form an area or region enclosing an area-applicable to the MTS. The scan pattern traverses the transformation block by proceeding through several non-overlapping collections of subblocks of residual coefficients, and after completing the scan of the current collection, proceeds from the current collection to the next collection.

[0166] In the example in Figure 18, each collection is a two-dimensional array of 4x4 subblocks with a width and height of up to four subblocks (collection option (i)). Collection 1840 corresponds to the area of ​​potentially significant coefficients when MTS is used, i.e., the 16x16 area of ​​TB1800. Scan pattern 1810 progresses from one collection to the next without re-entry; that is, once all residual coefficients in a collection have been scanned, scan pattern 1810 progresses to the next collection. Scan 1810 effectively completes the scan pattern of the current collection before proceeding to scan the next collection. The collections are non-overlapping, and each residual coefficient position is scanned once, starting from the last position and progressing toward the DC (top left) coefficient position.

[0167] Similar to scan pattern 1710, scan pattern 1810 also divides TU1800 into 4x4 subblocks. Due to the monotonic progression from one collection to the next, once the scan reaches the top-left collection 1840, no further scanning of residual coefficients outside collection 1840 occurs. In particular, if the final position is within collection 1840, for example, at the final position 1830 of position 15,15, then all residual coefficients outside collection 1840 are not significant. The fact that the residual coefficients outside 1840 are zero aligns with the zero-out performed in video encoder 114 when MTS is used. Therefore, video decoder 134 only needs to ensure that the final position is within collection 1840 to enable purging of mts_idx syntax elements (1122 when the CU belongs to a single coding tree, and 1226 when the CU belongs to a luma branch of a different coding tree). The use of scan pattern 1810 eliminates the need to ensure that all residual coefficients outside collection 1840 are zero. Whether a coefficient is outside collection 1840 is already evident thanks to scan pattern 1810, which has collection sizes aligned in the MTS conversion coefficient region. By dividing TB1800 into a set of collections, each of the same size, scan pattern 1810 also enables reduced memory consumption compared to scan pattern 1710. Memory reduction is possible because a scan across TB1800 can consist of a scan across one collection. For TBs of size 16×32 and 32×16, two collections can be used in the same way as for a 16×16 size collection. For a 32×8 size TB, it is possible to divide it into collections constrained to 16×8 size due to the TB size. Dividing a 32×8 TB into collections results in the same scan pattern as proceeding diagonally regularly over an 8×2 array of 4×4 subblocks that make up the 32×8 TB. Therefore, in the 8×16 coefficient region targeted by the 32×8TB MTS conversion, the significant coefficient characteristics are satisfied by confirming that the final position is within the left half of 32×8TB.

[0168] Figure 19 shows a TB1900 of size 8×32. TB1900 can be divided into collections. In the example in Figure 19, some collections, such as collection 1940, are constrained to an 8×16 size due to the TB size. Dividing an 8×32TB1900 into collections results in a different subblock order compared to the normal diagonal progression on a 2×8 array of 4×4 subblocks that make up the 8×32TB (as shown, e.g., in Figure 18). By using an 8×16 collection size, if the last significant coefficient position is within collection 1940, it is guaranteed that the significant coefficient is only possible in the MTS transformation coefficient region, for example, at the last significant position 1930 at 7,15.

[0169] The scan patterns in Figures 18 and 19 scan the residual coefficients of each subblock diagonally backward. In the examples in Figures 18 and 19, each collection's subblock is scanned diagonally backward. The scanning between collections is performed diagonally backward in Figures 18 and 19.

[0170] Figure 20 shows alternative scan order 2010 for a 32x32 TB2000. Scan order (scan pattern) 2010 is divided into parts 2010a to 2010f. Scan orders 2010 to 2010e relate to option (ii) collection, a set of subblocks that form an area or region enclosing an area applicable to the MTS. Scan pattern 2010f relates to (i) collection covering region 2040 that forms an area applicable to the MTS. Scan orders 2010a to 2010f are defined so that backward diagonal progression from one subblock to the next occurs across the TB2000 excluding region 2040, and then the scan is performed using the backward diagonal progression scan. Region 2040 corresponds to the MTS conversion coefficient region. Dividing TB2000 into scans on subblocks outside the MTS conversion coefficient region and subsequent scans on subblocks within the MTS conversion coefficient region results in progress on the subblocks as shown in 2010a, 2010b, 2010c, 2010d, 2010e, and 2010f. Scan pattern 2010 identifies two collections: the collection defined by 2010a through 2010e and the collection defined by region 2040, which is scanned by 2010f. The scan is performed in a manner that allows all subblocks adjacent to collection 2040 to be scanned before the lower right corner (2030) of collection 2040. Scan pattern 2010 scans the collection of subblocks formed using scans 2010a through 2010e. Once the collection covered by 2010a through 2010e is complete, scan pattern 2010 continues to the next collection 2040, which is scanned according to 2010f. To enable signaling of mts_idx, there is a property that ensures the position of the last significant coefficient, such as 2030, is within the region 2040, and it is not necessary to also ensure that residual coefficients outside the region 2040 are zero.

[0171] The scanning of residual coefficients is performed using a variation of the back oblique scan shown in Figure 20. In Figure 20, the scan pattern scans the collection in a back raster manner. In the pattern variations of Figures 18 and 19, the collection may be scanned in back raster order.

[0172] The scan patterns shown in Figures 18-20, namely 1810, 1910, and 2010a-f, substantially retain the property of progressing from the highest frequency coefficient of the TB to the lowest frequency coefficient of the TB, compared to scan pattern 1710 in Figure 17. Therefore, the arrangement of video encoder 114 and video decoder 134 using scan patterns 1810, 1910, and 2010a-f achieves the same compression efficiency as achieved when using scan pattern 1710, while allowing reliance on the position of the last significant coefficient without the further need to check zero-value residual coefficients outside the MTS conversion coefficient region.

[0173] Figure 13 shows a method 1300 for encoding frame data 113 into a bitstream 115, the bitstream 115 containing one or more slices as a sequence of encoding tree units. Method 1300 can be implemented by a device such as a configured FPGA, ASIC, or ASSP. Furthermore, method 1300 may be executed by a video encoder 114 under the execution of a processor 205. Thus, method 1300 may be implemented as a module of software 233 stored in a computer-readable storage medium and / or memory 206.

[0174] Method 1300 begins with step 1310 of SPS / PPS encoding. In step 1310, the video encoder 114 encodes the SPS 1010 and PPS 1012 into a bitstream 115 as a sequence of fixed-length and variable-length encoding parameters. Parameters of the frame data 113, such as resolution and sample bit depth, are encoded. Parameters of the bitstream are also encoded, such as flags indicating the use of a particular encoding tool. The picture parameter set includes parameters that specify how often the "delta QP" syntax element is present in the bitstream 113, and the offset of the chroma QP relative to the luma QP.

[0175] Method 1300 proceeds from step 1310 to step 1320 of picture header encoding. In performing step 1320, processor 205 encodes a picture header (e.g., 1015) into bitstream 113, and picture header 1015 is applicable to all slices in the current frame. Picture header 1015 includes partition constraints indicating the maximum allowable depth of binary, ternary, and quad-tree partitions, which can override similar constraints included as part of SPS 1010.

[0176] Method 1300 proceeds from step 1320 to step 1330 of slice header encoding. In step 1330, the entropy encoder 338 encodes the slice header 1118 into bitstream 115.

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

[0178] Method 1300 proceeds from step 1340 to step 1350, which is the coding tree determination. In step 1350, the video encoder 114 determines the coding tree for the currently selected CTU in the slice. Method 1300 begins with the first CTU in slice 0116 in the first call to step 1350 and proceeds to subsequent CTUs in slice 0116 in subsequent calls. In determining the coding tree for the CTU, various combinations of quad-tree, binary, and ternary partitioning are generated and tested by the block partitioner 310.

[0179] Method 1300 proceeds from step 1350 to step 1360 of encoding unit determination. In step 1360, the video encoder 114 uses known methods to determine the encoding for the CUs resulting from the various encoding trees under evaluation. Determining the encoding includes determining the prediction mode (e.g., intra-prediction by a specific mode 387 or inter-prediction by motion vectors) and the linear transformation type 389. If the linear transformation type 389 is determined to be DCT-2 and all quantized linear transformation coefficients that do not undergo a forward quadratic transformation are unsignificant, then the quadratic transformation index 388 is determined and may indicate the application of a quadratic transformation (e.g., encoding as 1120, 1224, or 1254). Otherwise, the quadratic transformation index 388 indicates a bypass of the quadratic transformation. Furthermore, a transformation skip flag 390 is determined for each TB in the CU to indicate whether to apply a primary transformation (and optionally a secondary transformation) or to completely bypass the transformation (e.g., 1126 / 1130 / 1134 or 1232 / 1262 / 1266). For lumana channels, the type of primary transformation is determined to be one of the DCT-2, transformation skip, or MTS options, while for chromana channels, DCT-2 or transformation skip are the available transformation types. Determining the encoding can also include determining quantization parameters that can change the QP, i.e., that the “delta QP” syntax element is encoded in bitstream 115. When determining individual encoding units, the optimal encoding tree is also determined jointly. If the encoding units in the shared encoding tree are encoded using intra-prediction, the lumana intra-prediction mode and chromana intra-prediction are determined in step 1360. If coding units in separate coding trees are to be coded using intra prediction, then either a luma intra prediction mode or a chroma intra prediction mode is determined in step 1360, depending on whether each branch of the coding tree is luma or chroma.

[0180] Step 1360 of the coding unit determination may prohibit the test application of the quadratic transformation if there are no "AC" residual coefficients in the primary region residuals resulting from the application of the DCT-2 primary transformation by the forward primary transformation module 326. The AC residual coefficient is the residual coefficient at a position other than the top-left position of the transformation block. Prohibiting the test of the quadratic transformation when only DC primary coefficients are present extends to the blocks to which the quadratic transformation index 388 is applied, i.e., the Y, Cb, and Cr of the shared tree (the Y channel only if the Cb and Cr blocks are 2 samples wide or high). Regardless of whether the coding unit is for a shared tree or a separated tree, if at least one significant AC principal coefficient is present, the video encoder 114 tests for the selection of a non-zero quadratic transformation index value 388 (i.e., for the application of the quadratic transformation).

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

[0182] Method 1300 proceeds from step 1370 to step 1380, which is the final coding unit test. In step 1380, the processor 205 tests whether the current coding unit is the last coding unit of the CTU. If not (NO in step 1380), control within the processor 205 returns to coding unit determination step 1360. If, otherwise, the current coding unit is the last coding unit (YES in step 1380), control within the processor 205 proceeds to step 1390, which is the final CTU test.

[0183] In step 1390 of the final CTU test, processor 205 tests whether the current CTU is the last CTU in slice 0116. If the current CTU is not the last CTU in the slice (1016 "NO" in step 1390), control in processor 205 returns to decision coding tree step 1350. Otherwise, if the current CTU is the last ("YES" in step 1390), control in processor 205 proceeds to step 13100 of the final slice test.

[0184] In step 13100 of the final slice test, processor 205 tests whether the current slice being encoded is the last slice in the frame. If the current slice is not the last slice ("NO" in step 13100), control in processor 205 returns to step 1330 of slice header encoding. Otherwise, if the current slice is the last slice and all slices have been encoded ("YES" in step 13100), method 1300 terminates.

[0185] Figure 14 shows a method 1400 for encoding the encoding unit into the bitstream 115, corresponding to step 1370 of Figure 13. Method 1400 may be implemented by a configured FPGA, ASIC, or ASSP or other device. Furthermore, method 1400 may be executed by a video encoder 114 under the execution of a processor 205. Thus, method 1400 may be stored as a module of software 233 on a computer-readable storage medium and / or in memory 206.

[0186] Method 1400 achieves improved compression efficiency by encoding the secondary transformation index 1254 only if it is applicable to the chroma TB of TU1260, and encoding the secondary transformation index 1120 only if it is applicable to any of the TBs of TU1124. When a shared coding tree is used, Method 1400 is called for each CU of the coding tree, e.g., CU1114 in Figure 11, to encode the Y, Cb, and Cr color channels. When separate coding trees are used, Method 1400 is first called for each CU of the luma branch 1214a, e.g., 1220, and then Method 1400 is also called for each chroma CU of the chroma branch 1214b, e.g., 1250.

[0187] Method 1400 begins with step 1410 of prediction block generation. In step 1410, the video encoder 114 generates prediction blocks 320 according to the prediction mode of the CU determined in step 1360, for example, intra-prediction mode 387. The entropy encoder 338 encodes the intra-prediction mode 387 for the coding unit determined in step 1360 into the bitstream 115. The "pred_mode" syntax element is encoded to distinguish the use of intra-prediction, inter-prediction, or other prediction modes for the coding unit. When intra-prediction is used for the coding unit, if a luma PB is applicable to the CU, the luma intra-prediction mode is encoded, and if a chroma PB is applicable to the CU, the chroma intra-prediction mode is encoded. That is, for an intra-predicted CU belonging to a shared tree, such as CU 1114, the prediction mode 1116 includes both the luma intra-prediction mode and the chroma intra-prediction mode. For intra-predicted CUs belonging to the luma branch of a separate coding tree, such as CU1220, prediction mode 1221 includes the luma-intra prediction mode. For intra-predicted CUs belonging to the chroma branch of another coding tree, such as CU1250, prediction mode 1251 includes the chroma-intra prediction mode. The primary transform type 389 is encoded for the luma TB of the coding unit to select from the use of DCT-2 horizontally and vertically, transform skipping horizontally and vertically, or a combination of DCT-8 and DST-7 horizontally and vertically.

[0188] Method 1400 proceeds from step 1410 to step 1420 of residual determination. The prediction block 320 is subtracted from the corresponding block of frame data 312 by the difference module 322 to generate the difference 324.

[0189] Method 1400 proceeds from step 1420 to step 1430 of residual transformation. In step 1430 of residual transformation, the video encoder 114, under the execution of processor 205, either bypasses the primary and secondary transformations for the residuals of step 1420, or performs the transformations for each TB of the CU according to the primary transformation type 389 and the secondary transformation index 388. The transformation of the difference 324 may be performed or bypassed according to the transformation skip flag 390, and if transformed, a secondary transformation may also be applied, as determined in step 1350 to generate the residual sample 350, as described with reference to Figure 3. After the operation of the quantification module 334, the residual coefficients 336 are available.

[0190] Method 1400 proceeds from step 1430 to step 1440 of coding the Luma transform skip flag. In step 1440, the entropy encoder 338 encodes a context-encoded transform skip flag 390 into the bitstream 115, indicating whether the residual of the Luma TB is transformed according to a linear transform and possibly a quadratic transform, or whether both the linear and quadratic transforms are bypassed. Step 1440 is performed when the CU contains a Luma TB, i.e., in the Luma branch of a shared coding tree (encoded 1126) or a dual tree (encoded 1232).

[0191] Method 1400 proceeds from step 1440 to step 1450 of Luma residual coding. In step 1450, the entropy encoder 338 encodes the residual coefficients 336 for Luma TB into the bitstream 115. Step 1450 operates to select an appropriate scan pattern based on the size of the coding unit. Examples of scan patterns are illustrated with reference to Figure 17 (conventional scan pattern) and Figures 18-20 (additional scan patterns used to determine the MTS flag). In the embodiments described herein, the scan patterns associated with the examples in Figures 18-20 are used. The residual coefficients 336 are typically scanned into a list according to a backward oblique scan pattern with 4x4 subblocks. For TBs with a width or height greater than 16 samples, the scan pattern is as illustrated with reference to Figures 18, 19, and 20. The position of the first non-zero residual coefficient in the list (i.e., 1140) is encoded in the bitstream 115 as Cartesian coordinates relative to the upper left coefficient of the transform block. The remaining residual coefficients are encoded as residual coefficient 1144, in the order of the coefficient at the final position, DC (top left) residual coefficient. Step 1450 is performed if CU contains a luma TB, i.e., it belongs to a shared coding tree (encoded 1128) or to a luma branch of a dual tree (encoded 1234).

[0192] Method 1400 proceeds from step 1450 to step 1460 of chroma transform skip flag coding. In step 1460, the entropy encoder 338 encodes two additional context-coded transform skip flags 390 into the bitstream 115, one for each chroma TB, indicating whether the corresponding TB undergoes a DCT-2 transform and, optionally, a quadratic transform, or whether the transform is bypassed. Step 1460 is performed if the CU contains a chroma TB, i.e., in a shared coding tree (encoded 1130 and 1134) or a chroma branch of a dual tree (encoded 1262 and 1266).

[0193] Method 1400 proceeds from step 1460 to step 1470 of chroma residual coding. In step 1470, the entropy encoder 338 encodes the residual coefficients of the chroma TB into the bitstream 115, as described with reference to step 1450. Step 1460 is performed if the CU contains a chroma TB, i.e., in a shared coding tree (encoded 1132 and 1136) or a chroma branch of a dual tree (encoded 1264 and 1268). For chroma TBs with a width or height greater than 16 samples, the scan patterns are as described with reference to Figures 18, 19 and 20. By using the scan patterns in Figures 18-20 for chroma TBs and chroma TBs, the need to define different scan patterns between chroma and chroma for TBs of the same size can be avoided.

[0194] Method 1400 proceeds from step 1470 to step 1480 of the LFNST signaling test. In step 1480, processor 205 determines whether the quadratic transformation can be applied to any TB in the CU. If all TBs in the CU use transformation skipping, there is no need to encode the quadratic transformation index 388 ("NO" in step 1480), and Method 1400 proceeds to step 14100 of the MTS signaling test. In the case of a shared coding tree, for example, the luma TB and each of the two chroma TBs are transformed skipped to return "NO" in step 1480. In the case of separate coding trees, the luma TB in the luma branch of the coding tree is transformed skipped for step 1480 to return "NO" for calls concerning the luma and chroma respectively, or both chroma TBs in the chroma branch of the coding tree are transformed skipped. For the quadratic transformation to be performed, the relevant TB only needs to contain a significant residual coefficient at the position of the TB to be transformed. That is, all other residual coefficients must be zero, and this condition is met if the final position of the TB is within 806, 824, 842, or 862 for the TB sizes shown in Figures 8A to 8D. If the final position of any TB in the CU is outside of 806, 824, 842, or 862 for the TB size considered, no quadratic transformation is performed ("NO" in step 1480), and method 1400 proceeds to step 14100 of the MTS signaling test.

[0195] In the case of chroma TBs, a width or height of 2 may occur. TBs with a width or height of 2 are not subject to quadratic transformation ("NO" in step 1480) because there is no defined kernel for TBs of such size, and method 1400 proceeds to step 14100 of the MTS signaling test. An additional condition for performing the quadratic transformation is that at least one AC residual coefficient exists for the TB in question. That is, if a significant residual coefficient exists only at the DC (top left) position of each applicable TB, the quadratic transformation is not performed ("NO" in step 1480), and method 1400 proceeds to step 14100 of the MTS signaling test. Provided that at least one TB of the CU is subject to a linear transformation (the transformation skip flag indicates that at least one TB of the CU is not skipped), the sampling position constraints for the TBs subject to the linear transformation are met, and at least one AC coefficient is included in one or more of the TBs subject to the linear transformation (YES in step 1480), control within processor 205 proceeds to step 1490 of LFNST index coding. In step 1490 of LFNST index coding, entropy encoder 338 encodes a truncated unary codeword representing three possible choices regarding the application of a quadratic transformation. The choices are zero (not applied), one (the first kernel of the candidate set is applied), and two (the second kernel of the candidate set is applied). The codeword uses at most two bins, each bin being context-coded. The tests performed in step 1480 indicate that step 1490 is performed only when a quadratic transformation can be applied, i.e., for non-zero indices to be coded. Step 1490 encodes, for example, 1120, 1224, or 1225.

[0196] In effect, the operation of steps 1480 and 1490 allows the secondary transformation index 1254 for the chroma in separate tree structures to be encoded only if the secondary transformation can be applied to the chroma TB of TU1260. In a shared tree structure, steps 1480 and 1490 operate to encode the secondary transformation index 1120 only if the secondary transformation can be applied to any of the TBs of TU1124. By excluding relevant secondary transformation indices (such as 1254 and 1120), method 1400 operates to improve encoding efficiency. In particular, for shared or dual trees, unnecessary flags are avoided, thereby reducing the number of bits required and improving encoding efficiency. For separate trees, if the corresponding chroma transformation block is skipped, the secondary transformation is not necessarily suppressed for the chroma.

[0197] Method 1400 proceeds from step 1490 to step 14100 of the MTS signaling test.

[0198] In step 14100 of the MTS signaling, the video encoder 114 determines whether the MTS index needs to be encoded into the bitstream 115. If the use of DCT-2 transformation was selected in step 1360, the last significant coefficient location may be anywhere within the upper-left 32x32 region of the TB. If the last significant coefficient location is outside the upper-left 16x16 region of the TB, and the scans of Figures 18 and 19 (rather than the scan pattern of Figure 17) are used, it is not necessary to explicitly signal mts_idx in the bitstream. In this case, the signal mts_idx is not needed in the bitstream because using MTS does not generate the last significant coefficient outside the upper-left 16x16 region. Step 14100 returns "NO", and method 1400 terminates with the use of DCT-2 implied by the location of the last significant coefficient.

[0199] The non-DCT-2 selection for the primary transformation type is only available if the width and height of the TB are 32 or less. Therefore, for TBs with a width or height greater than 32, step 14100 returns "NO", and method 1400 terminates at step 14100. The non-DCT-2 selection is also only available if no secondary transformation is applied, and therefore, if it is determined in step 1360 that the secondary transformation type 388 is non-zero, step 14100 returns "NO", and method 1400 terminates at step 14100.

[0200] When using the scans in Figures 18 and 19, the position of the last significant coefficient being within the upper-left 16x16 region of the TB can result from either the application of the DCT-2 linear transform or the DST-7 and / or DCT-8 MTS combination, thus requiring explicit signaling of mts_idx to encode the selection made in step 1360. Therefore, when the position of the last significant coefficient is within the upper-left 16x16 region of the TB, step 14100 returns "YES", and method 1400 proceeds to step 14110 of MTS index encoding.

[0201] In step 14110 of the MTS index coding, the entropy encoder 338 encodes a truncated unary bin string representing the linear transformation type 389. Step 14110 can encode, for example, 1122 or 1226. Method 1400 ends with the execution of step 14110.

[0202] Figure 15 shows a method 1500 for decoding a bitstream 133 to generate frame data 135, where the bitstream 133 contains one or more slices as a sequence of coding tree units. Method 1500 can be embodied by a device such as a configured FPGA, ASIC, or ASSP. Furthermore, method 1500 may be executed by a video decoder 134 under the execution of a processor 205. Thus, method 1500 may be stored as one or more modules of software 233 on a computer-readable storage medium and / or in memory 206.

[0203] Method 1500 begins with step 1510 of SPS / PPS decoding. In step 1510, the video decoder 314 decodes the SPS1010 and PPS1012 from the bitstream 133 as sequences of fixed-length and variable-length encoding parameters. Parameters of the frame data 113, such as resolution and sample bit depth, are decoded. Parameters of the bitstream, such as flags indicating the use of a specific encoding tool, are also decoded. Default partition constraints signal the maximum allowable depth of binary, terminally, and quad-tree partitioning and may also be decoded by the video decoder 134 as part of the SPS1010.

[0204] Method 1500 proceeds from step 1510 to step 1520 of picture header decoding. In the execution of step 1520, processor 205 decodes a picture header 1015 from bitstream 113 that is applicable to all slices in the current frame. The picture parameter set includes parameters that specify the frequency of the presence of "delta QP" syntax elements in bitstream 313, the offset of chroma QP relative to luma QP, and so on. Optional overridden partition constraints signal the maximum allowable depth of binary, ternary, and quad-tree partitions and may also be decoded by video decoder 134 as part of the picture header 1015.

[0205] Method 1500 proceeds from step 1520 to step 1530 of slice header decoding. In step 1530, the entropy decoder decodes slice header 0118 from bitstream 133.

[0206] Method 1500 proceeds from step 1530 to step 1540, which divides the slice into CTUs. In performing step 1540, the video encoder 114 divides slice 1016 into a sequence of CTUs. The slice boundaries are aligned to the CTU boundaries, and the CTUs within the slice are ordered according to the CTU scan order, generally the raster scan order. The division of the slice into CTUs establishes which parts of the frame data 133 should be processed by the video encoder 313 when decoding the current slice.

[0207] Method 1500 proceeds from step 1540 to step 1550 of coding tree decoding. In step 1550, video decoder 314 decodes the coding tree of the currently selected CTU in the slice. Method 1500 starts with the first CTU in slice 1016 in the first call to step 1550 and proceeds to subsequent CTUs in slice 1016 in subsequent calls. When decoding the coding tree of the CTU, flags indicating the combination of quadtree, binary, and ternary partition determined in step 1350 in video decoder 114 are decoded.

[0208] Method 1500 proceeds from step 1550 to step 1570, which involves decoding the encoded units. In step 1570, the video decoder 314 decodes the encoded units determined in step 1560 from the bitstream 133. An example of how the encoded units are decoded is illustrated in more detail with reference to Figure 16.

[0209] Method 1500 proceeds from step 1570 to step 1580, which is the final coding unit test. In step 1580, processor 205 tests whether the current coding unit is the last coding unit of the CTU. If not (NO in step 1580), control within processor 205 returns to step 1560, which is the coding unit decoding. If, otherwise, the current coding unit is the last coding unit (YES in step 1580), control within processor 205 proceeds to step 1590, which is the final CTU test.

[0210] In step 1590 of the final CTU test, processor 205 tests whether the current CTU is the last CTU of slice 1016. If it is not the last CTU of slice 1016 ("NO" in step 1590), control within processor 205 returns to step 1550 of the coded tree decoding. Otherwise, if the current CTU is the last ("YES" in step 190), control within the processor proceeds to step 15100 of the final slice test.

[0211] In step 15100 of the final slice test, processor 205 tests whether the current slice being decoded is the last slice in the frame. If the current slice is not the last slice (NO in step 15100), control in processor 205 returns to step 1530 of slice header decoding. Otherwise, if the current slice is the last slice and all slices have been decoded (YES in step 15100), method 1500 terminates.

[0212] Figure 16 shows a method 1600 for decoding an encoded unit from a bitstream 133, corresponding to step 1570 of Figure 15. Method 1600 may be embodied by a configured FPGA, ASIC, or ASSP or other device. Furthermore, method 1600 may be executed by a video decoder 314 under the execution of a processor 205. Thus, method 1600 may be stored on a computer-readable storage medium and / or as one or more modules of software 233 in memory 206.

[0213] If a shared coding tree is used, method 1600 is invoked for each CU in the coding tree, for example CU1114 in Figure 11, and the Y, Cb, and Cr color channels are coded in a single invoke. If separate coding trees are used, method 1600 is first invoked for each CU in the lumab branch 1214a, for example 1220, and then method 1600 is also invoked separately for each chroma CU in the chromab branch 1214b, for example 1250.

[0214] Method 1600 begins with step 1610 of decoding the Luma transform skip flag. In step 1610, the entropy decoder 420 decodes a context-encoded transform skip flag 478 (encoded in the bitstream as, for example, 1126 in Figure 11 or 1232 in Figure 12) from the bitstream 133. The skip flag indicates whether the transform is applied to Luma TB. The transform skip flag 478 indicates that the residual for Luma TB is transformed according to (i) a linear transform, (ii) a linear and a quadratic transform, or (iii) a linear and a quadratic transform being bypassed. Step 1610 is performed when the CU contains Luma TB in the shared coding tree (e.g., decoded 1126). Step 1610 is performed when the CU belongs to the Luma branch of the dual tree (decoded 1232) of the separated coding tree CTU.

[0215] Method 1600 proceeds from step 1610 to step 1620 of Luma residual decoding. In step 1620, the entropy decoder 420 decodes 424 residual coefficients for the Luma TB from bitstream 115. The residual coefficients 424 are combined into the TB by applying a scan to the list of decoded residual coefficients. Step 1620 operates to select an appropriate scan pattern based on the size of the coding unit. Examples of scan patterns are described in relation to Figure 17 (conventional scan pattern) and Figures 18-20 (additional scan patterns useful for determining the MTS flag). The examples described herein use scan patterns based on the patterns described in relation to Figures 18-20. This scan is typically a backward oblique scan pattern using 4x4 subblocks, as defined with reference to Figures 18 and 19. The position of the first non-zero residual coefficient in the list (i.e., 1140) is decoded from bitstream 133 as Cartesian coordinates relative to the upper left coefficient of the transform block. The remaining residual coefficients are decoded as residual coefficient 1144, in the order of the coefficient at the final position, DC (top left), and residual coefficient.

[0216] For each subblock of the TB, except for the top-left subblock and the subblock containing the last significant residual coefficient, an "encoded subblock flag" is decoded to indicate that each subblock contains at least one significant residual coefficient. If the encoded subblock flag indicates the presence of at least one significant residual coefficient within the subblock, a "significance map" (a set of flags) is decoded to indicate the significance of each residual coefficient within the subblock. If a subblock is shown to contain at least one significant residual coefficient from the decoded encoded subblock flag, and the scan reaches the last scan position of the subblock without encountering any significant residual coefficients, the residual coefficient at the last scan position of the subblock is presumed to be significant. The encoded subblock flags and significance map (each flag named "sig_coeff_flag") are encoded using context-encoded bins. For each significant residual coefficient within a subblock, an "abs_level_gtx_flag" is decoded to indicate whether the magnitude of the corresponding residual coefficient is greater than 1. For each residual coefficient in a subblock having a magnitude greater than 1, "par_level_flag" and "abs_level2_gtx_flag" are decoded according to equation (1) to further determine the magnitude of the residual coefficient. AbsLevelPass1 = sig_coeff_flag + par_level_flag + abs_level_gtx_flag + 2×abs_level_gtx_flag2 (1)

[0217] The syntax elements of abs_level_gtx_flag and abs_level_gtx_flag2 are encoded using context-encoded bins. For each residual coefficient with abs_level_gtx_flag2 equal to 1, the bypass-encoded syntax element "abs_remainder" is decoded using Rice-Goron coding. The decoded magnitude of the residual coefficient is determined as follows: AbsLevel = AbsLevelPass1 + 2 × abs_remainder. To obtain the value of the residual coefficient from its magnitude, the sign bit is decoded for each significant residual coefficient. The orthogonal coordinates of each subblock of the scan pattern can be derived from the scan pattern by adjusting (right-shifting) the orthogonal coordinates of the X and Y residual coefficients by log2 of the width and height of the subblock, respectively. In the case of Luma TB, the subblock size is always 4 × 4, and X and Y are right-shifted by 2 bits. The scan patterns shown in Figures 18-20 can also be applied to the chroma TB to avoid storing different scan patterns for blocks of the same size but with different color channels. Step 1620 is performed when the CU contains a luma TB, i.e., in a shared coding tree (decoding 1128) or for a call to a luma branch of a dual tree (e.g., decoding 1234).

[0218] Method 1600 proceeds from step 1620 to step 1630 of chroma transform skip flag decoding. In step 1630, the entropy decoder decodes a context-encoded flag from bitstream 1 for each chroma 33TB. For example, the context-encoded flags may be encoded as shown in 1130 and 1134 in Figure 11, or 1262 and 1266 in Figure 12. At least one flag is decoded for each chroma TB, one at a time. The flags decoded in step 1630 indicate whether a transform is applied to the corresponding chroma TB, in particular whether a DCT-2 transform and optionally a quadratic transform are applied to the corresponding chroma TB, or whether all transforms to the corresponding chroma TB are bypassed. Step 1630 is performed if the CU contains a chroma TB, i.e., if the CU belongs to a shared coding tree (decoded 1130 and 1134) or a chroma branch of a dual tree (decoded 1262 and 1266).

[0219] Method 1600 proceeds from step 1630 to step 1640 of chroma residual decoding. In step 1640, the entropy decoder 420 decodes the residual coefficients of chroma TB from bitstream 133. Step 1640 operates in a manner similar to that described with reference to step 1620, according to the scan patterns defined in Figures 18 and 19. Step 1640 is performed when CU contains chroma TB, i.e., when CU belongs to a shared coding tree (decoded 1132 and 1136) or a chroma branch of a dual tree (decoded 1264 and 1268).

[0220] Method 1600 proceeds from step 1640 to step 1650 of the LFNST signaling test. In step 1650, the processor 205 determines whether the secondary transformation is applicable to any TB of the CU. The luma transformation skip flag can have a different value from the chroma transformation skip flag. If all of the TBs of the CU use transformation skipping, the secondary transformation is not applicable and there is no need to encode the secondary transformation index ("NO" in step 1650), and Method 1600 proceeds to step 1660 of the LFNST index determination. For example, in the case of a shared coding tree, each of the luma TB and the two chroma TBs is transformed skipped, returning "NO" in step 1650. For a CU belonging to a luma branch of a separate coding tree (e.g., 1220), step 1650 returns "NO" if the luma TB is transformed skipped. For CUs (e.g., 1250) belonging to a chroma branch of a separate coding tree, step 1650 returns "NO" when both chroma TBs are skipped in the transformation. For CUs belonging to a chroma branch of another coding tree (e.g., 1250) and having a width or height of less than 4 samples, step 1650 returns "NO". For a quadratic transformation to be performed, the relevant TB only needs to contain a significant residual coefficient at the position of the TB to be quadratic transformed. That is, all other residual coefficients must be zero, and this condition is met when the final position of the TB is within 806, 824, 842, or 862 for the TB sizes shown in Figures 8A to 8D. If the final position of any TB in a CU is outside 806, 824, 842, or 862 for the TB size considered, no quadratic transformation is performed ("NO" in step 1650), and method 1600 proceeds to step 1660 of LFNST index determination. For chroma TBs, a width or height of 2 is possible. TBs with a width or height of 2 are not subject to quadratic transformation because there is no kernel defined for TBs of that size. An additional condition for performing quadratic transformation is that there must be at least one AC residual coefficient in the TB in question.In other words, if the only significant residual coefficient for each TB is at the DC (top left) position, the quadratic transformation is not performed ("NO" in step 1650), and method 1600 proceeds to step 1660 of LFNST index determination. The constraints regarding the position of the last significant coefficient and the presence of non-DC residual coefficients apply only to TBs of applicable size, i.e., TBs with widths and heights greater than 2 samples. Provided that at least one applicable TB is transformed, the final position constraint is met, and the non-DC coefficient requirement is met ("YES" in step 1650), control within processor 205 proceeds to step 1670 of LFNST index decoding.

[0221] Step 1660 of the LFNST index determination is performed if a quadratic transformation cannot be applied to any of the TBs associated with the CU. In step 1660, the processor 205 determines that the quadratic transformation index has a value of zero, indicating that no quadratic transformation is applied. Control in the processor 205 proceeds from step 1660 to step 1672 of the MTS signaling.

[0222] In step 1670 of LFNST index decoding, the entropy decoder 420 decodes the truncated unary codeword as a quadratic transform index 474, which represents three possible choices for applying the quadratic transform. The choices are 0 (not applied), 1 (the first kernel of the candidate set is applied), and 2 (the second kernel of the candidate set is applied). The codeword uses at most two bins, each bin being context-encoded. A test performed in step 1650 ensures that step 1670 is executed only if it is possible for the quadratic transform to be applied, i.e., a non-zero index can be decoded. When method 1600 is called as part of a shared coding tree, step 1670 decodes 1120 from bitstream 133. When method 1600 is called as part of a luma branch of a separate coding tree, step 1670 decodes 1224 from bitstream 133. When step 1670 is called as part of a chroma branch of a separate coding tree, step 1670 decodes bitstream 133 to 1254. Control within processor 205 proceeds from step 1670 to step 1672 of MTS signaling.

[0223] Steps 1650, 1660, and 1670 are performed to determine the LFNST index, i.e., 474. The LFNST index is decoded from the video bitstream (e.g., decode 1120, 1224, or 1254) if at least one of the luma and chroma transform skip flags applicable to the CU indicates that the transformation for each transform block should not be skipped (YES in step 1650, perform step 1670). The LFNST index is determined to indicate that no secondary transformation should be applied if all of the luma and chroma transform skip flags applicable to the CU indicate that the transformation for each transform block should be skipped (NO in step 1650, and perform step 1660). For a shared tree, the luma skip value, chroma skip value, and LFNST index can be different. For example, the LFNST index decoded for a chroma transform block can be based on the decoded chroma transform skip flag, even if, for example, the decoded chroma transform skip flag in a collated block indicates that the transform for the chroma block is skipped. Encoding steps 1480 and 1490 operate in a similar manner.

[0224] In step 1672 of MTS signaling, the video decoder 114 determines whether it is necessary to decode the MTS index from the bitstream 133. If the use of the DCT-2 transform was selected in step 1360 when encoding the bitstream, the position of the last significant coefficient may be anywhere within the upper-left 32x32 region of the TB. If the position of the last significant coefficient decoded in step 1620 is outside the upper-left 16x16 region of the TB, and the scans of Figures 18 and 19 are used, then it is not necessary to explicitly decode mts_idx, as using a non-DCT-2 primary transform will not produce the last significant coefficient outside this region. Step 1672 returns "NO", and method 1600 proceeds from step 1672 to step 1674 of MTS index determination. The non-DCT2 primary transform is only available if the TB width and height are 32 or less. Therefore, for TBs with a width or height greater than 32, step 1672 returns "NO", and method 1600 proceeds to step 1674 of MTS index determination.

[0225] The non-DCT-2 linear transform is only available if the quadratic transform type 474 indicates that it bypasses the application of the quadratic transform kernel, and accordingly, if the quadratic transform type 474 has a non-zero value, method 1600 proceeds from step 1672 to step 1674. When using the scans in Figures 18 and 19, the presence of the last significant coefficient position within the upper-left 16x16 region of the TB can result from either the application of the DCT-2 linear transform or the DST-7 and / or DCT-8 MTS combination, so explicit signaling of mts_idx is required to encode the selection made in step 1360. Thus, when the last significant coefficient position is within the upper-left 16x16 region of the TB, step 1672 returns "YES", and method 1600 proceeds to step 1676 for MTS index decoding.

[0226] In step 1674 of the MTS index determination, the video decoder 134 decides to use DCT-2 as the primary conversion. The primary conversion type 476 is set to zero. Method 1400 proceeds from step 1674 to conversion residual step 1680.

[0227] In step 1676 of the MTS index decoding, the entropy decoder 420 decodes the truncated unary bin string from the bitstream 133 to determine the linear transformation type 476. The truncated string is in the bitstream, for example, 1122 in Figure 11 or 1226 in Figure 12. Method 1400 proceeds from step 1676 to step 1680 of the residual transformation.

[0228] Steps 1670, 1672, and 1674 operate to determine the MTS index of the encoding unit. The MTS index is decoded from the video bitstream if the last significant coefficient is at or within the threshold coordinates (15, 15) (YES in steps 1672 and 1676). The MTS index is determined to indicate that MTS is not applied if the last significant coefficient is outside the threshold coordinates (NO in steps 1672 and 1674). Encoding steps 14100 and 14110 operate in a similar manner.

[0229] In the alternative arrangement of video encoder 114 and video decoder 134, a chroma TB of appropriate size (to which MTS is not applied) is scanned according to the scan pattern described with reference to Figure 17, the luma TB utilizes the scan according to Figures 18 and 19, and the DST-7 / DCT-8 combination is applied only to the luma TB.

[0230] In step 1680 of the residual transformation, the video decoder 314, under the execution of the processor 205, either bypasses the inverse linear and inverse quadratic transformations for the residuals of step 1420, or performs the inverse transformation according to the linear transformation type 476 and the quadratic transformation index 474. The transformation is performed for each TB of the CU according to the decoded transformation skip flag 478 for each TB of the CU, as described with reference to Figure 4. The linear transformation type 476 selects whether to use DCT-2 horizontally and vertically, or a combination of DCT-8 and DST-7 horizontally and vertically, for the luma TB of the coding unit. In effect, step 1680 transforms the luma transformation blocks of the CU according to the decoded luma transformation skip flag, the linear transformation type 476, and the quadratic transformation index determined by the operations of steps 1610 and 1650 to 1670, and decodes the coding unit. Furthermore, step 1680 can decode the coding unit by transforming the chroma transform blocks of the CU according to the respective decoded chroma transform skip flags and secondary transform indices determined by the operations in steps 1630 and 1650 to 1670. For TBs belonging to the chroma channel (e.g., 1132 and 1136 in the case of a shared coding tree, and 1264 and 1268 in the chroma branch in the case of a separate coding tree), secondary transform is performed only if the width and height of the TB are 4 samples or more, as there are no available secondary transform kernels for TBs with a width or height of less than 4 samples. For TBs belonging to the chroma channel, the VVC standard imposes restrictions on partitioning operations that prohibit intra-predictive CUs with TB sizes of 2×2, 2×4, and 42×, as it is difficult to process such small-sized TBs at the block throughput speed required to support video formats such as UHD and 8K. In addition, there is a restriction prohibiting intra-predictive CUs with a width of 2 due to the difficulty of memory access for on-chip memory, which is normally used to generate the reconstructed samples as part of the intra-predictive operation. Therefore, Table 1 shows the chroma TB sizes (chroma sample units) to which the quadratic transformation is not applied. [Table 1]

[0231] As described herein, different scan patterns can be used in encoding and decoding. Step 1680 transforms the transformed blocks of CU according to the MTS index and decodes the encoded units.

[0232] Method 1600 proceeds from step 1680 to step 1690 of prediction block generation. In step 1690, the video decoder 134 generates prediction blocks 452 according to the prediction mode of the CU, as determined in step 1360 and decoded from the bitstream 113 by the entropy decoder 420. The entropy decoder 420 decodes the prediction mode for the coding unit, as determined in step 1360, from the bitstream 133. The “pred_mode” syntax element is decoded to distinguish the use of intra-prediction, inter-prediction, or other prediction modes for the coding unit. When intra-prediction is used for the coding unit, the luma intra-prediction mode is decoded if luma PB is applicable to the CU, and the chroma intra-prediction mode is decoded if chroma PB is applicable to the CU.

[0233] Method 1600 proceeds from step 1690 to step 16100 of encoding unit reconstruction. In step 16100, the prediction block is added to the residual samples 424 for each color channel of the CU to produce reconstructed samples 456. Additional in-loop filtering steps, such as deblocking, may be applied to the reconstructed samples 456 before they are output as frame data 135. Method 1600 ends with the execution of step 16100.

[0234] As described above, in the case of separate coding trees, method 1600 is first called for each CU of the luma branch 1214a, e.g., 1220, and then method 1600 is also called separately for each chroma CU of the chroma branch 1214b, e.g., 1250. The call to method 1600 for the chroma determines the LFNST index 1254 in steps 1650 to 1670 with respect to whether all of the chroma transform skip flags for CU 1250 are set. Similarly, in the call to method 1600 for the luma, the luma LFNST index 1224 is determined in steps 1650 to 1670 with respect to the luma transform skip flags for CU 1220 only.

[0235] The scan patterns shown in Figures 18-20, i.e., 1810, 1910, and 2010a-f, performed in steps 1450 and 1620, substantially retain the characteristic of progressing from the highest frequency coefficient of TB to the lowest frequency coefficient of TB, compared to scan pattern 1710 in Figure 17. Thus, the arrangement of video encoder 114 and video decoder 134 using scan patterns 1810, 1910, and 2010a-f achieves the same compression efficiency as achieved with scan pattern 1710, while allowing reliance on the last significant coefficient position without the further need to check zero-value residual coefficients outside the MTS conversion coefficient region. The final position used in the scan patterns of Figures 18-20 allows the use of MTS only if all significant coefficients reside in a suitable upper-left region, such as the upper-left 16x16 region. The burden on decoder 134 to check flags outside the suitable region, e.g., outside the 16x16 coefficient region of TB, to ensure that no further non-significant coefficients exist is removed. The operation in the decoder does not require any specific modifications to implement MTS. Furthermore, as mentioned above, the use of the scan patterns in Figures 18 and 19, i.e., for conversion blocks of sizes 16×32, 32×16, and 32×32, is a replication of the 16×16 scan, thereby reducing memory requirements. [Industrial applicability]

[0236] This method is applicable to the computer and data processing industries, particularly to digital signal processing for encoding and decoding video and image signals, and achieves high compression efficiency.

[0237] Some of the decisions described in this specification improve compression efficiency by signaling a secondary transform index when the available choices include at least one option other than bypassing the secondary transform. The improvement in compression efficiency is achieved both when the CTU is divided into CUs spanning all color channels ("shared encoding tree") and when the CTU is divided into a set of luma CUs and a set of chroma CUs ("separate encoding tree"). In the case of a separate tree, redundant signaling of the secondary transform index is avoided when the secondary transform index cannot be used. In a shared tree, the LFNST index can be signaled even when luma uses transform skip in the primary case of chroma DCT-2. Other arrangements maintain compression efficiency while allowing MTS index signaling to depend on the last significant coefficient position without the additional need to check for zero-valued residual coefficients outside the MTS transform coefficient region of the TB.

[0238] It should be noted that the above only describes some embodiments of the present invention, and modifications and / or changes can be made without departing from the scope and spirit of the present invention, and the embodiments are illustrative and not restrictive.

Claims

1. A method for decoding an encoding unit from a bitstream, wherein the encoding unit is divided from an image encoding tree unit using a tree structure, the encoding unit may have at least a luma component or a plurality of chroma components, the plurality of chroma components include a Cb component and a Cr component, and the method is If the encoding unit has the luma component, a first decoding step of decoding a luma conversion skip flag for the luma component from the bitstream, If the encoding unit has the plurality of chroma components, a second decoding step is to decode a first chroma transformation skip flag for the Cb component and a second chroma transformation skip flag for the Cr component from the bitstream. A determination step for determining whether to decode an index for a specific transformation process from the bitstream to the encoding unit, wherein the kernel to be used in the specific transformation process can be selected from a set of candidate kernels, and the index is an index that identifies the kernel to be used, A third decoding step is performed in which the encoding unit decodes the index for the specific conversion process from the bitstream according to the result of the determination in the determination step, It has, The luma conversion skip flag indicates whether the luma conversion process for the luma component is skipped. The first chroma transformation skip flag indicates whether the first chroma transformation process for the Cb component is skipped. The second chroma transformation skip flag indicates whether the second chroma transformation process for the Cr component is skipped. In the case where the coding tree unit has a size of 128 × 128 and the coding tree structure for the luma component in the coding tree unit is separate from the coding tree structure for the plurality of chroma components in the coding tree unit, (a) the coding tree unit is divided into four regions, each having a size of 64 × 64, common to the luma component and the plurality of chroma components; (b) a dual tree structure for the luma component and a dual tree structure for the plurality of chroma components are started for each of the four regions; and (c) before the determination of whether to decode the index is performed for each of the coding units divided using the dual tree structure for the luma component from a certain region, the determination of whether to decode the index is performed for each of the coding units divided using the dual tree structure for the luma component from a certain region. When the encoding unit is divided from the encoding tree unit using a single-tree structure, and each transformation block in the encoding unit has a significance coefficient only at the DC position, the index for the encoding unit is never decoded from the bitstream. If the luma transformation process, the first chroma transformation process, and the second chroma transformation process are skipped, and the coding unit is split from the coding tree unit using a single-tree structure, then the specific transformation process for the coding unit is never performed regardless of other conditions, the index for the coding unit is not decoded from the bitstream, and the value of the index for the coding unit is estimated to be 0. If the Luma conversion process is skipped and the coding unit is separated from the coding tree unit using the dual tree structure for the Luma component, the index for the coding unit is not decoded from the bitstream, and the value of the index for the coding unit is estimated to be 0. If the first chroma transformation process and the second chroma transformation process are skipped, and the encoding unit is separated from the encoding tree unit using the dual tree structure for the plurality of chroma components, the index for the encoding unit is not decoded from the bitstream, and the value of the index for the encoding unit is estimated to be 0. Ternary partitioning can be used to divide the coding unit in the coding tree unit into multiple coding units. Binary partitioning can be used to divide the encoding unit in the encoding tree unit into multiple encoding units. A method characterized by the following:

2. A method for encoding an encoding unit into a bitstream, wherein the encoding unit is divided from an image encoding tree unit using a tree structure, the encoding unit may have at least a chroma component or a plurality of chroma components, the plurality of chroma components include a Cb component and a Cr component, and the method is If the encoding unit has the luma component, a first encoding step of encoding a luma conversion skip flag for the luma component into the bitstream, If the encoding unit has the plurality of chroma components, a second encoding step of encoding a first chroma conversion skip flag for the Cb component and a second chroma conversion skip flag for the Cr component into the bitstream, A determination step for determining whether to encode an index for a specific transformation process into the bitstream for the encoding unit, wherein the kernel to be used in the specific transformation process can be selected from a set of candidate kernels, and the index is an index that identifies the kernel to be used, A third encoding step in which, according to the result of the determination in the determination step, the encoding unit encodes the index for the specific conversion process into the bitstream, It has, The luma conversion skip flag indicates whether the luma conversion process for the luma component is skipped. The first chroma transformation skip flag indicates whether the first chroma transformation process for the Cb component is skipped. The second chroma transformation skip flag indicates whether the second chroma transformation process for the Cr component is skipped. In the case where the coding tree unit has a size of 128 × 128 and the coding tree structure for the luma component in the coding tree unit is separate from the coding tree structure for the plurality of chroma components in the coding tree unit, (a) the coding tree unit is divided into four regions, each having a size of 64 × 64, common to the luma component and the plurality of chroma components; (b) a dual tree structure for the luma component and a dual tree structure for the plurality of chroma components are started for each of the four regions; and (c) before the determination of whether to encode the index is performed for each of the coding units divided using the dual tree structure for the luma component from a certain region is performed, When the encoding unit is divided from the encoding tree unit using a single-tree structure, and each transformation block in the encoding unit has a significance coefficient only at the DC position, the index for the encoding unit is not always encoded in the bitstream. If the luma transformation process, the first chroma transformation process, and the second chroma transformation process are skipped, and the encoding unit is split from the encoding tree unit using a single tree structure, then the specific transformation process for the encoding unit is never performed regardless of other conditions, the index for the encoding unit is not encoded in the bitstream, and the value of the index for the encoding unit is estimated to be 0. If the Luma conversion process is skipped and the coding unit is separated from the coding tree unit using the dual tree structure for the Luma component, the index for the coding unit is not encoded in the bitstream, and the value of the index for the coding unit is estimated to be 0. If the first chroma transformation process and the second chroma transformation process are skipped, and the encoding unit is separated from the encoding tree unit using the dual tree structure for the plurality of chroma components, the index for the encoding unit is not encoded in the bitstream, and the value of the index for the encoding unit is estimated to be 0. Ternary partitioning can be used to divide the coding unit in the coding tree unit into multiple coding units. Binary partitioning can be used to divide the encoding unit in the encoding tree unit into multiple encoding units. A method characterized by the following:

3. A device for decoding an encoding unit from a bitstream, wherein the encoding unit is divided from an image encoding tree unit using a tree structure, the encoding unit may have at least a luma component or a plurality of chroma components, the plurality of chroma components include a Cb component and a Cr component, and the device, When the encoding unit has the luma component, a first decoding means decodes a luma conversion skip flag for the luma component from the bitstream, When the encoding unit has the plurality of chroma components, a second decoding means decodes a first chroma conversion skip flag for the Cb component and a second chroma conversion skip flag for the Cr component from the bitstream. A determination means for determining whether to decode an index for a specific transformation process from the bitstream to the encoding unit, wherein the kernel to be used in the specific transformation process can be selected from a set of candidate kernels, and the index is an index that identifies the kernel to be used, the determination means, A third decoding means is provided to the encoding unit in accordance with the result of the determination by the determination means, which decodes the index for the specific conversion process from the bitstream. It has, The luma conversion skip flag indicates whether the luma conversion process for the luma component is skipped. The first chroma transformation skip flag indicates whether the first chroma transformation process for the Cb component is skipped. The second chroma transformation skip flag indicates whether the second chroma transformation process for the Cr component is skipped. In the case where the coding tree unit has a size of 128 × 128 and the coding tree structure for the luma component in the coding tree unit is separate from the coding tree structure for the plurality of chroma components in the coding tree unit, (a) the coding tree unit is divided into four regions, each having a size of 64 × 64, common to the luma component and the plurality of chroma components; (b) a dual tree structure for the luma component and a dual tree structure for the plurality of chroma components are started for each of the four regions; and (c) before the determination of whether to decode the index is performed for each of the coding units divided using the dual tree structure for the luma component from a certain region, the determination of whether to decode the index is performed for each of the coding units divided using the dual tree structure for the luma component from a certain region. When the encoding unit is divided from the encoding tree unit using a single-tree structure, and each transformation block in the encoding unit has a significance coefficient only at the DC position, the index for the encoding unit is never decoded from the bitstream. If the luma transformation process, the first chroma transformation process, and the second chroma transformation process are skipped, and the coding unit is split from the coding tree unit using a single-tree structure, then the specific transformation process for the coding unit is never performed regardless of other conditions, the index for the coding unit is not decoded from the bitstream, and the value of the index for the coding unit is estimated to be 0. If the Luma conversion process is skipped and the coding unit is separated from the coding tree unit using the dual tree structure for the Luma component, the index for the coding unit is not decoded from the bitstream, and the value of the index for the coding unit is estimated to be 0. If the first chroma transformation process and the second chroma transformation process are skipped, and the encoding unit is separated from the encoding tree unit using the dual tree structure for the plurality of chroma components, the index for the encoding unit is not decoded from the bitstream, and the value of the index for the encoding unit is estimated to be 0. Ternary partitioning can be used to divide the coding unit in the coding tree unit into multiple coding units. Binary partitioning can be used to divide the encoding unit in the encoding tree unit into multiple encoding units. A device characterized by the following features.

4. An apparatus for encoding encoding units into a bitstream, wherein the encoding units are divided from an image encoding tree unit using a tree structure, the encoding units may have at least a chroma component or a plurality of chroma components, the plurality of chroma components include a Cb component and a Cr component, and the apparatus is A first encoding means that encodes a luma conversion skip flag for the luma component into the bitstream when the encoding unit has the luma component, When the encoding unit has the plurality of chroma components, a second encoding means encodes a first chroma conversion skip flag for the Cb component and a second chroma conversion skip flag for the Cr component into the bitstream. A determination means for determining whether to encode an index for a specific transformation process into the bitstream of the encoding unit, wherein the kernel to be used in the specific transformation process can be selected from a set of candidate kernels, and the index is an index that identifies the kernel to be used; A third encoding means that, according to the result of the determination by the determination means, provides the encoding unit with a third encoding means that encodes the index for the specific conversion process into the bitstream, It has, The luma conversion skip flag indicates whether the luma conversion process for the luma component is skipped. The first chroma transformation skip flag indicates whether the first chroma transformation process for the Cb component is skipped. The second chroma transformation skip flag indicates whether the second chroma transformation process for the Cr component is skipped. In the case where the coding tree unit has a size of 128 × 128 and the coding tree structure for the luma component in the coding tree unit is separate from the coding tree structure for the plurality of chroma components in the coding tree unit, (a) the coding tree unit is divided into four regions, each having a size of 64 × 64, common to the luma component and the plurality of chroma components; (b) a dual tree structure for the luma component and a dual tree structure for the plurality of chroma components are started for each of the four regions; and (c) before the determination of whether to encode the index is performed for each of the coding units divided using the dual tree structure for the luma component from a certain region is performed, When the encoding unit is divided from the encoding tree unit using a single-tree structure, and each transformation block in the encoding unit has a significance coefficient only at the DC position, the index for the encoding unit is not always encoded in the bitstream. If the luma transformation process, the first chroma transformation process, and the second chroma transformation process are skipped, and the encoding unit is split from the encoding tree unit using a single tree structure, then the specific transformation process for the encoding unit is never performed regardless of other conditions, the index for the encoding unit is not encoded in the bitstream, and the value of the index for the encoding unit is estimated to be 0. If the Luma conversion process is skipped and the coding unit is separated from the coding tree unit using the dual tree structure for the Luma component, the index for the coding unit is not encoded in the bitstream, and the value of the index for the coding unit is estimated to be 0. If the first chroma transformation process and the second chroma transformation process are skipped, and the encoding unit is separated from the encoding tree unit using the dual tree structure for the plurality of chroma components, the index for the encoding unit is not encoded in the bitstream, and the value of the index for the encoding unit is estimated to be 0. Ternary partitioning can be used to divide the coding unit in the coding tree unit into multiple coding units. Binary partitioning can be used to divide the encoding unit in the encoding tree unit into multiple encoding units. A device characterized by the following features.

5. A program characterized by causing a computer to perform the method described in claim 1.

6. A program characterized by causing a computer to execute the method described in claim 2.

Images