腾讯云音视频RT-ONE™&TRTC：三合一融合赋能多场景创新-技术圈

今年腾讯云音视频发布了“三合一”的RT-ONE™网络。该网络整合了腾讯云实时通信网络（TRTC）、即时通信网络（IM）以及流媒体分发网络（CDN）三张网络，为业界最完整的音视频通信PaaS平台构建基座，面向教育、零售、泛娱乐等行业需求提供服务。本次新知系列的第一堂课，我们邀请到了腾讯云音视频的技术导师 —— 刘连响，为大家详解RT-ONE™并分享RT-ONE™&TRTC赋能实时音视频场景的一些创新。

RT-ONE™

一站式、高质量满足基础网络协同需求

关注「腾讯云音视频视频号」，每天有新知

RTC即Real-Time Communication，这里面C代表Communication。但随着音视频技术的不断发展，其边界也在不断延展，现在C不仅仅是Communication，它还可以是Content、Control等等。当我们在在线教育、娱乐直播、游戏直播等场景中实时的消费内容，RTC便成为了面向内容的Real-Time Content。而当我们在云电脑、云游戏、远程驾驶、远程协助以及实时同屏等场景中实时的对远程进行操作并看到操作的结果，RTC便成为了面向控制的Real-Time Control。

虽然RTC的边界在不断扩展，但其基础依然是实时音视频技术。只是越来越丰富的实时场景对底层的音视频技术及基础网络提出了很多新的要求。比如：

超低延时的要求，延时越低越好，在云游戏、在线合唱、云电脑场景下，已经开始要求端到端小于100毫秒的延时。
大规模互动的要求，在在线教育大班课，线上活动直播场景下，需要满足单房间几万甚至几十万的实时互动直播，更高质量的传输效果和更大的带宽的要求。
视频开始追求2k甚至4k的高分辨率，甚至开始追求3D的内容和VR的内容。
音频开始追求空间音频以及高品质音乐的实时传输。
全球接入的需求，我们的客户是面向全球的，需要保证全球各个国家和地区的客户接入。
最后则是全场景的要求，客户的场景是很多变的，甚至很多场景下是互相冲突的。比如大房间互动直播，更关注低卡顿而可以牺牲延时指标。云游戏场景下则更关注于延时。

面对这么多的需求和挑战，腾讯云音视频给出了自己的解决方案 —— RT-ONE™。RT-ONE™包含三个网络，TRTC实时音视频通信网络，IM即时通信网络，CDN 流媒体分发网络，我们把这三张网络整合成一个网络，底层技术复用，互相融合，互相赋能，满足客户各种多变实时互动场景下的需求。目前，RT-ONE™已经拥有2800多个CDN加速节点，而且数量还在持续增长中。除了自建的节点之外，我们还在与第三方合作伙伴合作，引入第三方的节点。除此之外，RT-ONE™还拥有200Tbps+ 带宽储备，日通话时长超过31分钟，以及10亿+ IM全球月活。

那么“三网合一”的RT-ONE™能够带来哪些优势呢？

1. 互相融合、互相赋能。对于一个直播产品来说，一开始用户可能只是需要普通的直播能力，之后如果他开始需要连麦，直接上行切换为TRTC云端混流再进行旁路的直播，就可以实现，原有的业务逻辑都不需要动。如果用户对延时不满意，可以将普通的CDN直播可升级为快直播，只需要简单的修改一些参数就能完成。如果用户对延时和质量还有更高的要求，可以用腾讯云音视频的一套SDK升级为互动直播。此外，朋友关系、聊天等功能也可以通过开启腾讯云音视频的IM能力来快速实现。

2. 技术共享、技术复用。举几个例子，快直播是RTC技术和CDN技术组合而成的产品；云游戏，是基于TRTC的技术，再加上低延时和大码率的优化而产生的产品；远程控制，则是基于TRTC的技术，再加上超低延时的信令组合而成的。我们把技术共享、技术复用就可以在一个月内甚至更短的时间内组合出来创新的玩法。

