字节跳动《实时音视频通讯技术》学习笔记之 RTC 概述及技术简介

字节跳动《实时音视频通讯技术》学习笔记之 RTC 概述及技术简介

什么是实时音视频

实时音视频（RTC）即基于 IP 技术实现的实时交互的音视频通信技术。

RTC 与 直播常用协议的区别

而这里我们要使用的 RTC 技术就厉害了~

它是基于 IP 技术的，它的延迟低于 400ms，RTC 传输的内容是音视频数据。

实时音视频应用场景

• 音视频通话

• 产品功能

• 1V1，多人音视频通话

• 可以美颜、使用道具等等。

• 技术特点

• 支持设备差异性大

• 网路接入经常切换

因为这种产品主要是面向用户的，不同用户使用的设备的差别比较大。根据不同设备需要做不同的优化。这就是为什么我们说支持设备差异性大。

而在实际情况中，经常遇到移动网络 4G、5G 切换 WIFI，或者基站之间的切换。这些导致网络环境的变化需要中断重连。

下面介绍两种场景：抖音直播和直播连麦。

• 抖音直播

• 产品功能Ⅰ

• 电商直播

• 游戏直播

• 秀场直播

• 技术特点Ⅰ

• 主播段推流

• 观众端 CDN 拉流

• 直播连麦

• 产品功能Ⅱ

• 多个主播同框互动，观众围观实况

• K 歌、游戏互动、互动交流

• 技术特点Ⅱ

• 服务端 &客户端合流

• 合流转推

• 实时审核

直播连麦将多个主播的视频流合流然后发送给观众。这种合流一般是在服务端做的，但是现在由于客户端的性能不断提高，现在出现了将合流放在客户端的情况，这样节约了成本。

我们都知道传统直播技术的延迟比较高，从观众评论到看到主播反馈一般要 5-10 秒以上，那么这样在教育直播、电商直播、体育直播等直播就会出现一些问题。

前面我们提到 RTC 能够实现低延迟的实时传输音视频流，那么 RTC 可以应用在直播场景吗？

答案是是，因为只要我们将基于 TCP 的网络传输协议转化为基于 UDP 的 RTC 就行了。

那为什么我们不一开始就使用 RTC 呢？

第一因为成本，CDN 的成本是 RTC 的三分之一，RTC 的部署是比较消耗资源的。

第二是因为 RTC 是需要做很多网络的优化的，比较复杂。

普通直播替换为低延时直播的方案

方案Ⅰ

拉流端（播放端）替换为 RTC：收益大。

因为观众端的延时比较大，所以一般是从观众端替换为 RTC。

方案Ⅱ

推流端（主播端）替换为 RTC：收益中。

因为主播网络环境一般还不错，所以不优先考虑主播端。

RTC 应用场景：在线教育

• 一对一教育

• 产品功能

• 1V1 教学

• 白板、课件

• 云端录制

• 监课

• 技术特点

• 课件同步

• 音视频通话类似

• 可能需要跨国

• 要求和音视频通话一样，需要及时反馈，需要低延迟，跨国一对一可能物理距离较远，导致延迟可能较高。

• 大班课

• 产品功能

• 万人课堂

• 白板、课件

• 云端录制

• 监课

• 技术特点

• 1 人发布

• 课件同步

大班课技术难度比 1V1 教育低，因为一般情况下只是老师一个人推流，不存在过多互动。总的来看，大班课互动性较差，学习体验可能不是很好。

于是，小班课就产生了，它有较强的互动性，但是其难度最大，比 1v1 教育难度要高。因为每个人网络环境不一样，需要给不同用户下发不同码率的视频。

• 小班课

• 产品功能

• 多人互动

• 白板、课件

• 云端录制

• 监课

• 技术特点

• 多人发布与订阅

• 课件同步

RTC 使用场景：视频会议

• 飞书视频会议

• 产品功能

• 百（千）人视频互动

• 屏幕共享

• 文档分享

• PSTN 接入

• 背景虚化，美颜...

• 技术特点

• 多人音视频互动

• 接入设备多样性

• 音频降噪

• 弱网优化

• AI 能力

总体来说，视频会议的技术难度较大，对音频降噪的要求比较高，同时存在 PSTN 接入的情况。

RTC 使用场景：游戏

• 游戏对战

• 产品功能

• 小队语音

• 范围语音

• 技术特点

• 低延迟、低耗能、流量小

• 范围语音

因为游戏比较耗计算机资源和网络资源，又要求低延迟。所以需要达到低延迟、低耗能、流量小。

• 云游戏

• 产品功能

• 游戏运行在服务端

• 客户端渲染、控制

• 技术特点

• 超低延迟

• 海量控制指令

这样即使设备性能不高也能实现尝试高性能的游戏。适用于大型游戏和游戏试玩。

因为需要良好的游戏体验，就需要超低延迟。而且因为我们 RTC 可以传输海量的控制指令，所以可以用于云游戏。

实时音视频技术概览

RTC 系统架构图

信令是一些控制指令，信令服务器可以用于呼叫、协调。

合流转推等等这些操作是后处理服务器来完成的。

客户端是音视频通话的终端，我们来看看客户端整体技术架构。

QoS 是保证在弱网的情况下仍然能够使用。

事件上报是因为任何的日志都需要上传，可以处理错误和进行性能优化、算法改进。

• 全平台支持

• 设备适配

• 性能适配

• 连接保持

• 断网重连

• 多径传输

• 数据运营

• 事件上报

• 日志收集

低性能的设备使用低性能的算法。

同时支持 WIFI、4G 就需要实现多径传输。

采集到音视频等数据需要进行编码压缩然后通过网络传输，然后解码播放。

信令服务器

信令：为使网络中各种设备协调运作，在设备之间传递的控制信息。

信令服务器：就是用来传输、中专信令的服务器。

• 常见问题

• 全球化部署

• 信令到达率

• 连接保持

• 实现方案

• WebSocket

• 自定义协议

媒体服务器

媒体服务器：在终端用户之间中转音视频流，进而让用户之间可以进行音视频通信。通常部署在边缘，距离用户较近的地方。

Simulcast&SVC 是根据不同用户的网络状况提供不同码率、帧率的视频。

BWE&拥塞控制是用来估计用户的可用带宽，来判断给用户发送多大码率的码流。

下面来看看几种媒体服务器的典型架构：

后处理

• 音视频录制

• 合流转推

• 截图、切片

• 审核

还有什么？

• 数据运营

• 质量评估

• QoS

• 自动化测试

• 应用场景探索

需要数据才能优化，视频是否清晰，音频是否悦耳这就需要质量评估。

自动化测试和质量评估也是比较重要的。

去探索新的应用场景也是非常重要的。