10 月 21 日，在上海舉辦的 QCon 全球軟件開發(fā)者大會上，融云聯(lián)合創(chuàng)始人兼 CTO 楊攀作為出品人發(fā)起的技術(shù)專場「實時通信技術(shù)」，受到開發(fā)者的歡迎與關(guān)注。

融云首席架構(gòu)師李淼、視頻算法專家黃震坤、流媒體架構(gòu)師許杰，分別帶來了《全球低延遲通信網(wǎng)絡(luò)的設(shè)計與優(yōu)化》、《AI 算法在視頻可分級編碼中的應(yīng)用》、《實時通信全鏈路質(zhì)量追蹤與指標(biāo)體系構(gòu)建》的主題分享。

(圖1 從左至右依次為：黃震坤、楊攀、李淼、許杰)

今天分享許杰老師的演講議題 ——實時通信全鏈路質(zhì)量追蹤與指標(biāo)體系構(gòu)建。內(nèi)容主要包括五大部分：實時音視頻平臺面臨的質(zhì)量挑戰(zhàn)、融云實時音視頻質(zhì)量控制總體架構(gòu)、客戶端實時音視頻質(zhì)量檢測、SDN 大網(wǎng)的組建與質(zhì)量跟蹤、鏈路問題的跟蹤與查詢。

獲取講師完整 PPT，請在【融云全球互聯(lián)網(wǎng)通信云】公眾號后臺回復(fù)“許杰”。

(圖2許杰在 QCon 現(xiàn)場做主題演講)

一、實時音視頻平臺面臨的質(zhì)量挑戰(zhàn)

實時音視頻平臺面臨的挑戰(zhàn)，可以概括為三個“多樣化”：

終端多樣化。包括 OS 版本特性、硬編碼差異、APP SDK 版本多等問題。

眾所周知，iOS 和 Android 是比較新生的系統(tǒng)，處于快速迭代期。在迭代過程中，不論新老特性，包括廠商兼容性等問題都比較突出，這也給我們 ToB 平臺帶來很大挑戰(zhàn)。不同于 PC 端升級有后臺駐留引擎的幫助，移動端情況非常困難，很多 APP 還是幾年前的版本。

而所謂“硬編碼”—— 在移動互聯(lián)網(wǎng)時代，硬件編解碼得到了廣泛應(yīng)用。很多網(wǎng)紅直播是在戶外，如果用純軟件編解碼，很快電量就會耗光。這也是為什么盡管其他編碼器也陸續(xù)發(fā)布，但最普及的卻仍是 H.264，與硬件有很大的關(guān)系。

全球網(wǎng)絡(luò)多樣化。涉及到網(wǎng)絡(luò)種類差異、跨國出口、國外基礎(chǔ)設(shè)施差異、專線建設(shè)限制等。其中前兩項大家會感觸很深，而在融云賦能大量企業(yè)出海的過程中，也非常深刻地體會到，海外基礎(chǔ)設(shè)施建設(shè)與中國差異之大。

用戶場景多樣化，比如 1V1、教育、金融、會議、低延時直播、語聊房等。舉一個簡單的例子，假如某 APP 直播時平均觀看時長為 10 分鐘，但在某一時段突然跌至 5 分鐘，我們就可以排查 —— 這種數(shù)值波動是不是由質(zhì)量引起的，比如畫面質(zhì)量下降，或者是卡頓嚴(yán)重導(dǎo)致用戶無法耐心觀看、不得不頻繁切換直播間?由此通過 QoE 監(jiān)測，側(cè)面反推質(zhì)量。

　　二、 融云實時音視頻質(zhì)量控制總體架構(gòu)

上面提及的種種需求側(cè)的“挑戰(zhàn)”，切換到解決問題的角度，還是要轉(zhuǎn)化成技術(shù)思維。質(zhì)量架構(gòu)需要解決哪些問題?

首先是算法優(yōu)化，包括編解碼優(yōu)化、弱網(wǎng)網(wǎng)絡(luò)優(yōu)化等。從實驗室環(huán)境切入，看我們的研發(fā)質(zhì)量究竟符不符合生產(chǎn)環(huán)境要求，生產(chǎn)環(huán)境泛化能力如何，先小規(guī)模地推到生產(chǎn)環(huán)境的網(wǎng)絡(luò)上，如果發(fā)生問題，再進(jìn)行召回。

其次是 SDN。SDN 建設(shè)就是如何評估服務(wù)器選點以后的覆蓋能力，尤其在海外很多國家，像東南亞地區(qū)，其人員分布較廣，基站、機(jī)房的覆蓋能力同樣需要嚴(yán)格審核。再有，如何評估當(dāng)前的專線質(zhì)量、全球鏈路質(zhì)量，以及容災(zāi)恢復(fù)情況等，都需要及時進(jìn)行監(jiān)控。

