Method and computing device for video encoding

Abstract

A method for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic coding (CABAC) includes: encoding and decoding a first CBF (tu_cbf_cr) of a Cr chroma (Cr) transform unit using a first context model. Encoding and decoding a second CBF (tu_cbf_cb) of a Cb chroma (Cb) transform unit using a second context model. Encoding and decoding a third CBF (tu_cbf_luma) of a luma transform unit using two context modes.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 816,898, filed on March 11, 2019. The entire disclosure of the foregoing application is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to coding (eg, encoding and decoding) and compression of video data. More specifically, the present disclosure relates to methods and apparatus for improving and / or simplifying the coding and decoding of transform coefficients in video coding. Background Art

[0004] This section provides background information related to the present disclosure. The information contained in this section should not necessarily be construed as prior art.

[0005] Various video codec technologies can be used to compress video data. Video coding is performed in accordance with one or more video codec standards. For example, video codec standards include Versatile Video Codec (VVC), Joint Exploration Test Model Codec (JEM), High Efficiency Video Codec (H.265 / HEVC), Advanced Video Codec (H.264 / AVC), Moving Picture Experts Group Codec (MPEG), etc. Video codecs typically use prediction methods (e.g., inter-frame prediction, intra-frame prediction, etc.), which utilize redundancy in video images or sequences. An important goal of video coding technology is to compress video data into a form that uses a lower bit rate while avoiding or minimizing the degradation of video quality.

[0006] The first version of the HEVC standard was finalized in October 2013, providing approximately 50% bitrate savings or equivalent perceptual quality compared to the previous generation video codec standard H.264 / MPEG AVC. Although the HEVC standard provides significant codec improvements over its predecessor, there is evidence that superior codec efficiency over HEVC can be achieved with additional codec tools. Based on this, both VCEG and MPEG have initiated exploration work on new codec technologies for future video codec standardization. A Joint Video Exploration Team (JVET) was established in October 2015 by ITU-T VECG and ISO / IEC MPEG to begin major research on advanced technologies that can achieve significant improvements in codec efficiency. JVET developed reference software called the Joint Exploration Model (JEM) by integrating several additional codec tools on top of the HEVC Test Model (HM).

[0007] In October 2017, ITU-T and ISO / IEC issued a joint call for proposals (CfP) for video compression with capabilities beyond HEVC. In April 2018, at the 10th JVET meeting, 23 CfP responses were received and evaluated, showing a compression efficiency gain of about 40% over HEVC. Based on such evaluation results, JVET launched a new project to develop a new generation of video codec standards, which was named Versatile Video Codec (VVC). In the same month, a reference software code base called VVC Test Model (VTM) was established to demonstrate a reference implementation of the VVC standard. Summary of the invention

[0008] This section provides a general summary of the disclosure, and is not a comprehensive disclosure of its full scope or all of its features.

[0009] In accordance with a first aspect of the present disclosure, a method for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic codec (CABAC) includes: encoding and decoding a first CBF of a Cr chroma (Cr) transform unit (tu_cbf_cr) using a first context model; encoding and decoding a second CBF of a Cb chroma (Cb) transform unit (tu_cbf_cb) using a second context model; and encoding and decoding a third CBF of a luminance transform unit (tu_cbf_luma) using two context modes.

[0010] In accordance with a second aspect of the present disclosure, a method for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic codec (CABAC) includes: encoding and decoding a first CBF of a luminance transform unit (tu_cbf_luma) using a first context model; encoding and decoding a second CBF of a Cb transform unit (tu_cbf_cb) using a second context model; and encoding and decoding a third CBF of a Cr transform unit using two context modes, wherein for a current codec unit (CU), two context modes are selected based on the value of the second CBF of the Cb transform unit. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Hereinafter, multiple groups of illustrative, non-limiting embodiments of the present disclosure will be described in conjunction with the accompanying drawings. A person of ordinary skill in the relevant art may implement variations of structure, method, or function based on the examples presented herein, and such variations are all included within the scope of the present disclosure. In the absence of conflicts, the teachings of different embodiments may, but need not, be combined with each other.

[0012] Figure 1An example block-based hybrid video coding system is shown in accordance with an example embodiment, including an example encoder suitable for use with a variety of different video coding and decoding techniques such as a common video coding (VCC) approach;

[0013] Figure 2 An example decoder in accordance with an example embodiment is shown, which is suitable for use with a variety of different video coding and decoding techniques such as a common video coding (VCC) method;

[0014] Figure 3A-3E An example partition type, namely a quad partition ( Figure 3A ), horizontal binary partition ( Figure 3B ), vertical binary partition ( Figure 3C ), horizontal trifurcated division ( Figure 3D ) and vertical trisection ( Figure 3E );

[0015] Figure 4 An example intra mode in VCC is shown;

[0016] Figure 5 shows multiple reference rows in VCC for intra prediction;

[0017] Figure 6A-6C Shown for Fig. 6A The flat rectangular block (W / H=2) shown in FIG. Figure 6B The high rectangular block (W / H=1 / 2) shown in FIG. Figure 6C Reference samples and angular directions for intra prediction of the square block (W=H) shown;

[0018] Figure 7 shows the positions of neighboring reconstructed samples for position-dependent intra prediction combining (PDPC) of a codec block;

[0019] Figure 8A-8C Shown as Fig. 8A The 8x 4 blocks shown, Figure 8B The 4x 8 blocks shown and Figure 8C Short distance intra prediction (SDIP) partitioning of other blocks shown;

[0020] Fig. 9 Sub-block transform modes - Sub-block transform (SBT)-V and SBT-H are shown; and

[0021] Figures 10A-10F A flow chart of a method for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic coding and decoding (CABAC) according to an example embodiment. DETAILED DESCRIPTION

[0022] The terms used in this disclosure are intended to illustrate specific examples rather than to limit the disclosure. As used in this disclosure and the appended claims, the singular forms "a", "an", and "the" also refer to the plural forms unless the context clearly implies otherwise. It should be appreciated that the term "and / or" as used herein refers to any or all possible combinations of one or more associated listed items.

[0023] It should be understood that although the terms "first", "second", "third", etc. may be used herein to describe various information, the information should not be limited by these terms. These terms are merely used to distinguish one type of information from another type of information. For example, without departing from the scope of the present disclosure, the first information may be referred to as the second information; and similarly, the second information may also be referred to as the first information. As used herein, the term "if" may be understood to mean "when..." or "upon..." or "in response to..." depending on the context.

[0024] Throughout this specification, references to "one embodiment," "another embodiment," etc. in the singular or plural indicate that one or more specific features, structures, or characteristics described in connection with the embodiment are included in at least one embodiment of the present disclosure. Thus, the appearances of the singular or plural phrases "in one embodiment," "in one embodiment," "in another embodiment" in different places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments may be combined in any suitable manner.

[0025] The present disclosure generally relates to encoding and decoding (e.g., encoding and decoding) video data. More specifically, the present disclosure relates to methods and apparatus for context-adaptive binary arithmetic coding (CABAC) of block flags (CBF) for improved coding. In various different embodiments, the example methods and apparatus may be applied independently or in conjunction with one or more other example methods and / or apparatus. In conventional methods, context selection for CABAC coding of CBF flags may not be efficient in VVC. For example, the CBF value probability distribution may not depend on the transform depth of a given transform block. Moreover, the CBF value probability distribution may not depend on whether the block is a regular intra-frame block or a SDIP sub-block. Using different contexts according to these conditions may increase implementation costs and potentially involve corresponding probability adaptation.