3. 体验统一。腾讯云音视频对控制台进行了协同，推出了腾讯云视立方·音视频终端引擎产品，可以在一个控制台下管理IM, 直播和互动直播等多种能力。账号系统也进行了统一，用户可以用同一个账号来管理IM, 直播，TRTC的用户，进行统一登录，鉴权。监控&日志系统也进行了打通，用户可以在一个地方查看不同能力的用量，监控用户状态，查看用户日志。我们技术统一，体验统一，让用户可以随意组合，便捷管理，随心创造出各种实时场景。

TRTC的整体构架&技术特性

介绍完RT-ONE™基础网络，我们再来介绍一下TRTC 腾讯实时音视频。TRTC 源自于QQ音视频团队，是基于QQ22年来的⾳视频技术积累，以PaaS产品的形式开放出来的RTC云服务。TRTC 支持了腾讯会议、微信群直播、微信视频号直播、企业微信直播、腾讯课堂、全民K歌等国民级业务，是腾讯集团丰富的音视频场景的最佳实践输出。

TRTC的整体架构

TRTC 的客户端SDK是全平台覆盖的，我们覆盖了微信小程序、QQ小程序、企业微信小程序及浏览器， iOS、Android、Windows、macOS、Linux平台。除此之外TRTC还支持了Unity SDK，Flutter SDK，React Native SDK。TRTC 可以旁路到云直播并通过CDN分发，这样就可以复用直播系统的转码、极速高清等等能力，并录制存储到云点播。

TRTC包含两个大的基础场景，第一个基础场景是多人实时互动。TRTC针对多人实时互动进行了深度优化，全球端到端延时小于300毫秒，抗丢包率超过80%，抗⽹络抖动也超过1000毫秒，单个房间支持300人同时在线，50人同时上行音视频。

第二个大场景就是超低延时直播，观众可以实现平滑上下⻨，单房间⽀持10w⼈一秒以内的低延时播放。

TRTC的技术特性

TRAE音频引擎

在实时互动场景下，用户的音频数据是“即发又收“，3A处理必不可少，比如你的声音经过远端传送过来，并再通过外放放出来之后就会产生回声，通话过程中的各种背景噪声也会带来不好的通话体验。

我们在讲话的时候声音是连续的，但如果你把这个时间颗粒度放小，你会发现声音是连续的波形，如果在传输的过程中丢了一小部分，可以根据这个波形来补齐，这种技术叫做PLC，但如果你连续波形丢的比较多，恢复回来就会有很大的难度。

TRTC的cPLC技术可以很好的应对音频连续丢包的场景，cPLC会根据历史语音帧进行上下文分析然后进行波形合成，即使在120毫秒级别连续丢帧的情况下，语音通话效果也能非常的顺畅。

全链路H.265支持

大家都知道H.264是行业主流的编码方案，H.265相比于H.264来讲，在相同画质的情况下，大概会有30%的带宽节省。TRTC房间内用户可以动态的协商编码能力，在H.265能支持的情况下会开启H.265，并可以转推H.265到直播系统，观众可以从直播系统中拉取H.265的编码能力的直播流，从而大幅节省带宽成本。

云端智能流控系统

TRTC支持动态调整客户端QoS策略，可以动态配置拥塞控制， FEC⽐例、ARQ的⽐例。基于云端的控制引擎，TRTC能不断收集BadCase并通过BadCase积累⼤量规则，让调控更具有针对性。即使身处⼀个房间，也能做到每个用户独⽴调控，保障每个⽤户的⾳视频体验。

TRTC会根据：丢包率，延时，抖动，设备信息、性能指标来总体做出决策。⽐如在海外英语教学场景下，对应低端机、⾼延时场景，TRTC会采⽤⾼RTT策略；语⾳聊天室对应双声道、⽴体声场景，TRTC会采⽤⾳质优先的qos策略；⼩班课对应低延时、低课损场景，TRTC会使⽤多⼈QoS策略；低延时直播场景，对应强互动、⾼画质，TRTC则会使⽤画质优先的QoS策略。我们会通过历史的⾳质评分，画质评分，流畅表现在提升我们的QoS流控系统。

