具体实施方式

现在参考附图更详细地描述本发明的实施例，在附图中，相同或相似的元件具有相同的附图标记。

如上所述，在如何将二进制决策分组到上下文模型中的设计中，以前的标准只考虑了降低整体熵对比(vs.)所使用的上下文模型数量的方面。与该方法相反，根据本发明提出了关于如何将二进制决策分组到上下文模型中的设计的新方面。该方法考虑了算法本身日益增加的复杂性。本发明例如通过插入上下文来调整上下文建模，以将编码上下文与适合于关闭特定编码工具的上下文对齐。这使编码器能够在具有不同算法复杂度的操作点之间进行选择，同时避免压缩效率的恶化。

使用以下示例来说明本发明方法。假设概率建模的二进制决策在算法1表示的第一工具和算法2表示的第二工具之间切换。这里，第二工具被认为是基线工具，而第一工具被认为是更特殊的工具。根据这个假设，总体而言，第二工具比第一工具更有可能被选择。例如，假设第一工具优于第二工具的总概率为0.3。

现在假设给出两个应用场景。在第一应用A中，有N种情况，其中，测试了两个工具并选择了性能最好的一个。在第二应用B中，出于某种原因，仅针对所有N种情况的确定部分测试了两个工具，而对于其余情况，仅选择基线工具，即，第二工具。对于这两个应用，针对所有N种情况的决策都必须进行上下文建模并在比特流中传输。例如，假设两个工具都在应用B中测试的情况数量等于N/2。对于其他N/2种情况，在应用A中测试了工具，但未在应用B中测试工具。

如果工具标志使用单个CC进行上下文编码，则在第一应用A中，算法1的概率具有稳定值0.3，而在第二应用B中，其平均概率下降到0.15，对于所有N种情况引入了固定概率惩罚±0.15：在应用B中测试了工具的情况下，真实概率将为0.3而不是0.15，而未在应用B中测试工具的情况下，真实概率将为0。换言之，在应用B中，使用单个CC，实际决策的概率将以非最佳方式建模，这导致在比特流中传输时产生更高的比特率。

在本发明方法中，以如下方式克服了这种决策概率的非最佳建模的缺点。代替对所有决策使用一个概率模型，两个(或更多个)概率模型或CABAC上下文被分配给相同的决策。使用选择索引来选择针对N种情况中的每一个使用哪个概率模型。

当再次考虑上述示例时，选择索引以这种方式被选择：将在第二应用B中测试算法1和算法2的确定部分与仅测试算法2的剩余部分区分开。换言之，这两种不同的情况被聚集，并由选择索引的不同值来表示。

当在应用A中将该选择指数与两个概率模型一起使用时，尽管选择指数在两个概率模型之间切换，但几个不同的CC仍然可以对工具标志的统计数据进行建模。在这两个模型中，算法1表示的工具的概率为0.3。这导致与原始情况中的等效建模，原始情况仅使用一个概率模型进行建模。

然而，在第二应用B中使用具有两个概率模型的上述选择索引也会导致这种情况的最佳建模。对于测试两种算法的所有N/2种情况的确定部分，算法1的概率为0.3，而对于仅测试基线算法2的其余部分，算法1的概率为0.0。在两个概率模型中以很好区分的方式捕获这两个概率，从而产生没有任何建模惩罚的建模，其导致在比特流中传输时的低比特率。

因此，本发明方法的实施例基于针对发送工具启用标志引入附加CABAC上下文。仅当满足条件时才应用该额外上下文。否则，将照常选择CABAC上下文。根据实施例，条件可以是当前块的大小属于块大小的预定义子集，该条件可能被快速编码器搜索策略跳过，但对于需要高编码效率的应用可能是有益的。根据另一实施例，条件可以是当前块的纵横比高于特定值(例如，2)，该条件可能被快速编码器搜索策略跳过，但对于需要高编码效率并且可以在块级别而不是图片级别或切片级别进行控制的应用可能是有益的。

