目录
前言
近两年,在各种内外因素的促进作用下,实时音视频技术迎来了飞速发展,同时,RTC 厂商也如雨后春笋般迅速占领着各行各业的市场份额。但是面对那么多的实时音频通讯方案,应该如何选择呢?不禁让大多数人陷入了鱼和熊掌不可兼得的迷茫。今天,本文将从视频 QoS 的角度来对比分析腾讯云的 TRTC 方案和常见的几家 RTC 厂商的方案的技术水平和产品性能,为大家今后的选择提供一项参考。
正文
一、创建音视频应用
如果想要体验腾讯云的 TRTC 产品,我们首先需要创建一个 TRTC 的音视频应用,创建地址如下:https://console.cloud.tencent.com/trtc/app,应用名称暂定为 RTCTest,如下图所示:
点击“确定”按钮,音视频应用就创建好了。接下来,还需要开通 TRTC 后付费功能,具体操作如下图所示:
点击“确认开通后付费”按钮后,会弹出如下提示对话框。
当应用管理页面中,实时音视频服务状态变为“正常”时,就可以使用对应的音视频功能了,如下图所示:
二、获取工程代码
我们可以通过如下地址获取快速跑通的 Demo 工程代码,非常的方便,之后的功能开发和测试实验都可以直接基于 Demo 工程来完成:https://console.cloud.tencent.com/trtc/quickstart 。接下来,选择已有应用,在应用名称的下拉列表中找到包含 RTCTest 字段的应用,如下图所示:
点击“下一步”,就来到了下载工程源码的页面,支持的平台非常多,包括 iOS、Android、Web、MacOS、微信小程序、Electron 等,这里我们选择 Web 平台的 Demo 工程,如下图所示:
三、修改配置信息
解压上一步中下载的源码包,找到并打开 /base-js/js/debug/GenerateTestUserSig.js 文件,将 SDK AppID 和密钥粘贴到下图的指定位置。
四、工程编译运行
配置修改完毕后就可以编译工程了,执行如下命令 npm install && npm run build
编译工程源码,编译成功后,会把结果输出 dist 目录中。编译成功后,执行 npm run start
命令,启动 Web Demo,此时可以先检测当前浏览器是不是支持 TRTC 的功能,如果检测通过会生成如下检测结果:
检测通过后,选择摄像头和麦克风设备,就可以通过下图中的蓝色按钮进行加入房间和发布流操作了。
然后就可以把房间号告诉其他人来加入了,或者复制邀请链接给别人。注意:上图中显示的视频画面是虚拟摄像头。
五、测评实验
1. 选择 RTC 厂商
本次对比测评一共是四家 RTC 厂商,除了腾讯云的 TRTC 之外,还随机挑选了三个 RTC 厂商,为了不引起领域内友商之间不必要的误会,暂时分别是命名为厂商A、厂商B、厂商C。
2. 实验环境
接下来,简单描述一下实时音视频通讯的实验场景,首先,使用各家厂商的手机 APP 对着旋转的地球仪拍摄,然后,使用各家的 Web 网页端订阅 APP 的媒体流,同时设置不同的网络环境并观看视频画面的播放效果。与此同时,我们可以通过谷歌浏览器的 chrome://webrtc-internals/
调试工具面板查看拉流端的音视频流的媒体数据信息。
3. 软硬件设备
移动端手机:华为P40 Pro
手机操作系统:鸿蒙 2.0
浏览器:Chrome
浏览器版本:102
弱网环境模拟:使用 Linux 系统的路由器,并利用 TC 命令模拟各种网络条件。这里科普一下,TC(Traffic Control)是 Linux 内核级的流量控制工具,非常好用和靠谱。
4.实验场景一
我们先来看一下各家 RTC 厂商在纯带宽限制情况下的具体表现。首先,设置手机 APP 的视频推流参数,分辨率是1280*720,帧率是25fps,码率是1M。然后,限制 APP 推流端的上行网络带宽,分别是不限速、2M、1M、500k、400k、300k、200k、100k。最后,在 Web 端观看视频播放效果同时统计媒体数据信息。
几轮测试对比后,实验结果如下表所示。
注意:表格中的分辨率、帧率和码率都是网页接收端的媒体统计信息,来自 webrtc-internals 调试工具。另外,所有统计数据均取平均值。
(1)TRTC
网络限速条件 |
视频发送码率 |
分辨率 |
帧率 |
码率 |
现象 |
不限速 |
1024k |
1280*720 |
25 |
1.25M |
画面正常;声音正常 |
2M |
1024k |
960*540 |
20 |
1.25M |
画面正常;声音正常 |
1M |
700k |
960*540 |
20 |
950k |
画面正常;声音正常 |
500k |
300k |
480*270 |
15 |
400k |
画面正常;声音正常 |
400k |
160k |
320*180 |
11 |
250k |
画面正常;声音正常 |
300k |
40k |
320*180 |
2 |
200k |
画面正常;声音正常 |
200k |
30k |
320*180 |
0 |
208k |
画面开始出现周期性卡顿;声音正常 |
100k |
10k |
320*180 |
0 |
100k |
画面基本卡住不动,偶尔播几帧;声音不丢字,但是出现1秒左右的延时 |
(2)厂商 A
网络限速条件 |
视频发送码率 |
分辨率 |
帧率 |
码率 |
现象 |
不限速 |
2000k |
1280*720 |
25 |
2.2M |
画面正常;声音正常 |
2M |
1800k |
1280*720 |
25 |
2.0M |
偶现小卡顿;声音正常 |
1M |
860k |
960*540 |
25 |
1M |
画面正常;声音正常 |
500k |
400k |
640*360 |
25 |
500k |
画面正常;声音正常 |
400k |
300k |
480*270 |
25 |
400k |
画面正常;声音正常 |
300k |
200k |
320*180 |
25 |
300k |
画面开始模糊并伴有偶现卡顿;声音正常 |
200k |
130k |
320*180 |
25 |
180k |
画面模糊,周期性卡顿;声音基本流畅,延时500毫秒左右 |
100k |
0 |
320*180 |
0 |
100k |
画面卡住不动;声音基本流畅,延时1秒左右 |
(3)厂商 B
网络限速条件 |
视频发送码率 |
分辨率 |
帧率 |
码率 |
现象 |
不限速 |
2000k |
1280*720 |
25 |
2.2M |
画面正常;声音正常 |
2M |
1800k |
1280*720 |
25 |
2.0M |
画面正常;声音正常 |
1M |
620k |
960*540 |
15 |
800k |
画面正常;声音正常 |
500k |
400k |
640*360 |
10 |
500k |
画面正常;声音正常 |
400k |
300k |
640*360 |
5 |
400k |
画面正常 ;声音正常 |
300k |
200k |
640*360 |
5 |
300k |
画面正常 ;声音正常 |
200k |
70k |
480*270 |
5 |
200k |
视频开始模糊,还能看;声音正常 |
100k |
0 |
0 |
0 |
0k |
视频关闭;音频流畅 |
(4)厂商 C
注意:由于厂商C的产品没有网页端 Demo,所以有些数据信息没有办法统计到,只能用客户端统计。
网络限速条件 |
视频码率 |
视频分辨率 |
帧率 |
接收带宽 |
说明 |
不限速 |
* |
* |
25 |
1.7M |
画面正常;声音正常 |
2M |
* |
* |
25 |
1.7M |
画面正常;声音正常 |
1M |
* |
* |
25 |
900k |
画面正常;声音正常 |
500k |
* |
* |
25 |
460k |
画面正常;声音正常 |
400k |
* |
* |
20 |
390k |
画面正常;声音正常 |
300k |
* |
* |
15 |
280k |
画面忽快忽慢;声音正常 |
200k |
* |
* |
15 |
200k |
画面会周期性卡顿;声音正常 |
100k |
* |
* |
0 |
0 |
视频关闭;声音流畅,但是有变调倾向 |
通过上面的测试数据可以得到如下结论,首先说共同点,尽管厂商C没有统计到完整的数据信息,但是通过现象是可以知道的。
1、四家 RTC 厂商都具有一定的网络自适应能力,当网络带宽被限制时,会通过降低分辨率或者帧率的方式保证画面质量。
2、当网络变差时都优先保证音频质量,再兼顾视频效果。
然后说一说他们的不同点,四家 RTC 厂商在带宽限制时的策略各有侧重点,但是并不明显,接下来通过后面的实验再具体分析。
5. 实验场景二
众所周知,网络环境都不是某个单一因素决定的,都是带宽、丢包、延时等众多影响因素的综合表现。实验一中已经对比了纯带宽限制条件下,四家 RTC 厂商的具体表现。接下来,我们看一下丢包和延时对音视频效果的影响。
带宽/延时/丢包 |
接收带宽/编码码率/分辨率/帧率 |
现象 |
|||
TRTC |
厂商A |
厂商B |
厂商C |
||
无/50ms/20% |
1350/1024/1280*720/25 |
2400/1800/1280*720/25 |
2500/1900/1280*720/25 |
1100/x/x/20 |
厂商AB接收端的码率不稳定;厂商C帧率有降档 |
无/50ms/30% |
1450/1000/1280*720/25 |
2600/1800/1280*720/25 |
2600/1800/1280*720/25 |
800/x/x/20 |
TRTC渲染忽快忽慢,偶尔卡一下;厂商B接收端的码率不稳定 |
无/50ms/40% |
1550/950/960*540/20 |
4000/1800/1280*720/25 |
3000/1900/1280*720/25 |
700/x/x/20 |
厂商B偶尔顿一下 |
无/50ms/50% |
1650/900/640*360/15 |
3000/1800/1280*720/25 |
3100/1800/1280*720/20 |
520/x/x/20 |
厂商C画面清晰度降档 |
无/50ms/60% |
1400/800/640*360/12 |
3500/1700/960*540/25 |
3200/1700/1280*720/10 |
500/x/x/15 |
TRTC每3秒卡一下;厂商B也出现卡顿;厂商C帧率明显下降 |
无/50ms/80% |
500/200/320*180/10 |
200/60/320*180/0 |
0/0/0/0 |
200/0/0/0 |
TRTC画面开始变糊;厂商AB画面卡着不动;厂商C卡的比较严重,偶尔动一下 |
根据上面的统计数据,我们可以得出如下结论。首先看帧率的变化,当延时固定50ms,丢包率分别设置20%、30%、40%、50%、60%、80%时,四家 RTC 厂商的视频帧率变化情况如下图所示。
其中,当丢包率为80%时,四家 RTC 厂商中只有 TRTC 的视频还可以正常播放,但是画面的分辨率已经很低了;厂商A的丢包策略是优先保证视频画面的流畅度;厂商B的丢包策略是优先保证视频画面的清晰度;厂商C的丢包策略介于视频画面流畅度和清晰度之间,这一点和 TRTC 类似。
结论
综上所述,各家 RTC 厂商的实时音视频通讯方案都有各自的侧重点,当网络变差时,有的更关注流畅度,有的更关注清晰度,有的则二者兼顾。总得来说,腾讯云的 TRTC 方案属于本次测评集合中表现最好的,特别是低带宽时,依然可以保证视频流畅。本文只是向大家提供一种选择参考,具体抉择时还需要考虑很多因素,比如业务场景、费用等,毕竟适合自己的才是最好的。