腾讯技术开放日 | 腾讯会议如何构建实时视频传输算法架构，来实现用户体验质量最优？
在实时视频通讯中，要达到终端用户的体验质量（QoE）最优，需要实现实时视频传输的信号质量和交互性最优，而时延和带宽是有限的，如何衡量取舍对有限资源进行分配，成为构建腾讯会议实时视频传输算法架构的核心问题。为实现QoE最优，腾讯会议如何构建实时视频传输算法架构？在【腾讯技术开放日 · 云视频会议专场】中，腾讯多媒体实验室高级研究员许景禧针对实时视频传输算法架构与实践进行了分享。
腾讯会议的架构为优化QoE服务
腾讯会议总体的架构比较大，主要分成左边和右边两部分。左边是早期的腾讯会议客户端，包括windows、安卓、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做出决策，驱动算法。
讲师简介
许景禧，腾讯多媒体实验室高级研究员，2017年博士毕业于香港中文大学计算机系，博士到现在的研究方向一直是实时多媒体网络传输的优化，多篇一作论文发表在TMM和ACM TOMM等期刊和会议上。加入腾讯后，先后参与腾讯无线投屏和腾讯会议项目底层SDK的网络算法研究和代码开发，目前是腾讯会议视频传输算法体系架构与优化的负责人。