一方面，由于CABAC上下文的概率自适应，如果在应用场景中从未针对该条件定义的特定情况测试工具，则针对这些情况发送工具标志的信令开销将非常小。因此，对于这些情况，编码效率几乎与不发送工具标志一样好。

另一方面，再次由于CABAC上下文的概率自适应，如果在不同的应用场景中工具也由编码器在该条件确定的情况下进行了测试，则如果针对由该条件确定的情况使用单独的CABAC上下文，用于发送工具标志的编码效率将不会显著降低。

因此，与现有技术方法相比，本发明提出的不同的CABAC上下文的分配不是通过尝试对工具标志的整体条件概率分布进行建模来指导的。相反，如上述示例所述，不同的CABAC上下文的分配对应于工具的不同应用场景。这里，每个应用场景被定义为特定条件，在该条件下，给定工具的执行原则上是可能的，但在给定场景中永远不会被编码器测试。

在特定条件下排除工具或算法可能有不同的原因，并且下面给出由条件确定的情况的一些实施例，但本发明不限于这些实施例。首先，排除的算法对于这些情况可能过于复杂。其次，对于这些情况，例如由于硬件或资源限制，该算法可能无法实现或甚至是不可实现的。第三，在一些场景中，在这些情况下使用的算法可能仅略微提高压缩性能。第四，在这些情况下使用底层算法基本上总是提供非常有限的压缩收益，因此只有在以最大压缩性能为目标时才可行。第五，这些情况不包括算法或工具最初设计用于的核心应用领域。

工具的一个以上上下文拆分

本发明的实施例还结合将上下文拆分为多种上下文，其中，每个附加上下文对应于底层工具的不同用例场景。本说明书的一个实施例可以如下。原始或常规工具启用标志由单个上下文进行建模。根据实施例，本发明方法替代地使用三个上下文，其中，选择索引例如由块区域的量化版本控制。这里，选择索引可能被分配如下：

根据其他实施例，本发明方法使用四个上下文或上下文模型，以用于表示通用视频编码VVC标准的仿射线性加权帧内预测LWIP或基于矩阵的帧内预测MIP的语法元素intra_mip_flag的二值化。选择索引由当前块的纵横比(宽度/高度或高度/宽度)控制：

图1示出了根据本发明的实施例的用于对图像或视频数据进行编码的装置100。装置100包括编码器102。编码器102接收图像或视频数据104，并对所接收到的图像或视频数据104进行编码，以便提供表示编码图像或视频数据的比特流106。编码器102包括CABAC编码器108。CABAC编码器108接收与要编码的图像或视频数据的特定数据块相关联的二进制值语法元素110，并使用选定的上下文模型将二进制值语法元素编码为比特流的编码比特112。二进制值语法元素包括工具标志，该工具标志指示在对图像或视频数据进行编码时是否采用特定编码工具。针对特定数据块中与应用无关、编码工具始终适用的一个或多个第一部分，选择用于对工具标志进行编码的第一上下文模型组。针对特定数据块中取决于应用、编码工具适用或不适用的一个或多个第二部分，选择用于对工具标志进行编码的第二上下文模型组。根据实施例，也如下所述，CABAC编码器108响应于选择索引针对特定数据块的当前处理部分选择第一上下文模型或第二上下文模型。选择索引具有第一值，其指示特定数据块的当前处理部分是第一部分，并且选择索引具有第二值，其指示特定数据块的当前处理部分是第二部分。

图2示出了根据本发明的实施例的用于对编码图像或视频数据进行解码的装置200。装置200包括解码器202。解码器202接收比特流106，类似于图1中编码器102提供的比特流。比特流106包括编码图像或视频数据，并且解码器202从所接收到的比特流中解码编码图像或视频数据，并提供解码后的图像或视频数据204。解码器包括CABAC解码器206，其使用选定的上下文模型从比特流106中解码与编码图像或视频数据的特定数据块相关联的二进制值语法元素110。二进制值语法元素包括工具标志，该工具标志指示在对图像或视频数据进行编码时是否采用特定编码工具。针对特定数据块中与应用无关、编码工具始终适用的部分，选择用于对工具标志进行解码的第一上下文模型组，并针对特定数据块中取决于应用、编码工具适用或不适用的部分，选择用于对工具标志进行解码的第二上下文模型组。根据实施例，也如下所述，CABAC解码器206响应于选择索引针对特定数据块的当前处理部分选择第一上下文模型或第二上下文模型。选择索引具有第一值，其指示特定数据块的当前处理部分是第一部分，并且选择索引具有第二值，其指示特定数据块的当前处理部分是第二部分。

