作者：AGOUAILLARD（原文链接）
翻译：刘通
原标题：Webrtc Codec vs Media Engines: Implementation Status and why you should care.
前文链接：WebRTC编解码器vs媒体引擎-1，WebRTC编解码器vs媒体引擎-2
抖动及丢包
这些是最难处理的问题。抖动比较容易解决，首先创建一个缓冲区，由于所有的数据包都是编了号的，所以你可以把它们恢复成原来的顺序。在实时状态下，你不希望抖动太严重，否则你可能会等待过久才能将抖动问题恢复，这就会让你超过了实时的界限（33ms端到端延迟）。使用大的抖动缓冲区可能会有帮助。
丢包通常是通过重发数据包（RTX）来解决。如果从发送端到SFU并且返回所需的时间（RTT）要短于33ms的约束。那么我们就有足够的时间在数据包过期之前进行重传。如果这么做还不够的话，或者网络不好（丢包率超过0.01%），则需要实施更高级的错误消除算法，如FEC。
一个更好的方法再次使用到了SVC编解码器。由于各层交织的方式，以及只需要基础层来进行呼叫，你可以重传与基础层相对应的数据包的时间窗是RTT的几倍。这意味着只需要重新传输数据包就可以弥补非常差的网络状况（1%+的丢包率），并且不会丢失通话的连续性。虽然同播只是带宽管理的其中一种解决方案，SVC编解码器是解决带宽波动和网络质量的解决办法。
4. 各种浏览器的当前状态
当涉及到媒体引擎时，Firefox和Safari浏览器会跟Google保持一致。他们只是偶尔更新他们的libwebrtc的内部副本，而不会遵循Google Chrome的发布时间表（每6周）。他们可能有一点更新不同步，但是最后也都赶上了，除了Safari浏览器中的VP8编解码器。
你可以通过下面的表格来了解完整性，通常我们都会忽略Edge浏览器。今天，你必须在支持iOS Safari和高质量之间选择一个。iOS Safari一方面只支持H.264，另一方面libwebrtc仅使用VP8和SVC与VP9实现同播。
当我们在iOS中已经有正常的H.264支持时，同播有多重要？大多数情况下，客户不会原谅你在互操作性方面所做的降低质量的行为。如果你想以同级别的质量支持iOS系统，那么请你立刻转用原生版本。
5. 未来
很显然，VP8将无法在Safari浏览器中使用。同样可以推断VP9也没有什么可能。
虽然早些时间，通过支持HLS可以看出苹果似乎想要在WebRTC中加入H.265的支持。但是它最近嘉瑞了开放媒体联盟和一些其他小东西，让我认为AV1可能是接下来会出现的东西。这只是我的一个个人想法。
在任何情况下，AV1参考编码器离实时标准都差的比较远，参考硬件速度为0.3fps。虽然对于预先录制好的内容来说可能不会出现这样的问题，但是对于实时媒体而言这是绝对无法接受的。至少需要一年的时间才可能达到足以能在RTC中使用的速度。
同时，在非RTC用例中，由于采用了bitmovin（高延迟，非webrtc）流媒体技术，你可以在Firefox浏览器中播放预编码的AV1文件。他们的创始人发明了MPEG-DASH，并宣布筹集3000万美元以准备下一代视频基础架构。