[0026] Figure 1An example block-based hybrid video coding system is shown in accordance with an example embodiment, including an example encoder 100 suitable for use with a variety of different video coding techniques such as a common video coding (VCC) approach. Figure 1 In the encoder 100, a video frame is divided into a plurality of video blocks for processing. For each given video block, a prediction is formed based on an inter-frame prediction method or an intra-frame prediction method. In inter-frame prediction, one or more prediction values ​​are formed by motion estimation and motion compensation based on pixels from a previously reconstructed frame. In intra-frame prediction, prediction values ​​are formed based on reconstructed pixels in the current frame. Through mode decision, the best prediction value can be selected to predict the current block.

[0027] The prediction residual representing the difference between the current video block and its predicted value is sent to the transform circuit system 102. As used herein, the term "circuitry" includes hardware and software that operates the hardware. The transform circuit system 102 applies a transform, such as a discrete cosine transform (DCT) or a conceptually similar transform, to the residual block, producing a video block including transform coefficient values. Instead of DCT, a wavelet transform, an integer transform, a sub-band transform, a discrete sine transform (DST), or other types of transforms can be used. The transform circuit system 102 applies the transform to the residual block, producing a transform coefficient block. The transform can convert the residual information from the pixel domain to a transform domain such as the frequency domain.

[0028] The resulting transform coefficients are then sent from the transform circuit system 102 to the quantization circuit system 104 for entropy reduction. The quantization circuit system 104 quantizes the transform coefficients to further reduce the bit rate. The quantization process can reduce the bit depth associated with some or all of the coefficients. The degree of quantization can be modified by adjusting the quantization parameters. The quantized coefficients are then fed to the entropy coding and decoding circuit system 106 to generate a compressed video bitstream. The entropy coding and decoding circuit system 106 performs entropy coding and decoding on the quantized transform coefficients. For example, the entropy coding and decoding circuit system 106 can perform context adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), syntax-based context adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding and decoding, or another entropy coding and decoding technique. In the case of context-based entropy coding and decoding, the context can be based on neighboring blocks. After entropy coding and decoding by the entropy coding and decoding circuit system 106, the encoded bitstream can be transmitted to another device (e.g., a video decoder), or archived for later transmission or retrieval. As Figure 1As shown, prediction-related information 110 from the inter-frame prediction circuit system and / or the intra-frame prediction circuit system 112, such as video block partition information, motion vectors, reference picture indexes and intra-frame prediction modes, is also fed through the entropy encoding and decoding circuit system 106 and saved in the compressed video bitstream 114.

[0029] In encoder 100, decoder-related circuitry is also required to reconstruct pixels for prediction purposes. First, the prediction residual is reconstructed by inverse quantization circuitry 116 and inverse transform circuitry 118. The reconstructed prediction residual is combined with block prediction value 120 to generate unfiltered reconstructed pixels for the current video block. Inverse quantization block 116 and inverse transform circuitry 118 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain. In some embodiments, a summer adds the reconstructed residual block to a motion compensated prediction block previously generated by motion compensation circuitry 122 or intra-frame prediction circuitry 112 to generate a reconstructed video block for storage in reference picture memory 111. The reconstructed video block can be used as a reference block by motion estimation circuitry 124 and motion compensation circuitry 122 to inter-code and decode the block in a subsequent video frame.

[0030] In order to improve the coding efficiency and visual quality, an in-loop filter 115 is used. For example, deblocking filters are available in the current versions of AVC and HEVC and VVC. In HEVC, an additional in-loop filter called SAO (sample adaptive offset) is defined to further improve the coding efficiency. In the current version of the VVC standard, another in-loop filter called ALF (adaptive loop filter) is being actively investigated for inclusion in the final standard. These in-loop filter operations are optional. Performing these operations helps to improve coding efficiency and visual quality. As a decision made by the encoder 100, these operations can also be turned off to save computational complexity. It should be noted that intra-frame prediction is usually based on unfiltered reconstructed pixels, while inter-frame prediction is based on filtered reconstructed pixels if these filter options are turned on by the encoder 100.

[0031] Figure 2 An example decoder 200 is shown in accordance with an example embodiment, which is suitable for use with a variety of different video codec techniques such as a common video codec (VCC) method. In an example embodiment, the decoder 200 is similar to a decoder resident in Figure 1 The reconstruction related part in the encoder 100. Figure 2In decoder 200, an incoming video bitstream 201 is first decoded by entropy decoding circuitry 202 to derive quantized coefficient levels and prediction related information. Next, the quantized coefficient levels are processed by inverse quantization circuitry 204 and inverse transform circuitry 206 to obtain a reconstructed prediction residual. Inverse quantization circuitry 204 inverse quantizes, i.e., dequantizes, the quantized transform coefficients provided in the bitstream and decoded by entropy decoding circuitry 202. The inverse quantization process may include using a quantization parameter QPy calculated by decoder 200 for each video block in a video slice to determine a degree of quantization, and similarly determining a degree of inverse quantization that should be applied. Inverse transform circuitry 206 applies an inverse transform, such as an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process, to the transform coefficients to produce a residual block in the pixel domain.

[0032] The block prediction value mechanism that can be implemented in the intra / inter mode selector circuit system 208 includes an intra prediction circuit system 210 and / or a motion compensation circuit system 212, wherein the intra prediction circuit system 210 is configured to perform an intra prediction process and the motion compensation circuit system 212 is configured to perform a motion compensation process based on the decoded prediction information. The unfiltered reconstructed pixel set is obtained by summing the reconstructed prediction residual from the inverse transform circuit system 206 and the prediction output generated by the block prediction value mechanism using a summer 214. With the in-loop filter 216 turned on, a filtering operation is performed on these reconstructed pixels to derive the final reconstructed video for output.

[0033] When the video slice is coded as an intra-coded (I) slice, the intra-prediction circuitry 210 may generate prediction data for the video blocks of the current video slice based on data from previously decoded blocks of the current frame or picture and the signaled intra-prediction mode. When the video frame is coded as an inter-coded (i.e., B, P, or GPB) slice, the motion compensation circuitry 212 generates prediction blocks for the video blocks of the current video slice based on motion vectors and other syntax elements received from the entropy decoding circuitry 202. These prediction blocks may be generated from one of the reference pictures in one of the reference picture lists. The decoder 200 may construct reference frame lists, such as List 0 and List 1, based on reference pictures stored in a reference picture memory using a default construction technique.

[0034] The motion compensation circuitry 212 determines prediction information for video blocks of the current video slice by parsing the motion vectors and other syntax elements, and uses the prediction information to generate a prediction block for the current video block being decoded. For example, the motion compensation circuitry 212 uses some of the received syntax elements to determine a prediction mode (e.g., intra prediction or inter prediction) used to encode or decode video blocks of the video slice, an inter prediction slice type (e.g., a B slice, a P slice, or a GPB slice), construction information for one or more of the reference picture lists for the slice, a motion vector for each inter-coded video block of the slice, an inter prediction state for each inter-coded video block of the slice, and other information for decoding video blocks in the current video slice.

[0035] The motion compensation circuitry 212 may also perform interpolation based on interpolation filters for sub-pixel precision. The motion compensation circuitry 212 may use interpolation filters such as those used by the encoder 100 during encoding of the video block to calculate interpolated values ​​for sub-integer pixels of the reference block. In an example embodiment, the motion compensation circuitry 212 determines the interpolation filters used by the encoder 100 from the received syntax elements and generates prediction blocks using these interpolation filters. The motion compensation circuitry 212 may be configured to perform (alone or in any combination) any or all of the methods described in the present disclosure.