根据实施例，第一上下文模型组包括一个第一上下文模型或多个第一上下文模型，并且第二上下文模型组包括一个第二上下文模型或多个第二上下文模型。

与原始上下文索引组合

如前所述，在许多情况下，当二进制决策可能具有不同的概率时，工具启用标志由一个以上上下文模型进行建模，这些概率可以从相邻邻域中已解码符号中预测出来。本发明方法也可以作为这种熵驱动上下文选择和本发明选择索引的组合来应用。这种组合的动机是显而易见的，因为原始的熵驱动上下文索引在分离后也可能适用。

通过熵驱动上下文选择和通过本发明的方法二者来选择工具标志的上下文模型的实施例如下。

CombinedIndex＝EntropyIndex+3*SelectionIndex

因此，在该实施例中，纯熵驱动上下文选择将针对给定工具标志产生三个可能的上下文模型，而其与本发明的上下文模型选择的组合产生由索引CombinedIndex编索引的六个可能的上下文模型。

旁路模式编码启用标志的替换

本发明方法也适用于最初使用旁路模式进行编码的标志。在这种情况下，需要一个或两个附加的上下文模型来实现用例驱动的实现。如果仅使用一个附加的上下文模型，则选择索引将使用旁路模式对情况的未受影响部分进行编码与针对所有其他情况使用一个上下文模型(其中现在可以开启和关闭工具)区分开。

在使用两个上下文模型的情况下，旁路模式完全由上下文建模算术编码代替，并且选择索引将区分这两个上下文模型。应该提到的是，借助即将推出的VVC标准中改进的更新技术，可以使用较小的更新强度来更新对情况的不可切换部分进行建模的一个上下文，以实现准静态模型。

还应该提到的是，对情况的可切换部分进行建模的附加模型肯定会与非常强的更新强度一起使用，以实现上下文模型对工具开启或工具关闭概率的快速适配。

在参数集中用信号通知部分工具启用的替代方式

前述部分工具启用行为也可以在参数集中用信号通知，在比特流中针对一个或几个帧的每个预定部分(例如，针对每个切片)用信号通知该参数集。在这种情况下，不需要上下文分离，因为来自参数集的传输标志将包含所有必要的信息。然而，这种信令与用例驱动的上下文模型选择相比的缺点在于：在前一种情况下，贯穿参数集适用的整个视频序列部分，工具针对对应于应用场景的情况只能完全启用或禁用，而在后一种情况下，工具也可以在视频序列的任何可变部分中被禁用，该可变部分不需要被预先确定或被解码器所知。原因是，在后一种情况下，如果将针对工具标志的特殊上下文模型分配给所有情况，其中，针对特定应用场景禁用工具有时是可行的，则从顺序编码中的任何位置开始，对应于特定应用场景的编码器永远不会针对相应的情况测试工具，直到序列编码中的一个灵活点，这与在视频序列的这个特定部分中的应用场景相对应的所有情况下完全禁止该工具的情况相比，只有很小的信令开销。

使用任意编码工具的应用

本发明的上下文拆分可以应用于由启用标志控制的任何编码工具。下面列出了可与本发明方法一起使用的未来VVC标准中出现的当前候选工具。然而，本发明方法的应用不限于这些工具。候选工具包括DMVR、OBMC、BIO、FRUC、LIC、ISP、ALF、SAO、MTS间或MTS内、65种角度帧内模式、MRL以及诸如QTBT、MTT或QTBT+TT之类的划分工具。

