实时音视频互动，延迟不到200ms才算合格？

摘要：本次分享将从网络传输、应用服务器开发和客户端SDK开发几个方面，向大家介绍实时音视频通讯所牵扯到的技术点，以及又拍云在路上踩过的一些坑。

演讲 / 黄慧攀

出处 / LiveVideoStack

如何定义实时音视频互动，延迟400ms内才能无异步感

实时音视频互动如果存在1秒左右的延时会给交流者带来异步感必须将视频播放延迟限制在400ms以内才能给用户较好的交互体验。当延迟控制在400ms以内时两个人音视频互动是实时的不会有异步感存在即实时音视频互动。

实时音视频互动产生延迟的原因

音视频互动的延迟是如何产生的？我们先假设这样一个场景：位于北京的A客户端与位于广州的B客户端进行实时音视频互动。该场景会有以下几个产生延迟的原因：

• 光的传输耗时：30ms
• 网络处理耗时：10ms
• 应用服务处理耗时：10ms
• 客户端发送处理耗时：50ms（采集、编码、缓冲……）
• 客户端接收处理耗时：50ms（缓冲、解码、渲染……）

网络层面在跨地区、跨运营商等情况下传输延迟会非常高并且不稳定，尤其在晚高峰或网络拥堵的情况下延时更加无法把控。单纯通讯环境导致超过100ms的延迟，因此需要在技术层面达到较高的性能才能将延迟控制在200ms以内。

又拍云UTUN通讯网数据传输耗时低于50ms

为了解决这个问题又拍云设计了基于公网的通讯网UTUN，以此实现所有客户端接入又拍云通讯网之后再进行交互。UTUN是一个分布式网络路由器，加入UTUN可以将数据以最快的速度传达到目的地，同时无需担心跨地区、跨 ISP、负载均衡、容灾等问题。

又拍云UTUN网络基于又拍云CDN网络部署，同时拥有200多个边缘接入节点、4000多台服务器、覆盖3大运营商、3个小运营商。通过又拍云UTUN网络进行数据传输国内可以做到传输低于50ms，海外传输低于200ms。计算入上文提到的应用层产生延时的50ms，以及其他因素所导致的延时，又拍云国内传输可以做到100~200ms音视频互动。国际传输音视频互动延时等于应用层所消耗掉的100~200ms，再加上网络传输的延时，又拍云能够做到400ms之内。

音视频互动必须遵守三大点

1.必须基于UDP协议，否则不要谈实时

又拍云音视频互动方案是基于UDP协议，使用TCP协议无法保障实时性。TCP协议有包重传机制保证传输内容100%传输到目的地，这个特性导致延时增加。当然由于UDP协议没有包重传机制需要完善业务的容错性。目前来说UTUN网络提供的两种配置都可以保证数据100%传输。在极差的网络状态下可以选择容忍丢包，使用算法保障90%以上的数据包正常到达，以此达到200ms以内延迟。

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

2.考虑多终端适配使用WebRTC协议

目前包括苹果Safari在内的所有桌面端浏览器都已支持WebRTC协议。网络层使用P2P模式无法解决跨地域、跨ISP的跨运营商网络问题，会导致延时过高的情况产生。如果一直纠结于P2P模式，那么QOS码率控制、包容忍等问题就无法在算法上有所突破。

3.云服务化

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

云服务化非常重要，上文提到的UTUN网络属于完全分布式网络，分布在又拍云两百多个节点、四千台服务器上。只需要接入又拍云任意边缘服务器就可以做到自主服务，自动选择出一条甚至数条路径让用户与通讯网中任何地点的人交互。

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

又拍云WebRTC相比外部的WebRTC有较大的差别。即使你在同一个地方、同一个服务商、同一个无线信号下，又拍云都没有使用P2P模式，都是通过云服务来进行网络传输的。我们严格遵循官方标准搭建，包括服务端、客户端在内的WebRTC体系。目前WebRTC版本为可变性非常大的1.0版本，未来该技术可能会有革命性的迭代。如果采用自研的方式，会有无法跟进版本技术更新的风险。再者如果完全自主编写Server端或者客户端，势必要投入非常大的精力和研发时间。因此又拍云选择紧跟官方的步伐，无论官方有何种bug修复都选择同步更新。

下面列举一些又拍云在实践中遇到的问题：

• 当iOS端使用新版本WebRTC时，由于音频处理部分导致的Bug会导致CPU占用率过高；
• 服务端由于编码传输时WebRTC是可变码率、可变帧率的，但是内核代码在进行传输时却使用了固定帧率，操作时间戳不一致的Bug导致了音视频不同步的情况，声音与画面不同步最大延时可以达到数十秒不断累积。为了解决这个Bug，需要把视频时间戳进行修正，统一使用音频的时间戳来保证音视频同步；
• Android端不支持高通外的芯片硬解码，又拍云在近期把各个Android端编解码功能完善，目前已经能够适配华为、MTK、三星等品牌的机型；
• 目前客户端解码能力有限，会话人数最好控制在8个人以内；
• 自动根据参与人数控制总带宽在2Mbps以内；
• 美颜、滤镜等功能的接入会增加延迟，加入额外功能不能过度消耗客户端CPU资源。

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

目前业务信令还没有一套完整的解决方法，业务信令在WebRTC中虽然是开源的，但没有形成标准的信令协议，这个部分需要我们自行构建。架构网络电话场景时牵扯到三个信令——呼叫、等待接听、通话，但实际中会有更多信令。

假设一个会议场景：A邀请B参会，A会设置多个邀请途径：

• A直接将B拉到会议室；
• A把会议室号码给B，B自行进入；
• A配置房间权限，控制需要得到授权才能进入房间等。

随着业务的发展，业务信令会不断增加，我们需要构建一套完善的信令体系显得非常重要。我们在编写信令系统时，把信令系统分成了两类——底层系统信令和公共业务信令。底层系统信令只需编写公共业务信令的总通道协议和API接口让应用程序对接，将业务信令进行统一标准化。比如在房间里发送一条广播给所有参会者的业务信令S，而业务信令S只想传达给B，但是C在同一个会议室也听到了，C会选择性的对业务信令S忽略，以此达成这个业务功能。

总结

WebRTC项目中会牵涉到主要三大块技术：

• 网络端、服务端的开发和传输算法；
• WebRTC协议中牵扯到服务端的应用协议和信令服务；
• 客户端iOS、安卓编解码技术。

团队必须要覆盖系统全局否则进程都会被卡住。

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