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.264、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+視訊實錄傳送門：