Use-case driven context model selection for hybrid video coding tool

By employing use-case-driven context model selection for video coding tools in the VVC standard, separate CABAC contexts are used for block aspect ratios to optimize tool enable flags, addressing algorithmic complexity and maintaining compression efficiency.

JP2025166148APending Publication Date: 2025-11-05FRAUNHOFER GESELLSCHAFT ZUR FORDERUNG DER ANGEWANDTEN FORSCHUNG EV
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2025134717
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2019-03-05
Filing Date
2025-08-13
Publication Date
2025-11-05

AI Technical Summary

Technical Problem

The evolution of video coding methods has resulted in increased algorithmic complexity due to varying block shapes and coding tools, leading to inefficiencies in encoding and decoding processes, particularly in scenarios where certain tools are unnecessarily evaluated or disabled, impacting compression efficiency.

Method used

The implementation of a use-case-driven context model selection for encoding tools like affine linear weighted intra prediction (LWIP) and matrix-based intra prediction (MIP) in the VVC standard, using separate CABAC contexts based on block aspect ratios to optimize tool enable flags transmission, reducing algorithmic complexity while maintaining compression efficiency.

Benefits of technology

This approach allows encoders to select operating points with different algorithmic complexity without losing compression efficiency by using separate CABAC contexts for specific block conditions, thereby optimizing tool flag transmission and reducing bit rate overhead.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025166148000001_ABST
    Figure 2025166148000001_ABST
Patent Text Reader

Abstract

To provide an image or video decoder, encoder, method and non-transitory computer-readable medium that avoid deterioration of compression efficiency.SOLUTION: A decoder 202 for decoding an image is configured to perform, in a device 200, the steps of: receiving a bitstream including coded data representing the image; determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context on the basis of the result of the determination; decoding a flag associated with the block from the bitstream using the selected context; and decoding the block based in part on the flag. Therein the flag indicates whether or not to use a linear weighted intra prediction (LWIP) coding tool in order to decode the block.SELECTED DRAWING: Figure 4
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to the field of picture, image or video encoding / decoding, and more particularly to the encoding of one or more encoding tools, such as affine linear weighted intra prediction (LWIP) or matrix-based intra prediction (MIP) of the versatile video coding VVC standard, using a context or a context mode of a context-adaptive binary arithmetic coding (CABAC) engine. Embodiments relate to the encoding of a flag, such as intra_mip_flag, indicating the applicability of LWIP or MIP of the VVC standard based on a context model selected depending on the aspect ratio of the block of image or video data being processed. [Background technology]

[0002] In state-of-the-art video coding standards such as ITU-T H.265 and MPEG-4 HEVC [1], a picture is divided into fixed square-sized CodingTreeUnits, which can be further subdivided into smaller blocks. The reconstructed signal of such a block is usually a superposition of a prediction signal and a residual signal. The prediction signal is obtained either by extrapolating neighboring samples to the current block (intra-prediction) or by copying filtered or unfiltered representations of samples from one or two reference pictures (inter-prediction). A reference picture is a picture that has already been reconstructed from the bitstream and stored in a picture buffer for reference. The residual signal is obtained by inverse transforming the dequantized transform coefficients read from the bitstream. After the block reconstruction process, an in-loop filter is applied to enhance the signal of the reconstructed block and obtain a reconstructed picture.

[0003] The entropy decoding process, which reads symbols such as transform coefficients, delta QP, intra-prediction modes, and motion vector differences from the bitstream, is performed by a parser that converts the bits read from the bitstream into binary decisions (bins) using a context-adaptive binary arithmetic coding (CABAC) engine. The parser then converts or combines these bins into symbols or syntax elements. The adaptability of the entropy coding process is achieved through the use of CABAC contexts (CCs). Each context represents an adaptive probability model that models the entropy of a particular symbol or set of symbols. The term "adaptation" refers to the constant updating of the model toward the current coding state. Thus, the model adapts to the local statistics of the corresponding symbol. The update step is typically embedded in the arithmetic coding operation. First, the current state of the CC is used to parameterize the arithmetic coding process. Then, as decoded symbols are derived, they are used to update the CC with a given step size relative to the current decoded probabilities.

[0004] Various improvements to the arithmetic coding process have been evaluated and adopted in JEM-Software [2] and the upcoming VVC standard [3]. The arithmetic coding engine has been modified, and the CC initialization and update process has also been improved. The dynamic range of the probability representation and the behavior of the CC update process have been improved. Each CC has an individual two-level update step that controls the strength of the CC's adaptation to the current probability. This improvement helps to customize the CC update process according to the expected CC usage statistics.

[0005] Due to the large number of binary decisions required to transmit syntax elements, and the number of such syntax elements, binary decisions must be grouped using the same CC to reach a practical number or amount of CCs that can be processed by the decoder. Furthermore, the grouping helps the update process to exploit local statistics and improves the stability of the underlying probability model.