本发明方法还可以应用于具有由索引值表示的不同配置的工具。这里，本发明的CC分配将由以下事实确定：在一些应用场景中，对于特定情况或一般情况，仅工具的所有配置的子集是可行的。本发明的CC分配将通过将额外的CC分配给工具对于场景不可行的配置来考虑这些不同的应用场景。本发明的这个方面的实施例是针对预测残差的逆变换应用n个变换中的一个变换的工具，其中，在比特流中传输变换的索引。

使用本发明方法，许多工具仅可以在特定情况下提供有一些上下文拆分启用工具。这里，根据本发明的上下文拆分是根据在特定应用场景下特定工具可能不可行的特定情况。这些特定情况取决于工具的关键属性。可以评估或与不限于本发明用例的特定情况组合的属性列表为：块大小、块形状、块纵横比、时间级别、QP、图片类型、图片分辨率、图片的动态范围、参考图片、GOP的前置图片。

特定情况也可以是上述那些属性的组合。

本发明的上下文分配方法的应用实施例

仿射线性加权帧内预测(LWIP)[4]是一种新的帧内预测技术。与传统的帧内预测一样，LWIP由预测模式集组成。给定左侧和上方的重构(参考)样本，以信号通知的预测模式中的每一个对应于生成不同预测信号的预测函数。

在传统模式和LWIP模式二者均可用的情况下，编码器比较传统模式和LWIP模式的率失真成本，并决定总成本最低的模式。然后，选定的预测模式在比特流中被发送到解码器，并且其用于选择相应的预测函数来预测块。以信号通知预测模式具有以下语法：首先，发送标志，该标志指示该块是用传统模式还是LWIP模式预测的。如果选择了传统预测，则根据帧内预测信令从比特流中读取传统预测模式。否则，如果选择了LWIP预测，则在该标志之后发送可用LWIP模式集内的模式索引。由于传统模式和LWIP模式均可用于编解码器通常支持以用于帧内预测的所有块大小，因此必须针对每个块发送标志。

VVC编码标准目前支持对范围W×H＝{4，8，16，32，64}×{4，8，16，32，64}内的亮度块大小进行帧内预测。显然，使用率失真优化(RDO)的编码器搜索会变得非常复杂，因为针对所有不同的预测模式对所有不同块大小(由于将较大块拆分为较小块而导致)的率失真成本进行评估。为了降低编码器的复杂性，优化通常会减少被测试的组合数，排除统计上不太可能导致最低率失真成本的情况。

LWIP的核心预测仅支持W_LWIP＝H_LWIP∈{4，8，16}的方形块。为了对所有其他块大小启用LWIP预测，参考样本被下采样以匹配核心预测大小，并且输出被上采样以匹配块大小。这具有以下效果：对于在水平和竖直方向上具有高度不相等的下采样和上采样比的块形状，降低了预测质量。这意味着，对于纵横比大于2的块，即，或与传统预测模式相比，LWIP模式不太可能导致更低的率失真成本。

通过将LWIP模式限制为纵横比小于或等于2的块，并且未对具有更高纵横比的块测试LWIP模式，此效果可用于降低编码器的复杂性。然而，这也导致编码效率有所降低。不针对纵横比大于2的块发送标志会减少编码效率的损失，但也无法实现通过针对纵横比大于2的块测试LWIP模式来得到更高整体编码效率的编码器(这可能是不同应用所需要的)。

支持快速和高压缩效率编码器二者的解决方案是引入单独的、附加的CABAC上下文，以用于针对纵横比大于2的块发送标志。现在，如果LWIP模式未针对这些块在编码器处进行测试，则标志始终为0(＝不使用LWIP模式预测的块)，并且发送标志几乎不会导致开销(仅用于上下文向零调整发送1的概率的开销)，这意味着编码效率非常接近不针对那些块发送标志的解决方案。如果LWIP块在编码器处针对这些块进行了测试，则标志以一定概率为1(＝使用LWIP模式预测块)，并且发送标志几乎不会导致开销，这意味着编码效率非常接近针对所有块大小利用相同上下文来发送标志的解决方案。

换言之，如上所述，根据实施例，本发明方法使用四个上下文或上下文模型，以用于表示通用视频编码VVC标准的仿射线性加权帧内预测LWIP或基于矩阵的帧内预测MIP的语法元素intra_mip_flag的二值化。选择索引由当前块的纵横比(宽度/高度或高度/宽度)控制：

