不同的浏览器支持哪个或者哪种编解码器。对于每个想要定义产品期望和路线的产品经理来说这都是一个棘手的问题。我应该只支持VP8/H264吗？我应该等待VP9吗？这些编解码器的多流，同播和SVC版本都是什么？除了所有这些问题还有：我什么时候可以告诉我的客户我能够分别支持桌面浏览器，Android和iOS系统？如果不能做到这点的话，那么我应该有一个原生app。本篇博文旨在讨论所有问题的本质。
1. 编解码器和带宽
通常人们在谈论编解码器的时候，人们主要探讨的到时质量和带宽占用情况，并没有提及网络及CPU占用空间。但是谈到与录制媒体的编码时，就需要考虑到这些问题了。
首先，你有大把的时间来编码你的内容，所以所有的优化，不管CPU和时间成本有多高昂，都是值得的。大多数优秀的编码器都使用多级算法：
1. 第一级：以同质块（相同的背景，快或慢的场景……）切割视频
2. 第二级：然后计算一些能够协助编码器的统计数据，以及一些帧间值（这需要用几个帧来计算）
3. 第三级：分别使用来自第二级的统计信息对每个块进行编码
对于实时流传输，显然，你不能等到会议结束的时候才开始进行推流。这就是“实时”的方面，以及为实时流带来价值的互动，而不仅仅是质量本身。
然后，如果分布在传统的物理介质（如DVD或BR磁盘）上，你的视频尺寸大小是固定的，无法进行扩展，所以你会希望获得固定尺寸的最佳质量。如果通过网络进行发布（Netflix/YouTube意义上的流式传输），你的主要成本和观众的主要瓶颈是带宽使用情况。因此你希望在给定带宽（带宽有限时）的情况下提供最佳质量，以及在给定质量（指分辨率，例如全高清，4K等）的情况下尽可能少的使用带宽以降低成本。智能缓冲可以解决由网络端造成的所有问题。
对于实时流式传输，任何物理存储都没有用了。而且当流式传输实时内容时（如youtube-live）时，由于最重要的是交互性，所以任何类型的缓冲和延迟都是不可接受的。
最后，很长一段时间内编解码器专家都认为一次只能有一个视频流在计算机上呈现（流媒体或从DVD端读取），并且可以始终将其卸到GPU上。所以编解码器的复杂性并不重要。之后移动端出现了。再之后WebRTC和SFU也出现了。
如果你没有考虑对实时约束和网络质量的极端敏感度，那么在实时媒体环境中谈论或比较编解码器是没有意义的。只比较可达到的最大压缩比是无关紧要的，但不幸的是，我经常会看到这些内容被引用。即使是在关于VP8和H264的最初讨论中，最具争议的讨论之一是编解码器是否现实。“纯粹编解码器”一派的人会说，基准测试时不应该考虑网络影响，其他人会争辩说，如果没有自适应性，没有考虑到数据包丢失，以及其他网络抖动等，测试结果将不切实际。
2. 编解码器：所以当前现状是什么？
这里的目的不是给出什么明确的答案，而是产品经理做出决定的经验法则。
# 在质量和带宽方面，H.264和VP8基本相当。
# VP9和H265在质量和带宽方面几乎差不多，比VP8/H.264的平均增益高30%，也会多出20%的CPU占用。
# 与VP8/H.264相比，AV1与VP9/H.265的增益/损耗差不多。
然而秘诀是，在实时媒体用户体验方面，这都不重要。重要的是你的编解码器是否是网络环境中合格的一员。现如今在实时媒体中，没有人只关心编解码器，人们更多关注的是媒体引擎：捕捉器+编/解码器+RTP以及他们处理网络（带宽波动和带宽质量）的能力。如果你的编码器在带宽低于阈值时就立即停止工作了，如果解码器在发生单个数据包丢失时停止工作，如果你的编码器无法以至少20fps的速率编码，那么你的实时媒体解决方案就是毫无价值的，无论你编解码器的压缩率有多高。
所以我们并不惊讶于看到谷歌赞助斯坦福的博士研究更好的编码器/网络组合。这才是未来。
作者：AGOUAILLARD（原文链接）
翻译：刘通
原标题：Webrtc Codec vs Media Engines: Implementation Status and why you should care.