[0006] Binary decisions with similar statistical probabilities of belonging to the same syntax element are usually grouped into one CC. An exception to this type of grouping occurs in cases where the binary decisions are likely to have different probabilities that can be predicted from the already decoded symbols in their immediate neighborhood. In this case, the selected CC is predicted from the already decoded symbols in their immediate neighborhood. Such a procedure is usually applied to symbols that are transmitted quite frequently in the bitstream.

[0007] Besides context-controlled arithmetic coding, there is a bypass mode with a fixed probability of 0.5. This bypass mode, built into the arithmetic coder, is a low-complexity mode for high throughput. The bypass mode is widely used, for example, in transform coding. Summary of the Invention [Problem to be solved by the invention]

[0008] The evolution of video coding methods has shown an increasing variety of block shapes and an increasing number of coding tools, resulting in a significant amount of algorithmic complexity in the encoder to find a good coding representation. Therefore, it may be beneficial for the encoder to skip evaluating (i.e., switching off) coding tools in certain contexts to achieve a better complexity vs. compression efficiency trade-off. The use of coding tools for a block is usually conveyed to the decoder by sending a context modeling tool enable flag in the bitstream.

[0009] Ideally, a decoder has minimal constraints on whether tool enable flags, i.e., flags that determine whether a tool, such as a coding mode or a prediction mode, is applied to a particular block, are transmitted in the bitstream. The reason is that disabling a tool in certain cases can have a negative impact on compression performance in some scenarios, even though these scenarios are quite unlikely. Indeed, one of the main reasons for the efficiency of hybrid video codecs is that a wide variety of competing coding tools are always possible, and only one of these tools is selected in a given case.

[0010] For example, allowing tools only for small block sizes, and therefore the constraint on sending tool enable flags, potentially reduces coding efficiency for future applications with very high resolutions that typically involve only a small portion of small blocks.

[0011] On the other hand, sending tool enable flags for all possible cases is inefficient in application scenarios where the fast encoder search strategy does not test the tool for some cases, either because the tool is too expensive in terms of execution time and therefore unlikely to be selected in these cases, or because using the tool in these cases has a fairly small impact on overall coding efficiency. In such settings, not testing the tool in certain cases results in a faster encoder, but at the cost of some reduced coding efficiency. In certain cases, the tool enable flag is sent in the bitstream, but the tool is not used for that case in a given scenario. Therefore, in this scenario, coding efficiency is higher if the encoder search constraint is also expressed by a constraint on sending tool enable flags in the bitstream. [Means for solving the problem]

[0012] From the prior art as described above, there may be a need for improvements or enhancements to the coding of one or more coding tools used to code / decode pictures, images or videos. Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. [Brief explanation of the drawings]

[0013] [Figure 1] 1 shows an apparatus for encoding image or video data according to an embodiment of the present invention; [Figure 2] 1 illustrates an apparatus for decoding encoded image or video data according to an embodiment of the present invention; [Figure 3] FIG. 1 illustrates an apparatus for encoding image or video data according to an embodiment of the present invention, which introduces a separate additional CABAC context for signaling flags for blocks with an aspect ratio greater than 2. [Figure 4] FIG. 4 shows an apparatus for decoding image or video data according to an embodiment of the present invention, which introduces an additional individual CABAC context for flags of blocks with aspect ratios greater than 2, encoded using the apparatus of FIG. [Figure 5] 1 illustrates an example of a computer system in which the units or modules and method steps described in accordance with the present technique may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0014] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings, in which the same or similar elements are assigned the same reference numerals.

[0015] As mentioned above, previous standards only considered the design of how to group binary decisions into context models, reducing the overall entropy relative to the number of context models used. In contrast to this approach, the present invention presents a new design for how to group binary decisions into context models, which takes into account the increasing complexity of the algorithm itself. The present invention adapts the context modeling, for example, by inserting contexts, to align the coding context with a context suitable for turning off specific coding tools. This allows the encoder to select operating points with different algorithmic complexity while avoiding a loss of compression efficiency.

[0016] The technique of the present invention will be explained using the following example. Assume that a probability-modeled binary decision switches between a first tool represented by Algorithm 1 and a second tool represented by Algorithm 2. Here, the second tool is considered to be the baseline tool, and the first tool is considered to be the more specialized tool. According to this assumption, the second tool is more likely to be selected overall than the first tool. As an example, assume that the overall probability that the first tool will be preferred over the second tool is 0.3.

[0017] Now, suppose two application scenarios are given. In the first application, A, there are N cases where both tools are tested and the best performing tool is selected. In the second application, B, for some reason, both tools are tested only for a determined portion of all N cases, and for the remaining cases, only the baseline tool, i.e., the second tool, is selected. For both applications, the decisions for all N cases need to be context-modeled and transmitted in the bitstream. As an example, suppose the number of cases where both tools are tested in application B is equal to N / 2. For the other N / 2 cases, the tool is tested with application A but not with application B.

