直播的用戶體驗體系與質量監控方案

 

6月24日，又拍雲OpenTalk |2018音視頻技術沙龍·上海站順利落幕，這是又拍雲OpenTalk | 2018音視頻技術沙龍系列活動的第二站。做爲又拍雲技術分享的看家活動，本次OpenTalk邀請了網易雲、穀人雲、又拍雲、戰旗等四家公司的講師。四位講師在活動中拿出了看家本領，爲到場、觀看直播的觀衆貢獻了精彩的分享！

戰旗直播高級流媒體研發工程師石碩，在現場分享了《視頻直播的用戶體驗體系與質量監控方案》，重點介紹了直播質量監控方案的搭建，以及直播卡頓、延時監控、首屏秒開三個方面的優化。

• 直播質量評價體系
• 直播質量監控方案的結構和邏輯
• 卡頓優化的十條法則
• 延時監控：自定義擴展、數字水印
• 首屏秒開的三個優化方向

△ 石碩：戰旗直播高級流媒體研發工程師

如下是石碩分享內容的整理：

 

你們好，我是來自戰旗直播平臺的高級流媒體工程師石碩。今天我主要講兩個內容：第一方面，直播、點播的總體用戶體驗體系。現有公開場合講總體用戶體驗體系的內容偏少一點。另外一方面，「質量監控方案」，這也不多有說起的。

從本質上來說，用戶體驗和質量監控，作的是一件事情，即：在必定程度上保證用戶觀看直播的體驗是最好的。

個人分享內容主要分爲四個部分：

• 直播質量評價。用戶體系覆蓋了哪些方面，用戶總體的體驗由幾部分組成的。
• 卡頓監控與優化。卡頓優化依賴於監控體系如何發現卡頓現象。
• 延時監控的難題。視頻延時監控存在難題，由於如今業界對於「延時」的監控仍是比較欠缺，商用方案裏面尚未看到比較切實有效的辦法。
• 首屏優化要點。首屏優化在行業裏講得比較多，我簡單羅列一下要點。

 

直播質量評價體系

直播質量評價這一塊，先講一下音視頻的質量評價體系。

音視頻評價起源比較早。早在1996年，ITU國際組織就已經有了主觀評價流媒體音視頻的傳輸質量，當時主要評測電話的通話質量。而後在2003年根據我的主觀評價提出了一套MOS體系，2012年、2013年對MOS體系進行了不一樣方面的補充，推出了vMos體系。

今天我主要講華爲的U-vMOS主觀質量評價體系。一方面，對整套體系，國內中文的資料比較充實；另外一方面，U-vMOS在vMOS的基礎上面作擴展的，U-vMOS的整個質量體系，也是在vMOS內容裏面的。

MOS質量評價的主要目的，是根據用戶的主觀體驗來對音頻或者是視頻質量進行評分。它的分值，常規意義上是分爲五分，分值越高它的質量就越好。

△ MOS質量評價△ U-vMOS質量評價的建模方法

MOS質量評價體系針對音頻質量。視頻質量的評價能夠在這個基礎上作一個延伸，具體看一下U-vMOS質量評價體系。

U-vMOS將視頻質量評價分爲三個部分：

• 視頻質量，指視頻的分辨率、幀率、碼率、編碼級別；
• 互動體驗，主要指被叫視頻載入時間的長短；
• 觀看體驗，主要指畫面的花屏和卡頓。

針對視頻質量的各類相關因素，其中咱們能取到的「典型分值」的「分」，主要是播放設備的屏幕尺寸及視頻的分辨率，這兩個相關度是比較大。

視頻質量的評分

△ 視頻質量：視頻分辨率與屏幕尺寸的關係

4分以上能夠算是比較好的觀看體驗，看這張表格，4.5寸、5.5寸的手機屏幕，都至少須要有720P的視頻流才能達到4分以上。那咱們作手機的視頻服務時，若是用戶對於視頻的要求不是特別苛刻，一般狀況來說720P足夠了；個別提供1080P，其實對觀看體驗並無特別大的提高，僅從4.3分提高到4.6分，這個過程不光對碼率有要求，視頻幀率、解碼難度都會高出不少。

