video-encoding - 视频压缩中基于块的运动估计

Question

正如我们所知，几乎所有的视频编码器都使用一些时间编码。它使用基于块（矩形区域）的运动估计来为参考/先前帧中的当前帧找到像素块的最佳math。这给出了运动矢量。如果运动是平移的（即，如果块向左/向右或向上/向下移动），这很好不会导致最少的偏差（原始减去预测）。

那么视频编码器采用什么方法来处理这种旋转运动。/运动。

然后它是否通过将该块编码为 P 帧内的帧内块（代码原样，没有任何先前的任何参考）来处理这种情况

或者

在将其编码为 P 宏块本身时，是否还有其他技巧可以处理它？

Answer 1

据我所知，视频编码器没有任何旋转运动的特殊情况。首先，检测旋转运动本身会消耗大量时间。此外，运动估计是在宏块级别完成的，因此帧中可能有相当多的宏块不会以旋转方式移动，除非整个帧本身以某种方式旋转。

我可以建议的一个“技巧”如下 -

计算预测帧（P 帧）和实际帧之间的 PSNR。如果 PSNR 太低，将帧编码为信息帧（I 帧）更有意义。请注意，这不能用于实时传输，因为这会很耗时。但是当编码时间不是一个因素时，它可以做到。在这种情况下，您可以简单地使用完整搜索。

Answer 2

首先是计算复杂度，每增加一个旋转方向都会显着增加。例如，运动估计时间是“x”秒。在添加右手 90 度后，我们再次有 'x' 秒，因为它需要使用旋转块再次检查相同的参考系搜索窗口。再次添加左旋转 90 度后，它再次为运动估计增加了 x 秒，依此类推。这里的主要问题是，在整个编码器中，通常，运动估计是消耗大部分编码时间的块。

第二个问题是运动补偿单元的复杂性。如果我们在估计或预测中有旋转块，那么我们必须在编码器和解码器中生成相同的变换来生成补偿帧。最糟糕的是，它也增加了解码器端的复杂性。

第三件事是支持可变块大小的预测单元。该标准始终为固定的块大小定义运动矢量。如果提出了旋转块大小，则还需要在解码器中对方向进行标准化，其中运动补偿单元、熵编码器/解码器等。

第四件事是运动矢量编码。由于我们添加了旋转运动矢量，因此我们需要在运动矢量中添加额外的位。所以，将这些东西放在一个光束平衡中 - “为每个 MV 添加附加位”和“使用旋转运动矢量提高压缩效率”，其中一个权重更多的。如果平衡是平衡的，或者如果“为每个 MV 添加额外的位”权重更大，那么使用旋转 MV 就没有用处。

第五件事是关于编码器框图的深刻理解。我们使用的编码器类似于自适应差分脉冲编码调制器或任何具有预测编码的类似类型。视频信号始终是差分编码器。当视频信号或任何信号被差分编码时，前一个样本和当前样本之间的时间差非常小（这里是 1/帧速率），因此各个块始终遵循平移方向。所以，我们开始使用，仅当我们使用多个参考帧时，如果参考帧大于帧速率或至少大于 GOP 大小，则旋转 MV。因此，在这种情况下，旋转 MV 可以在 PSNR 方面提供非常轻微的改善或显着增加运动估计时间。

另一件事是关于运动方向的主观和统计研究。

尽管如此，JCT-VC 中也有一些实现这一点的建议，但最终没有在当前的 HEVC 标准中获得批准。可能他们会在未来试图弄清楚并解决所有问题。

Answer 3

运动估计的关键在于它是一种减少“典型”视频的计算成本低的方法。

如果您要在瀑布视频之类的内容上使用基于运动的编码，则无法减小大小。

类似的概念适用于 JPEG 照片。JPEG 压缩之所以有效，是因为它利用了人眼的特殊敏感性。

归根结底，数据就是数据，你不能无损地减少它的数量。您可以做的最好的事情是对源和目标进行一些猜测，然后尝试重新创建观众无法区分但使用较少数据的东西。这就是运动估计有效的原因。人类观看的 99.99% 的电影中都有人类，像人类一样四处走动……左右……上下。通过 WORKS，我的意思是，可以在足够快的时间内完成，以使每年制作数百万小时的镜头值得这样做。

这当然与香农熵有关http://en.wikipedia.org/wiki/Entropy_(information_theory ) ，但那篇文章让我的大脑开始有点从我的眼窝渗出......