房间内⾳频混流

TRTC采用了腾讯会议同款混⾳引擎。在常规的⾳视频通话场景中，每个⽤户都会有⼀路⾳频，我们进⼀步优化⾳频的带宽使⽤，引⼊了房间内⾳频混流。TRTC基于能量竞争选路，实时下发发⾔⼈身份以及⾳量，多路⾳频变一路，降低用户带宽。这样做的另一个好处是将混流计算放到了服务端，能减少客户端的CPU使⽤。

超大房间支持

TRTC针对大集群做了Set改造，按照国家、地区、运营商分解为固定大小的Set， Set内自动选择扩散代理，按流的粒度进行收敛，缓解上行节点的媒体分发压力。绝大部分Set通过内网互联，这样针对某些海外偏远国家和国内边缘节点，它们和其他节点互通只需要一跳就可以回到国内。

房间服务器改造

在房间管理部分，TRTC从原来的集中式管理升级为分布式房间管理和信令通道，房间服务只保存用户列表和视频列表的基本信息，极大地减轻了控制系统的负担。

在新的架构下，TRTC对房间按订阅关系进行了拆解，在内部集群做了一层收敛，这样运算量就会非常少，从而实现了房间规模的扩展。房间服务所有的信息都可以动态扩展并快速恢复。比如核心节点宕机，这个核心节点的信息在其他的节点中都有，只需要更换一台机器，并把原来的信息搬到这台机器上，就可以得到完整信息。

再比如Set中有一个小的节点宕机，但媒体节点里的信息是完整的，换一个新的机器，将数据重新构建，那么这个房间就可以重新构建出来。在新的架构下，保守估计，TRTC单房间支撑可达100万人，并具备高可用、高可扩展、高可靠等特点。

TRTC和WebRTC的互通

WebTransport + WebCodecs+

WebAssembly 新方案

大家应该都听过WebRTC，WebRTC的前身是GIPS, 在2011年Google收购了GIPS并开源出来命名为WebRTC， 10年之后就是2021年WebRTC1.0正式定稿。但WebRTC本身仍存在很多问题，比如浏览器之间的适配问题，QoS可定制的空间比较小，以及硬件编码器的适配问题。腾讯云音视频在WebRTC上面做了很多的优化，比如端和后台之间互相作用的带宽评估算法，在有些场景，我们采用发送端来进行带宽评估，而在屏幕共享的场景，我们则使用后台来进行带宽评估。我们还做了大量的各平台各版本之间的明控适配以及动态的pacing支持，客户可以配置追求低延时还是追求低卡顿。

在Web端中不得不提的一套新的API组合：WebTransport + WebCodecs+ WebAssembly。

我们先介绍一下WebTransport，WebTransport是 WebRTC体系下的一套浏览器API，提供低延迟client和server之间双向通信的能力。WebTransport 提供基于QUIC 和 HTTP3实现的API, 自动获得QUIC和HTTP3本身的特性，比如应用层的拥塞，避免队头阻塞。双向通信的能力，多个传输通道复用一个连接的能力，能够很好的替代WebSocket。同时它提供了发送/接受不可靠UDP的能力，这个是浏览器一直欠缺的能力。

第二个Webcodecs是在浏览器中提供高效的音视频编解码的API。在目前的WebAPI中，已经有了MediaRecorder 和 MSE 两套编解码相关的API, 但它们都有很多限制。比如 MediaRecorder 允许将含有视频和音频的mediatrack 进行编码，但对于一些关键参数无法进行控制，比如对编码的精确控制，对关键帧的精确编码控制。同时它在输出数据前会有一段缓冲，这对于低延时的场景以及需要使用自有容器格式的场景也不合适。MSE也可以实时解码媒体数据，但对于音视频的输入输出有比较大的限制。WebCodecs 提供的高效音视频编解码API 能扩展更多的场景。

