10 月 21 日，在上海舉辦的 QCon 全球軟件開發(fā)者大會上，融云聯(lián)合創(chuàng)始人兼 CTO 楊攀作為出品人發(fā)起的技術(shù)專場「實(shí)時(shí)通信技術(shù)」，受到開發(fā)者的歡迎與關(guān)注。
融云首席架構(gòu)師李淼、視頻算法專家黃震坤、流媒體架構(gòu)師許杰，分別帶來了《全球低延遲通信網(wǎng)絡(luò)的設(shè)計(jì)與優(yōu)化》、《AI 算法在視頻可分級編碼中的應(yīng)用》、《實(shí)時(shí)通信全鏈路質(zhì)量追蹤與指標(biāo)體系構(gòu)建》的主題分享。
(圖1 從左至右依次為：黃震坤、楊攀、李淼、許杰)
今天分享許杰老師的演講議題 ——實(shí)時(shí)通信全鏈路質(zhì)量追蹤與指標(biāo)體系構(gòu)建。內(nèi)容主要包括五大部分：實(shí)時(shí)音視頻平臺面臨的質(zhì)量挑戰(zhàn)、融云實(shí)時(shí)音視頻質(zhì)量控制總體架構(gòu)、客戶端實(shí)時(shí)音視頻質(zhì)量檢測、SDN 大網(wǎng)的組建與質(zhì)量跟蹤、鏈路問題的跟蹤與查詢。
獲取講師完整 PPT，請?jiān)凇救谠迫蚧ヂ?lián)網(wǎng)通信云】公眾號后臺回復(fù)“許杰”。
(圖2許杰在 QCon 現(xiàn)場做主題演講)
一、實(shí)時(shí)音視頻平臺面臨的質(zhì)量挑戰(zhàn)
實(shí)時(shí)音視頻平臺面臨的挑戰(zhàn)，可以概括為三個(gè)“多樣化”：
終端多樣化。包括 OS 版本特性、硬編碼差異、APP SDK 版本多等問題。
眾所周知，iOS 和 Android 是比較新生的系統(tǒng)，處于快速迭代期。在迭代過程中，不論新老特性，包括廠商兼容性等問題都比較突出，這也給我們 ToB 平臺帶來很大挑戰(zhàn)。不同于 PC 端升級有后臺駐留引擎的幫助，移動(dòng)端情況非常困難，很多 APP 還是幾年前的版本。
而所謂“硬編碼”—— 在移動(dòng)互聯(lián)網(wǎng)時(shí)代，硬件編解碼得到了廣泛應(yīng)用。很多網(wǎng)紅直播是在戶外，如果用純軟件編解碼，很快電量就會耗光。這也是為什么盡管其他編碼器也陸續(xù)發(fā)布，但最普及的卻仍是 H.264，與硬件有很大的關(guān)系。
全球網(wǎng)絡(luò)多樣化。涉及到網(wǎng)絡(luò)種類差異、跨國出口、國外基礎(chǔ)設(shè)施差異、專線建設(shè)限制等。其中前兩項(xiàng)大家會感觸很深，而在融云賦能大量企業(yè)出海的過程中，也非常深刻地體會到，海外基礎(chǔ)設(shè)施建設(shè)與中國差異之大。
用戶場景多樣化，比如 1V1、教育、金融、會議、低延時(shí)直播、語聊房等。舉一個(gè)簡單的例子，假如某 APP 直播時(shí)平均觀看時(shí)長為 10 分鐘，但在某一時(shí)段突然跌至 5 分鐘，我們就可以排查 —— 這種數(shù)值波動(dòng)是不是由質(zhì)量引起的，比如畫面質(zhì)量下降，或者是卡頓嚴(yán)重導(dǎo)致用戶無法耐心觀看、不得不頻繁切換直播間?由此通過 QoE 監(jiān)測，側(cè)面反推質(zhì)量。
二、 融云實(shí)時(shí)音視頻質(zhì)量控制總體架構(gòu)
上面提及的種種需求側(cè)的“挑戰(zhàn)”，切換到解決問題的角度，還是要轉(zhuǎn)化成技術(shù)思維。質(zhì)量架構(gòu)需要解決哪些問題?
首先是算法優(yōu)化，包括編解碼優(yōu)化、弱網(wǎng)網(wǎng)絡(luò)優(yōu)化等。從實(shí)驗(yàn)室環(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ù)器選點(diǎn)以后的覆蓋能力，尤其在海外很多國家，像東南亞地區(qū)，其人員分布較廣，基站、機(jī)房的覆蓋能力同樣需要嚴(yán)格審核。再有，如何評估當(dāng)前的專線質(zhì)量、全球鏈路質(zhì)量，以及容災(zāi)恢復(fù)情況等，都需要及時(shí)進(jìn)行監(jiān)控。
再次是客戶體驗(yàn)—— 客戶把信任交給我們，如何為客戶提供可靠的實(shí)時(shí)全局狀態(tài)監(jiān)控?數(shù)據(jù)報(bào)表匯總一旦發(fā)現(xiàn)問題，又是如何查詢鏈路細(xì)節(jié)信息、快速定位到問題所在?這些都是需要著力解決的問題。
帶著上述問題，來看一下融云實(shí)時(shí)音視頻質(zhì)量控制系統(tǒng)的總體架構(gòu)圖(圖3)。
(圖3 融云 RTC 質(zhì)量體系總體架構(gòu))
最底層是研發(fā)管理，包括用例管理、自動(dòng)驗(yàn)證、鏈路跟蹤、數(shù)據(jù)大屏、預(yù)警等。
中間層是融云全球“大網(wǎng)”SDN 的建設(shè)過程，其中比如日志系統(tǒng) —— 從全球十幾個(gè)大的節(jié)點(diǎn)把日志拉回來進(jìn)行實(shí)時(shí)分析;路由管理，實(shí)際上就是整個(gè)系統(tǒng)的“大腦”，包括路徑如何規(guī)劃、容災(zāi)怎么做等等。
最上方是客戶平臺，我們有報(bào)表、數(shù)據(jù)大屏和鏈路信息自查系統(tǒng)。
三、客戶端實(shí)時(shí)音視頻質(zhì)量檢測
客戶端 RTC 質(zhì)量檢測是本次分享的重點(diǎn)。
(圖4 RTC音視頻處理流程&質(zhì)量因素)
如圖 4 所示，數(shù)據(jù)從發(fā)送端經(jīng)過采集、前處理、編碼、發(fā)送，接收上來數(shù)據(jù)以后進(jìn)行解碼、后處理、渲染，這就是 RTC 典型的一個(gè)數(shù)據(jù)處理過程。
顯而易見，這個(gè)過程呈線性排布，由此帶來的麻煩是，一旦某一環(huán)節(jié)出現(xiàn)差錯(cuò)，后續(xù)所有環(huán)節(jié)質(zhì)量都會受到影響，就像一根“水管”，任何一個(gè)地方堵了，都會導(dǎo)致水流不暢通。
逐一來看：
采集端可能有硬件問題、焦點(diǎn)問題、噪點(diǎn)問題等隱患。硬件問題比如設(shè)備本身的解析度;焦點(diǎn)問題大家時(shí)常忽略，實(shí)際軟件的自動(dòng)對焦也會有失靈的情況，了解單反相機(jī)的人都知道，使用長焦鏡頭時(shí)焦平面非常短，稍微有一點(diǎn)問題都會導(dǎo)致畫面不清楚;噪點(diǎn)問題是指，電子元器件在低感光度時(shí)都會有噪點(diǎn)，而這種“隨機(jī)的小白點(diǎn)”對于整體質(zhì)量的影響非常大。
有了噪點(diǎn)以后就需要前處理，即編碼前的處理過程，包括美顏、下采樣、去噪等。目前主要采用“單幀去噪”，效果尚可，缺點(diǎn)是在視頻連續(xù)幀里面不會參考前后幀，導(dǎo)致幀與幀平均值不同，最后殘差較大。
到編碼階段，轉(zhuǎn)換、變換、量化也是畫面降低最大的因素，因?yàn)樗苤朴诰W(wǎng)絡(luò)的傳輸。眾所周知，RTC 重點(diǎn)就是優(yōu)化網(wǎng)絡(luò)，盡量增大可用帶寬，增強(qiáng)丟包、抖動(dò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)點(diǎn)是以人為本;缺點(diǎn)是成本太高了，并且不能精確復(fù)現(xiàn)，評判會隨著測試人員的情緒而變化。
所以研發(fā)人員希望有一些用機(jī)器代替人工的操作，比較典型的就是兩類：全參考和無參考。
無參考比如模糊度、塊效應(yīng)等，其優(yōu)點(diǎn)是只需要接收方一方的數(shù)據(jù);缺點(diǎn)是判斷力會偏弱，不能夠定位到系統(tǒng)內(nèi)外問題，比如最后結(jié)果圖效果不好，無法判斷是源本身不好，還是在處理過程中引進(jìn)了問題。
而全參考比如 PSNR、VMAF 等，具有技術(shù)上好操作的優(yōu)點(diǎn)，可以頻繁重復(fù)，并且能夠精準(zhǔn)復(fù)現(xiàn)，便于快速定位問題;缺點(diǎn)則是需要雙方數(shù)據(jù)，必須嚴(yán)格比對原圖和目標(biāo)圖。在這一點(diǎn)上，我們 RTC 模型的好處是，能夠容忍網(wǎng)絡(luò)丟包的問題。
比如發(fā)送端發(fā)了十張圖片，接收端只收到八張，無法滿足全參考的一一對應(yīng)，也不知道丟的是哪兩張，如何解決?
(圖6 視頻對齊方案)
如圖 6，我們參考英特爾的方案，在拿到一張?jiān)紙D時(shí)，會在圖片左上角加一個(gè)視頻編號，將這個(gè)編號處理完的圖作為原始圖傳至 RTC，接收端經(jīng)過解碼，通過深度學(xué)習(xí)的文字識別，將編號提取出來，這樣兩邊就能對應(yīng)起來。
以上是視頻的對齊方式，音頻又是如何?音頻對齊主要是利用一個(gè)“物理現(xiàn)象”：人類在語音聊天時(shí)主要集中在 4K 頻率以下，于是可以以 4K 作為標(biāo)準(zhǔn)線。
(圖7 音頻對齊方案)
如圖 7 為我們的音頻對齊方案：拿到音頻信號以后，先經(jīng)過時(shí)域轉(zhuǎn)頻域，進(jìn)行頻域的低通，只保留 4K 以下的人聲，4K 以上的則作為打入特征碼，把原始信息留存，以備后續(xù)與目標(biāo)對比。編完碼以后再轉(zhuǎn)成時(shí)域給 RTC ，RTC 進(jìn)行時(shí)域轉(zhuǎn)頻域，進(jìn)而經(jīng)過提取就能取得音頻編號，最后通過低通濾波，再轉(zhuǎn)成原始的聲音。
除了視頻及音頻對齊方案，另外一個(gè)比較重要的方案是時(shí)鐘對齊。
1V1 通話中，500 毫秒延時(shí)就會影響交互體驗(yàn)。我們在使用實(shí)時(shí)通信產(chǎn)品時(shí)都遇到過這樣的情況：一個(gè)人想在對方兩句話之間的氣口接話，結(jié)果因?yàn)檠舆t過大(超過 500毫秒)，對方并沒有接收到信號，因而沒有停下來，最終兩個(gè)人就會互相進(jìn)退推讓，造成整個(gè)交互過程的零亂。這也是我們需要測量延遲性能的主要原因。
另外，在進(jìn)行自動(dòng)化驗(yàn)證時(shí)，往往使用多端設(shè)備，不同設(shè)備的時(shí)鐘之間其實(shí)差異較大，多達(dá)幾秒之高，這與我們所希望的毫秒誤差有很大差距，所以必須先將多端同步，把誤差控制在 100 毫秒之內(nèi)。實(shí)際上，我們的實(shí)驗(yàn)室環(huán)境誤差甚至能控制在幾十毫秒。
(圖8 時(shí)鐘對齊方案)
如圖 8 為時(shí)鐘對齊方案。每個(gè)客戶端在進(jìn)行測試之前，都需要先將自己的時(shí)間戳發(fā)到統(tǒng)一的時(shí)間服務(wù)器，由時(shí)間服務(wù)器把客戶端 A 的時(shí)間戳帶上服務(wù)器的時(shí)間戳返回來，客戶端收到返回包時(shí)會取到一個(gè)自己的時(shí)間戳 B。
修正時(shí)間=服務(wù)器時(shí)間戳+ (客戶端時(shí)間戳 B - 客戶端時(shí)間戳 A)/2。也就是說，我們所有的客戶端都和時(shí)間服務(wù)器對齊，即便時(shí)間服務(wù)器有誤差也沒關(guān)系。
綜上我們拿到了視頻、音頻、時(shí)鐘三方面的對齊，爾后便可以完成全參考模型的對比工作。
(圖9 分析方式)
如圖 9 左側(cè)為發(fā)送端，需要記錄幀號、時(shí)間戳、圖像二進(jìn)制信息。接收端也類似。這里我們模擬一個(gè)丟包情況(3、4 號丟包)，有了這兩張表以后通過質(zhì)量分析，就能夠發(fā)現(xiàn)丟幀、幀率&流暢度變化、全參考圖像質(zhì)量、延遲、抖動(dòng)等各種異常情況。
對前面講的全參考模型做一個(gè)總結(jié)。
(圖 10 音視頻端側(cè)特征處理)
如圖 10，虛線上下方分別是視頻和音頻處理過程。在送入 WebRTC 之前，要進(jìn)行原始視頻和時(shí)間戳日志的記錄，接收端編碼識別之后，也需要將目標(biāo)視頻和時(shí)間戳日志記錄下來。音頻也類似。另外，還會記錄 WebRTC 本身的一些狀態(tài)，便于比對最終結(jié)果進(jìn)行快速定位，初步判斷問題所在。
如圖 11 是我們自動(dòng)化測試的總框架。
(圖11 自動(dòng)化總框架)
最左側(cè)為驗(yàn)證管理服務(wù)器作為“總控”，拿到一個(gè)測試時(shí)，先是模擬網(wǎng)絡(luò)環(huán)境，自動(dòng)化配置弱網(wǎng)儀、服務(wù)器和端，然后進(jìn)行真正的實(shí)測，產(chǎn)生我們前面提到的所有文件，最后完成匯總分析，進(jìn)入數(shù)據(jù)庫。
如圖 12，自動(dòng)化驗(yàn)證的流程為：研發(fā)人員更改編碼、網(wǎng)絡(luò)等特性后進(jìn)行新版本提交，先是在驗(yàn)證環(huán)境中部署版本，獲取用例信息、配置弱網(wǎng)儀、執(zhí)行測試過程、分析結(jié)果。如果發(fā)現(xiàn)其他用例，會不斷循環(huán)執(zhí)行，最后生成報(bào)告。
(圖12 自動(dòng)化驗(yàn)證流程)
從觸發(fā)條件來說，無論是優(yōu)化弱網(wǎng)算法、音視頻算法，還是流程優(yōu)化和 OS 特性跟進(jìn)，不管修改了什么，原則上都要進(jìn)行所有東西的驗(yàn)證，包括網(wǎng)絡(luò)環(huán)境、向后兼容性、特殊機(jī)型覆蓋、歷史覆蓋、精準(zhǔn)測量等。
四、 SDN 大網(wǎng)的組建與質(zhì)量跟蹤
SDN 大網(wǎng)建設(shè)的主要目標(biāo)有兩個(gè)：
一個(gè)是實(shí)時(shí)組建，從功能拆分來主要就是節(jié)點(diǎn)狀態(tài)的收集、路徑規(guī)劃和線路優(yōu)化，具體指標(biāo)有：節(jié)點(diǎn)間多線路 QoS、節(jié)點(diǎn)度數(shù) & 介數(shù)、節(jié)點(diǎn)負(fù)載壓力、可達(dá)路徑數(shù)等。
另一個(gè)是快速自愈。網(wǎng)絡(luò)建立起來后，在日常運(yùn)營中可能會出現(xiàn)節(jié)點(diǎn)損壞、專線臨時(shí)跑不通等情況，需要進(jìn)行容災(zāi)處理。容災(zāi)處理首先要有錯(cuò)誤收集反饋機(jī)制，以及路徑的重規(guī)劃、關(guān)鍵線路的均衡，有問題還需要不斷優(yōu)化。
節(jié)點(diǎn)間主要鏈接方式有公網(wǎng)、云內(nèi)專線、專線、SD-WAN四種。
(圖13 節(jié)點(diǎn)間鏈接方式與質(zhì)量特點(diǎn))
公網(wǎng)成本低，但是穩(wěn)定性比較差;云內(nèi)專線成本比其他專線低一些，部署非常方便，但是無法在云服務(wù)商中打通，跟 SD-WAN 比起來修復(fù)時(shí)間會長一些;專線就比如上海到新加坡之間跨國鏈路質(zhì)量不好，直接拉一條專線，缺點(diǎn)是有些點(diǎn)運(yùn)營商覆蓋不到;SD-WAN也就是軟件定義的網(wǎng)絡(luò)，鏈接能力強(qiáng)，成本稍貴，可以自動(dòng)修復(fù)。
在實(shí)際應(yīng)用中，幾種鏈接方式會同時(shí)使用。一旦有某條路徑出現(xiàn)問題，就能做到及時(shí)切換。
在級聯(lián)鏈路選取上，我們主要平衡三個(gè)因素：質(zhì)量+場景+成本。比如 1v1 通話要求延時(shí)低一些，而直播對延遲放寬、但對帶寬的總量要求更高，最后會結(jié)合成本綜合考慮。
(圖14 實(shí)時(shí)質(zhì)量信息收集)
如圖 14，在對節(jié)點(diǎn)進(jìn)行實(shí)時(shí)質(zhì)量信息收集時(shí)，我們會把一個(gè)節(jié)點(diǎn)里所有服務(wù)數(shù)據(jù)匯總到節(jié)點(diǎn)的一個(gè) Agent，進(jìn)行初步分析后再到實(shí)時(shí)狀態(tài)管理服務(wù)器，由它進(jìn)行多節(jié)點(diǎn)之間的同步。這樣，全球網(wǎng)絡(luò)所有節(jié)點(diǎn)的負(fù)載情況、當(dāng)前帶寬質(zhì)量等情況都可以知道。
五、 鏈路問題的跟蹤與查詢
針對布局全球的鏈路，融云自建了一套監(jiān)控系統(tǒng)。通過這個(gè)平臺，我們可以查詢用戶接入點(diǎn)、接入設(shè)備以及使用的融云 SDK 版本號等信息，也可以得到用戶在業(yè)務(wù)過程中訂閱流的相關(guān)信息，以及通過各種監(jiān)測點(diǎn)，來對整體音視頻服務(wù)狀態(tài)進(jìn)行監(jiān)控。
(圖15 全球鏈路監(jiān)控看板，詳細(xì)信息在【融云全球互聯(lián)網(wǎng)通信云】公眾號)
這樣，我們可以對服務(wù)質(zhì)量和性能進(jìn)行實(shí)時(shí)監(jiān)控，分析影響客戶使用體驗(yàn)的原因，為開發(fā)者提供更加詳細(xì)的位置信息、準(zhǔn)確的參數(shù)信息、實(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)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
