在之前一篇的 DevforDev 專欄中，我們的工程師分享了聲網的無參考視訊評價體系（VQA）的建立與實踐經驗。建立一套 VQA 體系需要一個較長的過程，在那之前，大家仍然有很多方法可以來判斷實時視訊的質量。我們今天就來講講有哪些行業通用的視訊體驗指標。
我們一般通過視訊的實時性、流暢性（卡頓率、渲染幀率）、主觀畫質、首幀出圖、音畫同步等效能指標來判斷視訊質量的好與壞。以下內容分別對這些指標做逐一說明，並講一講在實驗室環境中，每個指標的詳細測試方法。
實時性
說到視訊直播延時測試，我們就不得不先探討一下產生延時的幾個環節：
part1. 視訊採集與編碼
part2. 視訊裝置到伺服器的傳輸
part3. 伺服器分發到客戶端的傳輸
part4. 客戶端的播放
其中，這個過程延時消耗最大的是 part1 和 part4，也就是編/解碼部分，而 part2 和 part3，為網路資料轉發與傳輸，時間消耗是非常小的。視訊延時，是一個用於體現視訊實時性的指標，傳送拍攝內容到接收端渲染的延遲，單位：ms。通常來講，視訊端到端延遲數值越小，實時性越好。
當前業界較為精準的測試方法為在 PC 上開啟一個精確到毫秒的計時器，再通過攝像機/手機/桌面編碼推流將直播流推送到伺服器，再同時開啟一個播放器（在本機或者另外的 PC/手機播放器），再通過螢幕截圖或者手機拍照的方式，將源視訊和播放視訊都包括在一張照片內，再進行時間差值的計算。實驗室測試方法和業界測試方法基本類似。
實驗室測試方法
1、裝置 1 和裝置 2 連麥。
2、找一個裝置開啟精度為 ms 的線上秒錶或秒錶，將裝置 1 後置攝像頭正對著秒錶，攝像頭採集秒錶的數字，裝置2上能清晰的看到裝置 1 傳送過來的秒錶數字，具體擺放位置如下圖 1 所示。
■圖1
3、擺好圖 1 的位置，然後用 iPhone 拍下 10s 視訊，過 3-5 分鐘後再拍下 10s 視訊，再過 3-5 分鐘後拍 10s 視訊，共 3 段視訊。
4、延時統計：每個視訊選 10 個圖片（每秒選擇一個樣點），視訊延遲=線上秒錶上顯示的時刻-手機 2 上顯示的時刻（圖 1 中的視訊延遲=762-447=315ms）。3 段視訊共 30 個視訊延遲資料，取平均值為最終的視訊延遲。
卡頓率和幀率
在視訊質量檢測中，檢測視訊是否卡頓也屬於視訊質量檢測的標準之一。
卡頓率：用於體現視訊流暢性的指標，測試周期內的卡頓總時長/測試總時長*100%，卡頓率越高，主觀體驗越差。
幀率：接收端觀測到的渲染幀率，幀率越高，流暢性越好。
業界測試流暢性測試方法為：
1.通過自動化錄製的測試視訊；
2.利用 FFmpe 選擇興趣區域進行擷取；
3.拿到興趣區域進行視訊前 10s，中間 10s，後 10s 視訊；
4.把三段 10s 的視訊進行每 50ms 一張圖片；
5.通過 opencv 進行圖片的分析；
判斷卡頓的主要依據是，當人的視線規則是相同的圖片持續 200ms。根據這個規則，通過 opencv 比較上述步驟 4 獲取的圖片。如果第 n 個圖片與第 n+1 的圖片比較，畫素相似度在某個範圍內持續了 4 張圖片（50ms*4=200ms）就認為這段視訊是卡頓的，從而計算出卡頓率。實驗室測試原理與該方法大致相同。
實驗室測試方法
1、手機 1 和手機 2 連麥；
2、將手機 1 後置攝像頭正對著旋轉的地球儀（採集的影像需要保持一直運動），攝像頭採集運動的地球儀和運動的主播，球體佔整體畫面約 1/4 大小，主播佔整體畫面 1/4。手機 2 上看到手機 1 傳送過來地球儀和主播，具體擺放位置如下圖 2 所示；
■圖2
3、擺好圖 2 的位置後，設定弱網，比如限制上行頻寬為 500K，丟包 20%。弱網生效後，過約 30-40s，使用手機 2 自帶錄屏功能錄屏 3 分鐘，效能較差的手機需要通過轉 HDMI 連到電腦，用 QuickTime Player 進行錄屏；
4、將錄製的 mp4 視訊傳到電腦，用卡頓率統計指令碼計算卡頓率和幀率：200ms 卡頓率：測試周期內，卡頓超過 200ms 的累計時長/測試總時長*100%。
主觀畫質
視訊主觀質量評估的目的是準確衡量出人眼對於視訊內容的感知。源視訊在經過採集編碼傳輸解碼等模組傳輸到人眼之後，會不可避免的引入一些壓縮失真，嚴重的時候甚至會有綠屏、花屏、馬賽克等問題。在業界評估視訊主觀畫質有兩種常用方法：主觀評估和客觀評估。主觀評估是通過主觀打分來驗證所有視訊質量的等級。客觀評估通過一些與主觀質量評估結果相近的數學模型來量化人眼對於視訊內容的感知，可以提升一些評估的效率。
主觀畫質是指收到接收端的畫面質量，質量等級越高，畫面質量越好。
實驗室測試方法
觀察視訊畫面質量給出主觀畫面質量等級評價。
10分： 運動球體清晰，主播輪廓清晰，主播五官清晰，主觀感受畫質清晰無損
9分： 運動球體清晰，主播輪廓清晰，主播五官有輕微馬賽克
8分： 運動球體清晰，主播輪廓清晰，主播五官有馬賽克
7分： 運動球體較清晰，主播輪廓較明顯，主播五官較糊，有塊狀馬賽克
6分： 運動球體較糊，主播輪廓較明顯，主播五官較糊，有大量馬賽克
5分： 運動球體模糊，主播輪廓模糊，面部有較多馬賽克
4分： 運動球體糊，主播臉大糊，有較多馬賽克
3分： 運動球體糊，主播臉大糊，有大量馬賽克
2分： 運動球體大糊，主播臉大糊，五官不明顯，有大量馬賽克
1分： 畫面整體大糊，辨識度低
首幀出圖
從進入頻道到看到對端畫面的時間，單位：ms，首幀出圖越快越好，至少要達到 1 秒內顯示。
簡單來講，視訊首幀出圖就是視訊首幀載入出圖的時間，那麼這個時間怎麼來計算呢？
要想計算出視訊首幀載入的時間，我們就需要找到視訊首幀載入的標誌是什麼，也就是我們怎麼確定首幀是否載入了，在哪載入的？
這裡我們採用的辦法是通過播放視訊後定時擷取圖片的方式，找到第一張跟基準圖片相似度達到 90% 的圖片，就是首幀圖片，然後從點選進入頻道的系統時間到接收到這張圖片的系統時間，這個時間差就是視訊首幀載入時間。
實驗室測試方法
1、手機 1 先進入頻道；
2、手機 2 反覆進出 10 次相同的頻道，每次在頻道內的時間約 10s，在頻道外的等候時間約 10s；
3、在錄製裝置上用固定幀率（如 30 幀/秒）錄製手機 2 進出頻道的整個過程；
4、將錄製好的視訊倒入電腦，開啟視訊編輯軟體 Final cut Pro，並匯入該視訊。在軟體中檢索錄製的視訊幀，找出所有點選“進入頻道”按鈕的幀（圖5） ，和所有首幀出現的幀（圖6）。由於錄製的視訊時 30 幀/秒的固定幀率，我們用幀號相減，就得到了兩個事件中間隔了多少幀。再按照每幀 1/30 秒，就可以快速計算出每次進入頻道的時間；
5、首幀出圖時間=[c30+d-(a30+b)]*1000/30，10 次出圖時間取平均值；
■圖5
音畫同步
所謂音畫同步，其原理是對直播進行錄影，通過分解錄製視訊的音訊視訊檔案得出影像時間、音訊時間，二者差值得出同步延時差。
音畫同步反映視訊和音訊的同步程度，音畫同步的標準是 -200m至200ms，表示：音訊最大可以超前視訊 200ms，視訊最大可以超前音訊 200ms。音畫同步延遲越靠近 0，同步效果越好。
目前常見的測試音畫同步的方式，是由測試人員觀看視訊，並對比視訊畫面中人物的脣動和聽到的聲音是否同步。由於測試人員的個體差異，會有 200ms 左右的誤差，因而，需要對視訊的音畫是否同步進行客觀的測試。
實驗室測試方法
1、手機 1 和手機 2 進入同一個頻道；
2、電腦上迴圈播放測試用視訊檔案；
3、將手機 1 後置攝像頭正對著電腦螢幕，採集正在播放的同步視訊源，保證能在手機 2 端完整地看到紅色矩形框以及數字（圖7）；
3、將手機 2 移到另一個房間，為了防止電腦播放的聲音干擾到手機 2 上播放的聲音被正確採集。調整電腦播放音量，保證能在手機 2 端較大聲地聽到滴滴的聲音；
5、用 iPhone 錄製手機 2 的播放視訊和聲音，擺放位置如下圖8所示；
■圖7
■圖8
6、將錄製的視訊匯入電腦，播放並分析視訊。錄製的視訊中每一幀都帶有幀號，並且在螢幕底部還繪製了一行方格，有一個滑塊在上面移動，每幀移動一格，每格代表 1/30 秒（33ms）。在製作測試用的視訊時，保證每次打點的聲音都正好在滑塊位於中心位置時發聲。因此播放視訊，聽到聲音立刻暫停，觀察幀號或者觀察滑塊的位置，就可以計算出音畫之間的延遲。
頻寬跟蹤
頻寬跟蹤，即檢測頻道內位元速率傳輸的大小。
業界測試方法有使用 ping 測試網路，使用測試網站，使用路由跟蹤等來測試視訊頻寬，實驗室是通過 wireshark（網路資料包分析軟體）擷取網路資料包，來分析視訊的頻寬大小。
實驗室測試方法
1、手機連線電腦後，開啟 Xcode，然後選擇 window-->Device and Simulator-->Device 選中自己的手機，就能看到資訊，"Identifier"這一欄，便是UDID；
2、建立 RVI 介面，獲取虛擬介面。終端輸入 $ rvictl -s
3、開啟 wireshark ,在 capture 中選擇剛才生成的介面名（例圖 9 為 rvi0）；
■圖9
4、開啟 app 開始互通，wireshark 會顯示各種各樣的的包；
5、選中傳送端（本機）和接受端（伺服器）的 ip，一般 Source 出現頻率最高為本機 ip，Destination 出現頻率最高為伺服器 ip。（如圖 10 和 11）；
■圖10
■圖11
6、複製過濾條件，點選統計，將複製的過濾條件貼上到顯示過濾器一欄中，顯示出所抓資料的 I/O 圖，便可得到實時通訊的頻寬大小（如圖 12）
■圖12
以上就是我們在 RTC 場景下的視訊體驗指標，以及對應的實驗室測試方法。這些測試方法可以參考用於日常場景開發中。如果大家視訊體驗還有其它希望瞭解的知識，可以給我們留言交流。
Dev for Dev專欄介紹
Dev for Dev（Developer for Developer）是聲網與 RTC 開發者社群共同發起的開發者互動創新實踐活動。透過工程師視角的技術分享、交流碰撞、專案共建等多種形式，匯聚開發者的力量，挖掘和傳遞最具價值的技術內容和專案，全面釋放技術的創造力。