新知：RTC+X:RT-ONE和TRTC赋能实时音视频场景创新原创

大家好，我是腾讯音视频的技术导师刘连祥，首先介绍一下我自己目前主要是在做TRDC和握把这些方向的技术研发工作，今天给大家带来的分享是r tne和TRDC赋能实时音视频场景创新。我们先介绍一下r tne到底是什么。在说到RT之前，我们先从web r TC开始。大家应该都听过我把C，我把C的前身是GPS。在2011年，Google收购了GPS，并开展出来，命名为web c。十年之后，就是2021年，V8C的1.0正式定稿，近年来通过腾讯云以pass的产品的形式开放出来，RTC，字面的意思就是实时通信c communication，但现在C还有了更多的含义。C content，死神的内容。

我们在在线教育、娱乐直播、游戏直播等场景中实时的消费的内容，我们称为面向内容的RTC。C、还可以是CTR实时的控制。我们在云电脑、云游戏、远程驾驶、远程协助以实时同频场景下，除了实时的互动之外，还需要对远程进行操作，并看到操作的结果。现在的实时场景对实时互动也提出了更高的要求。比如超低延迟的要求。延迟越低越好。在云游戏在线合唱云电脑场景下，已经开始要求端脑端小于100毫秒的延迟。大规模互动的要求。在在线教育大班课线上活动直播场景下，需要满足单房间几万甚至几十万的实时互动直播、更高质量的传输效果和更大的带宽的要求。视频开始追求2K甚至4K的高分辨率，甚至开始追求3D的内容和VR的内容的。

音频，开始追求空间音频以及高品质音乐的实时传输。还有全球接入的需求。我们的客户是面向全球的，需要保证全球各个国家和地区的客户接入。另外一个就是全场景的要求。客户的场景是很多变的，甚至很多场景下是互相冲突的，比如大房间互动直播更关注低卡顿而可以牺牲延迟指标。云游戏场景下则更关注于延迟。面对这么多的需求和挑战，我们给出了我们的解决方案，就是r tne r tone，包含我们三个网络。TRDC实时音视频通信网络，R'M即时通信网络。CDN0媒体分发网络。我们把这三张网络组成一个网络。底层技术复用，互相融合，互相赋能，满足各种多变实时互动场景下的需求。接下来给大家介绍一下阿T万的规模，目前R有2800个C丁加速节点。

除了我们自建的CD节点之外，还会与第三方合作伙伴合作，引入第三方的节点，节点数量还在不断的增长。有GPS的带宽的储备。我们日通话时长超过31分钟，以及11家I'm全球月活。八七是带来的优势。第一个就是互相融合，互相赋能。对于一个直播产品来说，一开始我可能只是需要普通的直播能力。然后开始需要连麦了。那直接上行切换为TRDC云端混流，再进行旁入到直播。原有的业务逻辑都不需要动。如果用户对延迟不满意了，普通的CDN直播可以升级为快直播，只需要简单的修改一些参数就能完成升级。

如果对延迟和质量有更高的要求，可以用我们的一套的SDK升级为互动直播。此外，如果用户还需要好友关系、聊天等，开启我们的I'm能力就可以完成。第二个优势是技术共享和技术复用。比如快直播产品就是RTC技术和CDN技术组合出来的产品。比如云游戏就是基于TRTC的技术，再加上低延迟和大码率的优化。再比如远程控制场景。就是基于TRDC加超低延迟的信令组合而来。我们把技术共享、技术复用，就可以在一个月内甚至更短的时间内组合出来创新的玩法。介绍完RT，我们来介绍一下TRTCTRTC是什么呢？就是腾讯实时音视频。TRTC源自于QQ音视频团队，是基于QQ21年来的音视频技术积累，在腾讯云上进行售卖的RTC云服务。

TRTC支持了腾讯会议、微信群直播、微信视频号直播、企业微信直播、腾讯课堂、全民K歌等业务。是腾讯集团丰富的音视频场景的最佳实践输出。那我们来介绍一下TRTC的整体架构，TRTC的客户端SDK是全平台覆盖的。我们覆盖了微信小程序、QQ小程序、企业微信以及浏览器。IOS、安卓、Windows Mac Linux平台。除此之外呢，我们还支持了SDK Fla的SDK以及react SDK。TRTC可以盘入到云直播，并通过CDN分发，这样的话就可以复用直播系统的转码、极速、高清等等能力。并录制存储到云点播。TRDC包含两个大的基础场景，第一个基础场景就叫多人实时互动。

