这次我们邀请到了腾讯云实时音视频TRTC后台的R&D负责人薛迪，他给我们分享了腾讯云TRTC在架构升级和产品实践方面的经验。对mixing engine的原始制造来源、整个优化过程中发现的问题以及解决方案进行了细致的讲解，为以后的腾讯大会和云呼叫中心打下了良好的基础。

文/薛迪

组织/直播视频堆栈

大家好，我是薛迪，来自腾讯云实时音视频TRTC后台研发负责人。今天很荣幸和大家分享腾讯云TRTC在架构升级和产品实践方面的经验。

我们团队曾经服务过QQ影音产品，分为两人、多人、群组视频秀三种形式。前两者倾向于实时对话，而群视频秀更像是视频直播。在这些产品中，两人视频通话是最常用的，也是最大的一个，在规模上比多人场景和群组视频秀的总和还要多一个数量级，微信现在也差不多。

01音像制品形式

1.1双音频和视频

从架构上看，二人影音系统比较简单明了。红点代表房间信令业务，房间信令业务的主要功能是管理房间信息，实现上下行链路联动的能力协商和质量控制。例如，当下行信道拥塞时，上行比特率和分辨率也会降低。

在传输渠道层面，我们的策略是以直连为主。在跨地区、跨运营商的情况下，我们会选择单中转渠道或者双中转渠道。在战略上，我们将尽力同时保持直接联系和中转渠道。当一个信道质量差时，系统会自动将流量切换到另一个信道。

1.2多人影音

多人视频通话的产品形态是整个房间不超过50人，房间平均人数在4.x人左右，房间最多容纳1个大视频和3个小视频(4个画面)。根据这一条件，我们在建筑上采用了典型的SFU隔间设计。

上图中的红点代表房间信令服务，主要用于房间管理和状态信息同步。房间管理主要包括用户列表的管理，比如谁开了视频/音频，我看了谁，谁看了我，这些都以房间管理的信息为准，然后房间信令业务会将这些信息同步到媒体传输业务进行数据分发。

客房服务的另一个功能是客房级别的容量协商和质量控制。比如刚开始的时候，房间里所有人都支持H.265编码。当某个时刻一个只支持H.264编码的用户进来，房间里的所有上游主播都必须把H.265切到H.264，另一种情况是，当房间里有一定比例的人下行通道质量不好时，上行房间的质量就会下降。

在传输层面，我们采用单层分布式媒体传输网络。我们都选择换乘方式，不区分两人或多人。我们采用全网状传输机制，把所有数据推过去。比如一个节点上的人不都看另外两个人的视频，但还是会把视频推送给他们。

02混合引擎

当时我们的产品还有一个特点——视频占比不高，但是纯音频室很活跃。有一个案例让我印象深刻。一款热门游戏出皮肤后，语音室人数会暴涨，这也是因为很多玩家用QQ多人语音开黑。基于这种现象和成本考虑，我们开发了混合引擎。当房间数超过成本线时，我们会将所有的流转移到混音引擎，混音引擎会根据音量对流进行重新编码，然后将流推送到下游媒体平台。它的架构不再是典型的SFU，而是更像MCU。虽然当时的出发点是节约成本，但是为我们后来做腾讯会议和云呼叫中心打下了很好的基础。

03深度优化的云平台即服务-TRTC

腾讯云实时音视频产品——TRTC是基于QQ多人音视频平台的云PaaS服务，针对To B场景进行了深度优化和改造。首先，它提供了一个全平台的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(基于上下文的丢包补偿技术)可以在120 ms内恢复连续丢包，并且我们自主研发的cFEC比OPUS的原生带内FEC具有更好的恢复效果，因此在正常网络下，我们可以应对一些突发丢包场景，而无需添加很多带外FEC。

当然，这些技术点如果单独使用，效果并不好。我们必须将编解码、信源和信道阻力、带宽预测、拥塞控制、媒体传输有机结合起来，才能保证低时延、高质量的通话效果，这也是RTC与标准直播最大的区别之一，也是它的魅力所在。

