作者：AGOUAILLARD（原文链接）
翻译：刘通
原标题：Webrtc Codec vs Media Engines: Implementation Status and why you should care.
前文链接：WebRTC编解码器vs媒体引擎-1
3. 编解码器到媒体引擎：逻辑中断
实时媒体与普通媒体有着近乎相同的目标，但是其优先级有着非常大的区别：
1. 我需要保持30fps（速度）
2. 我需要保持30fps并且还要保证交互性（延迟）
并且因为你不能对公共网络进行任何推断，所以如果你在公共网络上进行流传输的话，你就会有额外的限制（公共网络目标）：
1. 我需要适应小带宽波动
2. 我需要适应巨大的带宽波动
3. 我需要适应抖动（数据包乱序到达）
4. 我需要适应丢包
图片来源：http://www.enginegroup.com/
3.1 媒体引擎：主要目标
整个过程都要保持30fps的速度意味着你在发送端有33ms的时间进行捕获，编码（编解码器），封包（RTP），加密（SRTP）和发送（UDP/TCP），并且在接收端会进行相反的处理过程。
你即使保持30fps的吞吐量也会引起延迟。例如，具有多个帧的帧缓冲器来计算一些编码优化（帧间预测，运动矢量……）是很有诱惑力的。但是这反过来会减少你的带宽使用。不幸的是，等待5帧意味着你在开始任何编码工作之前就积累了5帧的延迟。编码本身较慢，所以会导致系统延迟。虽然你的持续速度是30fps，但是你的端到端延迟（从发送摄像头捕捉到接收屏幕渲染）超过了33ms。许多网站有意或无意地，将端到端延迟作为从输出端或输出端的UDP/TCP socket到接收机的时间，来欺骗他们的用户。他们没有计算编码和解码的时间，以及在客户端引入的任何附加延迟。不用说也知道，他们的数据并不能体现实际的用户体验。
解决方案吗？放弃导致过多延迟的每个编解码器子组件和子算法。基本上，就是要恢复到几乎逐帧处理的方式。尽管这是对编解码领域最令人愤慨，遗憾，耻辱甚至亵渎的做法，但是现在大多数的新编解码器都有一个“实时模式”，即一组参数，其中延迟要优先于任何其他事情。但是传统上只有“最佳质量”和“最小尺寸”模式，时间并不是重要的衡量标准。
在新的编解码器中，因为屏幕共享的内容十分特别（高空间分辨率，低时间分辨率，无损……），所以你还有屏幕共享模式。
3.2 媒体引擎：公共网络目标
小带宽波动
传统的编解码器不能改变它们的带宽速率，即一旦开始，他们就会认为一定的带宽总是可用的，如果实际情况中带宽出现了问题，那么就会发生失败的状况。在以前编解码器和音频/视频流被认为是网络设备的附加组件，因此安全性和带宽并不是由它们处理的，而是网络设备的工作。使用专用端口，专用带宽。并没用公共互联网。
第一个变化时使编解码器具有“比特率适应性”。在任何编解码器中，您都可以更改某些参数。像改变（空间）分辨率一样，一些改变对于人类的眼睛是很明显的，有些改变对人来说不那么明显，例如时间分辨率（30fps到25fps），有些改变则几乎不可见，例如量化的改变。量化参数是给定颜色可以具有的色调的数量。如果你使用256（通常是默认值），你将会有从白色到黑色十分平滑的过度，但是如果这个数值降低了，过度过程也就相应的不会那么光滑，但你的眼睛在大多数情况下不会看到什么差异。传统编码器使用QP参数作为调节旋钮来实现比特率适应，而不会对视频的视觉质量产生太多影响。
当然，你需要能够计算可用带宽并提供反馈。这些机制在媒体引擎中，但不在编解码器中。
大带宽波动
比特率自适应是很好的事情，它是自动调节的。但是，它无法适应大的带宽变化。假设你的带宽可用量突然下降为原来的一半了，那么即使使用比特率自适应编解码器，你也无法弥补。
在这些情况下，你需要降低空间分辨率或时间分辨率。时间分辨率通常是首先进行下调的，原因有两个。第一，人眼对帧速率变化的敏感度略低于对分辨率变化的敏感度（在适当范围内）。但在大多数情况下，你需要在发送端执行此操作，并且如果你的发送端连接到将媒体流中继到多个远程对等端的媒体服务器上，则所有的远程对等端都将受到影响。基本上，它们都会收到一个适用于所有远程对等端的恶劣配置/网络的流。
如果你控制着发送端，并且使用SFU，但在（其中一个）接收端上有带宽限制，则更好的方法是使用联播。发送端将以三种不同的分辨率对相同的流进行编码，取决于给定时间的远程对等端容量。SFU或接收客户端决定要使用原始流的哪个分辨率。现在，你可以单独照顾每个远端节点了，但需要对相同的数据流编码三次，并且发送它们。请注意，如果存在相应的实现，则可以在联播模式下使用任何编解码器。这不是一个内在的编解码器功能，而是外部功能。
SVC，又名分层编解码器（layered codecs），可以实现同样的功能：在SFU内选择哪个额分辨率来为每个远程对等端进行中继，但是是以更加智能的方式。总共就只有一个编码器，而不是每种分辨率有一个。它能节省约20%的带宽来进行相同分辨率的同播。其中只有一个编码比特率，它的分辨率是“分层的”或者交织的，这简化了端口管理及其他实用细节。它在SFU上也起到了简化的作用，因为现在每个数据包都会被标记，并且改变分辨率实际上可以视为丢包，而这根本不需要花时间，不像是转换同播数据流那样需要重写数据包并且等待下一个完整帧的到达。
