第五章 编码器/解码器

视频编码基础知识

什么是视频编码？

视频编码是压缩和可能改变视频内容格式的过程，有时甚至将模拟源改为数字源。关于压缩，目标是使其消耗更少的空间。这是因为这是一个有损的过程，会丢掉与视频相关的信息。在解压回放时，会产生一个原始的近似值。应用的压缩越多，丢掉的数据越多，近似值与原始值相比就越差。

为什么编码很重要？

现在有两个原因，为什么视频编码是重要的。第一个原因，特别是当它涉及到流媒体，是它使它更容易在互联网上传输视频。这是因为压缩减少了所需的带宽，同时也提供了高质量的体验。如果没有压缩，原始的视频内容将排除许多人由于正常的连接速度不够而无法在互联网上传输流媒体内容。重要的方面是比特率，或视频中每秒的数据量。对于流媒体来说，这将决定他们是否可以轻松地观看内容，或者他们是否会卡在视频的缓冲区。

视频编码的第二个原因是兼容性。事实上，有时内容已经被压缩到一个足够的大小，但仍然需要进行编码以实现兼容性，尽管这通常更准确地描述为转码。兼容性可能与某些服务或程序有关，这些服务或程序需要一定的编码规范。它也可以包括增加与观众播放的兼容性。

视频编码的过程是由视频编解码器或视频压缩标准决定的。

什么是编解码器？

视频编解码器是通过软件或硬件应用完成的视频压缩标准。每个编解码器都由一个编码器和一个解码器组成，前者用于压缩视频，后者用于重现视频的近似值。编解码器的名称实际上是将这两个概念合并成一个词：Encoder和Decoder.

视频编解码器的例子包括H.264，VP8，RV40和许多其他标准或这些编解码器的后期版本，如VP9。虽然这些标准与视频流紧密相连，但视频通常与音频流捆绑在一起，而音频流可以有自己的压缩标准。音频压缩标准的例子，通常被称为音频编解码器，包括LAME/MP3，Fraunhofer FDK AAC，FLAC等。

这些编解码器不应该与用于封装一切的容器相混淆。MKV(Matroska Video)、MOV(MOVie的缩写)、AVI(Audio Video Interleave)和其他文件类型都是这些容器格式的例子。这些容器没有定义如何对视频数据进行编码和解码。相反，它们以兼容应用程序可以播放内容的方式存储来自编解码器的字节。此外，这些容器不仅存储视频和音频信息，还存储元数据。不过，这可能会让人感到困惑，因为一些音频编解码器的名称与文件容器相同，例如FLAC。

什么是最好的视频编解码器？

这是一个很有意义的问题，如果没有更多的信息，是无法直接回答的。原因是不同的视频编解码器在某些领域是最好的。

对于互联网上的高质量视频流，H.264已经成为一种常见的编解码器，估计占多媒体流量的大部分。该编解码器以优良的质量、编码速度和压缩效率著称，虽然不如后来的HEVC（高效视频编码，又称H.265）压缩标准。H.264还可以支持4K视频流，这对于一个2003年创建的编解码器来说，是相当超前的想法。

不过如前所述，HEVC已经有了更先进的视频压缩标准。这种编解码器的压缩效率更高，可以让更多人在较慢的连接上观看高质量的视频。这也不是孤例。2009年，谷歌收购了On2，让他们控制了VP8编解码器。虽然这个编解码器没能风靡全球，但它经过改进，发布了一个新的编解码器，被称为VP9。Netflix使用他们目录中的5000个12秒的片段，测试了这些后来的格式与H.264的对比。由此，他们发现这两种编解码器都能将比特率大小降低50%，但仍能达到与H.264相似的质量。在这两种编解码器中，HEVC在许多分辨率和质量指标上都优于VP9。例外的是在1080p分辨率下，要么接近，要么在某些场景下VP9的效率更高。

通过这些测试，岂不是让HEVC成为最好的编解码器？虽然在技术上它优于H.264，但它忽略了旧编解码器的一个关键优势：兼容性。H.264在各个设备上都得到了广泛的支持，比如直到2017年底的iOS 11，iPhone才可以支持HEVC。因此，尽管H.264没有那么先进，但为了覆盖更广泛的播放对象，在很多情况下，H.264仍然受到青睐。

