導語 | 延時是網絡直播服務中不可忽視的一環，延時統計方案的實施使我們有了衡量大盤數據的標準，為後續的延時優化及衡量收益奠定基礎，但是目前業界常用的方案對於大型平臺整體延時的統計尚顯不足。本文將從該情景出發，和大家一同探討直播延時統計層面上的技術方案。文章作者：井帥軍，騰訊前端研發工程師。
一、延時的產生
直播延時，對於任何一個接觸過直播的人都不會陌生。延時產生的環境是複雜的，整個直播流程從內容採集處理編碼封包推流傳輸轉碼分發解碼播放，每個階段都會產生延時。我們可以用一張圖來概括延時的產生：
目前業界常用的是採用讀秒的方式來大體統計端到端延時：
統一的計時器
同步的源時間和播放時間快照
如下圖所示，可以捕獲本地時間推流，然後計算播放時間和推流時間的偏差就能大體統計出端到端的延時。
但這種方法存在很大的偶然性，不適合統計大型平臺整體的延時情況，目前很多大型平臺也都缺乏有效的統計手段。
二、FLV統計延時方案
HTTP-FLV 一直是直播的首選方案，FLV 主流上封裝了 H.264/AVC 編碼的碼流，H264 提供了一種在碼流裡加入自定義數據的能力（自定義SEI）。
前端播放 FLV 的流程如下：
在整個播放流程中，音視頻數據流對我們完全透明，前端有解析音視頻碼流原始數據的能力。基於這兩點，我們設計了一套統計大盤延時的方案，如下圖所示：
首先推流側和客戶端需要保證時鐘同步，前端我們使用雲函數開發了一個對時服務。推流側將採集編碼的數據在發送之前通過自定義 SEI 的方式將當前時間戳寫入 H264 碼流。
前端對 FLV 解封裝並探測 H264 碼流是否含有相關的 SEI 數據，如果有就計算延時偏差。
另外需要注意一點，這裡計算的偏差並不是最終的延時，因為瀏覽器內部也會有一段時間的播放緩存，兩者相加就是最終的端對端延時。
經過實踐檢驗，該方案簡單可行，並且可以完整統計整個播放鏈路延時。
三、WebRTC統計延時方案
其實，騰訊企鵝電競很早就開始研究如何使用 WebRTC 降低直播延時，提升用戶的觀看體驗。WebRTC 較 HTTP-FLV 給我們帶來的最大收益就是更低的延時，但是真實的用戶延時到底降低了多少我們其實無法直接獲知，那麼 WebRTC 有統計延時的辦法嗎？
App 端可以自己編譯 WebRTC, 如果播 H264 碼流的話可以復用 SEI 統計延遲的方案，通過修改源碼獲取原始碼流數據。
Web 端統計 WebRTC 延時的難點在於實時音視頻播放流程複雜，整體被瀏覽器接管，沒有為開發者暴露底層數據的接口，無法獲取客戶端播放的數據流。
為了統計現網大盤的延時數據，我們發明了一套 Web 端大體統計 WebRTC 延時的方案，流程如下圖所示：
通過將 WebRTC 的播放流程分解，我們將 WebRTC 直播延時分為 5 大階段：
第一階段是上行延時，是從推流到達 WebRTC Server 的延時，這裡使用 SEI 統計的方案。
第二階段是 WebRTC Server 到瀏覽器的延時，這裡通過測量 RTT 可以得到。
第三階段是 WebRTC 內部抖動緩衝區的延時，計算方法為：jitterBufferDelay / jitterBufferEmittedCount 。
第四階段是解碼緩衝區的延時，計算方法為：(framesReceived - framesDecoded - framesDropped) / framesPerSecond 。
第五階段是渲染緩衝區延時，使用 Media Stream 時 Video 的 Buffer 長度為 0，可以忽略解碼幀到繪製的延時。
五大階段相加就是整個鏈路的延時。詳細數據依賴 RTCPeerConnection.getStats API 。
四、結語
不管是主播還是用戶，對直播低延時的要求越來越高，統計現網大盤的延時數據變得越來越重要。延時統計方案的實施使我們有了衡量大盤數據的標準，為後續的延時優化及衡量收益奠定了基礎。
本文分別介紹了在使用 FLV 和 WebRTC 直播技術下的現網大盤延時統計方案，希望能給大家帶來一些啟發，也歡迎大家在留言區與我一同交流探討更多直播延時統計方面的話題~
沙龍預告