Table of contents
1. Create audio and video applications
2. Obtain the engineering code
3. Modify configuration information
4. Compile and run the project
3. Software and hardware equipment
foreword
In the past two years, under the promotion of various internal and external factors, real-time audio and video technology has ushered in rapid development. At the same time, RTC manufacturers have sprung up to occupy the market share of various industries. But in the face of so many real-time audio communication solutions, how should we choose? It can't help but make most people fall into the confusion that they can't have both. Today, this article will compare and analyze the technical level and product performance of Tencent Cloud's TRTC solution and the solutions of several common RTC vendors from the perspective of video QoS, so as to provide a reference for your future choices.
text
1. Create audio and video applications
If you want to experience Tencent Cloud's TRTC products, we first need to create a TRTC audio and video application, the creation address is as follows: https://console.cloud.tencent.com/trtc/app, the application name is tentatively RTCTest, as shown below Shown:
Click the "OK" button, and the audio and video application is created. Next, you need to activate the TRTC postpaid function, the specific operation is as shown in the figure below:
After clicking the "Pay After Confirmation" button, the following prompt dialog box will pop up.
When the real-time audio and video service status changes to "Normal" on the application management page, the corresponding audio and video functions can be used, as shown in the following figure:
2. Obtain the engineering code
We can obtain the demo project code that runs quickly through the following address, which is very convenient, and subsequent function development and testing experiments can be completed directly based on the demo project: https://console.cloud.tencent.com/trtc/quickstart . Next, select an existing application, and find the application containing the RTCTest field in the drop-down list of the application name, as shown in the following figure:
Click "Next", and you will come to the page to download the project source code. There are many supported platforms, including iOS, Android, Web, MacOS, WeChat applet, Electron, etc. Here we choose the Demo project of the Web platform, as shown in the figure below :
3. Modify configuration information
Unzip the source package downloaded in the previous step, find and open the /base-js/js/debug/GenerateTestUserSig.js file, and paste the SDK AppID and key to the specified location in the figure below.
4. Compile and run the project
After the configuration is modified, the project can be compiled. Execute the following command npm install && npm run buildto compile the project source code. After the compilation is successful, the result will be output in the dist directory. After the compilation is successful, execute npm run start the command to start the Web Demo. At this time, you can first check whether the current browser supports the TRTC function. If the test passes, the following test results will be generated:
After the detection is passed, select the camera and microphone device, and then you can join the room and publish the stream through the blue button in the figure below.
Then you can tell others the room number to join, or copy the invitation link to others. Note: The video screen shown in the picture above is a virtual camera.
5. Evaluation experiment
1. Select RTC vendor
In this comparative evaluation, there are a total of four RTC manufacturers. In addition to Tencent Cloud’s TRTC, three RTC manufacturers were randomly selected. In order not to cause unnecessary misunderstanding among friends in the field, they are temporarily named as Manufacturer A, Manufacturer B and Manufacturer C.
2. Experimental environment
Next, briefly describe the experimental scene of real-time audio and video communication. First, use the mobile phone APP of each manufacturer to shoot at the rotating globe, and then use the web page of each company to subscribe to the media stream of the APP, and set up different networks at the same time. environment and watch the playback effect of the video screen. At the same time, we can view the media data information of the audio and video streams at the streaming end through the chrome://webrtc-internals/debugging .
3. Software and hardware equipment
Mobile phone: Huawei P40 Pro
Mobile operating system: Hongmeng 2.0
Browser: Chrome
Browser version: 102
Weak network environment simulation: Use the router of the Linux system and use the TC command to simulate various network conditions. Here is a popular science, TC (Traffic Control) is a Linux kernel-level traffic control tool, very easy to use and reliable.
4. Experimental scene one
Let's first take a look at the specific performance of each RTC manufacturer in the case of pure bandwidth limitation. First, set the video streaming parameters of the mobile APP, the resolution is 1280*720, the frame rate is 25fps, and the bit rate is 1M. Then, limit the upstream network bandwidth of the APP streaming terminal, which are unlimited speed, 2M, 1M, 500k, 400k, 300k, 200k, and 100k. Finally, watch the video playback effect on the web and count the media data information at the same time.
After several rounds of test comparisons, the experimental results are shown in the table below.
Note : The resolution, frame rate and bit rate in the table are the media statistics information of the receiving end of the web page, which comes from the webrtc-internals debugging tool. Also, all statistics are averaged.
（1）TRTC
| Network speed limit conditions |
Video sending bit rate |
resolution |
frame rate |
code rate |
Phenomenon |
| no speed limit |
1024k |
1280*720 |
25 |
1.25M |
The picture is normal; the sound is normal |
| 2m |
1024k |
960*540 |
20 |
1.25M |
The picture is normal; the sound is normal |
| 1M |
700k |
960*540 |
20 |
950k |
The picture is normal; the sound is normal |
| 500k |
300k |
480*270 |
15 |
400k |
The picture is normal; the sound is normal |
| 400k |
160k |
320*180 |
11 |
250k |
The picture is normal; the sound is normal |
| 300k |
40k |
320*180 |
2 |
200k |
The picture is normal; the sound is normal |
| 200k |
30k |
320*180 |
0 |
208k |
The picture starts to freeze periodically; the sound is normal |
| 100k |
10k |
320*180 |
0 |
100k |
The picture basically freezes, and occasionally plays a few frames; the sound does not lose words, but there is a delay of about 1 second |
(2) Manufacturer A
| Network speed limit conditions |
Video sending bit rate |
resolution |
frame rate |
code rate |
Phenomenon |
| no speed limit |
2000k |
1280*720 |
25 |
2.2m |
The picture is normal; the sound is normal |
| 2m |
1800k |
1280*720 |
25 |
2.0M |
Occasionally a small stutter occurs; the sound is normal |
| 1M |
860k |
960*540 |
25 |
1M |
The picture is normal; the sound is normal |
| 500k |
400k |
640*360 |
25 |
500k |
The picture is normal; the sound is normal |
| 400k |
300k |
480*270 |
25 |
400k |
The picture is normal; the sound is normal |
| 300k |
200k |
320*180 |
25 |
300k |
The picture starts to blur and occasionally stutters; the sound is normal |
| 200k |
130k |
320*180 |
25 |
180k |
The picture is blurry and freezes periodically; the sound is basically smooth, with a delay of about 500 milliseconds |
| 100k |
0 |
320*180 |
0 |
100k |
The picture freezes; the sound is basically smooth, with a delay of about 1 second |
(3) Manufacturer B
| Network speed limit conditions |
Video sending bit rate |
resolution |
frame rate |
code rate |
Phenomenon |
| no speed limit |
2000k |
1280*720 |
25 |
2.2m |
The picture is normal; the sound is normal |
| 2m |
1800k |
1280*720 |
25 |
2.0M |
The picture is normal; the sound is normal |
| 1M |
620k |
960*540 |
15 |
800k |
The picture is normal; the sound is normal |
| 500k |
400k |
640*360 |
10 |
500k |
The picture is normal; the sound is normal |
| 400k |
300k |
640*360 |
5 |
400k |
The picture is normal; the sound is normal |
| 300k |
200k |
640*360 |
5 |
300k |
The picture is normal; the sound is normal |
| 200k |
70k |
480*270 |
5 |
200k |
The video starts to blur, but you can watch it; the sound is normal |
| 100k |
0 |
0 |
0 |
0k |
Video off; audio smooth |
(4) Manufacturer C
Note : Since the products of manufacturer C do not have a web-side demo, some data information cannot be counted, and can only be counted by the client.
| Network speed limit conditions |
Video bit rate |
video resolution |
frame rate |
receiving bandwidth |
illustrate |
| no speed limit |
* |
* |
25 |
1.7M |
The picture is normal; the sound is normal |
| 2m |
* |
* |
25 |
1.7M |
The picture is normal; the sound is normal |
| 1M |
* |
* |
25 |
900k |
The picture is normal; the sound is normal |
| 500k |
* |
* |
25 |
460k |
The picture is normal; the sound is normal |
| 400k |
* |
* |
20 |
390k |
The picture is normal; the sound is normal |
| 300k |
* |
* |
15 |
280k |
The picture is fast and slow; the sound is normal |
| 200k |
* |
* |
15 |
200k |
The picture freezes periodically; the sound is normal |
| 100k |
* |
* |
0 |
0 |
Video is off; sound is smooth, but tends to shift pitch |
The following conclusions can be obtained through the above test data. First, let’s talk about the common points. Although manufacturer C has not collected complete data information, it can be known through the phenomenon.
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 方案属于本次测评集合中表现最好的，特别是低带宽时，依然可以保证视频流畅。本文只是向大家提供一种选择参考，具体抉择时还需要考虑很多因素，比如业务场景、费用等，毕竟适合自己的才是最好的。