Tsahi Levent-Levi
- H.264的最初设定就是为了在WebRTC服务中取代VP8。
微软在上一个星期公布了支持ORTC的H.264/AVC现在已经可以在Edge浏览器中使用了。
*对的，是ORTC而不是WebRTC。
*对的，只是在运行标识的后面。
*对的，只能在Edge上运行，IE不可以。
当然，这只是今天让视频通话在Firefox，Chrome和Edge之间运行的唯一方式。VP8或者VP9只能让你在Chrome和Firefox之间进行。
Edge支持ORTC中运行H.264并不是一件大事。甚至都不会引起更大的一些事件的兴趣。但还是一个重要的转折点—在这个转折点上我们可以问自己这个问题，我们应该倾向于哪个视频编解码器来开发我们的WebRTC产品呢。
去年的答案是“VP8”。
几个月之前的答案是“看情况”。
今天，答案更倾向于“H.264，除非你必须用VP8没有别的选择”。
现在给出为什么答案会出现这些变化的4个原因：
#1 浏览器交互基线
如果你想让你的视频服务覆盖尽可能多的浏览器种类，那么H.264就是你的选择。在未来的几个月来，H.264将会得到这些提供商的官方支持，而这也是最终情况了。还有，你可以期望苹果公司能够首先使用H.264而且预期VP8—就像现在微软在Edge浏览器上做的工作。
#2 移动端
移动设备相比于VP8，更喜欢H.264。视频编解码器会占用很多的资源。为了解决这个问题，手持移动端在视频编码器上使用了硬件加速。他们都具备H.264加速（尽管他们不能总是像开发者一样接触它）。他们之中很多人甚至都不知道VP8是什么。这使WebRTC在移动端的实现需要用软件实施VP8.
一些开发者最终在移动端上用H.264替代VP8就是因为上述原因。尤其是移动应用作为唯一产品的时候。
尽管我是肯定支持VP8进一步发展的，但是有一个讨厌的问题就是需要支持早已经存在的数以万计的设备。而且现在，所有的浏览器都支持H.264，有什么东西能够激励开发者们支持在移动应用中使用VP8吗？
#3 传统视频系统
所有的视频会议系统？他们使用H.264，多数没有VP8，在他们最新发布的产品中也没有。在今天之前他们不支持WebRTC是通过特殊的网关，MCU或者什么都没有。
转码是将WebRTC加入传统视频系统会遇到的主要困难之一。它会造成大量的花费。如果只是使用H.264的话会把整个事情变的更容易，而且现在已经可以实现。
这也是Cisco为什么最初Spark在Firefox上工作的原因之一。决定在WebRTC中使用H.264而不是从VP8处转码。
#4 流
超过60%的互联网传输的数据是视频。其中大多数不是实时视频，而是YouTube或者Netflix这样的视频网站，都是被动占用。
现今的视频流主要是基于H.264的，也有一部分是基于VP9。
要想在iPhone上进行视频通话，就必须要有HLS，也就是意味着H.264。
WebRTC视频编码的未来
一旦我们踏入了未来，我们就会遇到VP9，和VP9的SVC。
而且那时会有Open Media的联盟，而且他们的工作是下一代免费视频编解码器。我在最近的Virtual Coffee会谈上接触过他们的工作。
准确起见，我更愿意讨厌H.264以及它所支持的。但是现在我必须接受它正在与WebRTC共同成长的这一事实。
