[發明專利]基于視頻會議服務端實現碼率控制處理的方法

有效

• 申請號: 201910314101.9
• 申請日: 2019-04-18
• 公開（公告）號: CN110035251B
• 公開（公告）日: 2021-04-06
• 發明（設計）人: 王徐偉
• 申請（專利權）人: 電科云（北京）科技有限公司
• 主分類號: H04N7/15
• 分類號: H04N7/15;H04N21/24;H04N21/2662;H04L29/06
• 代理公司: 北京金咨知識產權代理有限公司 11612
• 代理人: 宋教花

本發明涉及一種基于視頻會議服務端實現碼率控制處理的方法，包括以下步驟：(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)分別計算上下行的丟包權重，并獲取過去一段時間內中出現的最大實際發送碼率；