对于 WebRTC，我们专注于有损媒体压缩编解码器。这些不会保留它们压缩的所有数据，只是因为我们也不会注意到它。
编解码器（语音和视频）的目的是压缩和解压缩需要通过网络发送的媒体。在 WebRTC 之前是这样，在 WebRTC 之后也是如此。
一般来说，有两种压缩方式：
- 无损压缩——这些是编解码器，无论它们看到的是什么输入到编码器，都会在解码器的另一端生成。没有任何东西会在途中丢失。把它想象成一个.zip文件，它存储文件，并要求在压缩的两端完美匹配。
- 有损压缩——这些编解码器并不保持从进入编码器的内容到解码器后的内容的精确匹配。这些类型的编解码器在音频和视频处理中相当常见。
音频和视频往往包含大量数据。既然我们想通过网络发送它，我们就不想浪费网络资源。那么这些编解码器有什么作用呢？他们试图移除我们的眼睛和耳朵不会注意到的任何东西。
在概念层面上，有损压缩具有这个虚拟刻度盘。你移动表盘来决定你愿意从数据中丢失多少。编码器会尽最大努力丢失您不会注意到的东西，但在某些时候，您会注意到。
这种设置压缩级别的灵活性也被用来管理比特率。通过估计带宽，编码器可以被指示调高或调低压缩级别，以产生更高或更低的压缩，满足估计的可用带宽的要求。
WebRTC 基础知识——视频编解码器
视频编解码器定义
视频编解码器获取原始视频流，它可以具有不同的分辨率、颜色深度、帧速率等，并对其进行压缩。
这种压缩可以是无损的，其中保留了所有数据（因此当您解压缩它时，您会得到完全相同的内容），但它几乎总是有损的。这个概念是我们可能会丢失人眼无论如何都不会注意到的数据。所以当我们压缩视频时，我们会考虑到这一点，并根据我们希望获得的质量丢弃一些东西。我们扔的越多——我们最终得到的质量就越差。
视频编解码器分为两部分：
- 编码器——获取原始视频数据并进行压缩
- 解码器——获取编码器创建的压缩数据并将其解压缩
解码后的流将与原始流不同，它的质量会下降。
解码器是规范
许多人错过的是，为了定义视频编解码器，我们唯一拥有的是解码器规范：
给定一个压缩的视频流，需要采取什么行动来解压它。
没有编码器规格。假定如果您知道压缩后的结果需要是什么样子，您就可以按照自己认为合适的方式对其进行压缩。这将我们带到下一点。
一般来说，解码器的性能各不相同：运行需要多少 CPU，需要多少内存等。
编码器是魔法？
在视频编解码器中，您需要决定很多事情。在运动估计上投入多少时间和精力，压缩当前帧的每个部分时要多积极等等。
您无法真正达到最终压缩，因为这需要很长时间才能实现。因此，您最终会得到一组启发式方法——编码器在压缩视频图像时将采用的一些“指南”或“捷径”。
通常，编码器是基于经验、编解码器开发人员进行的大量试验和错误以及调整。结果既是艺术又是科学。
编码器彼此之间的差异不仅在于它们的性能，还在于它们最终压缩的程度（以及不能用单个度量值总结的程度）。
硬件加速
编解码器所做的很大一部分是蛮力。
例如，当今大多数现代编解码器将图像分成宏块，每个宏块都需要DCT。在 720p 分辨率的每一帧中有超过 3,000 个宏块，每秒需要处理大量宏块。
运动估计和视频编解码器的其他部分也是如此。
为此，许多视频编解码器实现都是硬件加速的——要么编解码器完全由加速硬件运行，要么它的丑陋部分由“软件”管理编解码器实现。
这也是编解码器的硬件支持对其市场成功和采用至关重要的原因。
带宽管理
视频编解码器无法在空白中工作。尤其是当这一切的目的都是通过网络发送视频时。
网络具有不同的可用带宽、丢包、延迟、抖动等特性。
当视频编码器运行时，它必须考虑这些因素并对其进行补偿——降低网络拥塞时产生的比特率，重置其编码并发送完整帧而不是部分帧，等等。
关于如何“投资”其比特率的编解码器也有不同的实现。这又把我们带到了下一个话题。
不同内容类型（和用例）的不同实现
并非所有视频编解码器实现都是一样的。在选择要使用的编解码器时了解这一点很重要。
当谷歌将 VP9 添加到 YouTube 时，它基本上做出了两个妥协：
- 只需要在浏览器中实现一个解码器
- 声明编码器离线运行而不是实时运行
实时编码很难。这意味着您无需再三考虑如何对事物进行编码。你不能回去修复你已经完成的事情。只是时间不够。所以你使用单通道编码器。这些编码器只查看传入的原始视频流一次，并根据看到的数据块决定如何压缩它。例如，他们无法选择等待几帧来决定如何最好地压缩。
您的内容大部分是静态的，来自顶部有鼠标移动的 Power Point 演示文稿？这不同于网络会议中常见的头像视频，而后者又不同于最新的詹姆斯邦德幽灵预告片。
在很多方面——您可以根据内容类型选择编解码器实现。
关于 WebRTC 的一句话
WebRTC 给浏览器厂商带来了巨大的挑战。
他们需要创建一个足够智能的编解码器来处理所有这些不同类型的内容，同时在各种硬件类型和配置上运行。
从我们过去几年所看到的情况来看——它做得很好（尽管总有改进的余地）。
参考资料：
Media compression is all about purposefully losing what people won’t be missing
系列阅读：
WebRTC TURN 服务器是自建还是购买?【WebRTC认知篇6】
WebRTC 群组视频通话的带宽使用【WebRTC认知篇5】
WebRTC 媒体传输之质量或延迟优化，两者不可兼得【WebRTC认知篇4】
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/14726.html