再次是客戶體驗—— 客戶把信任交給我們，如何為客戶提供可靠的實時全局狀態(tài)監(jiān)控?數(shù)據(jù)報表匯總一旦發(fā)現(xiàn)問題，又是如何查詢鏈路細(xì)節(jié)信息、快速定位到問題所在?這些都是需要著力解決的問題。

帶著上述問題，來看一下融云實時音視頻質(zhì)量控制系統(tǒng)的總體架構(gòu)圖(圖3)。

(圖3 融云 RTC 質(zhì)量體系總體架構(gòu))

最底層是研發(fā)管理，包括用例管理、自動驗證、鏈路跟蹤、數(shù)據(jù)大屏、預(yù)警等。

中間層是融云全球“大網(wǎng)”SDN 的建設(shè)過程，其中比如日志系統(tǒng) —— 從全球十幾個大的節(jié)點把日志拉回來進(jìn)行實時分析;路由管理，實際上就是整個系統(tǒng)的“大腦”，包括路徑如何規(guī)劃、容災(zāi)怎么做等等。

最上方是客戶平臺，我們有報表、數(shù)據(jù)大屏和鏈路信息自查系統(tǒng)。

三、客戶端實時音視頻質(zhì)量檢測

客戶端 RTC 質(zhì)量檢測是本次分享的重點。

(圖4 RTC音視頻處理流程&質(zhì)量因素)

如圖 4 所示，數(shù)據(jù)從發(fā)送端經(jīng)過采集、前處理、編碼、發(fā)送，接收上來數(shù)據(jù)以后進(jìn)行解碼、后處理、渲染，這就是 RTC 典型的一個數(shù)據(jù)處理過程。

顯而易見，這個過程呈線性排布，由此帶來的麻煩是，一旦某一環(huán)節(jié)出現(xiàn)差錯，后續(xù)所有環(huán)節(jié)質(zhì)量都會受到影響，就像一根“水管”，任何一個地方堵了，都會導(dǎo)致水流不暢通。

逐一來看：

采集端可能有硬件問題、焦點問題、噪點問題等隱患。硬件問題比如設(shè)備本身的解析度;焦點問題大家時常忽略，實際軟件的自動對焦也會有失靈的情況，了解單反相機(jī)的人都知道，使用長焦鏡頭時焦平面非常短，稍微有一點問題都會導(dǎo)致畫面不清楚;噪點問題是指，電子元器件在低感光度時都會有噪點，而這種“隨機(jī)的小白點”對于整體質(zhì)量的影響非常大。

有了噪點以后就需要前處理，即編碼前的處理過程，包括美顏、下采樣、去噪等。目前主要采用“單幀去噪”，效果尚可，缺點是在視頻連續(xù)幀里面不會參考前后幀，導(dǎo)致幀與幀平均值不同，最后殘差較大。

到編碼階段，轉(zhuǎn)換、變換、量化也是畫面降低最大的因素，因為它受制于網(wǎng)絡(luò)的傳輸。眾所周知，RTC 重點就是優(yōu)化網(wǎng)絡(luò)，盡量增大可用帶寬，增強(qiáng)丟包、抖動的適應(yīng)力，給編碼創(chuàng)造比較好的條件。

解碼是編碼的反向過程，依然會遇到轉(zhuǎn)換、變換的問題。而所謂“濾波”，指的是，我們現(xiàn)在使用的編碼器基本是混合編碼器，使用“塊”進(jìn)行運(yùn)算，帶來的問題是，一張圖像中塊與塊之間的“平均值”誤差也很明顯，所以會使用濾波濾掉這種“塊效應(yīng)”。

后處理，除了前面講到的視頻采樣，音頻方面的主要問題是數(shù)據(jù)丟包，為了彌補(bǔ)丟包后的聽覺效果，會增加變速不變調(diào)的特性，甚至是舒適噪聲。

渲染主要是硬件方面，比如顯示速度不夠，導(dǎo)致解碼等都沒有問題、最后幀率卻不太均勻的情況。

針對以上問題，業(yè)內(nèi)有一些常用的評估指標(biāo)，以兩大類為主：主觀指標(biāo)和客觀指標(biāo)。

(圖5 常用評估指標(biāo))

主觀指標(biāo)中最具代表性的是 MOS。其優(yōu)點是以人為本;缺點是成本太高了，并且不能精確復(fù)現(xiàn)，評判會隨著測試人員的情緒而變化。

所以研發(fā)人員希望有一些用機(jī)器代替人工的操作，比較典型的就是兩類：全參考和無參考。

無參考比如模糊度、塊效應(yīng)等，其優(yōu)點是只需要接收方一方的數(shù)據(jù);缺點是判斷力會偏弱，不能夠定位到系統(tǒng)內(nèi)外問題，比如最后結(jié)果圖效果不好，無法判斷是源本身不好，還是在處理過程中引進(jìn)了問題。