针对多人实时互动，深度优化，全球端到端延迟小于300毫秒。抗丢包率超过80%，抗网络抖动可以超过1000毫秒。单个房间支持300人同时在线，50人同时上行音视频。第二个大的场景叫超低延迟直播，观众可以实现平滑上下麦单房间，支持十万人一秒以内的低延迟播放。接下来介绍一下TRTC的一些特性。TE。是领先行业的音频引擎，在实时互动场景下，用户的音频数据是既发又收的，3A处理必不可少。比如，你的声音经过远端传送出来，并在通过外放放出来之后，就会产生回声。通话过程中的各种背景噪声也会带来不好的通话体验。我们在讲话的时候，声音是连续的，但如果你把这个时间颗粒度放小，你会发现声音是连续的波形。

如果在传输的过程中丢了一小部分。我们可以根据这个波形来进行补齐，这种技术叫做PLC，但如果你连续波形丢的比较多，恢复回来就会有很大的难度，音频在连续丢失多帧的时候会严重伤害体验。TRT4的EPLC技术可以很好的应对音频连续丢包的场景。EPLC会根据历史语音帧进行上下文分析，然后进行波形合成。即使在120毫秒级别连续丢帧的情况下，语音通话效果也能非常的顺畅。全链路SR65的支持。大家都知道HR64是行业主流的编码方案，HR65相比于HR4来讲，在相同画质的情况下，大概会有30%的带宽节省，TRDC房间内用户可以动态的协商编码能力，在HR65能支持的情况下，会开启265，并可以转推HL5到直播系统，观众可以从直播系统中拉取HR的编码能力的直播流。

云端智能流控系统。可以动态调整客户端QS的策略，可以动态配置用设控制FC比例AQ的比例。基于云端的控制引擎，我们不断收集bad case，并通过bad case积累大量的规则。让调控更具有针对性，即使身处一个房间里，也能做到每个用户独立调控，保证每个用户的音视频体验。我们会根据丢包率、延迟、抖动、设备信息性能指标来总体做出决策。比如在海外英语教学的场景下。可以应对低端机高延迟场景，我们会采用高RTT的一些策略。

语音聊天室可以应对双声道立体声场景，我们会采用音质优先的QS策略。小班课对应低延迟、低课损的场景，我们会使用多人QS策略。D延直播场景对应，强互动、高画质，我们会使用画质优先的QS策略。我们会通过历史的音质评分、画质评分、流畅表现来提升我们的QS调控系统。房间内音频混流，我们采用了腾讯会议同款混音引擎。在常规的音视频通话场景中，每个用户都会有一录音频。我们进一步优化了音频的带宽使用，引入房间内音频混流。我们基于能量竞争选录、发言人身份以及音量实时下发。多录音频，便一路降低了用户的带宽。能带来的其他好处是，我们把混流计算放在了服务端。

能减少客户端的CPU的使用。KC超大房间的支持。首先，我们对大集群做了site改造，按照国家、地区、运营商分解为固定大小的site。下车内自动选择扩散代理。按流的力度进行收敛，缓解上行节点的媒体分发压力。绝大部分site通过内网互联，这样针对某些海外偏远国家和国内偏远节点，他们和其他节点互通，只需要一跳就可以回到国内房间服务器改造。在房间管理部分，我们从原来的集中式管理升级为分布式房间管理和心理通道。房间服务只保存用户列表和视频列表的基本信息，极大的减轻了控制系统的负担。在新的架构下，我们对房间按订阅关系进行了拆解，在内部集群做了一层收敛。这样运算量就会非常小，从而实现了房间规模的扩展，房间服务所有的信息都可以动态扩展并快速恢复。

比如核心节点舵机，这个核心节点的信息在其他节点中都有，只需要更换一台机器，并把原来的信息搬到这台机器上，就可以得到完整的信息。再比如set中有一个小的节点座机，但媒体节点里的信息是完整的，换一个新的机器，将数据重新构建，那么这个房间就可以重新构建出来。在新架构下，我们保守估计单房间可以支撑到100万人，并具备高可用、高可扩展、高可靠等特点。接下来介绍一下TRDC和Y8C的互通问题。Y8C本身存在很多问题。比如浏览器之间的适配问题，QS可定制空间比较小，以及硬件编码器的适配问题。我们在Y8Z上做了很多的优化。比如端和后台之间互相作用的带宽评估算法。在有些场景下，我们采用了发送端来进行带宽评估，但是在屏幕共享的场景下，我们使用后台来进行带宽评估。我们还做了大量的各平台、各版本之间的民控适配以及动态的ping支持。