通常電視端想要達到4.0分以上的觀看體驗的話，須要1080P的視頻。這個表格對直播企業的對於視頻流分辨率的選擇是具備必定參考意義的。

視頻體驗，首屏秒開的標準

互動體驗，主要是涉及到常規意義上所講的「首屏秒開」。首屏秒開一般被認爲在100毫秒之內纔算完美。

這個要求是局域網環境下，公網環境下首屏秒開達到100毫秒的幾乎沒有，或者說特別少。常規意義上，咱們都會努力讓首屏秒開作到1秒也就是1000毫秒左右的時間。

咱們能瞭解到的，現有像快手、鬥魚、虎牙這一類的App，一般首屏時間都會作到3秒之內。3秒是一個界限，你們通常是2秒左右。

△ 互動體驗（首屏秒開）的典型分值

觀看體驗：花屏再也不，重在優化卡頓

觀看體驗包括兩部分：花屏和卡頓。

如今直播平臺在又拍雲等CDN服務商的努力下，「花屏」已經出現得不多了，主要影響觀看體驗得因素是「卡頓「，主要指的是在一分鐘內卡頓出現了多少次，每一次卡頓的時長有多少，最後得出來一個卡頓的時長佔比。觀看體驗的質量評價體系是實驗室環境下得出的。

 

△ 觀看體驗的典型分值 (卡頓統計週期1分鐘)

直播質量監控方案的結構和邏輯

國外針對於這一套體系的執行方面可能會更多一些，國內企業目前來講主要關注的多是卡頓和首屏秒開。延時的話，關注相對會少一些。

咱們重點講一下卡頓的優化體系，包括「卡頓監控」，以及監控的結果收集完以後進行的一些優化工做。

△ 直播質量監控系統組成

卡頓主要分爲四個部分：數據收集、數據分析、數據展現、預警系統。

數據收集，收集主播端和觀看端的設備信息、網絡環境。設備信息主要是指設備機型、用戶IP，以及視頻流的分辨率、碼率，包括播放過程當中的CPU使用率、GDP使用率、內存使用率。網絡環境，主要指鏈接方式。還有一些須要探測才能得知的數據，好比：優先收集手機到本地路由器的網絡狀況，而後收集手機到公網出口的環境，以及手機到CDN節點的網絡狀況。第三部分數據是正常監控須要的，包括卡頓數據、首屏數據、延時數據。

數據分析，收集完以後，放到大數據中心作一些數據過濾、綜合分析；把用戶ID分門別類的處理成咱們實際上運營須要的監控數據。

第三是數據展現，這一塊主要是地圖展現。在一張地圖上面，把卡頓率及其它的一些數據展示出來，就是觀看會更方便一些。這是戰旗總體卡頓監控的監控圖表，左下角標註了卡頓率從低到高，最低是「0」，最高是「15」。能夠看到，戰旗的卡頓率應該在「4」個點之內，通常是3點多。

 

△ 卡頓數據展現示意圖

第四部分是預警系統。這一塊主要是運維人員及CDN廠商。常規意義上，這個預警一般會直接給本身公司的運營人員。可是作直播的，基本上都會用到CDN廠商的雲加速服務。若是咱們發現用戶卡頓的話，其實最終會分析得出來用戶卡頓緣由是CDN某個節點很差，把這個分析反饋給CDN，讓CDN進行相應的調整。

△ 卡頓監控體系的運行邏輯

整個監控體系，咱們這邊能夠簡單的分爲五大部分：客戶端、監控系統、運維支持、智能調度、CDN廠商。

監控系統首先是給運維支持，而後是給CDN廠商，告訴發生了某個事。而後是給智能調度系統，這一部分的報警級別相對低一點，是針對個別用戶的報警。咱們能夠針對用戶報警，根據他的硬件設備狀況及網絡狀況作一次智能調度。好比：探測到帶寬不夠，發生了卡頓；調度系統只須要給客戶端發一條命令，告訴它帶寬不夠，讓它把碼率降一級，可能卡頓狀況就會緩解。

