WebRTC基础篇：图像和视频帧的区别

图像和视频帧的区别

这个问题似乎很简单。视频就是一系列捕获的图像（称为帧）以给定的频率显示。而通过在一序列的特定帧处停止可获得单个视频帧。即图像。

如果我们只讨论视频帧序列，以上说法是正确的。将图像压缩算法（即“帧内”编码系统）应用于每个单独的帧也是正确的。这样的编码系统可能压缩率不是特别高，但它可以很好地满足某些应用程序的需求。例如那些仅需要使用一个压缩图像解码能力的应用程序：Motion JPEG（现已落伍）和Motion JPEG 2000（用于电影发行和其他应用程序）或关于演播室、捐助应用程序的MPEG视频编码标准的某些文件。

如果应用领域需要更精密的压缩算法，设计标准必然会有所不同。必须利用能解决冗余的帧间视频压缩方式。但是，通常情况下如果使用帧间编码模式压缩视频，单个帧可能显示不了图像。因为它的像素可能已使用其他一些帧的像素进行了编码。下图为30年前的MPEG-1。

左侧第一个长方形图像（序号I）代表仅使用了图像中的像素压缩。从I开始对左侧第四个长方形图像（序号P）进行预测编码。使用第一和第四个图像对第二和第三图像（序号B）进行插值。这样的操作在下一帧为P-B-B-B-P的序列中继续，其中第一个P图像预测最后的P图像，第一P图像和最后P图像创建3个内插图像（序号B）。

所有MPEG帧内编码方案-MPEG-1、MPEG-2、MPEG-4 Visual和AVC，MPEG-H（HEVC）和MPEG-I（VVC）都有帧内编码图像。这是必需的，因为在广播应用中，解码器“调入”所花费的时间要尽可能短。每隔半秒或每秒就产生一个帧内编码的图片是实现此目的的一种方法。在用户可能希望跳转到视频中任何位置的交互式应用程序中，帧内编码图片也很有帮助。

因此，帧间编码主题中的特定视频帧可以是图像。

那么，为什么不使帧内编码方案的图像编码和帧内编码图片的算法相同呢？

我们可以这样做，但由于以下原因未能付诸实践。

帧内编码模式是帧内视频编码总方案的子集。这样的方案相当复杂，多年来出现了很多编码工具，有一些在设计帧内编码模式时会用到。

采用帧间编码方案的大多数应用都对实时解码有严格要求。因此，相比静态图片编码方案来说，精密的解码工具在帧间编码方案中占重要地位。

帧间视频编码方案中的大量编码工具用于处理动态（motion-related processing）。

由于在抓取视频中收集的数据要比在图像中收集的数据多，因此提高编码效率的效果是不同的。

编码视频的实时交付要求促使MPEG开发出与以前有极大不同的系统层技术（例如DASH），并在系统层做出了不同的折中。

目前还没有一个能让涉及领域专家都认可的测试设计，用来比较在帧间编码标准下与在可用图像编码标准下静止图像编码模式的性能的不同。

目前没有得到证实，说强制使MPEG方案下的静止图像编码模式与JPEG开发的任何图像压缩标准相同。这是没有必要的，且不会带来很大优势。反之亦然。

我相信这个结论在未来的视频编码系统中会得到证实。那么为什么有一些与视频编码系统无关的图像压缩方案呢？很显然，因为需要压缩图像的行业与需要压缩视频的行业不同。两种行业要求不同。并且尽管某些压缩工具具有通用性，但图像压缩方案和视频压缩方案的规范是不同且不兼容的。

可以说，现有标准已经很好地满足了传统2D图像和视频的需求。但是如果是相对实现沉浸式2D视觉体验的新技术来说呢？

我们可以采取由总到分的方法。这在理论上是行得通的，但是技术上并不一定这样按部就班地进行。我们也可以选择由分到总的体验导向法。 MPEG一直采用的是后一种方法，在上述情况下，该方法在两个方面起作用：

沉浸式视频（MIV）的Metadata。这代表了3种数据流的动态沉浸式视觉体验：Texture、Depth 和 Metadata。通过在一系列精心选择的平面上适当投影场景，可以获取Texture信息。Texture和Depth当前使用的是HEVC编码。

具有大量point的Point Clouds可以有效代表沉浸式视觉内容。Point Clouds投影在固定数量的平面上，并且可以使用任何视频编解码器对投影进行编码。

编码方案1和2都包括等效的视频帧内编码图片。对于视频来说，这些图片是用与视频帧间编码图片等效的工具设计的。