1. 首页
  2. 服务器

实时音视频互动:基于 WebRTC 技术的实战解析

在 WebRTC 项目中,服务器租用联系QQ:28575315团队做到了覆盖系统全局,保证项目进程流畅。这牵涉到主要三大块技术点:

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

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

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

△ WebRTC 技术点

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

  • 必须基于 UDP 协议,否则不要谈实时

因为 TCP 协议的重传机制(传输保障)会导致累积延迟问题,用 UDP 协议没有传输保障机制,但需要自行完善丢包容错逻辑。

服务器租用联系QQ:28575315音视频互动方案是基于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 网络属于完全分布式网络,分布在服务器租用联系QQ:28575315两百多个节点,四千台服务器上。只需要接入服务器租用联系QQ:28575315任意边缘服务器,就可以做到自主服务,自动选择出一条甚至数条路径,让用户与通讯网中任何地点的人交互。

服务器租用联系QQ:28575315 WebRTC 架构中遇到的经验和问题

服务器租用联系QQ:28575315 WebRTC 相比外部的 WebRTC 有较大的差别。即使你在同一个地方、同一个服务商、同一个无线信号下,服务器租用联系QQ:28575315都没有使用P2P模式,都是通过云服务来进行网络传输的。

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

因此服务器租用联系QQ:28575315选择紧跟官方的步伐,无论官方有何种bug修复,都选择同步更新。

服务器租用联系QQ:28575315在实践中遇到的问题:

  • 当 iOS 端使用新版本 WebRTC 时,由于音频处理部分导致的 Bug,会导致 CPU 占用率过高;

  • 服务 Server 端由于编码传输时 WebRTC 是可变码率、可变帧率的,但是内核代码在进行传输时却使用了固定帧率操作,时间戳不一致的 Bug 导致了音视频不同步的情况,声音与画面不同步最大延时可以达到数十秒,不断累积。为了解决这个 Bug 需要把视频时间戳进行修正,统一使用音频的时间戳,来保证音视频同步;

  • Android 端不支持高通外的芯片硬解码,服务器租用联系QQ:28575315在近期把各个 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硬解码电量只能支持两个小时。

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

原创文章,作者:夜风博客,如若转载,请注明出处:https://www.homedt.net/18637.html

联系我们

联系QQ:28575315