腾讯会议如何构建实时视频传输算法架构，来实现用户体验质量最优？

一、腾讯会议的架构为优化 QoE 服务

    腾讯会议总体的架构比较大，主要分成左边和右边两部分。左边是腾讯会议的主体，包括四个 PC/Android/Mac/iOS 的客户端以及后台，右边是通过转码服务器连接的外部服务。

    我们知道业内很多同行可能用的是 WebRTC，但腾讯会议不是。腾讯从 QQ 时代过来，在音视频实时传输系统的搭建和优化上有很多年积累。腾讯多媒体实验室基于这些积累，重新编写了一个跨平台而且高效的引擎-xCast。这里面的网络传输层被称为 Pere, 它其实是一种飞的比高铁还快的神鹰的名字。

    今天讲的着重涵盖 Pere 这部分， 搭建 Pere 架构围绕 QoE 最优化。QoE 是什么? 说 QoE 就不得不说 QoS, QoS 一般来说是指单独的网络指标，比如延迟、丢包率、用户可用带宽等，这些是用来侧面反映当时的网络和系统的质量。

    QoE 指的是用户在终端上实际体验到的质量。它其实主要依赖线下用户主观测试，获取意见来得到的。但是在线上做优化的时候，实际上没有时间和条件来搜集用户的实时反馈，所以现在有很多的算法和模型，尝试通过一些指标侧面衡量 QoE 大概的水平，然后针对性地来做优化。腾讯会议架构的一切都是为了优化 QoE。

二、在影响 QoE 的指标之间取舍

    QoE 包含信号质量和交互性两个方面。信号质量指视频和音频质量，也就是用户实际上看到这个媒体的时候，觉得它的流畅度、清晰度怎么样的，还有它跟源信号的对比。交互性主要是指沟通的耗时，交互的便捷度，任务达成的难度，还有社交习惯的再现度等等。

    在互联网上传输东西是通过 IP 网络，这个过程中包可能会迟到，甚至直接丢了。那么如果一个视频会议系统做的不好，一旦发生丢包，它的画面可能就会卡顿，甚至会有一些花屏，用户就会觉得信号质量降低了。

    1. 延时与交互性取舍

    有很多信道层次保护方法，可以在包迟到或者丢包的时候做质量恢复。一个是 Jitter Buffer，那些包虽然来的有早有晚，但是可以用 Buffer 让包在出的时候变得平滑均匀。另外一个是 FEC，通过冗余技术，来传一些额外的包来补救。当然还可以通过重传的方式来让一些丢了的包再出现。通过这些方法，可以保证系统的信号质量。

    但是，信号质量提升的同时，交互性变差了。这是为什么呢？下面的图是在线下的面对面双人交流中，A 跟 B 在同一个世界，他们看到的东西是同一个，所以只要 A 说话，B 立刻能听到 A 的话语，B 说话的时候反之亦然。在这里大家的话语的传递很及时，沟通也没有什么困难。

    而在对应的线上双人会议中，因为有传输延迟，也有一些为了提升信号质量而做了重传或者很长的延迟，A 说话的语音跟画面，可能过了一段时间才到 B 那边，反向也是这样。这个会导致什么问题？

• 首先他们两人交互的总耗时变长了，增加的时间会改变端到端延迟引入的。

• 另外，会改变说话的对称性，人们在这种情况下，会觉得自己反应很快，但对方的反应很慢。说话方看起来说话很快，听到后立刻响应，但是很久之后才能听到对方的回应，这样其实会带来交流上的困难。

• 更严重的是，在 A 等待 B 的话过来的时候，感到不耐烦了，偏要说话，那就会出现两个人同时说话的场景，在音频传输上一般称为双讲。

    端到端时延，传统上认为占大头的是传输跟缓冲，但是实际上我们在实践中发现，无论是采集渲染还是编解码，都是要耗一定的时间的，而且有时候时间还不小，尤其是在一些特定的移动平台上。

    ITU G.114 指出，端到端时延在超过 150 毫秒时，就已经能开始察觉到了，超过 400 毫秒的话，很多用户就觉得不可接受了。所以说端到端的时延很重要。

    好在端到端时延是一个可变参数，可以通过调整缓存时间，调整策略来使时延变长或者变短。而通过调整时延，能在信号质量和交互性中间找到更好的平衡。

    在一些情况下也会根据交流的内容进行取舍。比如老师给学生们讲课，基本上是老师在讲，那么如果学生说话回的慢一点，一般也不容易被察觉，就可以把学生说话的时延稍微调大一点，来保证质量。

    2. 质量与抗性取舍

    质量指原来音视频展示的清晰度和帧率，而抗性一般指特定损伤网络下卡顿率的高低。

    从信道方面来看，在可用带宽受限时，源数据和冗余数据其实是竞争关系。源数据更多的话，清晰度会更好，而冗余数据更多的话，在网络有损伤的情况下会更容易恢复，所以这里要做一个权衡。

    另外信源本身也能提供一些抗性。视频里主要是可以通过编 I 帧，可以做帧内刷新，用 SVC，或者是选择参考帧来获得这些抗性，这样它其实是把一部分的编码的资源用在冗余上，也会导致清晰度下降。

    3. 核心问题：有限资源的分配

    这里的核心问题就是，时延和带宽有限，不能无限增加，那么应该怎么分配。下面的图只是举个例子，这里的数字不代表腾讯会议系统就是这样做的。

    例如说时延里有 30%用来做网络传输的固有时延；那么当网络不好的时候，就要占一部分时间来做重传；当网络有抖动的时候，还需要一些平滑时间来平滑一下那些帧；还有一部分是采集渲染编解码的时间。如果不能针对性地分配时间，就可能出现抗性不足的问题。

    带宽可能大部分是用来传源数据，但因应网络损伤场景，也要留一部分给冗余数据。

