[发明专利]基于视频会议服务端实现码率控制处理的方法

说明书

本发明涉及一种基于视频会议服务端实现码率控制处理的方法，包括以下步骤：(1)分别计算上下行的带宽；(2)判断是否存在转码器，如果是，则设置为转码器的目标码率，并返回至客户端；否则，继续步骤(3)；(3)将结果返回至上行，利用带宽调整策略来调整带宽。采用了本发明的基于视频会议服务端实现码率控制处理的方法，在网络带宽不足的情况下，能够迅速降低视频的质量或者取消视频，仅保留音频；在网络带宽仅足够音频传输时，不会反复尝试启动视频。在算法层面保证音频包的竞争性，音频丢包不会和视频丢包做同等处理。

技术领域

本发明涉及音视频编解码领域，尤其涉及码率控制领域，具体是指一种基于视频会议服务端实现码率控制处理的方法。

背景技术

随着Webrtc的发展，越来越多的公司开始利用Webrtc搭建视频会议系统。但是Webrtc是提供点到点的视频会议，本身不支持多人，所以在Webrtc之上，视频会议系统需要构建自己的媒体控制单元(MCU)或者单路转发单元(SFU)。服务端同时要接受和分发多路音视频码流，由于网络上下行带宽的不匹配，以及网络本身的波动。MCU端一个重要的功能就是对音视频码率的控制。

码率的控制分成两个部分，一部分是对现有带宽的侦测和估计，另一部分是对音视频码率的控制。SFU是一个纯转发的服务，无法直接对码率进行控制，更多的是做带宽的侦测。MCU作为一个比较复杂，功能比较完善的服务端，具备转码混流的功能，可以对下行的码率做比较方便的控制。

现有的音视频编码器都会提供码率控制的接口，可以在内部通过各种手段对输出码率进行有效的控制。对于MCU来说，最重要的事情是对现有的带宽做比较精确的估计，同时，由于网络总是存在不可预测的波动，所以，MCU也需要对网络波动做出一定程度的预判，这样可以有效减少码率的波动。

Webrtc在56版本以前，利用一种叫GCC的算法来做带宽的估计，在56版本之后，利用一种叫Trendline的算法来做带宽估计。GCC对于带宽的估计太过延迟，实际带宽的波动可能很大，但是GCC不够灵敏，经常会出现远高于或者远低于实际带宽的情况。Trendline又过于灵敏，特别是针对带宽从高到低，可以迅速捕捉到带宽的下降，但是对于带宽的上升，计算出的带宽回复过慢。带来的效果是，用户往往带宽足够，但是一直徘徊在低质量的视频流之中。

视频会议不止提供视频流，更重要的是提供音频流数据。当带宽不能够同时支持音视频流的时候，我们需要把视频流停掉，尽量保持音频流的数据。所以，对真实带宽的估计显得尤为重要。GCC和trendline都是基于视频流做带宽估计和检测，对于音频数据，是不考虑的。这使得这个算法的缺陷非常明显。当视频流数据和音频流数据在同时竞争带宽时，GCC和Trendline忽视了音频流数据的带宽，而实际上，对用户体验来说，音频数据是显而易见更重要的。

发明内容

本发明的目的是克服了上述现有技术的缺点，提供了一种满足低延时、灵敏度高、准确性高的基于视频会议服务端实现码率控制处理的方法。

为了实现上述目的，本发明的基于视频会议服务端实现码率控制处理的方法如下：

该基于视频会议服务端实现码率控制处理的方法，其主要特点是，所述的方法包括以下步骤：

(1)分别计算上下行的带宽；

(2)判断是否存在转码器，如果是，则设置为转码器的目标码率，并返回至客户端；否则，继续步骤(3)；

(3)将结果返回至上行，利用带宽调整策略来调整带宽。

较佳地，所述的步骤(1)具体包括以下步骤：

(1.1)根据RTCP的报文分别获取上下行的音频丢包率和视频丢包率；

(1.2)分别计算上下行的丢包权重，并获取过去一段时间内中出现的最大实际发送码率；