实时音视频互动系列（下）：基于 WebRTC 技术的实战解析

在 WebRTC 项目中，又拍云团队作到了覆盖系统全局，保证项目进程流畅。这牵涉到主要三大块技术点：

• 网络端、服务端的开发和传输算法

• WebRTC 协议中牵扯到服务端的应用协议和信令服务

• 客户端iOS、安卓 H.264 编解码技术

△ WebRTC 技术点

实时音视频互动必须遵照三大点

 

• 必须基于 UDP 协议，不然不要谈实时

     由于 TCP 协议的重传机制（传输保障）会致使累积延迟问题，用 UDP 协议没有传输保障机制，但须要自行完善丢包容错逻辑。

又拍云音视频互动方案是基于UDP 协议，使用 TCP 协议没法保障实时性。

TCP 协议有包重传机制，保证传输内容100%传输到目的地，这个特性致使延时增长。固然，因为UDP协议没有包重传机制，须要完善业务的容错性。目前来讲，UTUN 网络提供的两种配置，均可以保证数据100%传输。

在极差的网络状态下，能够选择容忍丢包，使用算法保障90%以上的数据包正常到达，以此达到200ms之内延迟。

UDP协议相比TCP协议具备多链路传输的优点。

TCP协议只支持单一链路传输。当连麦、音画同时须要传输时，TCP协议只有一条通道进行数据传输。而经过UDP协议，音视频能够经过两个节点将数据一分为二来传输，A路传输50%数据包，B路传输50%数据包。终端收到两路数据流，再合并放到应用层作解码处理。

• 考虑多终端适配，使用 WebRTC 协议

客户端网络跨地区和跨运营商信号不好，因此不能使用 P2P 模式。目前包括苹果Safari 在内的全部的桌面端浏览器都已支持 WebRTC 协议。

网络层使用 P2P 模式没法解决跨地域、跨 ISP 的跨运营商网络问题，会致使延时太高的状况产生。若是一直纠结于P2P模式，那么QOS码率控制、包容忍等问题就没法在算法上有所突破。

• 云服务化

单机、单机房存在硬件瓶颈，惟有云服务化才能按需作到横向扩展。

随着用户量的提高，单台服务器所能支撑的并发量直播有限，RTMP Server、WebRTC Server通常八核服务器能承受的并发量只有2000~4000路，单机房也会成为硬件瓶颈，而公有云能承受几十万甚至上百万的数量压力，因此机房中不能存在单点，必须是云服务化分布式的。

云服务化很是重要，上文提到的 UTUN 网络属于彻底分布式网络，分布在又拍云两百多个节点，四千台服务器上。只须要接入又拍云任意边缘服务器，就能够作到自主服务，自动选择出一条甚至数条路径，让用户与通信网中任何地点的人交互。

又拍云 WebRTC 架构中遇到的经验和问题

 

     又拍云 WebRTC 相比外部的 WebRTC 有较大的差异。即便你在同一个地方、同一个服务商、同一个无线信号下，又拍云都没有使用P2P模式，都是经过云服务来进行网络传输的。

        咱们严格遵循官方标准搭建包括服务端、客户端在内的 WebRTC 体系。目前 WebRTC 版本为可变性很是大的1.0版本，将来该技术可能会有革命性的迭代。若是采用自研的方式，会有没法跟进版本技术更新的风险。再者若是彻底自主编写 Server 端或者客户端势必要投入很是大的精力和研发时间。

       所以又拍云选择紧跟官方的步伐，不管官方有何种bug修复，都选择同步更新。

又拍云在实践中遇到的问题：

• 当 iOS 端使用新版本 WebRTC 时，因为音频处理部分致使的 Bug，会致使 CPU 占用率太高；

• 服务 Server 端因为编码传输时 WebRTC 是可变码率、可变帧率的，可是内核代码在进行传输时却使用了固定帧率操做，时间戳不一致的 Bug 致使了音视频不一样步的状况，声音与画面不一样步最大延时能够达到数十秒，不断累积。为了解决这个 Bug 须要把视频时间戳进行修正，统一使用音频的时间戳，来保证音视频同步；

• Android 端不支持高通外的芯片硬解码，又拍云在近期把各个 Android 端编解码功能完善，目前已经可以适配华为、MTK、三星等品牌的机型；

• 目前客户端解码能力有限，会话人数最好控制在8我的之内；

• 自动根据参与人数控制总带宽在2Mbps之内；

• 美颜、滤镜等功能的接入会增长延迟，加入额外功能不能过分消耗客户端 CPU 资源。

音视频互动最大的难点——业务信令

 

目前业务信令尚未一套完整的解决方法，业务信令在 WebRTC 中虽然是开源的，可是没有造成标准的信令协议，这个部分须要咱们自行构建。

架构网络电话场景时，牵扯到三个信令：呼叫、等待接听、通话。

可是实际中会有更多信令，假设一个会议场景，A邀请参会B，A会设置多个邀请途径：1.A直接将B拉到会议室；2.A把会议室号码给B，B自行进入；3.A配置房间权限控制，须要获得受权才能进入房间等。随着业务的发展，业务信令会不断增长，咱们须要构建一套完善的信令体系显得很是重要。

咱们在编写信令系统时，把信令系统分红了两类：1.底层系统信令，2.公共业务信令。

底层系统信令只需编写公共业务信令的总通道协议和 API 接口，让应用程序对接，将业务信令进行统一标准化。好比在房间里，发送一条广播给全部参会者的业务信令S，而业务信令S只想传达给B，可是C在同一个会议室也听到了，C会选择性的对业务信令S忽略以此达成这个业务功能。

 

目前来讲必须面临的现实问题：

 

1.客户端硬件性能未能支持高清码率：多人互动不可能作到720P分辨率，通常来讲都是在320P或者460P分辨率。通常手机由于客户端的解码能力支撑不了多路高清解码，达到6路以上码率只能作到300K如下；

2.硬编解码兼容性差：Android 机型太多，仅能有限支持H.264硬编解码，同时iOS和Android 端均不支持 H.265 硬编解码；

3.手机发热、耗电量大：参加会议iPhone电量支撑两、三个小时。桌面端耗电、发热最严重，测试时使用Chrome硬解码电量只能支持两个小时。

以上三点是目前整个业内所都要面临的最大的问题，只能等待终端的解码能力提高，相信到明年手机解码能力就能够支持多路高清互联。

 

相关阅读：

实时音视频互动系列（上）：又拍云UTUN网络详解

WebSocket+MSE——HTML5 直播技术解析