3.3基于云的智能监管

在监管方面，我们开发了基于云的控制引擎。把控制系统放在云端的好处是可以减少终端版本的兼容性问题，更方便验证算法AB-Test的效果。

第二点是在操作过程中，我们通过BadCase分析积累大量的规则，使场景识别更准确，调控更有针对性。

同时，我们从规则模型中提取丰富的配置参数，针对不同的客户需求进行优化。比如有的通话产品客户想要平滑优先，有的直播客户需要清晰的优先模式，可以通过调整配置来实现。

另外，我们也在不断改进算法。BBR出来的时候，我们参考了BBR带宽预测的方式，改编了超大规模房间的规定。

04 TRTC建筑进化之路

4.1系统瓶颈和场景需求升级

说到规模，我们开头说的多人音视频通话系统是基于小房间的SFU架构，房间人数变大就会出现系统瓶颈。首先是调控的计算和状态信息的同步，在一台计算机的一个过程中完成。人数非常多的时候，计算量越来越大，瓶颈非常明显。

其次，媒体传输采用单层分布结构。当房间越来越多，节点越来越多的时候，带宽就会出现明显的瓶颈。

最后，为了减少内网渗透，访问调度采用聚合分配策略。同一个房间，同一个操作员，同一个区域的用户会先分配到同一个机器，满了再分配到下一个。当短时间内大量房间一起进入房间时，服务的数据上报和状态同步可能无法及时更新，导致节点超标。

但随着RTC技术场景的拓展，很多客户都有10万间大房间的需求，比如教育场景的大班、超级小班、大语种聊天室、电商直播发货等。，因此对原有架构进行了升级，以满足客户需求。

4.2集合重构

首先，我们根据国家、地区和运营商将大的集群转换成固定大小的集合。在集合中，根据流的粒度技术自动选择扩散代理进行汇聚，以减轻上游节点的媒体分发压力。大部分集合通过内网互联，这样对于一些海外偏远国家或者国内边缘节点，只需要与其他节点互通一跳就可以返回内网。

4.3内部网传输

内网的传输部分通过腾讯云的云组网实现。目前，腾讯云在全球开放了27个地理区域和61个可用区域，内网专线切换的链路较多，带宽储备充足。

在腾讯大会上给高层做报告的时候，经常会做切换演练。几条专线可以互相切断。实际上，内部网的整体质量是相对稳定的。

4.4客房管理

在机房管理部分，我们从集中式管理升级为分布式机房管理和信令通道。RoomSvc只保存了用户列表和视频用户列表的基本信息，大大减轻了控制系统的负担。因为采用了原来的集中式架构，所以瓶颈非常明显。在新架构下，我们按照订阅关系对房间进行了拆解，在内部集群做了一层汇聚，这样计算量会很小，从而实现了房间规模的扩展。

RoomSvc的所有信息都可以动态扩展和快速恢复。比如核心节点宕机，这个核心节点的信息在其他节点都是可用的。只要换一台机器，把原来的资料搬到这台机器上，就可以得到完整的资料。例如，如果集合中的一个小节点宕机，但媒体节点中的信息是完整的，则更换一台新机器并重建数据，然后可以重建房间。

在新的框架下，我们保守估计单个房间可以支持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的特色功能，广泛应用于客户服务、呼叫中心和会议场景。

展望未来

虽然疫情客观上促进了实时音视频行业的发展，但RTC仍然处于爆发的前夜。比如社交、云游戏、远程实时控制、合唱等重要RTC场景虽然已经应用到地面，但是体验并不能达到最佳，或者说存在各种限制。未来，随着网络基础设施和终端软硬件能力的提升，平均端到端时延可以达到50-80ms，RTC产品的体验将得到质的提升，场景和应用将在generate中展现出更大的生命力。

以上是我今天的分享，谢谢大家。

-creativeboom.com的封面