[0018] When the tool flag is context-coded with a single CC, for the first application, A, the probability of Algorithm 1 has a stable value of 0.3, but for the second application, B, that average probability drops to 0.15, introducing a fixed probability penalty of ±0.15 for all N cases. If the tool is tested with application B, the true probability becomes 0.3 instead of 0.15, and if the tool is not tested with application B, the true probability becomes 0. In other words, for application B, using a single CC, the probability of the actual decision is modeled in a non-optimal way that results in a higher bit rate when transmitted in the bitstream.

[0019] In the approach of the present invention, the drawbacks of such non-optimal modeling of decision probabilities are overcome as follows: Instead of using one probability model for all decisions, two (or more) probability models are used respectively; CABAC contexts are assigned to the same decisions; and for each of the N cases, a selection index is used to select which probability model to use.

[0020] Considering the above example again, the selection index is chosen to distinguish between the determined portion where Algorithm 1 and Algorithm 2 are tested and the remaining portion where only Algorithm 2 is tested with a second application B. In other words, the two different cases are clustered and represented by different values ​​of the selection index.

[0021] When using this selection index with two probability models in Application A, the selection index switches between the two probability models, but several different CCs can still model the tool flag statistics. In both models, the tool represented by Algorithm 1 has a probability of 0.3. This results in modeling equivalent to the original case modeled with only one probability model.

[0022] However, using the aforementioned selection index with the two probability models in the second application B also results in optimal modeling in this case. For a determined portion of all N / 2 cases in which both algorithms are tested, the probability of Algorithm 1 is 0.3, and for the remaining portion in which only baseline Algorithm 2 is tested, the probability of Algorithm 1 is 0.0. Both probabilities are captured in a well-differentiated manner in the two probability models, thus resulting in modeling without modeling penalty and, consequently, a low bit rate when transmitted in the bitstream.

[0023] Therefore, an embodiment of the inventive approach is based on introducing an additional CABAC context for transmitting a tool enable flag. This additional context is applied only if a condition is met; otherwise, the CABAC context is selected as usual. According to one embodiment, the condition may be that the size of the current block belongs to a predetermined subset of block sizes that can be skipped by a fast encoder search strategy but may be beneficial for applications requiring high coding efficiency. According to another embodiment, the condition may be that the aspect ratio of the current block is above a certain value such as 2 that can be skipped by a fast encoder search strategy but may be beneficial for applications requiring high coding efficiency and that may be controlled at the block level rather than the picture or slice level.

[0024] On the other hand, if, due to the probability adaptation of the CABAC context, in an application scenario, the tool is never tested for certain cases defined by the conditions, the signaling overhead for sending the tool flags for these cases is very small, and therefore the coding efficiency is almost as good as if the tool flags were not sent in these cases.

[0025] On the other hand, if the tool is tested by the encoder even in the cases determined by the conditions in different application scenarios due to the probability adaptation of the CABAC context, the coding efficiency for transmitting the tool flag will not be significantly reduced if a separate CABAC context is used for the cases determined by the conditions.

[0026] Therefore, in contrast to state-of-the-art approaches, the assignment of different CABAC contexts as proposed by the present invention is not guided by attempting to model the entire conditional probability distribution of tool flags. Instead, as explained in the above example, the assignment of different CABAC contexts corresponds to different application scenarios of the tool. Here, each application scenario is defined as a specific condition under which the execution of a given tool is in principle possible, but which is never tested by the encoder in a given scenario.

[0027] There are various reasons for excluding each tool and algorithm under certain conditions. Below, several examples of cases determined by the conditions are given, but the present invention is not limited to these examples. First, the excluded algorithms may be too complex for these cases. Second, the algorithms may not be implemented or may even be impossible to implement for these cases, for example, due to hardware or resource limitations. Third, there are scenarios in which the algorithms used for these cases may only slightly improve compression performance. Fourth, using the underlying algorithms for these cases basically always provides very limited compression benefits and is therefore only feasible when maximum compression performance is the goal. Fifth, these cases do not include the core application fields of the respective algorithms, for which the tools were originally designed. Two or more context divisions for tools

[0028] Embodiments of the present invention also incorporate a division of the context into various contexts, each of which corresponds to a different use case scenario of the underlying tool. An embodiment herein may be as follows: The original or traditional tool enable flag is modeled by a single context. According to an embodiment, the inventive approach uses three contexts instead, where the selection index is controlled by, for example, a quantized version of the block region. Here, the selection index may be assigned as follows:

