火山引擎举办了 V-Growth 云端一体增长沙龙，本场沙龙围绕体验升级与业务创新，聚焦 RTC、智能美化特效、云游戏等业务场景，深入探讨了如何打造云端一体的全链路音视频能力。活动中，火山引擎 RTC 负责人宋慎义从实时性、富媒体传输、多人互动、全球化、RTC 与其他模块协同 5 个方面，详细阐述了火山引擎 RTC 的技术实践。
一、实时性
为解决实时性问题，我们在传输的信源分类、信道建模、信道策略三方面进行分别考虑。首先针对信道进行建模，根据信源分类和信道建模特征来整体调整信道策略。
信源
信源分类重要的是信源的分级，我们把信源用可靠性、实时性两个维度进行拆分。整体上需要传输的信息可以分为如下几类：
以音频内容为例，高频信号与低频信号在整体的音频的信息中，重要程度不同。很显然，低频分量重要性更高。视频也一样，不同清晰度的视频中，低清的重要性要比高清视频更高。
我们经过很多信道优化，可以将弱网环境下的丢包率优化至 2%-5%。在剩下 2%-5% 的丢包场景中，就需要让信源进行容错，例如：
信道
信道面临的主要挑战是如何评价信道的质量，有哪些评价体系。传输技术的好坏，最主要取决于能以多高的准确性、多快的速度评估信道。在过去，信道的评估往往只有信道容量这一个维度。后来有了一些新的评估手段，例如延时、带宽时延积、丢包等，现在主要用延时丢包乱序、平稳性等各个综合指标，以及主动探测、被动探测等多种方式来评估。整体上使用多种方法把信道尽可能完善、快速的描述、评估出来。
评估之后就是信道分级。信源是根据可靠性、实时性分级，信道也一样，可以把最可靠、实时的一些信道优化方式用于传输最重要的信息。
我们在搜索 RTC 时会了解到很多传输协议，但其实传输协议的格式并不重要，因为所有传输协议最终实现的都是 3 个目的：
信道策略
所以好的实时性保证，需要信源、信道分级相结合，用合适的协议传输合适的内容。
同时我们也需要考虑实时性的扩展优化，例如信道的容量是否可扩展？在早期 RTC 优化中，对信道容量是没有过多拓展的。但其实现在我们很多设备都是多网卡的，服务端转化也是多链路的，这些都可以实现扩展。
信道的扩展既可以扩充传输容量，另一方面也可以提升传输稳定性。
同时，不同场景对实时性的要求不同。例如在大型会议中，需要交互的观众并不多，对于不需要参与交互的观众，实时性要求并不高，我们就可以把最优质的信道、传输容量留给最需要实时的信息。火山引擎 RTC 目前能够实现在 70% 的突发丢包和 500 毫秒的突发乱序或延时场景下，保证重要数据不丢失，不影响信息理解和正常沟通。
二、富媒体
最开始的 RTC 传输都只采集单纯的视频和音频，而近年来越来越多的富媒体应用场景不断诞生，例如：体积视频包括全景视频、VR、双目等新场景；多信源也包括 KTV 合唱、多画面等应用；最近比较流行的全景声，也伴随着多声道和高精度采样等技术。
全景视频分块并行编码
其中全景视频对 RTC 的挑战巨大。火山引擎的解决方法是把 360 度的全景分层，分为一个 8K 超清视频和一个 540P 标清视频。对于 8K 的超清视频，整体的传输需要进行超清视频分块并行编码和局域传输。并行编码的技术有很多，例如 H.264 可以按照 Slice 进行编码，H.265 按 Tile 编码，最终实现在有限信道传输特定信息，标清的这一路视频作为背景进行兜底。这样在看全景视频时，即便当前网络无法传输很高清的图像，有 540P 的视频也不会影响流畅性。此外，因为全景视频经常用于教育、工业等场景，火山引擎私有云、边缘云可以提供局域网加速方案。
多信源下的实时性实现
富媒体下面临的另一个挑战是多信源。大家经常面临多个人需要同步沟通的场景。行业的通用做法是尽量降低延时，所有人的延时都很低，自然可以实现同步。我们在这个基础之上做了一些优化，即利用全局时钟同步信号，发布给所有发布端和接收端。这样产生的信源音频和视频都会同步进行时钟对齐，接收端也通过这个方式，即便在唱歌等场景下都能实现实现不同端很好的实时性。
此外，近些年研究的热点就是全景声的空间音效。如果要实现极致体验，不仅需要双声道，还需要多声道才能更好满足。不过目前很多的音频编解码和传输方式，对多声道支持并不太好。
另一个热点就是高精度采样，大家应该都知道奈奎斯特抽样定理，人耳感知是 20-20kHz，所以奈奎斯特抽样定义大概抽样到 40kHz。但这个方式有一些弊端，它只对连续信号可以进行采样，对于离散信号采样精度会严重影响整体视频的清晰度，目前火山引擎也提供了高精度采样，例如 24bit；在没有高精度采样的场景下，我们也提供更高的采样率，例如 96kHz、192kHz 的采样率的编解码，可以实现在不同场景下的重采样。
另外，在高精度采样和多声道场景下，音频编码之后的数据会非常大。为了让全景声能够在实时场景下得到更好的传输，我们引入了多描述编码 MDC 技术，Codec 就可以实现让全景声信号分层，达到非常低的延时。目前火山引擎 RTC 已经具备在 8K/120fps、100Mbps 源流情况下，能够实时观看 10Mbps FoV 流的传输能力，在多个观看端一起观看的情况下，pct95 端到端延时小于 500 毫秒，头动延时小于 300 毫秒。
三、多人互动
近些年随着 RTC 技术发展，互动人数、互动规模不断提升，这对 RTC 造成了更大挑战。
在超大房间，很多用户快速进房、退房时会有消息风暴；同时传输的拓扑也会不断进行动态的生成与重建；另外音视频的拓扑也会面临分离传输的情况。
火山引擎 RTC 在多人互动架构上也进行了多轮的演进：
1、在人数比较少的情况下，可以使用网状 SFU（大多数 RTC 架构采用的方式），相对简单，又可以实现全量交换，但服务端很容易遇到转发瓶颈；同时，因为每个人都是对等的，当人数很多，快速进房退房时，会产生信令的广播风暴。
2、网状拓扑变成树状拓扑，可以解决几百人规模互动存在的问题，但如果想达到更高的互动，还需要继续优化。例如：
目前火山引擎 RTC 支持单房间内 2 种超大规模互动的方式：
四、全球化
在面临全球化场景下，快速进房、稳定性是两大长期研究方向。
这是一个数据链路层的 Overlay 网络，相当于把我们之前局域网上的 SDN 搬到了公网上。当然这也面临一些新挑战，例如公网上的节点多种多样，且数量庞大，当达到上千的量级的时候，单一的路由中心也不能管理了。
于是我们又建设了分布式的路由表，而且本身的这个二层 Overlay 网络的传输能力也是能够根据 payload 进行分级 QoS 的。有了这个系统，节点和区域的故障就能够实现秒级感知和切换。
经过上述优化，火山引擎 RTC 能够实现全球传输延迟 PCT995 200 毫秒以内、全球端到端延迟 PCT95 400 毫秒以内，全球接入可用性达 99.9% 以上，全球转发可控性达 99.9% 以上。
五、RTC+X
在越来越复杂的场景下，客户往往不会单一的使用 RTC，而是更倾向于与其他多个模块协同共同解决一个或多个复杂的功能。RTC 与其他模块、客户自身应用的协同，则又是一大挑战。
RTC 在 APP 中，与点播、直播、网页、消息、下载、API 共存，不仅共用音视频设备，还共用网络带宽、CPU/GPU 内存。
所以 RTC 一定不能设计为专门抢占资源、带宽，而是需要考虑如何更好识别当前资源占用率，并能够允许客户自定义给 RTC 预留资源、使用特定限制的资源。
火山引擎 RTC 为实现与其他模块、客户自身应用的更好协同，目前已支持外部采集、渲染；带宽/性能数据的实时回调；根据静态设备适配清晰度、码率；动态性能/带宽的升降级；同时还支持自定义的降级策略。例如客户可以为 RTC 设定一个特定的带宽上限，也可以让 RTC 预留现有带宽 20% 给其他业务使用；以及当 CPU 使用率达 80%，RTC 直接进行降级等策略。
基于上述的方式，RTC 可以在确定的资源下与其他模块进行更好的协同。
