（圖1 全球軟體開發大會融雲「實時通訊技術」專場）
今天分享 “實時通訊全鏈路質量追蹤與指標體系構建”，內容主要包括五大部分：實時音視訊平臺面臨的質量挑戰、融雲實時音視訊質量控制總體架構、客戶端實時音視訊質量檢測、SDN 大網的組建與質量跟蹤、鏈路問題的跟蹤與查詢。
獲取完整 PPT，請在融雲公眾號後臺回覆“許傑”。
（圖2 許傑在 QCon 現場做主題演講）
實時音視訊平臺面臨的質量挑戰
實時音視訊平臺面臨的挑戰，可以概括為三個“多樣化”：
第一，終端多樣化。包括 OS 版本特性、硬編碼差異、APP SDK 版本多等問題。
眾所周知，iOS 和 Android 是比較新生的系統，處於快速迭代期。在迭代過程中，不論新老特性，包括廠商相容性等問題都比較突出，這也給我們 ToB 平臺帶來很大挑戰。不同於 PC 端升級有後臺駐留引擎的幫助，移動端情況非常困難，很多 APP 還是幾年前的版本。
而所謂“硬編碼”—— 在移動網際網路時代，硬體編解碼得到了廣泛應用。很多網紅直播是在戶外，如果用純軟體編解碼，很快電量就會耗光。這也是為什麼儘管其他編碼器也陸續釋出，但最普及的卻仍是 H.264，與硬體有很大的關係。
第二，全球網路多樣化。涉及到網路種類差異、跨國出口、國外基礎設施差異、專線建設限制等。其中前兩項大家會感觸很深，而在融雲賦能大量企業出海的過程中，也非常深刻地體會到，海外基礎設施建設與中國差異之大。
第三，使用者場景多樣化，比如 1V1、教育、金融、會議、低延時直播、語聊房等。舉一個簡單的例子，假如某 APP 直播時平均觀看時長為 10 分鐘，但在某一時段突然跌至 5 分鐘，我們就可以排查 —— 這種數值波動是不是由質量引起的，比如畫面質量下降，或者是卡頓嚴重導致使用者無法耐心觀看、不得不頻繁切換直播間？由此通過 QoE 監測，側面反推質量。
融雲實時音視訊質量控制總體架構
上面提及的種種需求側的“挑戰”，切換到解決問題的角度，還是要轉化成技術思維。質量架構需要解決哪些問題？
第一是演算法優化，包括編解碼優化、弱網網路優化等。從實驗室環境切入，看我們的研發質量究竟符不符合生產環境要求，生產環境泛化能力如何，先小規模地推到生產環境的網路上，如果發生問題，再進行召回。
第二是 SDN。SDN 建設就是如何評估伺服器選點以後的覆蓋能力，尤其在海外很多國家，像東南亞地區，其人員分佈較廣，基站、機房的覆蓋能力同樣需要嚴格稽核。再有，如何評估當前的專線質量、全球鏈路質量，以及容災恢復情況等，都需要及時進行監控。
第三是客戶體驗 —— 客戶把信任交給我們，如何為客戶提供可靠的實時全域性狀態監控？資料包表彙總一旦發現問題，又是如何查詢鏈路細節資訊、快速定位到問題所在？這些都是需要著力解決的問題。
帶著上述問題，來看一下融雲實時音視訊質量控制系統的總體架構圖（圖3）。
（圖3 融雲 RTC 質量體系總體架構）
最底層是研發管理，包括用例管理、自動驗證、鏈路跟蹤、資料大屏、預警等。
中間層是融雲全球“大網”SDN 的建設過程，其中比如日誌系統 —— 從全球十幾個大的節點把日誌拉回來進行實時分析；路由管理，實際上就是整個系統的“大腦”，包括路徑如何規劃、容災怎麼做等等。
最上方是客戶平臺，我們有報表、資料大屏和鏈路資訊自查系統。
客戶端實時音視訊質量檢測
客戶端 RTC 質量檢測是本次分享的重點。
（圖4 RTC 音視訊處理流程&質量因素）
如圖 4 所示，資料從傳送端經過採集、前處理、編碼、傳送，接收上來資料以後進行解碼、後處理、渲染，這就是 RTC 典型的一個資料處理過程。
顯而易見，這個過程呈線性排布，由此帶來的麻煩是，一旦某一環節出現差錯，後續所有環節質量都會受到影響，就像一根“水管”，任何一個地方堵了，都會導致水流不暢通。
逐一來看：
採集端可能有硬體問題、焦點問題、噪點問題等隱患。硬體問題比如裝置本身的解析度；焦點問題大家時常忽略，實際軟體的自動對焦也會有失靈的情況，瞭解單反相機的人都知道，使用長焦鏡頭時焦平面非常短，稍微有一點問題都會導致畫面不清楚；噪點問題是指，電子元器件在低感光度時都會有噪點，而這種“隨機的小白點”對於整體質量的影響非常大。
有了噪點以後就需要前處理，即編碼前的處理過程，包括美顏、下采樣、去噪等。目前主要採用“單幀去噪”，效果尚可，缺點是在視訊連續幀裡面不會參考前後幀，導致幀與幀平均值不同，最後殘差較大。
到編碼階段，轉換、變換、量化也是畫面降低最大的因素，因為它受制於網路的傳輸。眾所周知，RTC 重點就是優化網路，儘量增大可用頻寬，增強丟包、抖動的適應力，給編碼創造比較好的條件。
解碼是編碼的反向過程，依然會遇到轉換、變換的問題。而所謂“濾波”，指的是，我們現在使用的編碼器基本是混合編碼器，使用“塊”進行運算，帶來的問題是，一張影像中塊與塊之間的“平均值”誤差也很明顯，所以會使用濾波濾掉這種“塊效應”。
後處理，除了前面講到的視訊取樣，音訊方面的主要問題是資料丟包，為了彌補丟包後的聽覺效果，會增加變速不變調的特性，甚至是舒適噪聲。
渲染主要是硬體方面，比如顯示速度不夠，導致解碼等都沒有問題、最後幀率卻不太均勻的情況。
針對以上問題，業內有一些常用的評估指標，以兩大類為主：主觀指標和客觀指標。
（圖5 常用評估指標）
主觀指標中最具代表性的是 MOS。其優點是以人為本；缺點是成本太高了，並且不能精確復現，評判會隨著測試人員的情緒而變化。
所以研發人員希望有一些用機器代替人工的操作，比較典型的就是兩類：全參考和無參考。
無參考比如模糊度、塊效應等，其優點是隻需要接收方一方的資料；缺點是判斷力會偏弱，不能夠定位到系統內外問題，比如最後結果圖效果不好，無法判斷是源本身不好，還是在處理過程中引進了問題。
而全參考比如 PSNR、VMAF 等，具有技術上好操作的優點，可以頻繁重複，並且能夠精準復現，便於快速定位問題；缺點則是需要雙方資料，必須嚴格比對原圖和目標圖。在這一點上，我們 RTC 模型的好處是，能夠容忍網路丟包的問題。
比如傳送端發了十張圖片，接收端只收到八張，無法滿足全參考的一一對應，也不知道丟的是哪兩張，如何解決？
（圖6 視訊對齊方案）
如圖 6，我們參考英特爾的方案，在拿到一張原始圖時，會在圖片左上角加一個視訊編號，將這個編號處理完的圖作為原始圖傳至 RTC，接收端經過解碼，通過深度學習的文字識別，將編號提取出來，這樣兩邊就能對應起來。
以上是視訊的對齊方式，音訊又是如何？音訊對齊主要是利用一個“物理現象”：人類在語音聊天時主要集中在 4K 頻率以下，於是可以以 4K 作為標準線。
（圖7 音訊對齊方案）
如圖 7 為我們的音訊對齊方案：拿到音訊訊號以後，先經過時域轉頻域，進行頻域的低通，只保留 4K 以下的人聲，4K 以上的則作為打入特徵碼，把原始資訊留存，以備後續與目標對比。編完碼以後再轉成時域給 RTC ，RTC 進行時域轉頻域，進而經過提取就能取得音訊編號，最後通過低通濾波，再轉成原始的聲音。
除了視訊及音訊對齊方案，另外一個比較重要的方案是時鐘對齊。
1V1 通話中，500 毫秒延時就會影響互動體驗。我們在使用實時通訊產品時都遇到過這樣的情況：一個人想在對方兩句話之間的氣口接話，結果因為延遲過大（超過 500毫秒），對方並沒有接收到訊號，因而沒有停下來，最終兩個人就會互相進退推讓，造成整個互動過程的零亂。這也是我們需要測量延遲效能的主要原因。
另外，在進行自動化驗證時，往往使用多端裝置，不同裝置的時鐘之間其實差異較大，多達幾秒之高，這與我們所希望的毫秒誤差有很大差距，所以必須先將多端同步，把誤差控制在 100 毫秒之內。實際上，我們的實驗室環境誤差甚至能控制在幾十毫秒。
（圖8 時鐘對齊方案）
如圖 8 為時鐘對齊方案。每個客戶端在進行測試之前，都需要先將自己的時間戳發到統一的時間伺服器，由時間伺服器把客戶端 A 的時間戳帶上伺服器的時間戳返回來，客戶端收到返回包時會取到一個自己的時間戳 B。
修正時間=伺服器時間戳+ (客戶端時間戳 B - 客戶端時間戳 A)/2。也就是說，我們所有的客戶端都和時間伺服器對齊，即便時間伺服器有誤差也沒關係。
綜上我們拿到了視訊、音訊、時鐘三方面的對齊，爾後便可以完成全參考模型的對比工作。
（圖9 分析方式）
如圖 9 左側為傳送端，需要記錄幀號、時間戳、影像二進位制資訊。接收端也類似。這裡我們模擬一個丟包情況（3、4 號丟包），有了這兩張表以後通過質量分析，就能夠發現丟幀、幀率&流暢度變化、全參考影像質量、延遲、抖動等各種異常情況。
對前面講的全參考模型做一個總結。
（圖 10 音視訊端側特徵處理）
如圖 10，虛線上下方分別是視訊和音訊處理過程。在送入 WebRTC 之前，要進行原始視訊和時間戳日誌的記錄，接收端編碼識別之後，也需要將目標視訊和時間戳日誌記錄下來。音訊也類似。另外，還會記錄 WebRTC 本身的一些狀態，便於比對最終結果進行快速定位，初步判斷問題所在。
如圖 11 是我們自動化測試的總框架。
（圖11 自動化總框架）
最左側為驗證管理伺服器作為“總控”，拿到一個測試時，先是模擬網路環境，自動化配置弱網儀、伺服器和端，然後進行真正的實測，產生我們前面提到的所有檔案，最後完成彙總分析，進入資料庫。
如圖 12，自動化驗證的流程為：研發人員更改編碼、網路等特性後進行新版本提交，先是在驗證環境中部署版本，獲取用例資訊、配置弱網儀、執行測試過程、分析結果。如果發現其他用例，會不斷迴圈執行，最後生成報告。
（圖12 自動化驗證流程）
從觸發條件來說，無論是優化弱網演算法、音視訊演算法，還是流程優化和 OS 特性跟進，不管修改了什麼，原則上都要進行所有東西的驗證，包括網路環境、向後相容性、特殊機型覆蓋、歷史覆蓋、精準測量等。
SDN 大網的組建與質量跟蹤
SDN 大網建設的主要目標有兩個：
一個是實時組建，從功能拆分來主要就是節點狀態的收集、路徑規劃和線路優化，具體指標有：節點間多線路 QoS、節點度數 & 介數、節點負載壓力、可達路徑數等。
另一個是快速自愈。網路建立起來後，在日常運營中可能會出現節點損壞、專線臨時跑不通等情況，需要進行容災處理。容災處理首先要有錯誤收集反饋機制，以及路徑的重規劃、關鍵線路的均衡，有問題還需要不斷優化。
節點間主要連結方式有公網、雲內專線、專線、SD-WAN 四種。
（圖13 節點間連結方式與質量特點）
公網成本低，但是穩定性比較差；雲內專線成本比其他專線低一些，部署非常方便，但是無法在雲服務商中打通，跟 SD-WAN 比起來修復時間會長一些；專線就比如上海到新加坡之間跨國鏈路質量不好，直接拉一條專線，缺點是有些點運營商覆蓋不到；SD-WAN 也就是軟體定義的網路，連結能力強，成本稍貴，可以自動修復。
在實際應用中，幾種連結方式會同時使用。一旦有某條路徑出現問題，就能做到及時切換。
在級聯鏈路選取上，我們主要平衡三個因素：質量+場景+成本。比如 1v1 通話要求延時低一些，而直播對延遲放寬、但對頻寬的總量要求更高，最後會結合成本綜合考慮。
（圖14 實時質量資訊收集）
如圖 14，在對節點進行實時質量資訊收集時，我們會把一個節點裡所有服務資料彙總到節點的一個 Agent，進行初步分析後再到實時狀態管理伺服器，由它進行多節點之間的同步。這樣，全球網路所有節點的負載情況、當前頻寬質量等情況都可以知道。
鏈路問題的跟蹤與查詢
針對佈局全球的鏈路，融雲自建了一套監控系統。通過這個平臺，我們可以查詢使用者接入點、接入裝置以及使用的融雲 SDK 版本號等資訊，也可以得到使用者在業務過程中訂閱流的相關資訊，以及通過各種監測點，來對整體音視訊服務狀態進行監控。
（圖15 全球鏈路監控看板）
這樣，我們可以對服務質量和效能進行實時監控，分析影響客戶使用體驗的原因，為開發者提供更加詳細的位置資訊、準確的引數資訊、實際的場景情況等，最終方便研發人員快速定位根本問題、準確制定優化方案。