最后是WebAseembly。WebRTC作为浏览器的一个标准，在浏览器中我们无法控制WebRTC的内部工作机制。对于有能力处理好音视频前后处理的团队来说，加上WebTransport的提供的传输能力以及Webcodecs编解码能力完全可以在Web端通过WebAseembly来定制自己的RTC协议栈，这个想象力的空间特别大，我们也在做这方面的探索。

TRTC和aPaaS、云函数

TRTC和aPaaS

aPaaS可以让客户基于PaaS快速地搭建自己的应用，极大的降低了客户接入的成本。TRTC提供了泛娱乐场景、互动课堂场景以及通信场景的aPaaS解决方案。

在泛娱乐场景TRTC提供了在线KTV、语音沙龙、互动直播、实时合唱等丰富的场景玩法，客户换个皮肤就可以快速上线业务；在互动课堂场景，TRTC提供1V1精品课、小班课、大班课、小组课方向的aPaaS产品；在通信场景我们提供了轻量化的商业直播组件，企业通信、商业直播、音视频通话组件。

TRTC和云函数

云函数的特点是全球分布式集群部署，提供高可靠性的服务。它具有一键触发，免运维，弹性伸缩等特性。云函数还可以编程，可以快速整合其他第三方服务，高效的创造新的玩法。

TRTC基于云函数也构建了多个解决方案。第一个就是基于云函数的TRTC的合流录制方案。基于云函数高可用，低运维，弹性伸缩的特性，TRTC构建了定制化程度高的录制合流方案。比如我们可以把视频录制成不同的存储格式，灵活地调整录制的布局。

第二个是基于云函数，为TRTC在线输入媒体流。主要运用在以下场景：

同一个直播间内，主播与观众一起看电影、一起看赛事直播。
把老师预先录制好的课程再实时的推送给学生，学生之间观看老师课程的同时，还可以实时交流互动。

第三个方案是基于云函数的全景录制方案。在线教育场景的录制往往比较复杂，录制的过程中往往不单要录制老师和学生的音视频，还有白板互动，动画课件，PPT，以及聊天内容等，有的时候还会有家长旁听。这样的录制有很多痛点：比如多路音视频同步、学生上下麦导致的录制布局不断变化，音视频和PPT录制比较难同步，课件中的白板动画不易还原，真实上课过程中的互动效果难以还原等。TRTC基于云函数提供的解决方案是使用Headless Chrome 加载一个用户要录制的页面，并跑在云函数的docker镜像中，通过HTTP API的方式来触发录制，把该页面中的内容完整录制下来。云函数帮助我们做好了资源调度和资源隔离，不需要额外部署服务，免去了大量运维工作。

这样录制的方案有很多好处：

一个就是极优的录制效果，所见即所得的录制。页面中的音视频，课件内容，白板交互，动画特效，甚至聊天都可以录制下来。
第二个就是集成成本低。基于全景录制，免去了用户设置各种布局参数的成本。通过云端API控制何时开始，何时结束录制，录制完成之后可以设置回调。
第三个就是定制容易，通过调整录制页面的布局，就可以完成录制布局的调整，甚至可以复用现有的课堂页面。运维开发成本低，我们基于云函数开发，云函数提供了完整的资源调度隔离方案，还有完备的日志监控工具，可以做到即用即开，毫秒级的计费，极大地减少了大量的开发运维的成本。

目前这个全景录制方案已经在多家在线教育公司落地，反馈效果特别好。

TRTC相关场景的优化解决方案

TRTC+云游戏

TRTC+云游戏就是一个互动云游戏的场景。云游戏相信大家都不陌生，从2000年以来就不断的有人在喊云游戏，但它这两年才真正发展起来。中国的整个网络环境与用户的终端能力以及技术的成熟度，都已经能将端游和手游进行云化，甚至也出现了云游戏原生的游戏。