卡頓優化十條法則

針對於卡頓優化，咱們這邊能夠分爲十個部分：

• HTTP-DNS調度
• 播放端本地調度
• 服務端智能調度
• 服務端手動調度
• CDN手動調度
• 使用UDP推流
• 推流端流暢度監控
• 提供多種清晰度選擇
• 播放器優化
• 用戶反饋系統

HTTP-DNS調度：在國內DNS污染會比較嚴重，可能會把DNS解析到錯誤的節點上去。這個解析服務，可能會把你的域名，好比把海徐彙區的域名解析到浦東新區去。咱們儘量去避免這種錯誤，這個時候就須要HTTP-DNS調度。咱們每次拉一個地址以前，使用本身的服務器先作一次解析，保證每次反饋給你是最近的服務節點，這就會比較流暢。

播放端本地調度：若是發現用戶播放比較卡頓，咱們本地會有一些檢測機制。好比檢測是硬件CPU不高，CPU使用率超高了，咱們可能就會把它的分辨率、解碼率降一下，讓CPU有所緩解，這個時候卡頓就會緩解。另外，也多是網絡致使的本地卡頓，咱們就能夠給他換一個服務節點，或者是作一些其它的處理。

服務器端智能調度、服務器端手動調度：服務器端的智能調度、手動調度，這個主要是在後端經過遠程方式去作一些調整。在智能調度系統裏面，咱們會根據用戶的狀況作統一調度。好比用戶硬件不夠了，咱們幫他加一點。若是用戶卡頓的話，咱們先要判斷是CDN節點的問題，仍是用戶本身的問題。若是是CDN節點的問題，咱們幫他自動調到下一個節點去。

CDN手動調度：指手動干預的方式。好比：如今發生了用戶卡頓，智能調度系統好比發現上海徐彙區的一個服務節點特別很差，咱們能夠手動把這個節點拉黑掉，用戶不會訪問到這個質量比較差的節點。

第四點、第五點是會有必定的重合度，由於CDN的手動調度也是根據智能調度系統收集到的數據、下發的數據來進行相應的一些處理。

UDP推流：TCP的協議容災和慢恢復機制致使它抵抗網絡抖動的能力會比較差。爲了解決由於網絡抖動致使的卡頓問題，咱們會使用「自定義」或者是自有UDP協議處理這個問題。谷歌以前有推出相似於「類UDP」的各類SDK包，使用UDP代替TCP對抗網絡抖動，能夠把TCP的容災機制、恢復機制規避掉，能夠快速地恢復網絡。UDP還有一個做用，在丟包的狀況下「抗丟包能力」比較好，它能夠本身自主決定「重發多少數據包」。

推流端流暢度監控：這一塊主要是監控主播推流是否有音視頻不一樣步或者幀率不夠的狀況。若是主播端卡頓的話，全部的用戶調度到任何節點都會卡頓，因此推流端監控相對會重要一些。針對於主播端的監控，咱們實時反饋給主播，讓主播切換網絡或者是作一些調整。

提供多種清晰度選擇：提供多種清晰度選擇，這個主要針對於用戶手動操做的。一般狀況下會提供標情、高清、超清等多種分辨率。不一樣的分辨率對應的碼率、編碼複雜度都是不同的。清晰度越高，相應解碼的難度就會越高。讓用戶能夠手動去選擇，在總體狀況比較好的時間，他能夠提升清晰度。當發生卡頓的狀況下，能夠手動降清晰度或者是降分辨率，能夠解決一部分卡頓的問題。

播放器優化：播放器的優化，針對於卡頓主要是處理兩個事情：一個是音視頻不一樣步致使的卡頓。第二部分，主要是針對於緩衝區的處理，緩衝區相對於對抗「網絡抖動」是比較有用處的。

用戶反饋系統：這一塊是用戶主動提供一些卡頓的建議或者問題，用戶的反饋系統能夠做爲咱們總體監控系統的一個補充，能夠幫咱們改善整個監控系統。