客户可以配置追求低延迟还是追求低卡顿。在web当中，不得不提的一套新的API组合是web transport web codes以及web的新方案。我们先介绍一下web transport web transport是WE8TC体系下的一套浏览器的API，提供低延迟client是之间双向通信的能力。WE8C提供基于quick和DP3实现的API。它就自动获得了quick和TP3本身具备的一些特性。比如，我们可以在应用层做优势控制。我们可以避免对头阻塞，双向通信的能力，多个传输通道费用一个连接的能力能够很好的替代web socket，它提供了发送和接收不可靠udp的能力，这是浏览器一直欠缺的第二个web code。

Webs的目的是在浏览器中提供高效的音视频编解码的API。在目前的web API中，已经有了mid和MSE2套边界码相关的API，但他们都有很多限制。比如。Media record允许将含有音频和视频的track进行编码，但对于一些关键参数无法进行控制。比如对编码的精确控制，对关键帧的精确编码控制。Media在输出数据前会有一段缓冲，对于低延迟场景下不太合适，对于需要使用自有容器格式的场景也不合适。MSE。MSE可以实时解码媒体数据，但对于音视频的输入输出又比较大的限制。Web提供了高效的音视频的编辑版API，能扩展更多的场景。下一个是web SIM。

O8T作为浏览器的一个标准，在浏览器中我们无法控制O8的内部工作机制。对于有能力处理好音视频前后处理的团队来说，加上web transport提供的传输能力以及web的编解码能力，完全可以在web端通过web SIM定制自己的R3协议三。这个想象力的空间特别大，我们也在做这方面的探索。接下来介绍一下tr TC a。A pass可以让客户基于pass快速的搭建自己的应用，极大的降低了客户接入的成本。我们提供了泛娱乐场景以及互动课堂场景以及通信场景的a pass解决方案。在泛娱乐场景，我们提供了在线KTV、语音沙龙、互动直播、实时合唱。丰富的场景玩法，可以让客户换个皮肤就可以上线业务。在互动课堂场景，我们提供一对一精品课。

小班课、大班课、小组课方向的a pass产品。在通信场景，我们提供了轻量化的商业直播组件、企业通信商业直播、音视频通话组件。接下来介绍一下TRTC和云函数。云函数的特点有全球分布式集群部署，提高高可信的服务，云函数具有一键触发、免运维、弹性伸缩等特性。云函数还可以编程，可以快速整合其他第三方服务，高效的创造新的玩法。TRTC基于云函数也构建了多个解决方案，第一个就是基于运函数的TRTC的河流录制方案，基于运函数的高可用、低运为弹性申诉的特性，构建定制化程度高的录制河流方案。比如，我们可以把视频录制成不同的存储格式，灵活的调整录制的布局。第二个是基于云函数入为TRTC在线输入媒体流，可以设想这样的场景，同一个直播间内，主播与观众一起看电影，一起看赛事直播，还可以把老师预制路线好的课程在实时推送给学生，学生之间边看老师的课程，还可以实时的交流互动。第三个方案是基于云函数的全景录制方案，在线教育场景中的录制往往比较复杂，录制的过程中往往不是单纯的只录制老师和学生的音视频，比如还有白板的互动。

动画、课件、PPT以及聊天的内容，有的时候还会有家长的旁听功能。在线教育场景的录制有很多的痛点，比如多录音视频的同步，学生上下麦导致的录制布局不断的变化，音视频和PPT录制比较难同步。课件中的白板动画不易还原，真实的上课过程中的互动效果也难以还原。我们的解决方案是我们使用哈类似pro加载一个用户要录制的页面，并跑在云函数的刀客镜像中。

通过HPAPI的方式来触发录制页面的内容，进行完整的录制下来。运函数帮助我们做好了资源调度和资源隔离，不需要额外的部署服务，免去了大量的运维工作。站的录制方案有很多好处，第一个就是节约的录制效果，所见即所得，录制页面中的音视频、课件内容、白板交互、动画特效甚至聊天都可以录制下来。第二个就是集成成本低，基于全景录制，免去了设置各种布局参数的成本，并通过云端API控制何时开始何时接束录制，在录制完成之后可以设置回调。第三个就是定制容易。通过调整录制页面的布局，即可以完成录制布局的调整，甚至可以服用现有的课堂页面运维开发成本低，我们基于云函数开发，云函数提供了完整的资源调度隔离方案，还有完整的日志监控工具，可以做到即用即开，毫秒级的计费，极大的减少了开发运维的成本。目前我们这个全景录制方案已经在多家在线教育公司落地，反馈效果特别好。接下来给大家介绍一下RDC的一些场景，TDC加云游戏就是一个互动云游戏的场景，云游戏相信大家都不陌生。

