疫情将远程办公，视频会议推上了风口的同时，同样也为视频会议平台的运作带来了更多的挑战。蓝猫微会创始人兼CEO 邓昀泽在LiveVideoStack线上分享中针对视频会议系统优化中弱网定义，算法评估及技术实现等细节进行了详细解析。
文 / 邓昀泽
整理 / LiveVideoStack
视频回放
https://www2.tutormeetplus.co...
大家好，我是蓝猫微会的创始人兼CEO 邓昀泽，本次我分享的主题是：视频会议场景下的弱网优化，下面我将从以下三个方面展开本次分享的全部内容：
- 弱网的定义
- 评估算法
- 传输优化
要探究视频会议在弱网场景的优化，需要首先从场景化与数字化角度对弱网进行准确的定义，这样在处理相关问题时才能得出一些具有针对性的解决方案。接下来就需要评估并优化算法，结合场景与数字化的方式验证优化方法的可行性、有效性。算法优化永远是在各场景之间寻求一种平衡，不同场景对参数的选择是不同的。如果没有一个场景化的评估标准，那么针对不同场景的算法优化容易导致一个场景有效，另外场景恶化。因此弱网的定义与评估至关重要。在针对性地分析并得出优化算法之后，我们需要根据整个过程的效果评估不同场景下的算法选型。
弱网定义
首先我们需要明确弱网的定义，我们从两个维度进行定义：丢包率与带宽限制。丢包率在多少以下代表网络可用？网络带宽究竟达到多少代表该网络可稳定运行？只有在丢包和带宽都处于可接受范围内时，该网络才不算弱网。如果任何一个维度的指标出现异常，例如丢包率过高或者带宽限制明显，就可将其视为一种弱网环境。
在音视频这个对网络延迟十分敏感的应用场景当中，弱网是普遍存在的。例如在像网吧这样的环境中，下载一个文件网络带宽可以达到2～3M。但网络的抖动非常严重，不能满足音视频稳定传输的需求，这种波动明显的网络环境在音视频领域也会被称为弱网。所以音视频领域对弱网的定义和一般互联网中对弱网的定义存在一定区别，音视频对弱网的定义需要建立在相对可控的丢包率和延迟均衡的基础上。
接下来我们按照带宽资源分情况讨论：
● 100kb网络
100k的带宽可以被定义为很差的网络环境，在该网络环境下基本无法实现视频会议。该网络环境更多地出现在老旧小区的电梯间或地铁车厢当中，此时我们作为视频会议解决方案的提供方，会检测到该场景并建议客户改用语音模式进行会议沟通。
● 300kb网络
300kb的网络环境比较典型，例如使用家庭无线网络同时进行互联网实时游戏与音视频会议，此时便会出现音视频会议体验不佳的情况；在公共场合例如高铁或人流密集的车站当中；人数相对密集的星巴克。300K的网络勉强可以支撑视240P的视频会议，但是如果视频会议系统自适应算法没做好，没控制好码流，那么持续的网络抖动会使得画面分辨率在清晰与模糊之间不断变化。优化出色的算法可以让300kb的网络承载320p甚至是480p的视频会议；而优化不佳的算法则会让视频出现持续的卡顿和分辨率抖动。
● 600kb网络
600kb的网络代表很多公司的正常网络环境。大量位于密集写字楼，软件园区等位置的中小型公司，缺乏专业IT，虽然字面上带宽不低，但是时间带宽非常有限。
600kb的另外一个典型场景是夜间网络使用高峰期时的小区带宽。此时大家都打开了互联网电视或者使用联网设备时，整个带宽便仅有600kb左右。根据我们的统计我们认为，拥有600kb稳定带宽的用户，可能会占到总用量的40%左右。
● 1000kb
如果身处现代化的正规写字楼，或是企业拥有正规的办公网络与专业的IT运维团队，那么1M的带宽还是不难实现的，这种网络环境属于正常网络，可以支撑720P的流畅视频会议，不属于弱网的定义范围。
从弱网的定义上来说，我们将网络与视频会议的应用总结为以下三档：网络带宽为300kb，算法优化可以使得视频会议流畅在低清进行；网络带宽为600kb，则480p左右的视频会议可流畅进行；若需追求720p或更高清的视频会议体验，那么还需进一步提升弱网算法优化网络环境。
评估算法
在明确弱网的分类之后，我们需要一个高质量算法，以根据丢包、延迟等指标准确评估网络并为用户选择合适的分辨率或是否继续进行视频会议。检测的算法非常重要，因为算法决定了发送流量与客户能否正常接收并成功播放。
大家可以在公开资料上查到许多评估算法的开源标准，如Google的流量控制算法GCC以及TCP标准算法BBR等。从算法指标来看：丢包率在2%以内的网络可被视为质量不错，丢包率为4%~6%则属于正常网络，丢包率大于10%则网络环境较差，20%则意味着网络环境非常糟糕。
如果是延迟呢？
这里我们谈到的延迟并不是指RTP从发送端发送到接收端接收（服务端到客户端）之间的时间，例如新疆的用户到北京的服务器需要120毫秒，北京的用户到北京的服务器则可能需要10毫秒。本次所讨论的延迟是：假设客户端向服务器发100个同样的数据包，发端共耗时100毫秒；如果服务器没有延迟、路由器没有阻塞，则服务器收到这些包的时间也是100毫秒；但如果客户端发送100个数据包花费100毫秒而服务器接收这100个数据包用了200毫秒，说明发包的速度被卡住了。一般来说，出现这种情况不是由于服务器流量卡住而是客户端本地路由器流量卡住，例如家用网络游戏或小区宽带的路由器限速等。当然，发包耗时100毫秒但是接收端只用了80毫秒的情况一般不可能出现。因此，这里的延迟是指发端发送所需时间与收端接收所需时间之差，一般情况下服务器会将该数据反馈给客户端，客户端根据指标判断网络环境是否已经达到了稳定承载服务所要求的上限。
累计评估
因为丢包与延迟只能帮助我们进行一个瞬间的评估，例如第一次客户端在200毫秒之内向服务器传输100个包，随后得到来自服务器的反馈；第二次客户端发送100个数据包可能就需要300毫秒——网络在细节上的抖动非常之大，尤其是在一些并不那么稳定的网络当中。如果我们仅将某一固定指标作为评估依据，显然是不科学的。我们需要积累所有瞬间状态并推断出连续的网络状况，才能实现相对可靠的评估。
GCC
GCC全称为Google Congestion Control 拥塞控制算法。上图大致展示了GCC的运行过程，其中有两个核心数据包：SR（SendReport）表示发送端（客户端）上报，RR（Receive Report）接收端（服务端）上报。其中的时间表示了发送一个数据包需要多长时间对端才能接收以及其他一些数据标准。以上图展示的为例：首先客户端向服务器发送15个包，数据区间是100-115，发送之后客户端告诉服务端数据包已发送，同时服务端接收到数据包之后就会去检测区间100-115的数据是否接收完整，有多少包在传输过程中丢失。
除此之外，服务端也会统计收到这些数据包所花费的时间并将其作为RR发送给客户端，紧接着客户端持续不停地发SR，服务端也会不断地反馈 RR……客户端可基于此对网络进行精准评估并得出相应丢包率，以及统计发送这些数据包的开始与结束的时间并得出DLSR，就能知道该数据包发送过程是否存在明显的延迟。通过两个数据包之间来回的交互，统计之间的丢包率和延迟，我们就能够对网络质量有一个相对可靠的评估。
例如现在有一个限速600kb的网络，而一个480p的视频会议需要带宽在300~800kb。如果我们将该视频会议服务建立在600kb的网络之下，客户端首先会传输500kb，服务器反馈丢包率很低并且延迟也在可接受范围之内，此时客户端便知道该网络环境尚可，可以持续向上提升比特率；当比特率提升至所需带宽达到550kb时，客户端评估网络仍然能够接受；当比特率提升至所需带宽达到600kb时，服务端侦测到1%的丢包但延迟却没有太大变化，视频会议服务还没有超过带宽的限制，此时服务端将该信息反馈给客户端，如果客户端的评估算法足够精准，那么客户端就不会再继续提升比特率，从而控制丢包率与延迟在合理区间内；但如果评估算法不够精确，那么客户端可能会继续提升所需带宽至610kb、620kb，这会进一步提升丢包与延迟，此时网络环境便会呈现非常糟糕的状态。客户端应该做的是快速降低比特率，使得网关能够很快处理完上一次积压的数据，整个传输在经历一个小范围抖动之后恢复正常；如果在播放器端添加缓冲，那么该抖动可被抹平并达到平稳流畅的播放状态。
GCC算法的核心是SR与RR——通过二者持续的交互将整个网络的丢包与延迟清晰地呈现给系统；在汇总这些数据之后，得出一个网络质量评估的标准。随后客户端就要通过该网络评估标准来决定应该使用多大的带宽与服务器和其他的客户端进行数据交互。
在这里我们对网络评估算法有了大致的了解，其实视频会议本身的环节更加复杂。
传输优化
我们主要从两个方面建立对传输的优化：控制流量与充分利用流量。首先，带宽资源有限，主播端与客户端的网络环境可能存在天壤之别，也许主播端拥有10Mb的上行带宽而客户端所在的弱网环境导致其仅拥有600kb的下行网络带宽，为了应对这种情况我们需要建立有效的流量控制，也就是通过SVC或动态码流来实现。
SVC是可伸缩视频编码技术，其原理是将视频信号编码为一组图层，各层互相依赖形成一个层次结构，特定层及其所依赖的层提供了以特定的保真度解码视频信号时所必需的信息。例如我们将视频分为多个部分：一部分的数据包用于240p，一部分数据包用于480p或者是对480p的细节补充编码数据，还有一部分是对720p的细节补充编码数据。主播方会把240p、480p的补充数据与720p的补充数据都发出去，接收方则根据网络环境选择合适的数据包。若网络状况良好则选取720p，若网络状况不佳则选择480p甚至240p。这样的话无论网络环境如何变化客户端都可以流畅播放，改变的只是画面清晰度。
无论是对H.265还是VP9而言，SVC的算法复杂度都较高，其实H.264同样支持SVC，但我们希望寻求复杂度更低的算法。
于是我们可以采取大小流模式，例如有些客户需要480p，另一些客户需要720p，那么发端便可针对240p、480p、720p发两路或者三路，且不会相互干扰。
另一种解决方案是动态码流。我们无法按照自己的网络带宽决定所需传输指标，而是按照客户的带宽需求决定上线什么样的服务。例如在一对一情况下，如果客户拥有高性能终端与高质量传输网络，可能会提出4k的需求；此时我们便会在现有网络条件的基础之上不断提升分辨率，从而支持客户的网络带宽诉求。如果客户将终端换成手机等一般设备，可能仅支持240p，那么我们就会按照240p的需求调整传输。当然，SVC和动态码流实际上是相互配合的，对于传输有显著的优化效果。
除此之外，我们也会通过一些算法补充，尽可能充分地利用现有流量。例如在600kb的网络带宽下丢包率较低而延迟可控，那么通过一些高质量算法我可以把600kb的上限提升到800～900kb的水平，其优化效果也显而易见。比如典型的方法是FEC与ARQ。
FEC最初来源于光纤层面的算法优化，例如这里我需要传输10个数据包，一旦出现一个包丢失的情况，接收端会重新寻求该包，这其中就有一个包的损失。因此FEC采取了一个补偿方法，若需发送10个数据包，则发送端会多发一个数据包，该数据包根据前面10个数据包通过FEC算法算出，接收端实际上只需成功接收到11个包中任意10个包即可把原数据流重新组装出来。在这种模式下如果控制丢包率在10%以下，实际上是不需要做任何重传请求的，因此丢包率在10%以下的延迟基本上没有什么影响。当然这里存在一个10%的额外带宽消耗，如果在一些网络下丢包率较高而带宽没有问题的话，那么FEC会把丢包重传带来的损失降低，继而把延迟损失降低到最小。
ARQ则是接收端在侦测到丢包时自动发送重传请求，例如发送端发送十个数据包：1、2、3、4、5、6、7、8、9、10；而接收端在依次收到1、2、3、4、5、6、8、10后未收到7、9，随后接收端会向发送端发送一个重传请求，请求发送端再次发送7与9，随后发送端会重新打包7和9并发送到对端。ARQ是一个很常见的重传算法，该重传算法也存在连续型ARQ与不连续型ARQ，ARQ与FEC可以相互配合。如果网络带宽不错但延迟比较明显，我们会优先使用FEC，且控制丢包率在20%以内；如果丢包率超过20%，使用FEC会额外消耗更多的带宽，继而导致整个传输链路的持续恶化。一般情况下在丢包率超过20%，甚至达到10%时， 控制降低FEC算法的权重，并进一步使用ARQ能够带来更加出色的优化效果。
除了FEC与ARQ，还有一种被称为PacedSender的算法。在视频通信中，传输存在峰值与低谷，单帧视频可能有上百KB，我们知道视频当中存在I帧与B帧，一般情况下I帧出现时，代表着达到一个流量高峰；而B帧则是一个很小的片段，这就造成整个传输的抖动非常严重。如果是当视频帧被编码器编码出来后，就立即进行打包发送，瞬间会发送大量的数据到网络上，这可能会引起网络衰减和通信恶化。WebRTC引入pacer，pacer会根据estimator评估出来的码率，按照最小单位时间（5ms）做时间分片进行递进发送数据，避免瞬时对网络的冲击。pacer的目的就是让视频数据按照评估码率均匀的分布在各个时间片里发送，所以在弱网的WiFi环境，pacer是个非常重要的步骤，其可通过拉长时间，使得整个发送的抖动情况趋于平缓。
以上三个算法可有效提升弱网环境下的传输效率并降低丢包率。也许有些人会提到SRT，SRT不是一个算法而是一个开源的包，实际上是内置了FEC、ARQ等算法，通过UDP+FEC+ARQ来模拟TCP的算法。TCP严格遵循质量优先策略，不允许丢失任何一个数据帧，一旦丢包超过限度就会中断链路，而这对音视频的应用场景来说有些过于严苛。相对而言，基于UDP的SRT则更加适合音视频应用场景。我们知道最近业界有不少公司都开始测试 SRT算法，目前来看效果还是非常不错的。
除了以上介绍的内容，我们也会根据视频会议的具体场景进行动态码流方面的优化。例如在1对1视频会议场景下，用户希望追求更好的视频质量。我们就会根据双方的网络状况，不断调整分辨率，动态调控分配策略。
一旦加入视频会议的人数越来越多，甚至达到一二百人，由于用户所处网络环境是千差万别的，因此很难完美满足所有人的需求。在此情况下，我们可以提供给网络非常差的用户480p的流而给网络环境出色的用户最高720p的流，根据用户的数目进行优化和调整，以使服务尽量符合大多数人的利益与需求。
以常见的1对1授课为例，该场景下主播端会传出两路流：主播与PPT，此时为了保证传输的稳定可靠，我们会适当降低主播视频画面分辨率并提升PPT的分辨率，以使得用户能够更加清晰地观看PPT内容。综合考虑各方因素并根据场景进行优化，我们希望尽量让视频会议的比特率与带宽占用能够达到相对比较好的水平，以保证尽可能多的用户享受到清晰流畅、不卡顿的音视频服务。