在實時視頻通訊中，要達到終端用戶的體驗質量（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的網絡算法研究和代碼開發，目前是騰訊會議視頻傳輸算法體系架構與優化的負責人。