图3示出了根据本发明的实施例的用于对图像或视频数据进行编码的装置(例如，类似于图1中装置的装置)，该装置引入了单独的、附加的CABAC上下文，以用于针对具有大于2的纵横比的块发送标志。编码器102接收图像或视频数据104，并对所接收到的图像或视频数据104进行编码，以便提供表示编码图像或视频数据的比特流106。CABAC编码器108接收工具标志110，工具标志110指示在对图像或视频数据块进行编码时是否采用特定编码工具，例如，仿射线性加权帧内预测LWIP。仿射线性加权帧内预测LWIP在通用视频编码VVC标准中也被称为基于矩阵的帧内预测MIP，并且工具标志也被称为intra_mip_flag，其指示仿射LWIP或VVC标准的MIP的适用性。对于具有大于2的纵横比且特定编码工具适用的图像或视频数据的块300，从一个或多个第一上下文模型的组中选择用于对工具标志进行编码的第一上下文模型，并提供给CABAC 206。对于具有小于或等于2的纵横比且特定编码工具适用的图像或视频数据的块302，从一个或多个第二上下文模型的组中选择用于对工具标志进行编码的第二上下文模型，并提供给CABAC 206。例如，如果LWIP模式未针对纵横比大于2的块300进行测试，则标志始终为0，并且附加CABAC上下文向零调整发送1的概率，而如果LWIP模式针对纵横比大于2的块300进行了测试，则标志以一定概率为1。根据实施例，CABAC编码器108可以响应于选择索引针对当前处理的块选择第一上下文模型和第二上下文模型。选择索引指示当前处理的块具有大于2的纵横比或具有小于或等于2的纵横比。

图4示出了根据本发明的实施例的用于对图像或视频数据进行解码的装置(例如，类似于图2中的装置的装置100)，该装置引入了单独的、附加CABAC上下文，以用于针对具有大于2的纵横比且使用图3的装置进行编码的块的标志。对于具有大于2的纵横比且特定编码工具适用的图像或视频数据的块300，从一个或多个第一上下文模型的组中选择用于对工具标志进行编码的第一上下文模型，并提供给CABAC 206。对于具有小于或等于2的纵横比且特定编码工具适用的图像或视频数据的块302，从一个或多个第二上下文模型的组中选择用于对工具标志进行编码的第二上下文模型，并提供给CABAC 206。

例如，语法元素intra_mip_flag的二值化可以采用如下所示的总共四个具有上下文索引{0，1，2，3}的上下文模型：

-如果当前块的纵横比(宽度/高度或高度/宽度)大于2，则使用索引为3的上下文模型，

-否则，使用上下文模型0、1、2之一，其中，选择可以取决于当前块的左侧块和上方块的intra_mip_flag，例如因为其已知并用于其他几个语法元素。

在VVC规范中，编码单元语法可以如下所示(参见例如[5]的7.3.10.5-编码单元语法)：

intra_mip_flag[x0][y0]等于1指定亮度样本的帧内预测类型是基于矩阵的帧内预测。intra_mip_flag[x0][y0]等于0指定亮度样本的帧内预测类型不是基于矩阵的帧内预测(参见例如[5]的7.4.11.5-编码单元语义)。

语法元素intra_mip_flag的二值化可以如下所示(参见例如[5]的9.3.4.2-ctxTable、ctxIdx和bypassFlag的推导过程)：

尽管已经在装置的上下文中描述了所述的构思的一些方面，但是显然这些方面也表示对应方法的描述，其中块或设备对应于方法步骤或方法步骤的特征。类似地，在方法步骤上下文中描述的方面也表示对相应块或项或者相应装置的特征的描述。