延時監控：自定義擴展、數字水印

下面講一下「延時監控」。「延時監控」我主要講兩個部分的內容：

第一部分，開發階段延時的計算及延時的優化；

第二部分，發佈階段的延時計算。

一般狀況下，直播研發的開發階段的延時都會以「北京時間」的方式作對比。

 

△ 左圖是推流端本地的「北京時間」，右邊是播放器播放的「北京時間」

開發階段的延時，推流工具、播放工具在同一臺機器上。左邊的時間減去右邊的時間，實際上就是直播延時。咱們能夠看到上圖的直播延時是2秒2毫秒。

開發階段的延時計算到了發佈階段已經無論用了，由於正常狀況下不可能實時盯着用戶手機看「延時多高」，也不可能在視頻流裏面嵌入一個「北京時間」。

發佈階段延時計算須要藉助一些另外的手段，一種方式是自定義擴展，一種方式是數字水印。

自定義擴展實現延時監控

自定義擴展利用直播協議裏面的一些自定義字段作延時監控。

一個選擇是FLV協議的metadata字段。FLV協議自己有字段，能夠嵌入，而後在推流時發「北京時間」放到這個metadata字段裏面去，接到以後把它和本地的「北京時間」作差值。

第二個能夠擴展的地方，是H.26四、H.265編碼的SEI字段，這個字段也能夠自定義作擴展，計算延時的方法也是相同的，就是在這個字段裏面嵌入「北京時間」就能夠了。

自定義擴展的兩種方法有好處——配置比較簡單。

固然也有比較難的地方。由於CDN自己會有轉碼系統和分發系統，若是不和CDN廠商強調的話，全部的自定義字段從CDN系統過一遍以後所有都會刪除掉。

還有一個有問題的地方，在於CDN分發視頻流，默認會把全部的視頻流，不管是從什麼時間開始拉流的，都會「從零開始」。這個時候咱們在字段裏面嵌入的「北京時間」，實際上就沒有參照對象，由於咱們是根據視頻流裏面每一幀視頻的時間，以及嵌入到自定義字段的時間，還有本地時間三者作「差」獲得的延時，這一部分會有影響。

數字水印實現延時監控

基於前面兩種方法的缺點，而後咱們又擴展出了根據「數字水印」來嵌入數據計算延時的方法。「數字水印」出現得比較早，原來是用於音視頻版權確認，在音視頻嵌入不可見、聽不到的數據，這對於總體音視頻質量影響比較小，可是經過某種算法能夠嵌入進去、能夠被提取出來，主要是應用在這個方面。

我簡單講一下「數字水印」的原理，數字水印能夠嵌入的地方比較多。

先了解下經過修改YUV原始數據或PCM原始數據植入數字水印。以720P分辨率的視頻流爲參照，每一張畫面是1280×720像素點，每一個像素點是由一個Y以及1/4U、1/4V組成的。一般狀況下在Y裏面，每個Y像素是有8比特數據組成的。也就是說，數據範圍能夠從-127到127。Y數據總共有8比特，咱們能夠把它末三位抹掉，而後再嵌入咱們想要的數據。好比：咱們想要的第一個Y像素點裏面，就嵌入一個數字「0」或者是「1」，咱們能夠把8比特後3位抹掉，在裏面嵌入後3位是「0-7」的，咱們嵌入一個「3」表明「0」，嵌入一個「6」表明「1」。嵌入以後，而後根據一樣的方式把這個方式再提取出來，而後把這個數據再還原，就能夠獲得咱們嵌入的YUV裏面的數據。這種方式嵌入的話，會有必定的影響。由於正常狀況下，咱們知道Y數據是「-127」到「127」。末三位改變之後會對色彩有影響。數據準確率越高，就須要抹掉的比特位數越多，對於視頻的損傷就越大。咱們想要準確度越高，又須要比較多的比特位數，這個時候就須要作一些取捨。

PCM也是一樣的方式，在末位不重要、比較小的數據上面作一些修改。