而全參考比如 PSNR、VMAF 等，具有技術(shù)上好操作的優(yōu)點，可以頻繁重復(fù)，并且能夠精準(zhǔn)復(fù)現(xiàn)，便于快速定位問題;缺點則是需要雙方數(shù)據(jù)，必須嚴(yán)格比對原圖和目標(biāo)圖。在這一點上，我們 RTC 模型的好處是，能夠容忍網(wǎng)絡(luò)丟包的問題。

比如發(fā)送端發(fā)了十張圖片，接收端只收到八張，無法滿足全參考的一一對應(yīng)，也不知道丟的是哪兩張，如何解決?

(圖6 視頻對齊方案)

如圖 6，我們參考英特爾的方案，在拿到一張原始圖時，會在圖片左上角加一個視頻編號，將這個編號處理完的圖作為原始圖傳至 RTC，接收端經(jīng)過解碼，通過深度學(xué)習(xí)的文字識別，將編號提取出來，這樣兩邊就能對應(yīng)起來。

以上是視頻的對齊方式，音頻又是如何?音頻對齊主要是利用一個“物理現(xiàn)象”：人類在語音聊天時主要集中在 4K 頻率以下，于是可以以 4K 作為標(biāo)準(zhǔn)線。

(圖7 音頻對齊方案)

如圖 7 為我們的音頻對齊方案：拿到音頻信號以后，先經(jīng)過時域轉(zhuǎn)頻域，進(jìn)行頻域的低通，只保留 4K 以下的人聲，4K 以上的則作為打入特征碼，把原始信息留存，以備后續(xù)與目標(biāo)對比。編完碼以后再轉(zhuǎn)成時域給 RTC ，RTC 進(jìn)行時域轉(zhuǎn)頻域，進(jìn)而經(jīng)過提取就能取得音頻編號，最后通過低通濾波，再轉(zhuǎn)成原始的聲音。

除了視頻及音頻對齊方案，另外一個比較重要的方案是時鐘對齊。

1V1 通話中，500 毫秒延時就會影響交互體驗。我們在使用實時通信產(chǎn)品時都遇到過這樣的情況：一個人想在對方兩句話之間的氣口接話，結(jié)果因為延遲過大(超過 500毫秒)，對方并沒有接收到信號，因而沒有停下來，最終兩個人就會互相進(jìn)退推讓，造成整個交互過程的零亂。這也是我們需要測量延遲性能的主要原因。

另外，在進(jìn)行自動化驗證時，往往使用多端設(shè)備，不同設(shè)備的時鐘之間其實差異較大，多達(dá)幾秒之高，這與我們所希望的毫秒誤差有很大差距，所以必須先將多端同步，把誤差控制在 100 毫秒之內(nèi)。實際上，我們的實驗室環(huán)境誤差甚至能控制在幾十毫秒。

(圖8 時鐘對齊方案)

如圖 8 為時鐘對齊方案。每個客戶端在進(jìn)行測試之前，都需要先將自己的時間戳發(fā)到統(tǒng)一的時間服務(wù)器，由時間服務(wù)器把客戶端 A 的時間戳帶上服務(wù)器的時間戳返回來，客戶端收到返回包時會取到一個自己的時間戳 B。

修正時間=服務(wù)器時間戳+ (客戶端時間戳 B - 客戶端時間戳 A)/2。也就是說，我們所有的客戶端都和時間服務(wù)器對齊，即便時間服務(wù)器有誤差也沒關(guān)系。

綜上我們拿到了視頻、音頻、時鐘三方面的對齊，爾后便可以完成全參考模型的對比工作。

(圖9 分析方式)

如圖 9 左側(cè)為發(fā)送端，需要記錄幀號、時間戳、圖像二進(jìn)制信息。接收端也類似。這里我們模擬一個丟包情況(3、4 號丟包)，有了這兩張表以后通過質(zhì)量分析，就能夠發(fā)現(xiàn)丟幀、幀率&流暢度變化、全參考圖像質(zhì)量、延遲、抖動等各種異常情況。

對前面講的全參考模型做一個總結(jié)。

(圖 10 音視頻端側(cè)特征處理)

如圖 10，虛線上下方分別是視頻和音頻處理過程。在送入 WebRTC 之前，要進(jìn)行原始視頻和時間戳日志的記錄，接收端編碼識別之后，也需要將目標(biāo)視頻和時間戳日志記錄下來。音頻也類似。另外，還會記錄 WebRTC 本身的一些狀態(tài)，便于比對最終結(jié)果進(jìn)行快速定位，初步判斷問題所在。

如圖 11 是我們自動化測試的總框架。

(圖11 自動化總框架)