从2000年以来就不断的有人在喊云游戏，但真正这两年才发展起来，中国的整个网络环境与用户的终端能力以及技术的成熟度，都已经能将端游和手游进行云化。甚至也出现了云游戏原生的游戏。腾讯云基于TRTC提供云游戏的pass服务，可以在很短的时间内将一款游戏进行云化。云游戏对技术的一些需求，比如超低的延迟。端到端的延迟希望在100毫秒以内，还有超低延迟的限令，超大码率的要求。很多云游戏要求十兆以上的码率。

还有多终端的支持。要支持桌面浏览器，手机端的浏览器，微信环境，IOS安卓平台，甚至大屏TV端。目前，腾讯云的云游戏方案已经落地多家厂商，其实我们还看到了一些创新的玩法，比如菜鸡游戏在云游戏中做了主播和观众的接力玩法，比如主播正在玩，观众都在看的时候，观众可以申请与主播一起玩。可以接管云游戏的控制权，甚至可以跟主播在游戏中进行PK，还能进行实时的音视频通话。我们认为云游戏的发展还在初期阶段，非常期待看到这个方向上不断的新的创新。TRTC加营销就是腾讯云呼叫中心产品。在客服营销场景中经常会用到。那它有哪些优势呢？第一个就是全渠道多触点融合通信方案，它其电话、在线会话、以视频通话能力为一体的融合通信能力。

第二个就是利用AI能力，助力效能全面提升。智能外呼机器人，智能在线客服，能高效的解放生产力。智能坐席的语音助手，智能质检，能全面提升客户服务质量。第三个微信企业微信生态天然链接。微信公众号、微信小程序、微信客服，全面链接，无缝的对接的企业微信，实现公域到私域全流程的客服服务。在用户那一侧可以通过电话呼入。在线I'm的方式接入以及音视频通话的方式接入。在客服侧，我们提供了融合通信能力的工作台。TRTC加远控就是我们的远程驾驶方案。我们先看两个大的方向，一个是辅助驾驶，在新的自动驾驶分级标准中，引入了远程协助和远程驾驶人员，以及远程助手和远程驾驶员，实现了本地介入到远程介入的转化。在高危、复杂、恶劣环境的作业场景下，需要通过远程操控，可以使一线作线人员远离危险，为一线人员提供安全舒适的作业环境。在矿山场景下，无人矿卡、无人挖掘机、钻机、推土机，这些都需要远程的控制能力。

在港口场景中无人集卡。它是一个自动驾驶和远程控制互相配合的场景。无人吊车主要是远程控制能力。在冶金方向要是无人天车。在开放道路中，主要是无人物流车。它需要的是一个自动驾驶和远程控制互相配合的方案。在这个方案上我们也做了大量的优化，TTC与5G技术做了极致的融合，TRTC团队和5G团队进行了深度的优化。端到端延迟在5G专网情况下可以低于100毫秒，在省内的情况下可以低于150毫秒。

全国范围内可以低于200毫秒。我们还适配了工业场景下常用的硬件编码器，还适配了工业场景中使用的摄像头。后面还会陆续推出基于AI的能力辅助远程驾驶来规避障碍、识别行人等等等能力。人们都说，开挖掘机是每个男人的梦想。可能通过我们的远程驾驶方案，真的可以让你在家里远程开上挖掘机。TRTC在考试就是我们的在线考试方案，就是在疫情期间对这种各样的考试造成很大的阻力。各大考试纷纷的转到线上，学生在线远程考试，监考老师通过摄像头，通过录屏进行远程监控。同时通过全程录制保存考试过程、考试场景有它的特殊性。比如突发进房，往往在考试开始的时候开始密集的进房。考生需要推送多路流，比如可能有摄像头，可能有屏幕录制，可能还有一路流监控身体的姿态。

TRDC和R'M组合推出了在线考试的方案。我们在线考试方案的优势有百万级的并发能力，支持突发的考试场景，云端的多路录制存储，可以随时调取考试过程。最后，RTC场景和方案越来越多，这也说明了RTC越来越多的成为基础设施，TRTC会在这场变革中赋能更多的创新和场景。以上就是我今天的分享。