在線教育音視頻質量評價與感知系統

 

爲了探討用一套客觀，完備的評價系統對在線教育的音視頻通訊質量作出評價，力求作到定量，準確，橫向可對比，並基於線上運行的大數據系統，發掘端到端通訊平臺存在的問題，找到優化方向，提高在線教育的用戶體驗，VIPKID音視頻團隊負責人張武峯在LiveVideoStackCon2019北京站上作了有關在線教育音視頻質量評價與感知系統的分享。

文 / 張武峯

整理 / 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左右，咱們這樣作是爲了統計更多的卡頓案例並得到更多的數據以便於咱們進行卡頓分析與研究，促使技術團隊更出色地優化卡頓。每一項指標在確立的時候都與應用場景強相關，這些指標雖然都與技術相關但其和用戶主觀感知一一對應。

咱們爲統計到的卡頓狀況做出了以下級別細分，其中遇到一、2級別卡頓狀況的用戶佔比約爲5%，遇到三、四、5級別卡頓的用戶平均佔比約爲18%。這一數字在業內屬於比較好的狀況。

 

2.2. 視頻打分算法流程

咱們大概花費了兩到三個月探索視頻打分算法，在初期咱們閱讀了許多論文著做，發現業界尚未很出色的無參考視頻打分算法。當時也試驗過其餘廠商的比較成熟的算法也沒有達到理想的效果，直接用一張圖片訓練沒法實現收斂。因而咱們嘗試換了一個方向，也就是從視頻編碼數據流當中抽取一些參數例如GOP幀宏塊的大小，宏塊的個數、丟包個數等以造成訓練數據集，隨後再使用該數據集訓練打分算法模型。咱們將獲得的模型與人工標記作對比，最終的效果符合咱們的需求，和用戶主觀感知結果的匹配度大概在80%，該算法模型就固定下來並被咱們用於後續的關鍵開發活動當中。

 

2.3. 特徵提取

特徵提取的第一步是須要對文件進行解析，咱們的線上課程視頻文件基於不一樣的系統與格式，如mp四、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類型相關，不一樣的碼流須要從新訓練等等。這也是咱們將來努力探索的方向。