文 / 張武峰
整理 / LiveVideoStack
大家好我是來自VIPKID的張武峰，今天我與大家分享的是線上教育音視訊品質評價與感覺系統。
我有二十餘年的音視訊開發經驗，最早從事傳統視訊會議方向的探索，後來轉向至3G、4G網絡下的視訊電話。 傳統視訊會議多由專網傳輸，目标是如何盡可能地實作出色的音畫品質； 而消費級網際網路基于公共網絡的環境與專網有很大的不同，遇到的挑戰相對于專網來說完全不一樣，這就使得我在進入消費級網際網路行業時發現，自己之前在開發基于專網的商業級音視訊業務當中積累的知識與經驗無法有效應對新的業務場景和開發痛點，知識體系的更新重組對我而言是非常有必要的。
2017年我加入了VIPKID，帶領音視訊團隊探索如何更好地将實時RTC技術用于線上教育領域。 我之前一直從事技術方面的優化與創新，而這次選題我特意選取了QoE方向，就是因為探索了這麼多年的技術，我發現技術最重要的是為實際應用場景帶來具有建設性的優化改進，而品質評價與感覺系統是其中最為關鍵的一環。 我們希望完整建構一套嚴謹專業客觀的音視訊品質評價與感覺系統，進而為使用者體驗的優化與提升解決方案提供強有力的資料支撐。
我将基于以下四個方面開展本次分享
1. 使用者痛點
管理大師德魯克曾說： 沒有度量就沒有優化，這句話用于音視訊開發也非常恰當。 我們在之前的開發過程中就積累了許多教訓，如在優化系統時我們就曾遇見這樣的問題： 設計一項優化算法，設計初期我們預期該算法能将使用者體驗提升至新的高度，且我們也通過多種自證方式驗證了其邏輯自洽，于是我們在預期成立的前提下為該算法投入資源進行開發，但在算法上線之後我們卻發現其實際效果和預期存在很大的差異，該算法對于使用者的主觀體驗沒有帶來改觀甚至造成負面影響。 這一經驗令我們思考： 音視訊系統究竟需要一套怎樣的标準才能準确客觀評價算法的優劣？ 在設計任何音視訊系統或者針對系統當中某一點進行優化時，開發者一定需要先仔細思考如何借助資料準确合理度量正在開發的算法，不僅是從實驗室角度度量更應當從使用者角度度量。 這樣無論是灰階測試還是頻繁地版本疊代，甚至多個團隊基于同一方向進行的優化競争，确立好的度量标準就如一把尺子，可以準确客觀衡量出算法可為使用者體驗帶來多少提升與優化。
上圖右側餅狀圖展示了VIPKID使用者所反映的針對産品所提出的五大關鍵問題（占比從高到低依次為： 網絡問題、裝置問題、行為問題、軟體問題與課件問題）對于所有RTC開發者來說，網絡問題永遠是一項最艱巨的挑戰； 而當使用者數量達到一定規模時，不同軟硬體平台裝置、不同版本的軟體适配問題也将成為一項亟待解決的重要命題。
而上圖左側展示了如果使用者為我們的一項服務給出差評，其給出差評所選出的主要理由： （畫面/聲音卡頓、聲音延時/畫面不同步、聲音不清晰與回聲嚴重）。 需要注意的是由于使用者并非專業的開發者，這裡沒有一個統一的标準去衡量這些問題。 例如什麼是“畫面卡頓”，有些使用者可能會将攝像頭故障等其他問題歸類為”畫面卡頓“，這就需要我們基于大量的使用者資料進行篩選清洗與分析進而盡可能找出使用者最關注的幾項痛點。 線上教育屬于一個重度依賴音視訊技術的應用場景，故其暴露出來的音視訊技術問題也會很多。
2. 評價體系
既然存在如此多而複雜的使用者痛點，那麼确立一套專業客觀精準高效的音視訊使用者體驗評價體系就變得尤為重要。
上圖表格展示了音視訊評價的多個次元，用以評價一節完整線上教育課程的使用者體驗優劣。 首先在視訊方面，使用者對卡頓的感覺最為敏感，而其統計方法主要是将幀與幀之間超過200ms的間隔視為一次卡頓，（卡頓時間/上課市場）=卡頓率，我們将5%作為引起使用者卡頓感的門檻值，資料主要來自用戶端采集。
視訊畫面的清晰度則主要使用MOS分作為評價标準，也就是從原始錄像中按照每分鐘1幀的方式抽取I幀圖像并為其清晰度賦予MOS分值，所得到的系統分值再與使用者的主觀感覺評價進行比對，最終得到的分值如果低于3分那麼我們就視該視訊畫面清晰度不佳。 需要注意的是，這裡的MOS分并非單純基于肉眼感覺的畫面品質，而是基于綜合視訊編碼與網絡傳輸的參數，通過AI訓練而成的一套算法為其賦分，資料主要通過錄制上課視訊得到。
音頻方面，除了“清晰度”這樣一項常見的名額之外，“聲音大小”是我們根據使用者回報評價新增加的一項評價次元，這主要是因為許多使用者回報上課時感覺聲音過大或者過小以至于聽不清楚，發生這種情況多由于老師直播或錄制課程時離話筒距離不當或錄制裝置不佳，也有可能是使用者端的設定出現失誤。 我們選取老師講話的部分并計算其音量是否合适，低于30分我們就認為該片段聲音大小不符合使用者體驗要求； 而“清晰度”則依舊使用常見的MOS賦分的形式，利用程式給目标錄像片段的音頻打分，低于3分我們認為該片段的音頻清晰度不佳。 以上是我們确立的針對線上教育所設計的一套完整評價次元，作為技術團隊的KPI來使用。 針對每一項，我們會有專門的團隊負責優化與改進目标次元對應的算法與技術名額，以實作最優效果。
2.1. 視訊卡頓率：
卡頓率的定義如下： 如果是1對1的視訊應用場景，那麼使用者卡頓率為使用者觀看時間内幀與幀之間超過200ms的總時長除以使用者觀看總時長（課中使用者線上時長）； 而對于一對多的視訊場景，我們會統計卡頓使用者數占比也就是統計卡頓率大于等于5%的使用者數并将該數字除以總上課人數（也就是進過教室10s以上的使用者數）。 這裡的200ms門檻值其實算是一個比較嚴苛的标準，有一些網際網路公司會将該數值确定在600ms左右，我們這樣做是為了統計更多的卡頓案例并獲得更多的資料以便于我們進行卡頓分析與研究，促使技術團隊更出色地優化卡頓。 每一項名額在确立的時候都與應用場景強相關，這些名額雖然都與技術相關但其和使用者主觀感覺一一對應。
我們為統計到的卡頓情況作出了如下級别細分，其中遇到1、2級别卡頓情況的使用者占比約為5%，遇到3、4、5級别卡頓的使用者平均占比約為18%。 這一數字在業内屬于比較好的情況。
2.2. 視訊打分算法流程
我們大概花費了兩到三個月探索視訊打分算法，在初期我們閱讀了許多論文著作，發現業界還沒有很出色的無參考視訊打分算法。 當時也試驗過其他廠商的比較成熟的算法也沒有達到理想的效果，直接用一張圖檔訓練無法實作收斂。 于是我們嘗試換了一個方向，也就是從視訊編碼資料流當中抽取一些參數例如GOP幀宏塊的大小，宏塊的個數、丢包個數等以形成訓練資料集，随後再使用該資料集訓練打分算法模型。 我們将得到的模型與人工标記做對比，最終的效果符合我們的需求，和使用者主觀感覺結果的比對度大概在80%，該算法模型就固定下來并被我們用于後續的關鍵開發活動當中。
2.3. 特征提取
特征提取的第一步是需要對檔案進行解析，我們的線上課程視訊檔案基于不同的系統與格式，如mp4、flv、ts等等。 再将原檔案統一成H.264/H.265碼流之後，碼流解碼程式會解析得到解碼後的圖像序列，該圖像序列會被導入場景檢測程式以生成特征提取單元； 特征提取單元會在接下來的流程中被篩選，系統判斷其是否超過最大序列長度，如果未超過，那麼該特征提取單元會被直接輸入特征提取程式以提取出有效特征； 如果超過，那麼該特征提取單元會被依據最大序列長度做切分以生成符合序列長度要求的多條特征提取單元，這些特征單元會被輸入特征提取程式以生成我們想要的特征資料。
2.4. 視訊訓練的關鍵參數
下圖展示了訓練該算法模型所需要的幾項關鍵參數，其中包括宏塊個數、幀的類型、宏塊是否會丢包等。 這一部分訓練所消耗的算力資源是比較多的，如果想獲得比較出色的訓練效果，服務端強大且可靠的硬體支援必不可少。
2.5. 聲音品質P.563
從事音頻品質評價的朋友應該不會對該聲音品質評價模型感到陌生，該算法模型于2004年被提出。 無論是音頻還是視訊，所有全參考的打分算法線上上系統都是不可用的。 我們無法直接調取發端和收端的資料套用全參考算法，故面對線上音視訊場景所使用的打分算法一定是單邊的無參考算法。 P.563就是這樣一套可靠的單邊算法，其不依賴發端資料，僅需收端資料即可直接運算得到評估分數。 大緻流程如下圖中顯示的那樣：
首先，提取的原始資料會經由預處理後進行話音參數特征的提取與計算，所得到的參數會被歸類為多種失真類型，按照不同的失真類型選取對應的話音品質模型進而得到準确客觀的MOS分數。 之前我們提到了評價次元裡面有一項是音量大小，而P.563在預處理的過程中就會計算得到Active speech level adjustment這樣一個參數，我們将4ms幀長下的Speech Level作為聲音大小，取值範圍是1～100，連續3幀以上超過門檻值為不合格，反之則會被當成背景噪聲過濾，進而我們得到了評估聲音品質所需的所有關鍵評分。
2.6. 品質分析系統
之前我們介紹了如何擷取算法，而在擷取到準确算法之後，如何部署大批量的品質分析與資料運算便成了接下來的另一項關鍵命題，為解決該命題我們設計了一套支援全局任務排程的分布式品質分析系統： 接口層的HTTP接口與公司的BI系統對接，BI系統會下發品質分析任務，由HTTP接口傳輸至任務生成層； 任務生成層會根據上層所下發的任務清單合理進行任務配置設定，以充分高效利用計算資源； 配置設定結果傳遞至Job Server Node，Job Server Node會将任務真正下發至任務消費層CmqaWorker系統，而每個Worker下層的Audio-quality-evaluation或Video-quality-evaluation等會實際執行計算任務。 在-quality-evaluation進行評估計算時，CmqaCollector會收集相關資料并存儲到DBI，每一次任務分發時，Cmqa Master會從DBI當中調取資料以獲知哪些計算資源是空閑的或者任務負載較低，以合理科學高效配置設定下發任務。 該任務系統主要會在每天結束所有課程後的夜間22:00～次日08:00運作以避免影響實時上課，當然有些特殊資料需要在白天上課時同步進行，是以整個系統一直處于24小時不間斷運作狀态。
3. 品質感覺
3.1 海豚系統
我們将基于以上評價體系建構的品質感覺系統成為“海豚系統”，該系統全天運轉，用以感覺整個基于在全球四十多個節點部署的超過一千五百多台伺服器的上課系統。 通過該系統我們可以及時獲知那些節點出現異常，甚至精确到哪個使用者出現問題。 像VIPKID多為付費産品，使用者對于産品體驗的要求很高，我們必須提高所有技術标準并盡可能精确快速處理危機故障。 整個品質感覺系統的架構如下： 首先底層的資料來源于SDK上報日志（音視訊的SDK，包括音頻視訊幀率、卡頓率、使用者所使用平台版本、攝像頭資料等，其貢獻資料最多）、用戶端打點（使用者行為）、服務端日志（自建流媒體加速系統的流媒體服務、信令服務、工作狀态等）、BI資料與QOS資料（來自音視訊之外的其他資料），資料拉取與采集之後會進行資料清洗，這些清洗好的結構化資料會被賦予一定标簽，繼而便于接下來的多元分析預處理資料，最後通過統一的資料接口将資料傳輸至分析與查詢服務系統。 該系統由以下三大職責： 标簽系統和多元分析： 便于精細化課程分析與快速響應資料分析需求； 實時預警： 可以對動态問題與節點故障進行預警； 問題挖掘： 用于傳輸算法模型、産出智能覆寫模型，同時挖掘問題裝置。
上圖展示的就是我們基于該品質感覺系統制作的實時監控大盤。
3.2 核心名額
下圖展示的核心名額，用于實時課程品質追蹤、問題統計以及用戶端發版前後對比。 所有課程的分析結果會産生标簽，例如采集卡頓率資料，我們知道卡頓率和幀率是正相關的，正常的幀率為15FPS，但有些使用者的幀率為5FPS，這些就屬于遭遇卡頓問題的使用者。 每一節課都會被打上許多标簽，而真正的問題分析是通過分析某些标簽突然異常變多或者這一節課出現多個異常标簽，我們在定位問題時也是通過标簽來确定。
3.3 實時名額趨勢跟蹤
下圖展示了實時名額趨勢跟蹤，可以看到不同地區網絡覆寫情況差異很大，這也是我們優化調參的重要依據。
3.4 單節品質追蹤
下圖展示的是以時間作為緯度統計一節課的品質變動情況。 對一節課關鍵性事件、上課過程中的品質變化跟蹤、整節課的品質評價，主要面向SDK研發、後端研發等業務人員。
3.5 排查問題
房間的時間打點主要用于問題追蹤與排查，并與使用者回報相對應
4. 總結
我們的整套系統還存在許多可以進一步改進的地方，例如基于錄制檔案的評價标準不能完全展現下行品質，課程量大了之後服務端計算資源消耗比較高，基于參數的視訊品質評價算法和Codec類型相關，不同的碼流需要重新訓練等等。 這也是我們未來努力探索的方向。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/102908244「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。