[0029] 0|(block_area>=max_block_area / 4), SelectionIndex=1|(block_area>=max_block_area / 16)AND(block_area <max_block_area / 4)、 2|Otherwise According to another embodiment, the inventive technique uses four contexts or context models for the binarization of the syntax element intra_mip_flag, which represents the Affine Linear Weighted Intra Prediction LWIP or Matrix-Based Intra Prediction MIP of the Generic Video Coding VVC standard. The selection index is controlled by the aspect ratio (width / height or height / width) of the current block: 0 | otherwise, 1|If not, SelectionIndex=2|else 3|If the aspect ratio of the current block is greater than 2

[0030] FIG. 1 illustrates an apparatus 100 for encoding image or video data according to an embodiment of the present invention. The apparatus 100 includes an encoder 102. The encoder 102 receives image or video data 104 and encodes the received image or video data 104 to provide a bitstream 106 representing the encoded image or video data. The encoder 102 includes a CABAC encoder 108. The CABAC encoder 108 receives a binary-valued syntax element 110 associated with a particular data block of the image or video data to be encoded and encodes the binary-valued syntax element into coding bits 112 for the bitstream using a selected context model. The binary-valued syntax element includes a tool flag indicating whether a particular coding tool is employed when encoding the image or video data. A first group of context models for encoding the tool flag is selected for one or more first portions of the particular data block to which the coding tool is always applicable, regardless of the application. A second group of context models for encoding the tool flag is selected for one or more second portions of the particular data block to which the coding tool is applicable or inapplicable, depending on the application. According to an embodiment, as also described below, the CABAC encoder 108 selects the first context model or the second context model for the currently processed portion of the particular data block in response to a selection indicator, the selection indicator having a first value indicating that the currently processed portion of the particular data block is the first portion, and the selection indicator having a second value indicating that the currently processed portion of the particular data block is the second portion.

[0031] FIG. 2 illustrates an apparatus 200 for decoding encoded image or video data according to an embodiment of the present invention. The apparatus 200 includes a decoder 202. The decoder 202 receives a bitstream 106, similar to the bitstream provided by the encoder 102 of FIG. 1. The bitstream 106 includes encoded image or video data, and the decoder 202 decodes the encoded image or video data from the received bitstream to provide decoded image or video data 204. The decoder includes a CABAC decoder 206 that decodes, from the bitstream 106, a binary-valued syntax element 110 associated with a particular data block of the encoded image or video data using a selected context model. The binary-valued syntax element includes a tool flag that indicates whether a particular coding tool is employed when encoding the image or video data. A first group of context models for decoding the tool flag is selected for portions of the particular data block for which the coding tool is always applicable, regardless of the application, and a second group of context models for decoding the tool flag is selected for portions of the particular data block for which the coding tool is applicable or inapplicable, depending on the application. According to an embodiment, as also described below, the CABAC decoder 206 selects the first context model or the second context model for the currently processed portion of the particular data block in response to a selection indicator, the selection indicator having a first value indicating that the currently processed portion of the particular data block is the first portion, and the selection indicator having a second value indicating that the currently processed portion of the particular data block is the second portion.

[0032] According to an embodiment, the group of first context models includes one or various first context models, and the group of second context models includes one or various second context models.

[0033] Combined with original context indexing As mentioned above, in many cases, the tool enable flag is modeled by more than one context model when binary decisions are likely to have different probabilities that can be predicted from adjacent neighboring already decoded symbols. The technique of the present invention can also be applied as a combination of such entropy-driven context selection and the selection index of the present invention. The motivation for such a combination is clear, since the original entropy-driven context indexing may also be appropriate after separation.

[0034] An embodiment in which the context model for a tool flag is selected by both the entropy-driven context selection and the inventive approach is as follows. 0 | The tool is not used in blocks above or to the left of the current block EntropyIndex=1 | The tool is only used in one of the blocks above or to the left of the current block 2 The tool is used in the blocks above and to the left of the current block. SelectionIndex=0|(block_area>=max_block_area / 16), 1|Otherwise CombinedIndex=EntropyIndex+3*SelectionIndex.

[0035] Thus, in this embodiment, a purely entropy-driven context selection would result in three possible context models for a given tool flag, but in combination with the inventive context model selection would result in six possible context models, indexed by the index CombinedIndex.

[0036] Bypass mode encoding enable flag replacement The inventive approach is also applicable to flags that are conventionally coded using bypass mode. In such cases, one or two additional context models are needed to achieve a use case-driven implementation. If only one additional context model is used, the selection indicator distinguishes between using bypass mode to code the unaffected parts of the case and using one context model for all other cases where the tool can be switched on and off.

[0037] When two context models are used, the bypass mode is completely replaced by context-modeled arithmetic coding, and a selection index distinguishes between the two context models. Note that with improved update techniques in the upcoming VVC standard, one context modeling the non-switchable part of the case can be updated with a small update strength to achieve a quasi-stationary model.

