RTC.Blacker

专注RTC和音视频相关领域,支持开源,相关交流请关注微信公众号:blackerteam,或者发邮件到: blacker@rtc.help

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

本文主要介绍WebRTC选择H.264的理由(我们翻译和整理的,译者:weizhenwei,校验:blacker),最早发表在【编风网

支持原创,转载必须注明出处,欢迎关注我的微信公众号blacker(微信ID:blackerteam 或 webrtcorgcn)。

 

微软近日宣布: Edge的ORTC开始支持H.264/AVC。

 

这是目前唯一能够在Firefox、Chrome和Edge之间跨浏览器进行视频通话的方法。VP8和VP9至多能让你在Chrome和Firefox之间建立视频通话。

 

对我们来说,当开发一个基于WebRTC的产品时,我们应该选择什么样的视频编解码器?

 

去年的时候,答案可能是“VP8”。

几个月前,答案可能是“看情况”。

现在答案是“除非必须用VP8,否则就用H.264”。

 

下面是做出如上决定的四个原因:

 

1.浏览器互操作

 

如果你希望你的服务能够覆盖尽可能多的浏览器,并且需要视频功能,那么H.264是你正确的选择。再过几个月, H.264将获得所有浏览器厂商的官方支持,并就此一锤定音。

 

此外,你可以期待苹果首先使用H.264,并在后面再考虑使用VP8,就像微软现在在Edge上所做的那样。

 

2.移动领域

 

相比于VP8,移动设备更喜欢H.264。视频编解码器消耗相当多资源;为克服这个问题,移动设备使用硬件编解码。他们都支持H.264硬件加速,尽管开发者并不总是能够对此进行编程。许多移动设备商对VP8知之甚少,这归结为移动设备上的WebRTC需要用软件方式实现VP8。

 

基于这个原因,一些开发者在移动设备上用H.264替换VP8,特别是针对那些只在移动设备上运行的产品。

 

虽然我相信在新的芯片上VP8的性能正在提升,但是在已经存在的数百万个移动设备上支持VP8仍然是个麻烦的问题。既然现在所有浏览器都以各种方式支持H.264,那么开发者为什么还要去支持那些必须使用VP8的移动应用呢?

 

3.遗留视频系统

 

遗留视频系统主要是视频会议系统,他们使用H.264编解码器,绝大多数不支持VP8。直到今天,他们仍然通过一种特别的网关(MCU)支持WebRTC,或者根本就不支持。

 

视频转码是WebRTC连通遗留视频系统的主要障碍之一,这非常消耗资源。直接让H.264在运行在各系统上是最容易的办法,也是当前就可以实现的办法。

 

这也是思科用Spark连通Firefox的原因。思科决定在WebRTC中使用H.264,而不是对VP8进行转码。

 

4.流量

 

互联网上超过60%的流量都是视频。这其中大部分不是实时视频,而是像YouTube或者Netflix这样的非实时视频。

 

如今视频流基本上都是H.264,某些情况下是VP9(YouTube使用VP9编码)。

 

在iPhone上获取视频内容需要HLS协议,这再次意味着必须使用H.264编解码器。

 

因此我们面临两种选择:当我们想输出视频流时,是把WebRTC生成的视频内容转码成H.264,还是直接在开始就使用H.264生成视频内容。

 

你是否需要关注?

 

如果你的视频服务是一对一的会话服务,没有服务器端做视频处理,那么你大可不必关注。在这种场景下,浏览器的最终协商结果对你来说已经足够好了,并且很有可能是该特殊场景下的最佳选择。

 

如果厂商在服务端视频处理针对VP8进行大量投入,包括视频录制、混合、路由等,那么把这些服务端设备进行改造使其支持H.264可能很重要。对他们来说,转向H.264可能是一个困难的决定,但却是不得不做的决定。

 

WebRTC视频编解码器的未来?

 

一旦我们放眼未来,我们可能需要关注VP9。

 

然后就是开放媒体联盟,他们致力于开发一款广泛使用的下一代免专利视频编解码器。

 

从个人角度,我相当讨厌H.264和它代表的一切。但是现在必须承认, 它留了下来,和WebRTC一起发展。

 

译者:weizhenwei,具体详见:【编风网

 

posted on 2016-08-12 08:13  RTC.Blacker  阅读(2790)  评论(0编辑  收藏  举报