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

Question

众所周知，所有视频编码器都使用一些时间编码。它使用基于块（矩形区域）的运动估计来找到参考/先前帧中的当前帧的像素块的最佳macth。这给出了运动矢量。如果运动是平移的（即如果块向左/向右或向上/向下移动），这很好。如果对象旋转并且如果对象是矩形并旋转，则运动估计将不那么准确因此不会产生最少的主席（原始减去预测）。

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

它是否通过将该块编码为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有关，但那篇文章让我的大脑开始透过我的眼窝插出......