[0038] It should also be noted that the additional model modeling the switchable part of the case is certainly used with a very strong update strength to achieve fast adaptation of the context model to either the tool on or tool off probability.

[0039] Alternative Method for Signaling Partial Tool Activation in a Parameter Set The aforementioned partial tool enabling operation can also be signaled in a parameter set signaled in the bitstream for each predetermined portion of one or more frames, for example, for each slice. In this case, context separation is not required because the flags transmitted from the parameter set contain all necessary information. However, a disadvantage of this type of signaling compared to use-case-driven context model selection is that in the former case, the tool can only be fully enabled or disabled only for cases corresponding to the application scenario throughout all portions of the video sequence to which the parameter set applies, while in the latter case, it can also be disabled within any variable portion of the video sequence known to the decoder, which does not need to be determined in advance. The reason is that in the latter case, if a special context model for the tool flag is assigned to all cases in which it is sometimes feasible to disable the tool for a specific application scenario, starting from any sequential encoding, the encoder corresponding to the specific application scenario cannot test the tool for the corresponding cases up to the flexible point of sequential encoding, which involves only a small signaling overhead, compared to a situation in which the tool is completely prohibited for all cases corresponding to the application scenario of this specific portion of the video sequence.

[0040] Applications using any coding tool The context splitting of the present invention can be applied to any coding tool controlled by an enable flag. The current candidate tools that will appear in future VVC standards and can be used with the present technique are listed below. However, the application of the present technique is not limited to these tools. The candidate tools are DMVR, OBMC, BIO, FRUC, LIC, ISP, ALF, SAO, inter or intra MTS, 65-directional intra mode, MRL, and splitting tools such as QTBT, MTT, or QTBT+TT.

[0041] The present approach can also be applied to tools with different configurations represented by index values. Here, the CC allocation of the present invention is determined by the fact that in some application scenarios, only a subset of all configurations of the tool are feasible in specific cases or in general. The CC allocation of the present invention takes these different application scenarios into account by assigning additional CCs to configurations that the tool cannot implement for the scenario. One embodiment of this aspect of the present invention is a tool that applies one of n transforms for the inverse transformation of a prediction residual, and an index of the transform is transmitted in the bitstream.

[0042] Using the inventive approach, many of the tools can be equipped with some context-splitting tools only under certain circumstances. Here, the context splitting according to the present invention is subject to specific cases where certain tools may be infeasible in certain application scenarios. These specific cases depend on the important characteristics of the tools. A list of characteristics that can be evaluated or combined for specific situations, not limited to the use cases of the present invention, is: block size, block shape, block aspect ratio, temporal level, QP, picture type, picture resolution, picture dynamic range, reference picture, and first picture of a GOP. A particular situation may be a combination of these aforementioned characteristics.

[0043] Embodiments of the Application of the Inventive Technique of Context Allocation Affine Linear Weighted Intra Prediction (LWIP) [4] is a new intra prediction technique. Similar to traditional intra prediction, LWIP consists of a set of prediction modes. Given the left and top reconstructed (reference) samples, each signaled prediction mode corresponds to a prediction function that generates a different prediction signal.

[0044] For both conventional and LWIP modes available, the encoder compares the rate-distortion costs of the conventional and LWIP modes and determines the mode with the lowest overall cost. The selected prediction mode is then sent to the decoder in the bitstream and used to select the corresponding prediction function for predicting the block. The syntax for signaling the prediction mode is as follows: First, a flag is sent indicating whether the block is predicted in conventional mode or LWIP mode. If conventional prediction is selected, the conventional prediction mode is read from the bitstream according to the intra prediction signal. Otherwise, if LWIP prediction is selected, the flag is followed by a mode indicator within the set of available LWIP modes. Because both conventional and LWIP modes are available for all block sizes commonly supported by the codec for intra prediction, the flag must be sent for each block.

[0045] The VVC coding standard currently covers the range

number

[0046] The core forecast for LWIP is

number

number

number

[0047] This effect can be used to reduce encoder complexity by restricting LWIP mode to blocks with aspect ratios of 2 or less and not testing it for blocks with higher aspect ratios, although this also reduces coding efficiency somewhat. Not sending a flag for blocks with aspect ratios greater than 2 reduces the loss in coding efficiency, but it also makes it impossible to implement an encoder that improves overall coding efficiency by testing LWIP mode for blocks with aspect ratios greater than 2 that may be required for different applications.

