3

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共同成长的这一事实。

期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.