[0036] Refer again Figure 1, spatial prediction and / or temporal prediction can be performed. Spatial prediction (or "intra-frame prediction") uses pixels from samples of already coded adjacent blocks in the same video picture or slice (called reference samples) to predict the current video block. Spatial prediction reduces the spatial redundancy inherent in the video signal. Temporal prediction (also known as "inter-frame prediction" or "motion-compensated prediction") uses reconstructed pixels from already coded video pictures to predict the current video block. Temporal prediction reduces the temporal redundancy inherent in the video signal. The temporal prediction signal for a given CU is usually signaled by one or more motion vectors (MVs), which indicate the amount and direction of motion between the current CU and the temporal reference of the current CU. Furthermore, if multiple reference pictures are supported, a reference picture index is additionally sent, which is used to identify which reference picture in the reference picture library the temporal prediction signal comes from. After spatial and / or temporal prediction, the intra / inter mode decision block 121 in the encoder 100 selects the best prediction mode, for example based on a rate-distortion optimization method. Next, the prediction block is subtracted from the current video block, and the prediction residual is decorrelated using transformation and quantization. The quantized residual coefficients are inverse quantized and inverse transformed to form a reconstructed residual, which is then added back to the prediction block to form a reconstructed signal for the CU. Further in-loop filtering may be applied to the reconstructed CU using a deblocking filter such as, for example, sample adaptive offset (SAO) and adaptive in-loop filter (ALF) before the reconstructed CU is placed in the reference picture buffer 117 and used to encode and decode future video blocks. To form an output video bitstream, the codec mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy codec circuit system 106 to be further compressed and packaged to form a bitstream.

[0037] Figure 3A-3E Five example partition types are shown, namely, quad partition ( Figure 3A ), horizontal binary partition ( Figure 3B ), vertical binary partition ( Figure 3C ), horizontal trifurcated division ( Figure 3D ) and vertical trisection ( Figure 3E ).

[0038] In general, the basic intra prediction scheme applied in VVC remains the same as that of HEVC, except that several modules are further extended and / or improved, such as intra sub-partitioning (ISP) codec mode, extended intra prediction with wide-angle intra direction, position-dependent intra prediction combination (PDPC), and 4-tap intra interpolation. Figure 7The positions of adjacent reconstructed samples of the PDPC for a codec block are shown. The example method as described herein promotes improvements in ISP design in the VVC standard. Below are several codec tools (e.g., tools in intra-frame prediction and transform codecs) included in VVC and closely related to the example method described herein.

[0039] Intra prediction mode with wide-angle intra orientation

[0040] Figure 4 The figure shows the intra mode as defined in the VCC standard. Like HEVC, VVC predicts the samples of the CU using a previously decoded set of samples adjacent to the current CU (i.e., above the current CU or to the left of the current CU). However, in order to capture the finer edge directions present in natural video (especially for high resolution, such as 4K video content), the number of angular intra modes is expanded from 33 angular intra modes in HEVC to 93 angular intra modes in VVC. In addition to the angular direction, the same planar mode (which assumes a gradually changing surface with horizontal and vertical slopes derived from the boundary) and DC mode (which assumes a flat surface) of HEVC are also applied in the VVC standard.