[0048] A solution that supports both high-speed and high-compression-efficiency encoders is to introduce a separate, additional CABAC context for transmitting flags for blocks with aspect ratios greater than 2. Here, if LWIP mode is not tested in the encoder for those blocks, the flag is always 0 (=blocks not predicted in LWIP mode), and transmitting the flag incurs almost no overhead (only to adapt the context to a 0 probability to transmit a 1), which means that the coding efficiency is very close to the solution that does not transmit flags for those blocks. If LWIP blocks are tested in the encoder for those blocks, the flag is 1 with a certain probability (=block predicted in LWIP mode), and transmitting the flag incurs almost no overhead, which means that the coding efficiency is very close to the solution that transmits flags in the same context for all block sizes.

[0049] In other words, as mentioned above, according to an embodiment, the inventive technique uses four contexts or context models for the binarization of the syntax element intra_mip_flag, which represents the affine linear weighted intra prediction LWIP or matrix-based intra prediction MIP of the generic video coding VVC standard. The selection index is controlled by the aspect ratio (width / height or height / width) of the current block: 0 | otherwise 1|If not, SelectionIndex=2|else 3|If the aspect ratio of the current block is greater than 2

[0050] 3 illustrates an apparatus for encoding image or video data according to an embodiment of the present invention, e.g., an apparatus similar to that of FIG. 1, which introduces an additional individual CABAC context for transmitting flags for blocks with aspect ratios greater than 2. An encoder 102 receives image or video data 104 and encodes the received image or video data 104 to provide a bitstream 106 representing the encoded image or video data. A CABAC encoder 108 receives a tool flag 110 indicating whether a particular coding tool, such as affine linear weighted intra prediction (LWIP), is used when encoding a block of image or video data. Affine linear weighted intra prediction (LWIP) is also referred to as matrix-based intra prediction (MIP) in the generic video coding (VVC) standard, and the tool flag is also referred to as intra_mip_flag, which indicates the applicability of affine LWIP or MIP in the VVC standard. For a block 300 of image or video data having an aspect ratio greater than 2 and for which a particular encoding tool is applicable, a first context model for encoding the tool flag is selected from a group of one or more first context models and provided to CABAC 108. For a block 302 of image or video data having an aspect ratio less than or equal to 2 and for which a particular encoding tool is applicable, a second context model for encoding the tool flag is selected from a group of one or more second context models and provided to CABAC 108. For example, if LWIP mode is not tested for a block 300 with an aspect ratio greater than 2, the flag is always 0, and additional CABAC contexts are adapted to have a zero probability of transmitting 1; if LWIP mode is tested for a block 300 with an aspect ratio greater than 2, the flag is 1 with a certain probability. According to an embodiment, CABAC encoder 108 can select the first context model and the second context model for the currently processed block in response to the selection indicator. The selection indicator indicates whether the aspect ratio of the currently processed block is greater than 2 or whether the aspect ratio is less than or equal to 2.

[0051] 4 illustrates an apparatus for decoding image or video data according to an embodiment of the present invention, e.g., an apparatus 100 similar to the apparatus of FIG. 2, that introduces individual additional CABAC contexts for flags of blocks with aspect ratios greater than 2 that were coded using the apparatus of FIG. 3. For blocks 300 of image or video data that have an aspect ratio greater than 2 and for which specific coding tools are applicable, a first context model for coding the tool flags is selected from a group of one or more first context models and provided to CABAC 206. For blocks 302 of image or video data that have an aspect ratio less than or equal to 2 and for which specific coding tools are applicable, a second context model for coding the tool flags is selected from a group of one or more second context models and provided to CABAC 206.

[0052] For example, the binarization of the syntax element intra_mip_flag can use a total of four context models with context indices {0,1,2,3} as follows: If the aspect ratio (width / height or height / width) of the current block is greater than 2, use the context model with index 3;

[0053] Otherwise, one of context models 0, 1, or 2 is used, and the choice may depend, for example, on the intra_mip_flag of the blocks to the left and above the current block, as known and used for some other syntax elements.

[0054] In the VVC specification, the coding unit syntax can be as follows (see, for example, 7.3.10.5 - Coding Unit Syntax in [5]): [Table 1]

[0055] intra_mip_flag[x0][y0] equal to 1 specifies that the intra prediction type of the luma sample is matrix-based intra prediction. intra_mip_flag[x0][y0] equal to 0 specifies that the intra prediction type of the luma sample is not matrix-based intra prediction (see, for example, 7.4.11.5 - Coding Unit Semantics in [5]).

[0056] The binarization of the syntax element intra_mip_flag can be as follows (see, for example, 9.3.4.2 in [5] - derivation process of ctxTable, ctxIdx, and bypassFlag):

[0057] [Table 2]

[0058] Although some aspects of the described concepts are described in the context of an apparatus, it will be apparent that these aspects also represent a description of a corresponding method, with a block or apparatus corresponding to a method step or feature of a method step. Similarly, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus.