注意，H.264编解码器有时也被称为X.264。然而，这并不是相同的编解码器，实际上是编解码器与授权的H.264实现的免费等价物。

压缩前的数据主流格式

大致分两类： rgba 类型 yuv类型

也可参考连接：图像实战 - RGB、YUV图像格式介绍 - 简书 (jianshu.com)

rgba 类型：原理上由 rgba四个字节表示一个像素点的颜色 其中每个字节分别代表 红，绿，蓝，透明度的值 由于业务场景和需求的不通，又衍生出了不同的格式

第一类是只有三个通道 只有三原色 rgb 去除掉了透明度通道

第二类是 通道的顺序变化 比如 argb bgr(opencv中是这种排列) bgra

图像数据的排列也有区别，通常默认的多数是 交错式跑列 ：(rgb)(rgb)(rgb) 表示三个像素点

平面式排列 : rrrgggbbb 表示三个像素点

yuv 类型 ：为了减少图像在传输过程中的网络带宽占用，又由于人眼对亮度的感知强余对颜色的感知，所以此类型就牺牲了部分色度信息来减少数据的大小

具体原理参考：YUV数据格式是什么 - 开发技术 - 亿速云 (yisu.com)

y 通道指 亮度通道（灰度图黑白图就是纯亮度通道的图像）

uv 通道 颜色信息的通道

格式衍生： y u v 分辨代表三种通道 yuv420 （420 表示通道中的权重 uv通道只有y通道数据的一半大小）

内存中的排列 ： yyy uv uv uv 表示三个像素点

编码种类

以上是原图的理解和格式种类，下面介绍编码的种类和种类的区别

压缩编码从大类上分为有损压缩和无损压缩，但是都遵循香农定理

无损压缩： 压缩后的数据 = 解压缩后的数据 压缩前后 无损失

有损压缩 : 压缩前 != 压缩后 有损失 为了提交视频传输效率视频流都是有损压缩

主流的压缩方式

大体分两类： 非关联压缩，帧关联压缩

非关联压缩: 输入一张原图，压缩后是一张独立的 压缩图片，典型的就是 mjpeg ，一张原图对应一张压缩后的图片

帧关联压缩：输入多张原图，压缩后输出多帧压缩后的数据，但是压缩后的图像会分组组内的图像帧相互关联的，非关键帧不能独立解压恢复

原因：为了提高压缩效率，在连续的图像中可以通过算法计算只需要以一个关键帧数据作为基础后面只需要计算出后一张图像的和前一针图像的运动矢量差就可以在解码的时候根据运动矢量恢复出关键帧后面的图像，基于这个思路衍生出了这类帧关联压缩方式，大大减少了传输带宽，尤其是对于非运动的情况下带宽的占用则非常低

常见压缩比

非关联压缩： mjpeg (1-20 倍压缩率)

帧关联压缩： h264 (100-150倍压缩率) h265(200-300倍压缩率) vp8 vp9

根据以上原理主流的帧关联压缩中帧种类分为关键帧和非关键帧(也叫参考帧) 压缩方式的不通非关键帧的种类也不同

像 h264 其中分为 I P B 三种参考帧，这三种帧的参考方式也有多重多样，这个在编码器调参中需要根据自己的业务场景进行调优，只做了解，就不做更深入的分析了

包装格式

以上介绍完了压缩编码，还需要了解包装格式

所谓的包装格式就是把压缩好的图像帧数据根据标准协议进行包装，这样就可以对每一个压缩后的数据进行描述，在传输后解码播放的时候就大大方便

比如 MP4 flv MP3 rtp 这些都是对压缩后的视频帧的一个包装，记录描述了帧的序列，视频的持续时间等信息等

视频编码发展时间线

各种编码器性能比较

WebRTC 中标准且最流行的编解码器是 VP8 和 H.264，但这些并不是我们唯一的选择。VP9 已经推出一段时间了，一些 大型服务正在使用它 ，而 AV1 支持最近已添加到 Chrome 中。

