10 月 21 日，在上海舉辦的 QCon 全球軟件開發者大會上，融云聯合創始人兼 CTO 楊攀作為出品人發起的技術專場「實時通信技術」，受到開發者的歡迎與關注。
融云首席架構師李淼、視頻算法專家黃震坤、流媒體架構師許杰，分別帶來了《全球低延遲通信網絡的設計與優化》、《AI 算法在視頻可分級編碼中的應用》、《實時通信全鏈路質量追蹤與指標體系構建》的主題分享。
（圖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 全球鏈路監控看板，詳細信息在【融云全球互聯網通信云】公眾號）
這樣，我們可以對服務質量和性能進行實時監控，分析影響客戶使用體驗的原因，為開發者提供更加詳細的位置信息、準確的參數信息、實際的場景情況等，最終方便研發人員快速定位根本問題、準確制定優化方案。