最左側(cè)為驗證管理服務(wù)器作為“總控”，拿到一個測試時，先是模擬網(wǎng)絡(luò)環(huán)境，自動化配置弱網(wǎng)儀、服務(wù)器和端，然后進(jìn)行真正的實測，產(chǎn)生我們前面提到的所有文件，最后完成匯總分析，進(jìn)入數(shù)據(jù)庫。

如圖 12，自動化驗證的流程為：研發(fā)人員更改編碼、網(wǎng)絡(luò)等特性后進(jìn)行新版本提交，先是在驗證環(huán)境中部署版本，獲取用例信息、配置弱網(wǎng)儀、執(zhí)行測試過程、分析結(jié)果。如果發(fā)現(xiàn)其他用例，會不斷循環(huán)執(zhí)行，最后生成報告。

(圖12 自動化驗證流程)

從觸發(fā)條件來說，無論是優(yōu)化弱網(wǎng)算法、音視頻算法，還是流程優(yōu)化和 OS 特性跟進(jìn)，不管修改了什么，原則上都要進(jìn)行所有東西的驗證，包括網(wǎng)絡(luò)環(huán)境、向后兼容性、特殊機(jī)型覆蓋、歷史覆蓋、精準(zhǔn)測量等。

四、 SDN 大網(wǎng)的組建與質(zhì)量跟蹤

SDN 大網(wǎng)建設(shè)的主要目標(biāo)有兩個：

一個是實時組建，從功能拆分來主要就是節(jié)點狀態(tài)的收集、路徑規(guī)劃和線路優(yōu)化，具體指標(biāo)有：節(jié)點間多線路 QoS、節(jié)點度數(shù) & 介數(shù)、節(jié)點負(fù)載壓力、可達(dá)路徑數(shù)等。

另一個是快速自愈。網(wǎng)絡(luò)建立起來后，在日常運(yùn)營中可能會出現(xiàn)節(jié)點損壞、專線臨時跑不通等情況，需要進(jìn)行容災(zāi)處理。容災(zāi)處理首先要有錯誤收集反饋機(jī)制，以及路徑的重規(guī)劃、關(guān)鍵線路的均衡，有問題還需要不斷優(yōu)化。

節(jié)點間主要鏈接方式有公網(wǎng)、云內(nèi)專線、專線、SD-WAN四種。

(圖13 節(jié)點間鏈接方式與質(zhì)量特點)

公網(wǎng)成本低，但是穩(wěn)定性比較差;云內(nèi)專線成本比其他專線低一些，部署非常方便，但是無法在云服務(wù)商中打通，跟 SD-WAN 比起來修復(fù)時間會長一些;專線就比如上海到新加坡之間跨國鏈路質(zhì)量不好，直接拉一條專線，缺點是有些點運(yùn)營商覆蓋不到;SD-WAN也就是軟件定義的網(wǎng)絡(luò)，鏈接能力強(qiáng)，成本稍貴，可以自動修復(fù)。

在實際應(yīng)用中，幾種鏈接方式會同時使用。一旦有某條路徑出現(xiàn)問題，就能做到及時切換。

在級聯(lián)鏈路選取上，我們主要平衡三個因素：質(zhì)量+場景+成本。比如 1v1 通話要求延時低一些，而直播對延遲放寬、但對帶寬的總量要求更高，最后會結(jié)合成本綜合考慮。

(圖14 實時質(zhì)量信息收集)

如圖 14，在對節(jié)點進(jìn)行實時質(zhì)量信息收集時，我們會把一個節(jié)點里所有服務(wù)數(shù)據(jù)匯總到節(jié)點的一個 Agent，進(jìn)行初步分析后再到實時狀態(tài)管理服務(wù)器，由它進(jìn)行多節(jié)點之間的同步。這樣，全球網(wǎng)絡(luò)所有節(jié)點的負(fù)載情況、當(dāng)前帶寬質(zhì)量等情況都可以知道。

五、 鏈路問題的跟蹤與查詢

針對布局全球的鏈路，融云自建了一套監(jiān)控系統(tǒng)。通過這個平臺，我們可以查詢用戶接入點、接入設(shè)備以及使用的融云 SDK 版本號等信息，也可以得到用戶在業(yè)務(wù)過程中訂閱流的相關(guān)信息，以及通過各種監(jiān)測點，來對整體音視頻服務(wù)狀態(tài)進(jìn)行監(jiān)控。

(圖15 全球鏈路監(jiān)控看板，詳細(xì)信息在【融云全球互聯(lián)網(wǎng)通信云】公眾號)

這樣，我們可以對服務(wù)質(zhì)量和性能進(jìn)行實時監(jiān)控，分析影響客戶使用體驗的原因，為開發(fā)者提供更加詳細(xì)的位置信息、準(zhǔn)確的參數(shù)信息、實際的場景情況等，最終方便研發(fā)人員快速定位根本問題、準(zhǔn)確制定優(yōu)化方案。

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）