在比较编解码器时，有一些有趣的考虑因素，例如互操作性和许可，但可能最重要的因素是编解码器在压缩方面有多好以及编解码器在 CPU 和内存使用方面有多便宜。

压缩比通常是我们首先考虑的事情，并且有很多可用的比较，但如果我们希望能够在实时用例中使用编解码器，资源消耗也同样重要。

鉴于 AV1 在 Chrome Canary 版本中可用，我决定运行一些测试来估计我们在 WebRTC 生态系统中 4 个可用编解码器的 CPU 使用率。测试的目的是将整个视频管道与这 4 个编解码器进行比较，而不仅仅是单独的编解码器。

测试环境

测试通过一个简单的网页完成，该网页在 2 个 PeerConnections（一个发送，另一个接收）之间建立连接。如果您想自己运行测试，测试页面在这里：

https://jsfiddle.net/tvo7czxs

对该页面的测试通过改变 3 个变量进行：

• 编解码器：VP8、VP9、H264、AV1
• 分辨率：高清、VGA、QVGA
• 比特率：200Kbps、800Kbps、2Mbps

如果您查看测试页面，很容易更改这 3 个参数以使用其他配置或在其他设备中运行测试。

使用的 Chrome 版本是本周（1/2/21）从 git 同步的最新版本，测试在 MacBook Pro（2.4 GHz 8 核 Intel Core i9）上运行。

为了检查 CPU 使用率，我只需在系统活动监视器中查看 Chrome 进程的平均 CPU 消耗，等待 30 秒以让带宽估计和 WebRTC 内部的分辨率/帧速率适配稳定下来。当下面的结果显示 100% 时，这意味着机器的 1 个核心已满。

没有什么太花哨的，但希望足够容易理解。

在该环境中，我运行了 36 种参数组合几次，取平均结果并在以下部分进行了总结：

QVGA 结果

对于 QVGA 分辨率，结果符合预期，VP9 所需的 CPU 比 VP8 多一点，而 AV1 所需的 CPU 几乎是 VP8 的 2 倍。H.264 所需的 CPU 使用率较低，因为它使用硬件加速。

不同编解码器的 CPU 使用率百分比
QVGA	200Kbps	800Kbps	2Mbps
VP8	18	22	二十八
VP9	20	二十八	33
H264	10	14	15
AV1	三十六	四十六	50

VGA 结果

对于 VGA，结果没有太大差异，但在低比特率下，只有 VP9 能够保持分辨率，而当将比特率限制增加到 2 Mbps 时，AV1 使用了超过 1 个核心。200Kbps 的 H.264 质量非常差，帧率非常低，阻塞很多，因为在这种情况下，Chrome 中的适配显然效果不佳。

不同编解码器的 CPU 使用率百分比
显卡	200Kbps	800Kbps	2Mbps
VP8	18	三十	四十六
VP9	二十六	三十八	40
H264	8	十三	16
AV1	33	80	150

高清（1280x720）结果

HD 结果与 VGA 类似，但 AV1 无法编码原始分辨率，并在所有比特率的测试中将其缩小。H264 在低比特率下的表现也很差，VP8 和 VP9 成本之间的差异比 VGA 高得多。

不同编解码器的 CPU 使用率百分比
高清	200Kbps	800Kbps	2Mbps
VP8	17	三十	65
VP9	三十	50	80
H264	8	12	16
AV1	三十五	四十八	90

（此外，高清分辨率的 AV1 经常会因为 Mac 相关代码中的内存问题而崩溃，但也许在您阅读本文时该错误已经修复）

编码与解码成本

我又做了一个测试，将成本分摊到编码（发送方）和解码（接收方）之间。该测试针对 800 Kbps 的 VGA 进行，结果为接下来考虑的四种编解码器的结果。

结果差别不大，但 VP9 和 AV1X 的解码成本与编码成本相比相对较低。

仅比较不同编解码器的解码成本，AV1 的成本似乎比其他编解码器高出约 2 倍。VP9 比 VP8 稍贵，VP8 比 H264 稍贵，但这三者之间没有太大区别。