本发明的各种元件和特征可以以使用模拟和/或数字电路的硬件、软件、通过一个或多个通用或专用处理器执行指令、或者作为硬件和软件的组合来实现。例如，本发明的实施例可以在计算机系统或另一处理系统的环境中实现。图5示出了计算机系统400的示例。可以在一个或多个计算机系统400上执行这些单元或模块以及由这些单元执行的方法的步骤。计算机系统400包括一个或多个处理器402，如专用或通用数字信号处理器。处理器402连接到通信基础设施404，如总线或网络。计算机系统400包括：主存储器406，例如，随机存取存储器(RAM)；以及辅助存储器408，例如，硬盘驱动器和/或可移动存储驱动器。辅助存储器408可以允许将计算机程序或其他指令加载到计算机系统400中。计算机系统400还可以包括通信接口410，以允许软件和数据在计算机系统400和外部设备之间传输。通信可以是电子、电磁、光或能够由通信接口处理的其他信号的形式。通信可以使用电线或电缆、光纤、电话线、蜂窝电话链路、RF链路和其他通信信道412。

术语“计算机程序介质”和“计算机可读介质”通常用于指代有形存储介质，例如，可移动存储单元或安装在硬盘驱动器中的硬盘。这些计算机程序产品是用于向计算机系统400提供软件的装置。计算机程序也被称为计算机控制逻辑，被存储在主存储器406和/或辅助存储器408中。也可以经由通信接口410接收计算机程序。计算机程序在被执行时使计算机系统400能够实现本发明。具体地，计算机程序在被执行时使处理器402能够实现本发明的过程，例如本文所述的任何方法。因此，这样的计算机程序可以代表计算机系统400的控制器。在使用软件实现本公开的情况下，软件可以存储在计算机程序产品中并使用可移动存储驱动器、接口(如通信接口410)加载到计算机系统400中。

可以使用数字存储介质来执行硬件中或软件中的实现方式，数字存储介质例如云存储、软盘、DVD、蓝光、CD、ROM、PROM、EPROM、EEPROM或闪存存储器，其上存储有电子可读控制信号，其与可编程计算机系统协作(或能够与之协作)，从而执行相应的方法。因此，数字存储介质可以是计算机可读的。

根据本发明的一些实施例包括具有电子可读控制信号的数据载体，其能够与可编程计算机系统协作以便执行本文所述的方法之一。

通常，本发明的实施例可以实现为具有程序代码的计算机程序产品，该程序代码可操作用于在计算机程序产品在计算机上运行时执行这些方法之一。程序代码可以例如存储在机器可读载体上。

其他实施例包括存储在机器可读载体上的计算机程序，该计算机程序用于执行本文所述的方法之一。换言之，本发明方法的实施例因此是具有程序代码的计算机程序，该程序代码用于在计算机程序在计算机上运行时执行本文所述的方法之一。

因此，本发明方法的另一实施例是其上记录有计算机程序的数据载体(或者数字存储介质或计算机可读介质)，该计算机程序用于执行本文所述的方法之一。因此，本发明方法的其他实施例是表示计算机程序的数据流或信号序列，该计算机程序用于执行本文所述的方法之一。数据流或信号序列可以例如被配置为经由数据通信连接(例如，经由互联网)传送。其他实施例包括处理装置，例如，计算机或可编程逻辑器件，该处理装置被配置为或适于执行本文所述的方法之一。另一实施例包括其上安装有计算机程序的计算机，该计算机程序用于执行本文所述的方法之一。

在一些实施例中，可编程逻辑器件(例如，现场可编程门阵列)可以用于执行本文所述的方法中的一些或全部功能。在一些实施例中，现场可编程门阵列可以与微处理器协作以执行本文所述的方法之一。通常，方法优选地由任意硬件装置来执行。

上述实施例对于本发明的原理仅是说明性的。应当理解的是，本文所述的布置和细节的修改和变形对于本领域其他技术人员是显而易见的。因此，旨在仅由所附专利权利要求的范围来限制而不是由借助对本文的实施例的描述和解释所给出的具体细节来限制。

参考文献

[1]ISO/IEC，ITU-T.High efficiency video coding.ITU-TRecommendationH.265|ISO/IEC 2300810(HEVC)，edition 1，2013；edition 2，2014.

[2]JEM reference software，

https：//jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/.

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

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

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