本次分享我们邀请到了来自腾讯云实时音视频TRTC后台的研发负责人薛笛，他向我们分享了腾讯云TRTC在架构升级和产品实践中的经验。仔细讲解了混音引擎最初的制造源、在整个优化过程中发现的问题以及解决方法，为后来做腾讯会议和云呼叫中心打下了一个良好的基础。
文 / 薛笛
整理 / LiveVideoStack
大家好，我是来自腾讯云实时音视频TRTC后台的研发负责人薛笛。很荣幸今天能和大家分享腾讯云TRTC在架构升级和产品实践中的经验。
我们团队之前服务的对象是QQ音视频产品，它分为三个形态：双人、多人和群视频秀。前两者比较偏向于实时通话，而群视频秀比较像视频直播。在这几个产品中，最常用、体量最大的是双人视频通话，在规模上比多人场景和群视频秀加起来还多一个数量级，微信现在也差不多也是这样的。
01
音视频产品形态
1.1 双人音视频
从架构角度来看，双人音视频系统比较简单和清晰。红色点代表房间信令服务，房间信令服务主要功能是管理房间信息、实现能力协商和上下行联动的质量调控，比如当下行通道发生拥塞的时候，上行的码率、分辨率也会随之下降。
传输通道层面，我们的策略是优先选择直连，在跨地区和跨运营商的情况下，我们会选择单中转或双中转通道，在策略上尽量保持直连和中转通道同时存在，当其中一个通道质量不好的时候，系统会自动把流量切到另一个通道上。
1.2 多人音视频
多人视频通话的产品形态是整个房间不超过50个人，大盘平均房间人数大约4.x个人，房间里面最多满足一个大视频和三个小视频（四个画面）。根据这个限定条件，我们在架构上采用了典型的SFU小房间设计。
上图中红色点代表房间信令服务，主要用于房间管理和状态信息同步。房间管理主要包括用户列表的管理，比如哪些用户开了视频/音频、我观看了谁以及谁观看了我，这些都以房间管理的信息为准，然后房间信令服务会把这些信息同步给媒体传输服务用来做数据分发。
房间服务还有一个作用就是房间级的能力协商和质量调控，比如房间里一开始所有人都支持H.265编码，当某一时刻进来一个只支持H.264编码的用户，那么房间内所有的上行主播就必须将H.265切成H.264 。还有一种情况，当房间内有一定比例下行通道质量差的人，就会导致上行房间质量降级。
在传输层面上，我们采用单层的分布式媒体传输网络，我们全部选择中转方式，不区分双人和多人，采用Full-Mesh的传输机制，把数据全推过去，比如在一个节点上的人没有全都看另外两个人的视频，但是还是会把视频推给他们。
02
混音引擎
当时我们的产品还有一个特点——开视频的比例不高，反而纯音频房间非常活跃。我印象比较深刻的一个案例，一款热门游戏新出皮肤之后，语音房间的人数就会暴涨，这也是因为很多玩家使用QQ多人语音来开黑。基于这种现象以及成本考虑，我们开发了一个混音引擎。当房间人数超过成本线，我们就会把流都转到混音引擎，由混音引擎根据音量选路、混音重新编码后，再把流推到下行的媒体平台。它的架构已经不是典型的SFU，而很像MCU ，虽然当时的出发点在于成本节约，但这为我们后来做腾讯会议和云呼叫中心打下了良好的基础。
03
深度优化的云PaaS服务——TRTC
腾讯云实时音视频产品-TRTC，是在QQ多人音视频平台的基础上，针对To B场景深度优化改造之后推出的云PaaS服务。首先它提供了全平台SDK，这个SDK继承了QQ海量服务过程中，所针对的机型、硬件、系统层面的兼容和经验配置，它在各个平台上都有比较稳定的表现。其次这个SDK已经被集成到微信中，目前微信视频号直播、微信群直播和企业微信都用了TRTC-SDK和后台服务。外部客户也可以通过小程序的live-pusher和live-player两个标签来实现小程序和原生应用之间的高质量互通。在媒体的处理方面，我们和腾讯云多媒体实验室、腾讯会议天籁实验室以及QQ和微信都保持非常紧密的合作。在腾讯会议、QQ和微信里应用比较成熟的技术也都会被引入到TRTC中。
3.1 TRTC视频优化实践
在视频方面，我们采用时域分层编码来应对下行限带宽场景。一般直播产品在处理下行限带宽场景时，通常采用转码的方式——将原始码流转码出多种规格的流（原始流、高清、标清），根据不同网络质量切换不同的流。但RTC由于延时和成本考虑，一般不做房间内转码，所以我们需要在编码时把GOP内的帧序列进行分层，带宽超了的时候，选择丢弃一些增强层的帧、保留基础层的帧，同时对基础层的帧增加额外的冗余保护，以此来保障用户观看体验。
另一个经常和时域分层编码搭配使用的是RPS跨帧参考。RPS的策略是只有被接收端ACK确认过的帧才作为参考帧，这是通过牺牲一定画质来保障流畅性的策略。为了尽量减小画质损失，我们还设计了多种不同的参考模型来适配不同的网络情况。比如网络质量很好的时候，我们预测后面2-3帧大概率能收到，此时就不完全参照ACK模式，编码器在GOP的小分组内依然就近参考，从而保障清晰度；当网络质量下降时，我们会根据网络情况切换不同档位的模型，减少就近参考的数量；当网络持续变差的时候，我们才会严格按照ACK确认执行。
在编码效率方面，我们在编码之前会进行一定程度的滤波和降噪处理，这样编码的压缩率会有很好的提升，也能比较好的提升带宽。在资源有限的情况下，我们还会采用ROI把有限的码率倾斜到用户更感兴趣的区域。
3.2 TRTC音频优化实践
我们在音频处理中引入了腾讯会议的前处理和基于信源的抗性增强策略。比如开会中常见的敲键盘的声音、或者不那么常见的雨点打在窗户玻璃上的声音都可以很好的消除掉。
此外，我们自研的cPLC——基于上下文的丢包补偿技术，它可以把120ms以内的连续丢包恢复出来。以及我们自研的cFEC也比OPUS原生的带内FEC恢复效果更好，这样在正常网络下，不用加很多带外FEC就能应对一些突发丢包的场景。
当然，这些技术点如果单独拆开使用，是形不成战斗力的。我们必须要把编解码、信源和信道的抗性、带宽预测、拥塞控制和媒体传输有机结合起来，才能保证通话低延时高质量的通话效果，这也是RTC与标准直播最大的区别之一和它的魅力所在。
3.3 基于云端的智能化调控
在调控方面，我们开发了一个基于云端的控制引擎。把控制系统放在云端的好处是可以减少终端版本的兼容性问题，并且比较方便进行算法AB-Test的效果验证。
第二点是在运营过程中，我们通过BadCase分析积累大量的规则，这样对场景的识别更加准确，让调控更有针对性。
与此同时，我们在规则模型中提炼出丰富的配置参数，针对不同客户需求进行调优。比如有的通话产品客户希望流畅优先，而有的直播客户需要清晰优先模式，这些需求都可以通过调整配置来实现。
此外，我们在不断改进算法。在BBR出来的时候，我们参考了BBR带宽预测的方式，对超大规模房间的调控也做了适配。
04
TRTC架构演进之路
4.1 系统瓶颈与场景需求升级
说到规模问题，最开始讲到的多人音视频通话系统是基于小房间的SFU架构，在房间人数变多的时候会有一个系统瓶颈。首先是调控的计算和状态信息的同步，这两个是落在一台机的一个进程上完成的，当人数非常多的时候，运算量也越来越大，瓶颈就非常明显。
第二点，媒体传输采用单层分发结构，当房间人数越来越大，节点越来越多的时候，带宽就会产生很明显的瓶颈。
最后，为了减少内网穿越，接入调度采用了聚合分配的策略，同房间、同运营商、同地区的用户会优先分到同一台机器上，分满了再分下一台。当房间人数很多，短时间内一起进房的时候，服务的数据上报和状态同步可能更新不及时，导致节点超分。
但随着RTC技术场景的拓展，很多客户有10万人大房间的需求，如教育场景大班、超级小班课，大的语聊房以及电商直播带货等，所以针对客户需求对原始架构做了升级改造。
4.2 Set改造
首先我们对大集群做了Set改造——按国家、地区、运营商分解为固定大小的Set，Set内自动选择扩散代理，按流的粒度技进行收敛，缓解上行节点的媒体分发压力。绝大部分Set通过内网互联，这样针对某些海外偏远国家或国内边缘节点，它们和其它节点互通只需要一跳即可回到内网。
4.3 内网传输
内网传输部分是通过腾讯云的云联网来实现的，腾讯云目前已经在全球开放27个地理区域、61个可用区，内网专线有多条链路可切换，带宽储备充足。
在腾讯会议做高级别会议汇报的时候也经常做切换演练，几条专线可以互相切，实际应用下来内网质量整体比较稳定。
4.4 房间管理
在房间管理部分，我们从原来的集中式管理升级为分布式房间管理和信令通道， RoomSvc只保存用户列表和视频用户列表的基本信息，极大减轻控制系统的负担。由于原来采用的是集中式架构，瓶颈非常明显，在新架构下，我们对房间按订阅关系进行了拆解，在内部集群做了一层收敛，这样运算量就会非常少，从而实现了房间规模的扩展。
RoomSvc所有信息可动态扩展并快速恢复。比如核心节点宕机，这个核心节点的信息在其他的节点中都有，只需要换一台机器，并把原来的信息搬到这台机器上，就可以得到完整信息。再比如Set中有一个小的节点宕机，但媒体节点里的信息是完整的，换一个新的机器，将数据重新构建，那么这个房间就可以重新构建出来。
在新的架构下，我们保守估计单房间可支持100万人，且具备高可用、高可扩展，高可靠等特点。
4.5 实践落地成果
这套架构在去年疫情期前期发挥了重要作用，腾讯会议和腾讯课堂在疫情初期，每天同时在线人数都呈现翻倍上涨的现象，依靠这套架构，我们7天扩容100万核心，同时撑住了这两大产品千万级用户同时在线、亿级用户使用。
大规模的视频会议现在变得越来越常见，比如腾讯会议从300方到企业版2000方，不久还会提供更大规模的会议产品形态。有些机构的大班课/超级小班课现在开始尝试使用RTC代替标准直播来提升上课体验，大房间场景未来也会越来越多。
05
TRTC技术优化实践
——RTC平台媒体处理子系统
5.1 媒体处理子系统优点与问题
最后向大家探讨关于RTC平台的媒体处理子系统。RTC的媒体处理子系统——比如录制、鉴黄、播片、混流转推等，本质上是一个旁路系统，现在业界通用的做法是让一个linux sdk机器人模拟进房，把流拉到服务器本地，做出处理之后再转旁路出去。
Linux sdk机器人模拟进房不会影响两个房间的主业务流程。媒体处理子系统需求变更通常不需要动核心系统，且可以实现非常灵活复杂的业务逻辑，比如需要做白板和视频的对齐、K歌的场景下可以把音频和时间戳精确对齐，通过这样的模式可以实现复杂度的隔离。
但我们在做腾讯会议和呼叫中心的时候遇到两个难题。腾讯会议的场景需要打电话，最初的想法是用机器人进到房间之后把流拉回来，并转成g.711、g.729放到PSTN网络中就可以了。由于播放IVR是全房广播或是针对一个人单独广播，所以IVR需要排他式的播放，在SFU的转发架构下不太容易做精确控制，不管是对新进的控制、还是媒体的识别都是比较复杂、难以控制的。
此外，语音录制的情况下，金融行业的客户是不能接受在录制过程中有多录或是少录几个字的情况的，就像在念身份证号时少几位数字是绝对不可以的。但是系统中如果是采用机器人的方式去做，由于是两个系统的整合，系统之间会出现抖动、延迟，就导致录了不该录的内容或者该录的没录下来，这些情况对于较为苛刻的用户是绝对不可以接受的。
5.2 混音引擎解决问题
由于上述问题，我们采用了混音引擎，通过混音引擎将流做集中式的处理，既节省带宽、又方便实现IVR和录制功能，打通TRTC与PSTN电话系统，实现融合通信能力。
我们还与腾讯会议合作，做了PSTN窄带语音频域超分扩展和线路杂音检测和消除，进一步提升通话质量，PSTN的融合通信能力是TRTC的特色功能，广泛应用于客服、呼叫中心和会议场景等。
06
展望未来
虽然疫情在客观上推动了实时音视频行业的发展，但RTC仍然处在爆发前夜。目前比如社交、云游戏、远程实时控制、合唱等RTC重要场景虽然已经有落地应用，但体验都无法达到最佳，或者存在各种各样的限制。未来随着网络基础设施和终端软硬件能力的提升，端到端平均延迟能达到50-80ms，RTC产品的体验也将会有质的提升，场景和应用也会迸发出更多活力。
以上是我今天的分享，谢谢大家。
- The cover from creativeboom.com