腾讯云基于TRTC 提供云游戏的PaaS服务，可以在很短的时间内将一款游戏进行云化。云游戏对技术的一些需求，比如超低的延时（端到端的延时，希望在100毫秒以内），还有超低延时的信令，超大码率的要求（很多云游戏要求10兆以上的码率），还有多终端的支持，要支持桌面浏览器，手机端的浏览器，微信环境，iOS/Android平台，甚至大屏TV端。目前腾讯云的云游戏方案已经落地多家厂商。其实我们还看到了一些创新的玩法。比如菜鸡游戏，在云游戏中做了主播与观众的接力玩法，比如主播正在玩，观众都在看的时候，观众可以申请与主播一起玩，可以接管云游戏控制权，甚至可以跟主播在游戏中PK, 还能进行实时的音视频通话。我们认为云游戏的发展还在出初期，非常期待看到这个方向上不断的新的创新。

TRTC+营销

TRTC+营销就是腾讯云呼叫中心产品 TCCC，在客服和营销产品中经常会用到。它的优势主要有：

全渠道多触点融合通信方案。它集电话，在线会话，音视频通话为一体的融合通信能力。
AI应用助力效能全面提升。智能外呼机器人，智能在线客服能高效的解放生产力。智能坐席的语音助手，智能质检能全面提升客服服务质量；
微信&企业微信生态天然链接。微信公众号，微信小程序，微信客服全面链接，无缝对接企业微信，实现公域->私域全流程的客服服务。在用户侧可以通过电话呼入，在线IM方式接入以及音视频通话的方式接入。在客服侧，我们提供了融合通信能力的工作台。

TRTC+远控

TRTC+远控就是我们的远程驾驶方案。我们先看两个大的方向，一个是辅助驾驶，在最新的自动驾驶分级标准中引入了远程协助和远程驾驶的概念，以及远程助手和远程驾驶员。实现了本地介入到远程介入的转化。在高危复杂恶劣环境作业场景下，通过远程操控，可以使一线作业人员远离危险，为一线人员提供安全舒适的作业环境。在矿山场景下，无人矿卡、无人挖掘机、钻机、推土机，这些都需要远程的控制能力。在港口场景中无人集卡，它是一个自动驾驶和远程控制互相配合的场景。无人吊车，主要是远程控制能力。在冶金方面主要是无人天车(AI吊装+远控)。在开放道路中主要是无人物流车，它需要的是一个自动驾驶和远程控制互相配合的方案。我们在这个方向上也做了大量的优化，TRTC与5G技术做了极致的融合，TRTC团队和5G团队进行了深度的优化，端到端的延时在5G专网情况下可以低于100毫秒，在省内的情况下，可以低于150毫秒，全国范围内可以低于200毫秒。我们还适配了工业场景下常用的硬件编码器，还适配了工业场景中使用的摄像头，后面还会陆续推出基于AI的能力，辅助远程驾驶来规避障碍，识别行人等等。你们都说开挖掘机是每个男人的梦想，可能通过我们的远程驾驶方案，真的可以让你在家里远程开上挖掘机。

TRTC + 考试

TRTC + 考试就是我们的在线考试方案。疫情对各种各样的考试造成了很大的阻力，各大考试纷纷转到了线上。学生在线远程考试，监考老师通过摄像头,通过录屏进行远程监控，同时通过全程录制保存考试过程。考试场景有它的特殊性，比如突发进房，往往在考试开始的时候开始密集进房。考生需要推送多路流比如可能有摄像头、可能有屏幕录制，可能还有一路流监控身体姿态。TRTC 和 IM 组合推出了在线考试方法，我们的优势有，百万级的并发能力支持突发的考试场景，云端的多路录制、存储、可以随时调取考试过程。

最后，RTC的场景和方案越来越多，这也说明RTC越来越多的成为基础设施。TRTC会在这场变革中赋能更多的创新和场景。

点击文末「阅读原文」可以前往云+社区，查看往期完整内容。