那些千奇百怪的視訊直播延時測試方法，論正確姿勢是什麼？
說到視訊直播延時測試，我們就不得不先探討一下產生延時的幾個環節：
part1. 視訊採集與編碼 part2. 視訊裝置到伺服器的傳輸 part3. 伺服器分發到客戶端的傳輸 part4. 客戶端的播放
其中，這個過程延時消耗最大的是part1和part4，也就是編/解碼部分，而且通常情況下part1延時>part4延時，那麼part2和part3如果消耗比較大的延時，要麼是網路實在太差，要買就是程式寫的不好，網路差可以採用UDP或者TCP丟幀的方式減少長期的延時，那總結來說，如果在part2和part3部分一直保持著高延時，基本可以確定，是伺服器程式問題；
part1論述，目前市面上的視訊編碼多采用硬編碼，雖然是硬編碼，採用晶片進行的視訊編碼計算，但不得不說，這個還是計算量大，時間消耗長，在arm裝置中硬編碼，以海思晶片為例，大部分可以控制在200ms以下的時間消耗，在手機上，由於手機效能的不一樣，消耗的時間也不一樣，但經過長期的推流開發經驗，手機硬編碼的時間消耗大部分也在300ms左右，當然，這都不一定準確，只是個人的經驗值，實際還是要根據裝置來定；
part4論述，由於解碼大部分是在x86機器上，或者在移動手機上進行解碼播放，解碼和顯示的效率就比編碼高多了；
part2 & part3，此部分為網路資料轉發與傳輸，時間消耗是非常小的，具體網路傳輸的延時當然可以自行搜尋獲得，基本上在區域網延時可以忽略不計；
延時測試中的那些錯誤方法
1、徒手讀秒我們經常在遇到一些使用者關於延時問題的諮詢時候，遇到中間有很多的測試方法居然是靠掰手指讀秒來測試的，而且有的給出的結論居然精確到了毫秒，這種做法是有很大誤差的，我們在測試視訊的時候發現，實際的1s比我們想象中的要長，而且有時間感覺要長很多；
2、北京時間對比還有一種測試的方法，就是測試雙方各自百度上輸入“北京時間”，然後裝置源端對著本地的北京時間，客戶端一邊播放，一邊對照著自己本地的“北京時間”算差值，好吧，這也不準哪，北京時間到本地了之後，都是各個電腦自己開始計時，而且北京時間只能精確到秒，也就是說，這個時間會有0~999ms的誤差；
3、播放器緩衝
這個也是經常會出現的問題，大部分的直播測試用vlc或者ffmpeg這樣的通用播放器進行延時測試，但是vlc和ffmpeg為了保證視訊的平滑流暢播放，經常會在內部緩衝很長一段時間，例如vlc預設是1000ms的緩衝：
ffmpeg一方面會有一個比較長時間的視訊分析過程，還有內部的緩衝流程，具體引數為：-fflags nobuffer -analyzeduration 1000000，具體詳細引數說明在部落格《ffmpeg ffplay播放延時大問題：播放延時引數設定》中；
正確姿勢
正確的延時測試我們有幾個方面的要求：
- 統一的計時器
- 精確到毫秒
- 同步的源時間和播放時間快照
基於這種考慮，我們在做延時測試時的做法是，在PC上開啟一個精確到毫秒的計時器，再通過攝像機/手機/桌面編碼推流將直播流推送到伺服器，再同時開啟一個播放器（在本機或者另外的PC/手機播放器），再通過螢幕截圖或者手機拍照的方式，將源視訊和播放視訊都包括在一張照片內，再進行時間差值的計算，這也就做到了非常準確的延時統計了！
獲取更多資訊
Copyright © EasyDarwin.org 2012-2017