[0059] Various elements and features of the present invention may be implemented in hardware using analog and / or digital circuitry, software, through the execution of instructions by one or more general-purpose or special-purpose processors, or as a combination of hardware and software. For example, embodiments of the present invention may be implemented in the environment of a computer system or another processing system. FIG. 5 illustrates an example of a computer system 400. The units or modules, as well as the method steps performed by these units, may be executed on one or more computer systems 400. The computer system 400 includes one or more processors 402, such as a special-purpose or general-purpose digital signal processor. The processors 402 are connected to a communication infrastructure 404, such as a bus or a network. The computer system 400 includes a main memory 406, such as a random access memory (RAM), and a secondary memory 408, such as a hard disk drive and / or a removable storage drive. The secondary memory 408 may allow computer programs or other instructions to be loaded into the computer system 400. The computer system 400 may further include a communication interface 410, which allows software and data to be transferred between the computer system 400 and external devices. The communications may be from electronic, electromagnetic, optical, or other signals that can be processed by the communications interface. The communications may use wire or cable, fiber optics, phone lines, cellular phone links, RF links, and other communications channels 412.

[0060] The terms “computer program medium” and “computer-readable medium” are generally used to refer to tangible storage media, such as a hard disk installed in a removable storage unit or hard disk drive. These computer program products are a means for providing software to computer system 400. Computer programs, also referred to as computer control logic, are stored in main memory 406 and / or secondary memory 408. Computer programs may also be received via communications interface 410. When executed, computer programs enable computer system 400 to implement the present invention. In particular, when executed, computer programs enable processor 402 to perform the processes of the present invention, such as any of the methods described herein. Thus, such computer programs can represent the controller of computer system 400. When the present disclosure is implemented using software, the software can be stored in a computer program product and loaded into computer system 400 using an interface, such as a removable storage drive, communications interface 410, or the like.

[0061] The hardware or software embodiments may be implemented using a digital storage medium, such as cloud storage, floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, or flash memory, having electronically readable control signals stored therein and cooperating (or capable of cooperating) with a programmable computer system to perform the respective methods. Thus, the digital storage medium may be computer readable.

[0062] Some embodiments according to the invention comprise a data carrier having electronically readable control signals which, in cooperation with a programmable computer system, cause one of the methods described herein to be carried out.

[0063] Generally, embodiments of the present invention may be implemented as a computer program product having program code operative to perform one of the methods when the computer program product runs on a computer, The program code may for example be stored on a machine readable carrier.

[0064] Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier. In other words, a method embodiment of the present invention is a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0065] A further embodiment of the inventive method is therefore a data carrier (or digital storage medium or computer readable medium) comprising, and having recorded thereon, the computer program for performing one of the methods described herein. A further embodiment of the inventive method is therefore a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. The data stream or the sequence of signals may for example be arranged to be transferred via a data communication connection, for example the Internet. A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted for performing one of the methods described herein. A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0066] In some embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by any hardware apparatus.

[0067] The above-described embodiments are merely illustrative of the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to others skilled in the art. It is therefore intended to be limited only by the scope of the appended claims, and not by the specific details shown by the description and explanation of the embodiments herein.

[0068] References [1] ISO / IEC, ITU-T. High efficiency video coding. ITU-T Recommendation H.265 | ISO / IEC 23008 10 (HEVC), edition 1, 2013; edition 2, 2014.

[0069] [2] JEM reference software, https: / / jvet.hhi.fraunhofer.de / svn / svn_HMJEMSoftware / .

[0070] [3] B. Bross, J. Chen, Shan Liu, “Versatile Video Coding (Draft 4)”, JVET-M1001-v5, February 2019, Marrakesh, Morocco

[0071] [4] J. Pfaff, B. Stallenberger, M. Schaefer, P. Merkle, P. Helle, R. Rische, H. Schwarz, D. Marpe, T. Wiegand, “Affine Linear Weighted Intra Prediction”, JVET-M0043, February 2019, Marrakesh, Morocco

[0072] [5] B. Bross, J. Chen, Shan Liu, “Versatile Video Coding (Draft 8)”, JVET-Q2001-vD, February 2020, Brussels, Belgium

Claims

1. 1. A decoder for decoding an image, the decoder comprising at least one processor, the processor comprising: receiving a bitstream containing coded data representing the image; determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context based on a result of said determining; decoding, from the bitstream using the selected context, a flag associated with the block, the flag indicating whether a linear weighted intra prediction (LWIP) coding tool is used to decode the block; decoding the block based in part on the flag; a decoder configured to:

2. The processor: selecting a first context in response to determining that the first dimension of the block is greater than twice the second dimension of the block; selecting a second context in response to determining that the first dimension of the block is not greater than twice the second dimension of the block; further configured to: the first context and the second context are different; 2. A decoder according to claim 1.

3. the first dimension of the block is the height of the block and the second dimension is the width of the block; or the first dimension of the block is the width of the block and the second dimension is the height of the block; 2. A decoder according to claim 1.