[0041] Similar to intra prediction in HEVC, all intra modes in VVC (i.e., planar, DC, and angular) use the set of neighboring reconstructed samples above and to the left of the predicted block as reference for intra prediction. However, unlike with only the nearest row / column of reconstructed samples (i.e., Figure 5 Unlike HEVC, which uses row 0 in VVC as a reference, multiple reference lines (MRL) are introduced in VVC, where two additional rows / columns (i.e. Figure 5 The first and third rows in the reference block are used for intra prediction. The index of the selected reference row / column is signaled from the encoder 100 to the decoder 200. When non-nearest row / column is selected, planar mode and DC mode are excluded from the set of intra modes that can be used to predict the current block.

[0042] Figure 5 The figure shows multiple reference rows for intra prediction in VCC. Figure 5 Unlike HEVC, which uses row 0 in VVC as a reference, multiple reference rows are introduced in VVC, where two additional rows or columns (i.e. Figure 5 The first and third rows in the reference block are used for intra prediction. The index of the selected reference row or column is signaled from the encoder 100 to the decoder 200. When a non-nearest row or column is selected, the planar mode and the DC mode are excluded from the set of intra modes that can be used to predict the current block.

[0043] Figure 6A-6CThe figure shows the location of reference samples used in VCC to derive prediction samples for an intra block. Figure 6A-6C As shown, because a quad / binary / ternary tree partitioning structure is applied, in addition to square codec blocks, rectangular codec blocks also exist for intra prediction of VVC. Since the width and height of a given block are not equal, various different sets of angular directions are selected for different block shapes, which can be called wide-angle intra prediction. More specifically, for both square and rectangular codec blocks, in addition to the plane mode and DC mode, as shown in Table 1, 65 of the 93 angular directions are also supported for each block shape. Such a design not only efficiently captures the directional structure that is commonly present in the video (by adaptively selecting the angular direction based on the block shape), but also ensures that a total of 67 intra modes (i.e., plane, DC, and 65 angular directions) are enabled for each codec block. As a result, while providing a consistent design across different block sizes, good efficiency in signaling intra modes is achieved.

[0044] Table 1 shows the selected angular directions for intra prediction for different block shapes in VCC.

[0045] Table 1 Selected angular directions for intra prediction of different block shapes in VCC

[0046]

[0047] Context-Adaptive Binary Arithmetic Codec (CABAC)

[0048] Context-Adaptive Binary Arithmetic Codec (CABAC) is a form of entropy coding used in the H.264 / MPEG-4 AVC and High Efficiency Video Codec (HEVC) standards and VVC. CABAC is based on arithmetic coding with some improvements and changes to adapt CABAC to the needs of video coding standards. For example, CABAC encodes binary symbols, which keeps the complexity low and allows probabilistic modeling of more frequently used bits of any symbol. The probability model is adaptively selected based on the local context, allowing better modeling of the probability because the codec modes are usually well correlated locally. CABAC also uses multiplication-free range partitioning by using quantized probability ranges and probability states.

[0049] CABAC has multiple probability models for different contexts. It first converts all non-binary symbols into binary. Then, for each binary bit (or bit), the codec chooses which probability model to use and then optimizes the probability estimate using information from nearby elements. Finally, arithmetic coding is applied to compress the data.

[0050] Context modeling provides an estimate of the conditional probability of coded or decoded symbols. With an appropriate context model, a given inter-symbol redundancy can be exploited by switching between different probability models according to the already coded or decoded symbols in the neighborhood of the current symbol to be coded.

[0051] Encoding and decoding data symbols involves the following stages:

[0052] Binarization: CABAC uses binary arithmetic coding, which means that only binary decisions (1 or 0) are encoded. Symbols with non-binary values ​​(such as transform coefficients or motion vectors) are "binarized" or converted into binary codes before arithmetic coding. This process is similar to the process of converting data symbols into variable-length codes, but the binary codes are further encoded (by the arithmetic codec) before transmission;

[0053] The stages are repeated for each binary digit (or "bit") of the binarized symbol;

[0054] Context model selection: A "context model" is a probabilistic model for one or more binary bits of a binarized symbol. The model can be selected from available model selections based on statistics of recently encoded or decoded data symbols. The context model stores the probability of each binary bit being "1" or "0";

[0055] Arithmetic coding: The arithmetic codec encodes each binary bit according to the chosen probability model. Note that there are only two sub-ranges for each binary bit (corresponding to "0" and "1"); and

[0056] Probability update: Update the selected context model based on the actual decoded value (e.g., if the binary bit value is "1", increase the frequency count of "1").

[0057] Intra-frame sub-division coding and decoding mode

[0058] Intra mode can generate intra prediction samples of a block using only reconstructed samples adjacent to a codec block. Based on such a method, the spatial correlation between the predicted sample and the reference sample is roughly proportional to the distance between the predicted sample and the reference sample. Therefore, samples in the internal part (especially samples located in the lower right corner of the block) may have worse prediction quality than samples near the block boundary. In order to further improve the efficiency of intra prediction, short distance intra prediction (SDIP) was proposed a long time ago and was fully studied during the development period of the HEVC standard. This method divides an intra codec block horizontally or vertically into multiple sub-blocks for prediction. Typically, a square block is divided into four sub-blocks. For example, an 8x8 block can be divided into four 2x8 sub-blocks or four 8x2 sub-blocks. An example of such sub-block-based intra prediction is called row-based prediction, in which the block is divided into 1-D rows / columns for prediction. For example, a W×H (width×height) block can be split into H sub-blocks of size W×1 or into W sub-blocks of size 1×H for intra prediction. Each of the resulting rows / columns is processed in the same manner as a normal two-dimensional (2-D) block (e.g. Figure 1 2 (shown), i.e., it is predicted by the available intra mode, and the prediction error is decorrelated based on transformation and quantization and sent to the decoder 200 for reconstruction. Therefore, the reconstructed samples in one sub-block (e.g., row / column) can be used as a reference to predict the samples in the next sub-block. The above process is repeated until all sub-blocks in the current block are predicted and coded. In addition, in order to reduce signaling overhead, all sub-blocks in one coded block share the same intra mode.

[0059] In the case of SDIP, different sub-block partitions can provide different codec efficiencies. Generally, row-based prediction provides the best codec efficiency because it provides the "shortest prediction distance" among different partitions. On the other hand, it also has the worst encoding / decoding throughput problem for codec hardware implementation. For example, consider a block with 4×4 sub-blocks versus the same block with 4×1 or 1×4 sub-blocks, the latter case is only a quarter of the throughput of the former case. In HEVC, the minimum intra-frame prediction block size for luma is 4×4.

[0060] A video codec tool called sub-partition prediction (ISP) is introduced into VVC. Conceptually, ISP is very similar to SDIP. More specifically, depending on the block size, ISP divides the current codec block into 2 or 4 sub-blocks in the horizontal or vertical direction, and each sub-block contains at least 16 samples. Figure 8A-8C The figure shows possible partitioning scenarios for different codec block sizes. In addition, the following main aspects are also included in the current ISP design to handle its interaction with other codec tools in VVC:

[0061] Interaction with wide-angle intra direction: ISP is combined with wide-angle intra direction. In one exemplary design, the block size (i.e., width / height ratio) used to determine whether the normal intra direction or its corresponding wide-angle intra direction should be applied is the original codec block, i.e., the block before sub-block partitioning;

[0062] Interaction with multiple reference lines: ISP cannot be enabled jointly with multiple reference lines. More specifically, in the current VVC signaling design, the ISP enable / disable flag is signaled after the MRL index. When an intra block has a non-zero MRL index (i.e., referring to a non-nearest neighbor sample), the ISP enable / disable flag is not signaled but inferred to be 0, i.e., in this case, ISP is automatically disabled for the codec block;

[0063] Interaction with Most Probable Mode: Similar to normal intra mode, the intra mode for an ISP block is signaled through the Most Probable Mode (MPM) mechanism. However, compared with normal intra mode, the following modifications are made to the MPM method for ISP: (1) Each ISP block only enables intra modes included in the MPM list and disables all other intra modes not in the MPM list; (2) For each ISP block, the MPM list excludes DC mode and prioritizes horizontal intra mode and vertical mode for ISP horizontal partition and ISP vertical partition, respectively;

[0064] At least one non-zero Codec Block Flag (CBF): In VVC, a CBF flag is signaled for each transform unit (TU) to specify that the transform block contains one or more transform coefficient levels not equal to 0. Given a certain block using ISP, the decoder will assume that at least one of the subpartitions has a non-zero CBF. For this reason, if n is the number of subpartitions and the first n-1 subpartitions have yielded zero CBFs, the CBF of the nth subpartition will be inferred to be 1. Therefore, there is no need to transmit and decode it; and

[0065] Interaction with Multiple Transform Selection (MTS): ISP and MTS are applied exclusively, that is, when a codec block uses ISP, its MTS flag is not signaled but always inferred to be 0, i.e. disabled. However, instead of always using DCT-II transform, a fixed set of core transforms (including DST-VII and DCT-II) are implicitly applied to ISP-coded blocks based on the block size. More specifically, assuming W is the width of an ISP sub-partition and H is the height of an ISP sub-partition, its horizontal transform and vertical transform are selected according to the following rules as described in Table 2.

[0066] Table 2

[0067] Select the horizontal and vertical transforms for the ISP block

[0068]

[0069] Sub-block transform for inter-blocks

[0070] For inter-predicted CUs with CBF (cu_cbf) equal to 1, a CU sub-block transform flag (cu_sbt_flag) can be signaled to indicate whether to decode the entire residual block or a sub-part of the residual block, and this codec mode is called sub-block transform (SBT). When SBT is used for inter CUs, SBT type and SBT position information are further decoded from the bitstream.

[0071] In SBT-H and SBT-V, position-dependent transforms are applied to luma transform blocks (chroma TBs always use DCT-2). The two positions, SBT-H and SBT-V, are associated with different core transforms. More specifically, Fig. 9 The horizontal and vertical transforms for each SBT position are specified in . For example, the horizontal and vertical transforms for SBT-V position 0 are DCT-8 and DST-7, respectively. When a side of the residual TU is greater than 32, the corresponding transform is set to DCT-2. Therefore, the sub-block transform jointly specifies the TU tiling, CBF, and horizontal and vertical transforms of the residual block, which can be considered as a syntactic shortcut for the case where the main residual of a block is on one side of the block.

[0072] CBF codec for transform blocks in VVC

[0073] In VVC, a coded block flag (CBF) is signaled for each transform block (e.g., a luma transform block or a chroma transform block) to indicate whether there are coefficients in the transform block. The CBF flag can also be used for blocks that are coded as transform skip mode. For blocks coded in transform skip mode, the CBF flag is used to indicate whether the block contains a non-zero residual. More specifically, a CBF (tu_cbf_luma) equal to 1 for a luma transform block specifies that the luma transform block contains one or more transform coefficient levels that are not equal to 0. It should be noted that when tu_cbf_luma does not exist in the current CU, its value is inferred as follows: If the intra-prediction sub-partition partition type is

[0074] (IntraSubPartitionSplitType) is equal to ISP_NO_SPLIT (indicating that it is non-ISP mode), then tu_cbf_luma is inferred to be equal to 0; otherwise, tu_cbf_luma is inferred to be equal to 1.

[0075] The CBF (tu_cbf_cb) for a Cb chroma (Cb) transform block equal to 1 specifies that the Cb transform block contains one or more transform coefficient levels not equal to 0. When tu_cbf_cb is not present in the current CU, its value is inferred to be equal to 0.

[0076] The CBF (tu_cbf_cr) for a Cr chroma (Cr) transform block equal to 1 specifies that the Cr transform block contains one or more transform coefficient levels not equal to 0. When tu_cbf_cr is not present in the current CU, its value is inferred to be equal to 0.

[0077] Derivation process of ctxInc for syntax element tu_cbf_luma

[0078] There are four CABAC contexts that can be used to encode and decode the CBF (tu_cbf_luma) of the luma transform unit. The process of determining the context index (ctxInc) is described below. The transform block depth (trDepth) variable specifies whether the current transform block is smaller than the current CU.

[0079] If IntraSubPartitionSplitType is equal to ISP_NO_SPLIT or the current block is not a luma block, the following applies:

[0080] ctxInc=(trDepth==0)? 1:0

[0081] Otherwise (IntraSubPartitionSplitType is not equal to ISP_NO_SPLIT and the current transform block is a luma block), the following applies:

[0082] The CBF (prevTuCbfY) variable of the previous luminance transform unit is derived as follows:

[0083] If the current transform unit is the first transform unit to be parsed in the codec unit, set prevTuCbfY equal to 0; otherwise, set prevTuCbfY equal to the value of tu_cbf_luma of the previous luma transform unit in the current codec unit.

[0084] The context index (ctxInc) variable of the luma transform unit is derived as follows:

[0085] ctxInc=2+prevTuCbfY。

[0086] Derivation process of ctxInc for syntax element tu_cbf_cb

[0087] There are two CABAC contexts that can be used to encode and decode the CBF (tu_cbf_cb) of the Cb chroma (Cb) transform unit. The process of determining the context index (ctxInc) of tu_cbf_cb is:

[0088] ctxInc=(trDepth==0)? 0:1.

[0089] Derivation process of ctxInc for syntax element tu_cbf_cr

[0090] There are two CABAC contexts that can be used to encode and decode the CBF (tu_cbf_cr) of the Cr chroma (Cr) transform unit. The process of determining the context index (ctxInc) of tu_cbf_cr is:

[0091] ctxInc = the value of tu_cbf_cb of the corresponding Cb transform unit in the current coding unit.

[0092] Context model independent of trDepth

[0093] In VVC, trDepth can only take the values ​​0 and 1. Because the maximum transform size is equal to 64x64 and the maximum CTU size is 128x128, the depth resulting from implicit partitioning cannot exceed 1. Moreover, trDepth is set to 1 for ISP-coded blocks or when sub-block transform (SBT) is enabled. In example embodiments, context selection for CABAC codec for CBF flag does not depend on trDepth. In other example embodiments, there is only one context for CABAC codec for CBF flag (e.g., tu_cbf_cb) for Cb component.

[0094] In another example embodiment, there are only two contexts for CABAC encoding of the CBF flag for the luma component (e.g., tu_cbf_luma), and the selection depends on the variable prevTuCbfY. The context index (ctxInc) is derived as follows:

[0095] If IntraSubpartitionSplitType is equal to ISP_NO_SPLIT (ie, non-ISP mode) or the current block is not a luminance block, ctxInc is set to 1; otherwise (IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT (ie, ISP mode) and the current transform block is a luminance block), the following applies:

[0096] Export the variable prevTuCbfY as follows:

[0097] If the current transform unit is the first transform unit to be parsed in the codec unit, set prevTuCbfY equal to 0; otherwise, set prevTuCbfY equal to the value of tu_cbf_luma of the previous luma transform unit in the current codec unit. The variable ctxInc of tu_cbf_luma is derived as follows:

[0098] ctxInc=prevTuCbfY。

[0099] In another example, there are only two contexts for CABAC encoding of the CBF flag for the luma component (e.g., tu_cbf_luma), and the selection depends on the variable prevTuCbfY. The variable prevTuCbfY is derived as follows:

[0100] If IntraSubpartitionSplitType is equal to ISP_NO_SPLIT (ie non-ISP mode) or the current block is not a luma block, the following applies:

[0101] Export the variable prevTuCbfY as follows:

[0102] If both tu_cbf_cr and tu_cbf_cb of the corresponding chroma transform block are equal to 1, then

[0103] prevTuCbfY=1,

[0104] Otherwise (the tu_cbf_cr or tu_cbf_cb of the corresponding chroma transform block is equal to 0),

[0105] prevTuCbfY=0.

[0106] The variable ctxInc of tu_cbf_luma is derived as follows:

[0107] ctxInc=prevTuCbfY

[0108] Otherwise (IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT (i.e. ISP mode) and the current transform block is a luma block), the following applies:

[0109] Export the variable prevTuCbfY as follows:

[0110] If the current transform unit is the first transform unit to be parsed in the codec unit, set prevTuCbfY equal to 0; otherwise, set prevTuCbfY equal to the value of tu_cbf_luma of the previous luma transform unit in the current codec unit.

[0111] The variable ctxInc of tu_cbf_luma is exported as follows:

[0112] ctxInc=prevTuCbfY。

[0113] Context model independent of ISP mode

[0114] In VVC, when the current block is encoded in ISP mode and the context selection is based on the variable prevTuCbfY as described in the previous section, the context modes with indices equal to 3 and 4 are used to encode tu_cbf_luma. However, the additional context may not be efficient and can therefore be removed. In another example embodiment, only two contexts are used for CABAC encoding and decoding of the CBF flag for the luma component (i.e., tu_cbf_luma), and the selection depends on the variable trDepth. The variable trDepth is derived as follows:

[0115] If IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT, then

[0116] trDepth=1

[0117] Otherwise, if the transform block size is smaller than the current CU size (e.g., SBT is used or four 64x64 transform blocks are implicitly used for a 128x128 CU),

[0118] trDepth=1,

[0119] otherwise,

[0120] trDepth=0

[0121] The variable ctxInc of tu_cbf_luma is derived as follows:

[0122] ctxInc=trDepth.

[0123] Transform size dependent context model for CBF coding

[0124] According to another exemplary embodiment, the size of the transform block is used to determine the context model for CABAC encoding and decoding of the CBF flag. For example, when the current transform block is greater than or equal to a predefined size, one context model is selected; otherwise, another context model is selected.

[0125] Prediction mode dependent context model for CBF encoding and decoding

[0126] According to another example embodiment, the prediction mode information of the codec is used to determine the context model of the CABAC codec for the CBF flag. For example, when the current transform block belongs to the CU of the inter-frame codec, a context model is selected; otherwise, another context model is selected. In a specific example embodiment, the mode information may further include, for example, an affine mode or an AMVP mode.

[0127] Significantly simplified context model design for CBF encoding and decoding

[0128] According to another example embodiment, the CBF flags of the luma blocks are all coded and decoded using one CABAC context. The CBF flags of the Cb blocks are also all coded and decoded using another CABAC context. The CBF flags of the Cr blocks are coded and decoded using two contexts, which are selected according to the value of the corresponding CBF for the Cb block of the given CU. More specifically, the following describes the selection of context models for CABAC coding and decoding of the CBF flags of the luma transform blocks, Cb transform blocks, and Cr transform blocks.

[0129] Derivation process of ctxInc for syntax element tu_cbf_luma

[0130] Only one CABAC context is used to encode and decode tu_cbf_luma, and therefore no process for context model selection is required.

[0131] Derivation process of ctxInc for syntax element tu_cbf_cb

[0132] Only one CABAC context is used to encode and decode tu_cbf_cb, and therefore no process for context model selection is required.

[0133] Derivation process of ctxInc for syntax element tu_cbf_cr

[0134] There are two CABAC contexts that can be used to encode and decode tu_cbf_cr, and the process of determining the context index (ctxInc) of tu_cbf_luma is as follows:

[0135] ctxInc = the value of tu_cbf_cb of the corresponding Cb transform unit in the current coding unit.

[0136] Design of replaceable context model for CBF encoding and decoding of VVC

[0137] In VVC, trDepth can only take the values ​​0 and 1; therefore, it is possible to use the value of trDepth to directly select the context without any comparison operations. As explained in the section "CBF Codec for Transform Blocks in VVC" above, some context selections in the CBF codec in VVC require comparison operations. For example, in determining the context model index for the luma CBF, the following operations are defined:

[0138] ctxInc=(trDepth==0)? 1:0.

[0139] With a slight modification to the CBF context model design, such comparison operations can be avoided. More specifically, the initial brightness CBF CABAC context model index 0 and index 1 can simply be switched together with the corresponding initialization probability settings.

[0140] In summary, in this example embodiment, when there is only one CABAC context, the selection of the context model for CABAC encoding and decoding of the CBF flag may not be necessary. In the case of two CABAC contexts, a selection can still be made without any comparison operation, because trDepth can only take the values ​​0 and 1, and the value of trDepth can be directly used to select the context.

[0141] According to another example, CABAC context selection is determined based on the following conditions and process.

[0142] Derivation process of ctxInc for syntax element tu_cbf_luma

[0143] There are four CABAC contexts that can be used to encode and decode tu_cbf_luma. If IntraSubpartitionSplitType is equal to ISP_NO_SPLIT or the current block is not a luma block, the following applies:

[0144] ctxInc=trDepth,

[0145] Otherwise (ie, IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT and the current transform block is a luma block), the following applies:

[0146] Export the variable prevTuCbfY as follows:

[0147] If the current transform unit is the first transform unit to be parsed in the codec unit, set prevTuCbfY equal to 0; otherwise, set prevTuCbfY equal to the value of tu_cbf_luma of the previous luma transform unit in the current codec unit.

[0148] The variable ctxInc of tu_cbf_luma is exported as follows:

[0149] ctxInc=2+prevTuCbfY。

[0150] Derivation process of ctxInc for syntax element tu_cbf_cb

[0151] There are two CABAC contexts that can be used to encode and decode tu_cbf_cb. The process of determining the context index (ctxInc) of tu_cbf_cb is:

[0152] ctxInc=trDepth.

[0153] Derivation process of ctxInc for syntax element tu_cbf_cr

[0154] There are two CABAC contexts that can be used to encode and decode tu_cbf_cr. The process of determining the context index (ctxInc) of tu_cbf_cr is:

[0155] ctxInc = the value of tu_cbf_cb of the corresponding Cb transform unit in the current coding unit.

[0156] Figures 10A-10E Flowchart of a method 300 for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic coding and decoding (CABAC) according to an example embodiment. Figures 10A-10F The method 300 shown in Figure 1 The encoder 100 and / or Figure 2 However, in other examples, other devices may be configured to perform Figures 10A-10E The method 300 is shown in FIG.

[0157] In an example embodiment, a first context model is utilized 302 to encode and decode a first CBF (tu_cbf_cr) of a first chroma transform unit, such as a Cr chroma (Cr) transform unit. A second context model is utilized 304 to encode and decode a second CBF (tu_cbf_cb) of a second chroma transform unit, such as a Cb chroma (Cb) transform unit. Two context modes are also utilized 306 to encode and decode a third CBF (tu_cbf_luma) of a luma transform unit. For example, two contexts may be used for tu_cbf_cb, and the selection of these contexts is derived by the BDPCM mode flag: intra_bdpcm_chroma_flag? 1:0. Three contexts are used for tu_cbf_cr, and the selection of these contexts is derived by the BDPCM mode flag and the value of tu_cbf_cb: intra_bdpcm_chroma_flag? 2:tu_cbf_cb[][]. Four contexts are used for tu_cbf_luma, and the selection of these contexts is derived by the BDPCM mode flag, the ISP flag and the variable prevTuCbfY. The context index ctxInc for tu_cbf_luma is derived as follows:

[0158] 1) If BdpcmFlag[x0][y0][0] is equal to 1, set ctxInc equal to 1.

[0159] 2) Otherwise, if IntraSubpartitionsSplitType is equal to ISP_NO_SPLIT, set ctxInc equal to 0.

[0160] 3) Otherwise (BdpcmFlag[x0][y0][0] is equal to 0 and IntraSubpartitionsSplitType is not equal to ISP_NO_SPLIT), the following applies:

[0161] - Export the variable prevTuCbfY as follows:

[0162] - If the current transform unit is the first transform unit to be parsed in the codec unit, set prevTuCbfY equal to 0.

[0163] - Otherwise, set prevTuCbfY equal to the value of tu_cbf_luma of the previous luma transform unit in the current codec unit.

[0164] - Export the variable ctxInc as follows:

[0165] -ctxInc=2+prevTuCbfY

[0166] Further references Fig. 10A , in a specific example embodiment, the context model is independent of the transform depth (trDepth). For example, encoding and decoding the third CBF of the luma transform unit using 306 two context modes may depend on a variable (prevTuCbfY) for the CBF of the previous luma transform unit. In this specific embodiment, the method 300 further includes: deriving 308 a context index (ctxInc) for the luma transform unit (tu_cbf_luma). When IntraSubpartitionSplitType is equal to ISP_NO_SPLIT (meaning it is in non-ISP mode), setting 310 the context index to the first context index of the first context mode of the two context modes. In some example embodiments, the context index is set 310 equal to 1. When IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT, encoding and decoding the third CBF of the luma transform unit using 306 two context modes includes: deriving 312 a variable prevTuCbfY. In an example embodiment, deriving 312 the variable prevTuCbfY includes setting 314 prevTuCbfY equal to 0 when the current transform unit is the first transform unit to be parsed in the current codec unit, or setting 316 prevTuCbfY equal to the value of the CBF (tu_cbf_luma) of the luma transform unit of the previous luma transform unit in the current codec unit. In this particular embodiment, the context index (ctxInc) for the luma transform unit is derived by setting 318 the context index (ctxInc) for the luma transform unit equal to a second context index of a second context mode of the two context modes, wherein the second context index is derived from prevTuCbfY. In some example embodiments, the context index is set 318 equal to prevTuCbfY.

[0167] Further references Fig. 10BIn another example embodiment, encoding and decoding the third CBF of the luma transform unit using 306 the two context modes depends on a prevTuCbfY variable. In this particular embodiment, the method 300 includes deriving 320 a prevTuCbfY variable. When IntraSubpartitionSplitType is equal to ISP_NO_SPLIT and both the first CBF of the Cr transform unit (tu_cbf_cr) and the second CBF of the Cb transform unit (tu_cbf_cb) of the corresponding chroma transform unit are equal to 1, the prevTuCbfY variable is set 322 to be equal to 1. Alternatively, when at least one of the first CBF of the Cr transform unit (tu_cbf_cr) or the second CBF of the Cb transform unit (tu_cbf_cb) of the corresponding chroma transform unit is equal to 0, the prevTuCbfY variable is set 324 to be equal to 0. In this embodiment, deriving the context index (ctxInc) for the luma transform unit includes setting 326 the context index (ctxInc) for the luma transform unit equal to a first context index of a first context mode of the two context modes, wherein the first context index is derived by prevTuCbfY.

[0168] like Fig. 10C As shown, in another example embodiment, encoding and decoding the third CBF of the luma transform unit using 306 two context modes depends on the prevTuCbfY variable. In this particular embodiment, the method 300 includes: deriving 330 the prevTuCbfY variable based on one or more conditions, the one or more conditions including whether the IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT. The one or more conditions may include 331 whether the current transform unit is the first transform unit to be parsed in the current codec unit. When the IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT, and when the current transform unit is the first transform unit to be parsed in the current codec unit, the prevTuCbfY variable is set 332 to be equal to 0. Alternatively, the prevTuCbfY variable is set 334 to be equal to the value of the third CBF (tu_cbf_luma) of the luma transform unit of the previous luma transform unit in the current codec unit. In this particular embodiment, the context index (ctxInc) for the luma transform unit is derived by setting 336 the context index (ctxInc) for the luma transform unit equal to a first context index of a first context mode of the two context modes, where the first context index is derived by prevTuCbfY.

[0169] Further references Fig. 10D In another example embodiment, the context model is independent of the ISP mode. In this particular embodiment, the method 300 includes: utilizing 306 two context modes to encode and decode the third CBF of the luminance transform unit depending on the trDepth variable. The method 300 includes: deriving 340 the trDepth variable based on one or more conditions, the one or more conditions including whether the IntraSubpartitionSplitType is equal to ISP_NO_SPLIT. When the IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT, setting 342 trDepth to be equal to 1. Alternatively, when the IntraSubpartitionSplitType is equal to ISP_NO_SPLIT, setting trDepth based on whether the size of the transform unit is smaller than the size of the current encoding and decoding unit 341. For example, when the size of the transform unit is smaller than the size of the current encoding and decoding unit, setting 342 trDepth to be equal to 1, or setting 344 trDepth to be equal to 0. In this particular embodiment, the context index (ctxInc) for the luma transform unit is derived by setting 346 the context index (ctxInc) for the luma transform unit equal to a first context index of a first context mode of the two context modes, where the first context index is derived by trDepth.

[0170] In another example embodiment, the context model depends on the transform size used for CBF coding. In a specific embodiment, when the current transform unit is equal to or greater than a predefined size, a first context model is selected from a plurality of context models, and when the current transform unit is less than the predefined size, another context model is selected from a plurality of context models.

[0171] In yet another example embodiment, the context model depends on the prediction mode used for the CBF codec. In a specific embodiment, when the current transform unit belongs to a codec unit (CU) of inter-frame codec, a first context model is selected from a plurality of context models, and when the current transform unit does not belong to a CU of inter-frame codec, another context model is selected from a plurality of context models.

[0172] In an alternative exemplary embodiment, if Fig. 10EAs shown, an alternative context model design is provided for CBF encoding and decoding of VVC. In this embodiment, encoding and decoding the third CBF of the luma transform unit using 306 two context modes includes: deriving 350 a first context index (ctxInc) for the luma transform unit (tu_cbf_luma) in response to one or more conditions, the one or more conditions including whether IntraSubpartitionSplitType is equal to ISP_NO_SPLIT. When IntraSubpartitionSplitType is equal to ISP_NO_SPLIT, deriving 350 a first context index (ctxInc) for the luma transform unit (tu_cbf_luma) includes: setting 352 the first ctxInc for the luma transform unit to be equal to the first context index of the first context mode of the two context modes, wherein the first context index is derived by trDepth.

[0173] Alternatively, when IntraSubpartitionSplitType is not equal to ISP_NO_SPLIT, a prevTuCbfY variable is derived 354, wherein the prevTuCbfY variable is set 356 to be equal to 0 when the current transform unit is the first transform unit to be parsed in the current codec unit, or the prevTuCbfY variable is set 358 to be equal to the value of the third CBF (tu_cbf_luma) of the luma transform unit of the previous luma transform unit in the current codec unit. In this particular embodiment, a first ctxInc for the luma transform unit is derived 360, wherein the first ctxInc for the luma transform unit is equal to 2+prevTuCbfY variable. Next, a second context index (ctxInc) for the Cb transform unit (tu_cbf_cb) is derived 362. The second ctxInc for the Cb transform unit is equal to trDepth. Next, a third context index (ctxInc) for the Cr transform unit (tu_cbf_cr) is derived 364, wherein the third ctxInc for the Cr transform unit is equal to the value of the second CBF (tu_cbf_cb) of the Cb transform unit of the corresponding Cb transform unit in the current codec unit.

[0174] Further references Fig.10FIn another example embodiment, a significantly simplified context model design for CBF encoding and decoding is provided. In this embodiment, a method 400 for encoding and decoding a coded block flag (CBF) uses context adaptive binary arithmetic coding and decoding (CABAC). The method 400 includes: encoding and decoding a first CBF (tu_cbf_luma) of a luma transform unit using 402 a first context model. Encoding and decoding a second CBF (tu_cbf_cb) of a Cb transform unit using 404 a second context model. Encoding and decoding a third CBF of a Cr transform unit using 406 two context modes, wherein for a current codec unit (CU), the two context modes are selected based on the value of the second CBF of the Cb transform unit. A context index (ctxInc) for a luma transform unit is derived 408. In this embodiment, the context index (ctxInc) for the luma transform unit is set equal to the value of the second CBF (tu_cbf_cb) of the Cb transform unit of the corresponding Cb transform unit in the current codec unit.

[0175] Figures 10A-10F The example method shown in represents an example method for encoding and decoding a coded block flag (CBF) using context-adaptive binary arithmetic coding and decoding (CABAC) according to an example embodiment.

[0176] Example embodiments of the present disclosure may be described in terms of:

[0177] Clause 1. A method for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic codec (CABAC), the method comprising: encoding and decoding a first CBF of a Cr chroma (Cr) transform unit (tu_cbf_cr) using a first context model; encoding and decoding a second CBF of a Cb chroma (Cb) transform unit (tu_cbf_cb) using a second context model; and encoding and decoding a third CBF of a luminance transform unit (tu_cbf_luma) using two context modes.

[0178] Clause 2. The method of Clause 1, wherein encoding and decoding the third CBF of the luminance transform unit (tu_cbf_luma) using two context modes depends on the prevTuCbfY variable, and the method further includes deriving a context index (ctxInc) for the luminance transform unit (tu_cbf_luma), wherein when IntraSubPartitionSplitType is equal to ISP_NO_SPLIT, the context index is set to the first context index of the first context mode of the two context modes.

[0179] Clause 3. The method of Clause 1, wherein encoding and decoding the third CBF of the luminance transform unit (tu_cbf_luma) using two context modes further includes, when IntraSubPartitionSplitType is not equal to ISP_NO_SPLIT, deriving the variable prevTuCbfY includes setting prevTuCbfY to 0 when the current transform unit is the first transform unit to be parsed in the current codec unit; or setting prevTuCbfY to be equal to the value of the CBF of the luminance transform unit (tu_cbf_luma) of the previous luminance transform unit in the current codec unit.

[0180] Clause 4. The method of clause 3, further comprising deriving a context index (ctxInc) for the luma transform unit (tu_cbf_luma) equal to a second context index of a second context mode of the two context modes, wherein the second context index is derived by prevTuCbfY.

[0181] Clause 5. The method of clause 1, wherein encoding and decoding the third CBF of the luma transform unit (tu_cbf_luma) using two context modes depends on the prevTuCbfY variable, and the method further includes deriving the prevTuCbfY variable, wherein when IntraSubPartitionSplitType is equal to ISP_NO_SPLIT and the first CBF of the Cr transform unit (tu_cbf_cr) and the second CBF of the Cb transform unit (tu_cbf_cb) of the corresponding chroma transform unit are both equal to 1, the prevTuCbfY variable is equal to 1, or when at least one of the first CBF of the Cr transform unit (tu_cbf_cr) or the second CBF of the Cb transform unit (tu_cbf_cb) of the corresponding chroma transform unit is equal to 0, the prevTuCbfY variable is equal to 0.

[0182] Clause 6. The method of clause 5, further comprising deriving a context index (ctxInc) for the luma transform unit (tu_cbf_luma) equal to a first context index of a first context mode of the two context modes, wherein the first context index is derived by prevTuCbfY.

[0183] Clause 7. The method of Clause 1, wherein encoding and decoding the third CBF of the luminance transform unit (tu_cbf_luma) using two context modes depends on the prevTuCbfY variable, and the method further includes deriving the prevTuCbfY variable, wherein when IntraSubPartitionSplitType is not equal to ISP_NO_SPLIT, and when the current transform unit is the first transform unit to be parsed in the current codec unit, the prevTuCbfY variable is equal to 0, or the prevTuCbfY variable is equal to the value of the third CBF of the luminance transform unit (tu_cbf_luma) of the previous luminance transform unit in the current codec unit.

[0184] Clause 8. The method of clause 7, further comprising deriving a context index (ctxInc) for a luma transform unit (tu_cbf_luma) equal to a first context index of a first context mode of the two context modes, wherein the first context index is derived by prevTuCbfY.

[0185] Clause 9. The method of clause 1, wherein encoding and decoding the third CBF of the luminance transform unit (tu_cbf_luma) using two context modes depends on the trDepth variable, and the method further includes: deriving the trDepth variable, wherein trDepth is equal to 1 when IntraSubPartitionSplitType is not equal to ISP_NO_SPLIT, or trDepth is equal to 1 when the size of the transform unit is smaller than the size of the current encoding and decoding unit, or trDepth is equal to 0; and deriving the context index (ctxInc) for the luminance transform unit (tu_cbf_luma) equal to the first context index of the first context mode of the two context modes, wherein the first context index is derived by trDepth.

[0186] Clause 10. The method of Clause 1, wherein when the current transform unit is equal to or larger than a predefined size, a first context model is selected from multiple context models, and when the current transform unit is smaller than the predefined size, another context model is selected from multiple context models.

[0187] Clause 11. The method of Clause 1, wherein when the current transform unit belongs to a codec unit (CU) of inter-frame coding, a first context model is selected from multiple context models, and when the current transform unit does not belong to a CU of inter-frame coding, another context model is selected from multiple context models.

[0188] Clause 12. The method of clause 1, wherein encoding and decoding the third CBF of a luminance transform unit (tu_cbf_luma) using two context modes includes: when IntraSubPartitionSplitType is equal to ISP_NO_SPLIT, deriving a first context index (ctxInc) for the luminance transform unit (tu_cbf_luma), wherein the first ctxInc for the luminance transform unit is derived through trDepth; or when IntraSubPartitionSplitType is not equal to ISP_NO_SPLIT, deriving a prevTuCbfY variable, wherein when the current transform unit is the first transform unit to be parsed in the current coding unit, the prevTuCbfY variable is equal to 0, or prevTuCbfY is equal to the value of the third CBF of the luminance transform unit (tu_cbf_luma) of the previous luminance transform unit in the current coding unit, and deriving a first ctxInc for the luminance transform unit, wherein the first ctxInc for the luminance transform unit is equal to 2+prevTuCbfY variable.

[0189] Clause 13. The method of Clause 12 further includes: deriving a second context index (ctxInc) for a Cb transform unit (tu_cbf_cb), wherein the second ctxInc for the Cb transform unit is equal to trDepth; and deriving a third context index (ctxInc) for a Cr transform unit (tu_cbf_cr), wherein the third ctxInc for the Cr transform unit is equal to the value of the second CBF of the Cb transform unit (tu_cbf_cb) of the corresponding Cb transform unit in the current codec unit.

[0190] Clause 14. A method for encoding and decoding a coded block flag (CBF) using context adaptive binary arithmetic codec (CABAC), the method comprising: encoding and decoding a first CBF of a luminance transform unit (tu_cbf_luma) using a first context model; encoding and decoding a second CBF of a Cb transform unit (tu_cbf_cb) using a second context model; and encoding and decoding a third CBF of a Cr transform unit using two context modes, wherein the two context modes are selected for a current codec unit (CU) based on the value of the second CBF of the Cb transform unit.

[0191] Clause 15. The method of clause 14, further comprising: deriving a value of a second CBF of a Cb transform unit (tu_cbf_cb) whose context index (ctxInc) for the luma transform unit is equal to the corresponding Cb transform unit in the current codec unit.

[0192] Clause 16. A computing device comprising: one or more processors; a non-transitory storage device coupled to the one or more processors; and a plurality of programs stored in the non-transitory storage device, which, when executed by the one or more processors, cause the computing device to perform actions as in clauses 1-15.

[0193] Clause 17. A non-transitory computer-readable storage medium storing a plurality of programs for execution by a computing device having one or more processors, wherein the plurality of programs, when executed by the one or more processors, causes the computing device to perform the actions of clauses 1-15.

[0194] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on or transmitted through a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium or a communication medium, wherein the computer-readable storage medium corresponds to a tangible medium such as a data storage medium, and the communication medium includes, for example, any medium that facilitates the transfer of a computer program from one place to another in accordance with a communication protocol. In this way, a computer-readable medium may generally correspond to (1) a non-temporary tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the implementation described in the present application. A computer program product may include a computer-readable medium.

[0195] Further, the above method can be implemented using a device including one or more circuit systems, including an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a controller, a microcontroller, a microprocessor or other electronic components. The device can use these circuit systems in combination with other hardware or software components to perform the methods described above. Each module, submodule, unit or subunit disclosed above can be implemented at least in part using one or more circuit systems.

[0196] Other embodiments of the present invention will be apparent to those skilled in the art in view of the description and practice of the present invention disclosed herein. This application is intended to cover any variation, use or adaptation of the present invention, which follows the general principles of the present invention and includes such deviations from the present disclosure that fall within known or customary practices in the art. It is intended that the description and examples are considered to be merely exemplary, and the true scope and spirit of the present invention are indicated by the following claims.

[0197] It will be appreciated that the present invention is not limited to the exact examples described above and illustrated in the accompanying drawings and that various modifications and variations may be made without departing from the scope thereof. It is intended that the scope of the present invention be limited only by the appended claims.

Claims

1. A method for video encoding, comprising: Divide the current picture into one or more coding units; For a current luma transform block in a current codec in the one or more codecs, determining whether a first variable indicating an intra sub-division ISP split type is equal to ISP_NO_SPLIT; In response to determining that the first variable is equal to ISP_NO_SPLIT, determining a first context index of a first flag for the current luma transform block to be equal to 0 or 1 without determining whether the current luma transform block is smaller than the codec unit, wherein the first flag of the current luma transform block specifies whether the current luma transform block includes one or more transform coefficient levels not equal to 0; and In response to determining that the first variable is not equal to ISP_NO_SPLIT, the first context index is determined based on a second variable.

2. The method according to claim 1, further comprising: In response to determining that the current transform unit is encoded as the first transform unit to be parsed in the current coding unit, the second variable is derived to be equal to 0.

3. The method according to claim 1, further comprising: In response to determining that the current transform unit is encoded as not being the first transform unit to be parsed in the current coding unit, the second variable is derived to be equal to the value of the first flag of the previous luma transform block.

4. The method of claim 1 , wherein determining the first context index based on the second variable comprises: The first context index is derived to be equal to the second variable plus 2.

5. The method according to claim 1, further comprising: A second context index for a second flag of a Cb transform block in the current codec unit is derived, the second flag of the Cb transform block specifying whether the Cb transform block includes one or more transform coefficient levels not equal to zero. 6 . The method of claim 5 , wherein there is only one Context Adaptive Binary Arithmetic Coding and Decoding (CABAC) context available for encoding the second flag of the Cb transform block.

7. The method according to claim 1, further comprising: A third context index for a third flag of a Cr transform block in the current codec unit is derived, the third flag of the Cr transform block specifying whether the Cr transform block includes one or more transform coefficient levels not equal to zero.

8. The method of claim 7, wherein there are two CABAC contexts available for encoding the third flag of the Cr transform block.

9. The method of claim 7, wherein deriving the third context index comprises: The third context index is derived to be equal to a value of a second flag of a Cb transform block in the current coding unit, wherein the second flag of the Cb transform block specifies whether the Cb transform block includes one or more transform coefficient levels not equal to zero.

10. A computing device for video encoding, comprising: one or more processors; a non-transitory storage device coupled to the one or more processors; as well as A plurality of programs stored in a non-transitory storage device, which, when executed by the one or more processors, cause the computing device to perform the steps of the method of any one of claims 1 to 9 to generate a bit stream, and send the bit stream to a decoding device.

11. A non-transitory computer-readable storage medium storing a plurality of programs for execution by a computing device having one or more processors, wherein the plurality of programs, when executed by the one or more processors, causes the computing device to receive a bit stream and perform the steps of the method of any one of claims 1 to 9 according to the bit stream.

12. A computer program product comprising instructions, which, when executed by a processor, cause the processor to implement the steps of the method of any one of claims 1 to 9.

13. A non-transitory computer-readable storage medium storing a bitstream generated by a program that, when executed by a computing device having one or more processors, causes the one or more processors to perform the video encoding method according to any one of claims 1 to 9.

14. A method for storing a bit stream, comprising: Using the video encoding method according to any one of claims 1 to 9 to generate a bit stream; as well as The bitstream is stored on a non-transitory computer-readable storage medium.

Images