再看下經過AAC量化子帶或H.264塊的DCT參數實現數字水印。

AAC量化子帶由一系列的參數組成的，咱們能夠改寫參數第一位。

H.264塊的DCT參數，相應這個參數的修改方法也是同樣的，改第一位的不重要的這些數據。

客觀地講，剛纔幾種方式裏面，在數據的嵌入、提取的過程當中會受到CDN轉碼系統的必定影響。由於正常狀況下，咱們知道從YUV數據到H.264從新再解碼出YUV的時候，這個YUV數據實際上是發生了一些變化，只是這個變化被控制在必定的範圍內，絕大多數的狀況下是看不出差異。

這個時候，在剛纔講到的這些算法之上，延伸出了一些算法，針對於這些數據的這些參數；咱們剛纔講的是直接在這些數據裏面作修改，作延伸處理的方法是把這些數據放進，像壓縮一般會用到的「離散預選」參數。這個算法相對來講，對於原始數據的修改會更小，而後提取的成功率也會更高。

 

首屏秒開的三個優化方向

簡單過一下首屏秒開優化的要點。首屏優化的話題可能會特別多，我這裏就不一個一個去解釋了；這裏提供首屏秒開的三個優化方向，有優化需求的話，按照推流、轉發、播放三個方向去作優化，確定能收到效果。

推流優化——主播端：

• 合理的GOP值(建議2秒)
• 減小幀間依賴，不使用P幀
• X264無延時編碼
• 合理的分辨率、碼率、幀率
• 使用UDP對抗網絡抖動

轉發優化——CDN

• 緩存GOP數據
• 提早預熱資源
• TCP單邊加速
• 提供多路轉碼流

播放優化——播放端

• 優先加載視頻流數據
• 可變緩存，先小後大
• 使用HTTPDNS分配節點
• 優化FFmpeg視頻流探測
• 網絡請求並行加載

我今天講的內容大致上就是這些，謝謝你們的聆聽。

 

問答部分

Q1：賽事直播、遊戲直播的時候，主播推流必定會延遲。昨天我碰見一個主播，延遲就已經有20秒，也就是說在編碼完了以後，會有20秒纔會推出來，這樣的話，數字水印是不許確的。我看戰旗也有不少遊戲主播，這個問題怎麼解決的？

石碩：這分爲兩方面。咱們若是要作延時計算，相應來講直播用的工具咱們是可控的。像剛纔您講的狀況，應該是這個主播用的是開源的OBS推流工具。針對於OBS的推流工具，咱們須要作一些特殊的處理。戰旗爲OBS開發一個插件，這個插件是嵌入視頻水印的。第二這個插件要獲取OBS緩衝延時，把這個數據獲取以後，針對嵌入的視頻水印會作一些特殊處理。若是是用本身的直播軟件，相應的來講時延就是本地的緩衝區都是本身設置的，相應作一下處理就行了。

Q2：我前兩天剛上線了網頁端的H.265，碼率比較低；發現卡頓主要緣由來自於硬件狀況，好比CPU不夠或者GPU不行。我考慮在網頁端加一些什麼樣的東西，獲取到用戶的硬件狀況，而後發現能獲取到的硬件狀況很是有限，跟移動端在上H.265徹底不同的狀態。國內主流的瀏覽器能夠獲取到用戶的內存狀況，但獲取不到GPU等信息，即使有問題很難定位。戰旗在這一塊，目前是怎麼解決的？

石碩：這是一個很好的問題。如今主流的瀏覽器、比較常見的瀏覽器，一般狀況下若是用HTML5作直播，會默認更多得去選硬件。受限於瀏覽器，咱們是拿不到GPU信息的。這個時候，咱們會獲取一些再外圍的數據信息，好比去拿CPU型號，進而獲取GPU信息。某幾個GPU幸虧解1080P確實不行，這個時候咱們能夠嘗試把它的分辨率從1080降到720P，這個時候它的GPU是能吃得消的。

 

分享PPT+視頻實錄傳送門：

視頻直播的用戶體驗體系與質量監控方案​