本发明涉及音视频编解码领域，尤其涉及码率控制领域，具体是指一种基于视频会议服务端实现码率控制处理的方法。
背景技术：
随着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)分别计算上下行的丢包权重，并获取过去一段时间内中出现的最大实际发送码率；
(1.3)分别计算上下行的网络状态；
(1.4)分别计算上下行的估计带宽。
较佳地，所述的步骤(1.2)中计算丢包权重，具体为：
根据以下公式计算丢包权重：
fweight＝(1-faudio)*(1-fvideo)；
其中，faudio为音频丢包率，fvideo为视频丢包率。
较佳地，所述的步骤(1.3)中计算网络状态，具体为：
根据以下公式计算网络状态：
其中，fweight为丢包权重，snet_state为网络状态，1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
较佳地，所述的步骤(1.4)中计算估计带宽，具体为：
根据以下公式计算估计带宽bestimate：
其中，breal_bitrate_max为最大实际发送码率，fweight为丢包权重，bestimate为估计带宽，s为网络状态。
较佳地，所述的步骤(3)具体包括以下步骤：
(3.1)对上下行分别计数，判断是否估计带宽高于阈值且音频丢包率低于高阈值，如果是，则计数值减少；否则，计数值增加；
(3.2)判断计数值是否变化至预设数值，如果是，则通知客户端停止发送上行的视频，并在mcu层面停止发送下行的视频，继续步骤(3.3)；否则，继续步骤(3.1)；
(3.3)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.3)。
较佳地，所述的步骤(3.3)具体包括以下步骤：
(3.3.1)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.3.2)；否则，继续步骤(3.3)；
(3.3.2)判断重新发送视频的次数是否大于1，如果是，则继续步骤(3.3.3)；否则，继续步骤(3.1)；
(3.3.3)判断是否重新发送视频导致音频丢包率上升，如果是，则根据计算的启动视频的时间间隔增加发送的时间间隔，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.1)，直至视频会议结束。
较佳地，所述的步骤(1.3)中计算启动视频的时间间隔，具体为：
根据以下公式计算启动视频的时间间隔：
tinterval＝ttime_slice*cdisable_times。
通常，ttime_slice为固定的常量，通常取10秒，cdisable_times为视频被取消的次数。
采用了本发明的基于视频会议服务端实现码率控制处理的方法，在网络带宽不足的情况下，能够迅速降低视频的质量或者取消视频，仅保留音频；在网络带宽仅足够音频传输时，不会反复尝试启动视频。在算法层面保证音频包的竞争性，音频丢包不会和视频丢包做同等处理。
附图说明
图1为本发明的基于视频会议服务端实现码率控制处理的方法的流程图。
具体实施方式
为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。
本发明的该基于视频会议服务端实现码率控制处理的方法，其中包括以下步骤：
(1)分别计算上下行的带宽；
(1.1)根据rtcp的报文分别获取上下行的音频丢包率和视频丢包率；
(1.2)分别计算上下行的丢包权重，并获取过去一段时间内中出现的最大实际发送码率；
(1.3)分别计算上下行的网络状态；
(1.4)分别计算上下行的估计带宽；
(2)判断是否存在转码器，如果是，则设置为转码器的目标码率，并返回至客户端；否则，继续步骤(3)；
(3)将结果返回至上行，利用带宽调整策略来调整带宽；
(3.1)对上下行分别计数，判断是否估计带宽高于阈值且音频丢包率低于高阈值，如果是，则计数值减少；否则，计数值增加；
(3.2)判断计数值是否变化至预设数值，如果是，则通知客户端停止发送上行的视频，并在mcu层面停止发送下行的视频，继续步骤(3.3)；否则，继续步骤(3.1)；
(3.3)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.3)；
(3.3.1)继续计数音频丢包率，判断是否在预设时间内音频丢包率小于预设值，如果是，重新发送视频，继续步骤(3.3.2)；否则，继续步骤(3.3)；
(3.3.2)判断重新发送视频的次数是否大于1，如果是，则继续步骤(3.3.3)；否则，继续步骤(3.1)；
(3.3.3)判断是否重新发送视频导致音频丢包率上升，如果是，则根据计算的启动视频的时间间隔增加发送的时间间隔，继续步骤(3.1)，直至视频会议结束；否则，继续步骤(3.1)，直至视频会议结束。
作为本发明的优选实施方式，所述的步骤(1.2)中计算丢包权重，具体为：
根据以下公式计算丢包权重：
fweight＝(1-faudio)*(1-fvideo)；
其中，faudio为音频丢包率，fvideo为视频丢包率。
作为本发明的优选实施方式，所述的步骤(1.3)中计算网络状态，具体为：
根据以下公式计算网络状态：
其中，fweight为丢包权重，1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
作为本发明的优选实施方式，所述的步骤(1.4)中计算估计带宽，具体为：
根据以下公式计算估计带宽：
其中，breal_bitrate_max为最大实际发送码率，fweight为丢包权重，bestimate为估计带宽，s为网络状态。
作为本发明的优选实施方式，所述的步骤(1.3)中计算启动视频的时间间隔，具体为：
根据以下公式计算启动视频的时间间隔：
tinterval＝ttime_slice*cdisable_times。
通常，ttime_slice为固定的常量，通常取10秒，cdisable_times为视频被取消的次数。
本发明的具体实施方式中，使用gcc或者trendline的带宽估计算法无法满足服务端的需求。针对服务端，开发了新方法，综合音视频对带宽做出估计，并且利用估计的带宽来控制码率。本发明在mcu中实现相关算法，并利用webrtc实现视频会议的客户端，和mcu相连。
利用以下几种方式对带宽分别做估计
1、根据丢包率估计下行带宽
根据rtcp的报文获取下行音频丢包率faudio_downlink和下行的视频丢包率fvideo_downlink，计算丢包权重fweight＝(1-faudio_downlink)*(1-fvideo_downlink).获取过去一段时间内中出现的最大实际发送码率breal_bitrate_max。
计算网络状态：
1表示网络状态上升，0表示网络状态不变，-1表示网络状态下降。
计算估计带宽公式如下：
计算得出的带宽和来自remb中的估计带宽做比较，取小值，设置到解码器中，或者设置到上行链路，做进一步对比。
2、计算上行带宽，采取同样的算法，计算出上行的带宽，并且和下行的带宽做比较，如果存在转码器，则通过remb把计算得出的上行带宽返回给客户端，如果不存在解码器，则和下行带宽做比较，返回小值
3、对video的处理：
对上下行分别计数，估计带宽低于阈值的时候，或者音频丢包率高于高阈值的时候，计数增加，带宽增加到设定的高阈值之上，并且音频丢包率低于低阈值的时候，计数减少。当计数增加到一定程度，对于上行，通知客户端停止video发送，下行则在mcu层面停止video发送。上下行是互相独立的。停止video发送之后，会给停止计数加一
video停止之后，对于audio的丢包率继续计数。如果连续一段时间audio的丢包率都很小，则尝试重新发送视频，尝试的间隔根据统计结果增加。
启动视频时间间隔计算公式如下：
tinterval＝ttime_slice*cdisable_times
如果每次尝试都会导致音频丢包率上升，则尝试的间隔会越来越长，防止出现反复启动video导致体验下降。
整体的流程如图1所示，上下行分别计算带宽，计算的结果，如果存在转码器，则设置到转码器中作为目标码率，否则返回给上行，让上行利用webrtc的带宽调整策略来调整带宽。
本发明所声明的方法，是一种适用于服务端的，并且和现在主流的webrtc相兼容的码率控制算法。对于网络带宽的估计，目前主流的算法分成两类，第一，基于延迟来估算带宽；第二，基于丢包来估算带宽。实际中经常把两类方法综合起来做带宽估计，区别在于，不论是基于延迟还是基于丢包，所采用的模型和公式不同。
本发明采用的是基于丢包的带宽估计算法，并且提出了自有的丢包模型和估算公式，同时，本发明是考虑音频优先的原则，对视频和音频的丢包统一处理，并赋予不同的权重。本发明并未采用延迟估计算法，但对音视频的丢包做统一处理，得出的结果不会挤占音频带宽。本方法是用在基于webrtc的音视频服务中，服务端无法主动侦测带宽，因此通过数学模型来预测网络状态。
采用了本发明的基于视频会议服务端实现码率控制处理的方法，在网络带宽不足的情况下，能够迅速降低视频的质量或者取消视频，仅保留音频；在网络带宽仅足够音频传输时，不会反复尝试启动视频。在算法层面保证音频包的竞争性，音频丢包不会和视频丢包做同等处理。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。