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

本次分享我们邀请到了来自腾讯云实时音视频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中。