4. The at least one processor determining, in response to the flag representing a first value, to use the LWIP encoding tool to decode the block; determining not to use the LWIP encoding tool to decode the block in response to the flag indicating a second value different from the first value; further configured to:

2. A decoder according to claim 1.

5. the first value is 1; the second value is 0; 5. A decoder according to claim 4.

6. The at least one processor and after determining to use the LWIP encoding tool to decode the block, decoding a mode index for a set of available LWIP modes.

5. A decoder according to claim 4.

7. The LWIP coding tool supports matrix-based intra prediction; 2. A decoder according to claim 1.

8. 1. A method for decoding an image, the method comprising: receiving a bitstream containing coded data representing the image; determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context based on a result of said determining; decoding, from the bitstream using the selected context, a flag associated with the block, the flag indicating whether a linear weighted intra prediction (LWIP) coding tool is used to decode the block; decoding the block based in part on the flag; A method comprising:

9. selecting a first context in response to determining that the first dimension of the block is greater than twice the second dimension of the block; selecting a second context in response to determining that the first dimension of the block is not greater than twice the second dimension of the block; the first context and the second context are different; The method of claim 8.

10. the first dimension of the block is the height of the block and the second dimension is the width of the block; or the first dimension of the block is the width of the block and the second dimension is the height of the block; The method of claim 8.

11. determining, in response to the flag representing a first value, to use the LWIP encoding tool to decode the block; determining not to use the LWIP encoding tool to decode the block in response to the flag indicating a second value different from the first value; The method of claim 8 further comprising:

12. the first value is 1; the second value is 0; The method of claim 11.

13. decoding a mode index for a set of available LWIP modes after determining to use the LWIP encoding tool to decode the block; The method of claim 11 further comprising:

14. The LWIP coding tool supports matrix-based intra prediction; The method of claim 8.

15. When executed, the program causes at least one processor to: receiving a bitstream containing coded data representing an image; determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context based on a result of said determining; decoding, from the bitstream using the selected context, a flag associated with the block, the flag indicating whether a linear weighted intra prediction (LWIP) coding tool is used to decode the block; decoding the block based in part on the flag; A non-transitory computer-readable medium containing instructions to cause

16. selecting a first context in response to determining that the first dimension of the block is greater than twice the second dimension of the block; selecting a second context in response to determining that the first dimension of the block is not greater than twice the second dimension of the block; the first context and the second context are different; 16. The non-transitory computer-readable medium of claim 15.

17. the first dimension of the block is the height of the block and the second dimension is the width of the block; or the first dimension of the block is the width of the block and the second dimension is the height of the block; 16. The non-transitory computer-readable medium of claim 15.

18. In response to the flag representing a first value, the instructions, when executed, cause the at least one processor to determine to use the LWIP encoding tool to decode the block; In response to the flag indicating a second value different from the first value, the instructions, when executed, cause the at least one processor to determine not to use the LWIP encoding tool to decode the block.

16. The non-transitory computer-readable medium of claim 15.

19. the first value is 1; the second value is 0; 20. The non-transitory computer-readable medium of claim 18.

20. After determining to use the LWIP encoding tool to decode the block, the instructions, when executed, cause the at least one processor to decode a mode index for a set of available LWIP modes.

20. The non-transitory computer-readable medium of claim 18.

21. The LWIP coding tool supports matrix-based intra prediction; 16. The non-transitory computer-readable medium of claim 15.

22. 1. An encoder for encoding an image into a bitstream, the encoder comprising at least one processor, the processor comprising: determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context based on a result of said determining; encoding a flag associated with the block into the bitstream using the selected context, the flag indicating whether a linear weighted intra prediction (LWIP) coding tool is used to decode the block; encoding the block based in part on the flag; an encoder configured to:

23. 1. A method for encoding an image into a bitstream, the method comprising: determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context based on a result of said determining; encoding a flag associated with the block into the bitstream using the selected context, the flag indicating whether a linear weighted intra prediction (LWIP) coding tool is used to decode the block; encoding the block based in part on the flag; A method comprising:

24. When executed, the program causes at least one processor to: determining, for a block of the image, whether a first dimension of the block is greater than twice a second dimension of the block; selecting a context based on a result of said determining; encoding a flag associated with the block into a bitstream using the selected context, the flag indicating whether a linear weighted intra prediction (LWIP) coding tool is used to decode the block; encoding the block based in part on the flag; A non-transitory computer-readable medium containing instructions to cause

Citation Information

Patent Citations

  • Video coding method and device, video decoding method and device

    WO2019009503A1

  • Intra-prediction mode concept for block-wise picture coding

    WO2019185808A1

  • Intra predictions using linear or affine transforms with neighbouring sample reduction

    WO2020127811A2