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

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万人大房间的需求，如教育场景大班、超级小班课，大的语聊房以及电商直播带货等，所以针对客户需求对原始架构做了升级改造。