本文是 《直播疑難雜癥排查》系列的第四篇文章，我們來看看直播的延時問題。

1. 延時的測量

一般測量延時最簡單的方法，就是推流端和播放端對著同一個時鐘，然後用播放端顯示的時間減去推流端顯示的時間，就得到了粗略的直播延時。

2. 延時高問題分析

首先，我們看看可能產生延時的模塊有哪些：

- 圖像處理延時，比如畫面剪裁、美顏、特效處理

- 視頻編碼/解碼延時

- 網絡傳輸的延時

- 業務代碼中的緩沖區

一般圖像處理、數據拷貝、編解碼帶來的延時，都是 ms 級別的，真正會產生比較大延時的地方，一個是互聯網上的網絡傳輸延時，另一個就是業務代碼中的緩沖區了。

2.1 網絡傳輸延時

數據在網絡上傳輸，從一個節點經過多級服務器轉發到達另一個節點，是不可避免有物理延時的，下面這個表格給出了理論上數據在光纖中的網絡傳輸的時間（實際場景中的延時往往比這個要大很多，因為涉及到帶寬、網絡抖動等幹擾）：

由該表可以看出：播放端離推流端或者邊緣服務器節點的物理距離越近，延時會越小。

2.2 業務代碼中的緩沖區

業務代碼中的緩沖區，主要是推流端的緩沖區和播放端的緩沖區，一個 30 fps 的視頻流，緩沖區每滯留 30 幀，延時就會增大 1s，那麽，它們是怎麽產生緩沖數據的呢 ？

- 推流端的數據是怎麽 “積累” 起來的 ？

采集 -> 編碼 -> 數據發送 -> [服務器]

當網絡產生抖動的時候，“數據發送” 會因此減慢，產生一定的阻塞，從而導致這些數據會被 “積累” 在了推流端的發送緩沖區中。

- 播放端的數據怎麽 “積累” 起來的 ？

[服務器]-> 數據接收 -> 解碼 -> 渲染

當網絡產生抖動的時候，服務器的數據無法 “及時” 地傳輸到播放端，而由於 TCP 協議的可靠性，所有的數據都會被服務端積累起來，在網絡恢復良好的時候，會快速傳輸到播放端，這些數據會被動地 “積累” 在接收緩沖區中。

- 怎麽消除業務緩沖區的累積延時呢 ？

推流端的發送緩沖區，可以在網絡恢復良好的時候，快送發送出去，從而消除掉這個累積延時。

播放端的接收緩沖區，可以通過丟幀或者加速播放的方式快速消費掉緩沖區中的數據，從而消除累計延時。

2.3 協議延時

通常標準的直播協議有 RTMP，HLV，HLS 三種，一般 RTMP/HLV 協議的延時在 1～3s，HLS 協議的直播延時則會更大，註重延時的直播應用，大都會選擇 RTMP/HLV 協議，這些協議均是基於 tcp 的協議，tcp 協議的多個特性導致其延時明顯要高於基於 udp 的私有協議，主要有如下方面：

- 建立連接的三次握手

- ACK 機制

- 丟包重傳

因此，如果想從本質上解決直播延時問題，還是要換成基於 udp 的私有協議來傳輸數據。

3. 小結

關於播放延時高的問題排查大致就介紹道這裏了，有任何疑問歡迎來信 [email protected] 交流，另外，歡迎關註我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。

本文出自 “Jhuster的專欄” 博客，請務必保留此出處http://ticktick.blog.51cto.com/823160/1924289

直播疑難雜癥排查（4）— 延時高