实时音视频技术的演进与应用( 三 ) _音视频

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 混音引擎解决问题