三、将最优化问题与系统控制关联

    1. QoE 最优化问题

    腾讯会议 QoE 的最优化，实际上是在各种控制参数上，找到一个最优的参数组合。

    这里其实涉及三个问题，这三个问题都不太简单：

• 怎么评估、怎么获得 QoE；

• 第二，QoE 在实时系统上到底应该怎么算；

• 第三，给定了算式后，应该怎样做最优化。

    下面重点介绍一下第三个问题。

    QoE 最优化主要是考虑这些方面：卡顿，端到端时延，画面质量，音画同步，变化平稳度，下面图中是影响这些方面的因素。而它的约束主要有三点：时延约束，发送码率，接收码率。

    这里的难点在于，很多指标的估算都涉及概率方面的统计，而很多指标不是独立分布的，要算准一个期望很难。在期望算不准的情况下，最终的效果就会跟预期的差很远。在这里腾讯会议也花了很大的力气来做一些调整。

    2. 时延约束 

    因为时间有限，今天只讲其中两个最重要的约束，分别是时延约束和带宽约束。

    端到端时延与 RTT、重传次数、抖动、目标卡顿有关。在腾讯会议的系统上它是这样的，在发送端就已经决定好一个最优组合策略，来指导上下行所有参数的调整，而接收端会根据策略大方向，在必要的时候做一些紧急补救。

    实际上跑下来发现，因为预测大部分情况下都足够准确，所以那些紧急补救使用机会不是特别多。同时因为重传是一个比较节省流量的抗性策略，所以在时延和丢包的模式允许的情况下，腾讯会议会优先使用重传，不足的地方采用 FEC 来补救。这样的话，可以看到腾讯会议的时延其实最大的部分就是网络本身的延迟，还有重传的延迟。下行可能会多一个 Jitter Buffer 抖动的平滑延迟，之后还有一个音画同步的时延，这部分就组成了腾讯会议整个端到端的时延。 

    在做这个时延优化的实践里，我们发现还有很多需要考虑的地方。比如说媒体服务器不是一个点，它们之间传输需要时间，而且它们可能也不是百分之百可靠。另一方面就是因为腾讯会议做的是一个全平台的方案，可能遇到有一些平台，它的处理比较弱，在视频路数比较多的时候，很容易处理不过来，造成延时约束被打破。在这些地方腾讯会议都投入了很多精力来做微调的优化。

    3. 带宽约束

    一个视频会议里面，带宽的分配达到了“斤斤计较”的程度，这是因为无论是原来的码率，带内冗余、带外冗余还是重传的码率，都要使用带宽。而带宽如果超出了正常的范畴，视频的丢包率和抖动都会突然上涨。

    腾讯会议针对网络的类型来使用不同的拥塞控制算法，来保证带宽约束不被破坏。我们发现在大部分网络下面，拥塞之前数据都会先排一下队，那么在这种网络下，我们会做以延迟为主的拥塞控制。但是在一些网络上，主要是跨运营的网络，在有拥塞的情况下，很容易会立刻丢包，给它传的越多它丢包越厉害，那么在这种情况下就不能盲目的通过重传 FEC、超发等方式来做网络抗性，要针对性地做一些不同的拥塞控制。

    下行方面会相对复杂，因为一个上行可能对应很多下行。那么我们会靠一些粒度相对粗放的策略做拥塞控制，做完探测之后，通过一些时域、空域的 SVC，或者通过 FEC 增减，来进行拥塞控制，使得下行流量在控制范围内，而且不会比预测的可用带宽小太多。

    总结一下，腾讯会议的整个架构都是为优化 QoE 而服务的，要在这些 QoE 指标之间进行取舍。在实践中，腾讯会议会把控制跟最优化问题做一个关联，然后在各个模块上布置各种算法，基于最优化 QoE 做出决策，驱动算法。

头图：Unsplash

作者：许景禧

原文：https://mp.weixin.qq.com/s/_PvC58_zRlCbQOsKC-P-5w

原文：腾讯技术开放日 | 腾讯会议如何构建实时视频传输算法架构，来实现用户体验质量最优？

来源：腾讯多媒体实验室 - 微信公众号 [ID：TencentAVLab]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。