1.背景
直播的時效性保證了良好的使用者體驗，根據經驗在交易環節，延遲越低轉化效果也會越好。傳統的直播延遲問題已經成為了一個不容忽視的問題，高延遲不僅破壞了使用者的觀看體驗，也讓主播難以實時獲取到使用者的反饋。為了進一步最佳化直播時效體驗，我們需要對產生延遲的原因以及整個互動鏈路有個清晰的認知，才能穩定的實施相關方案。
2.主觀體驗
我們團隊內部觀察了其他電商平臺的延時，其中 TOP1 的平臺，端到端的延遲在 3s 左右，而得物在 5s 左右，提升空間還是比較明顯，我們需要進一步明確具體原因。
3.延遲降低有什麼好處
3.1 提升交易環節順暢度
在得物的直播場景中有新增秒殺商品的環節，秒殺商品的倒數計時是實時進行的，假如直播畫面有將近8s的延遲才能追上，在這一過程中無論是使用者還是主播溝通中都會存在gap。在直播過程中使用者在延遲高的場景中提問了但是主播遲遲沒有反饋，在這個期間使用者有可能退出直播間或者跳過這個商品，這個結果無論是對主播或者是對交易轉換都不太能接受。
3.2 提升體驗，不同使用者之間延遲差別太大
A、B兩個使用者可能在看某一個直播間，A使用者可能很早就進直播間了，而B使用者是新進來的，但是B使用者的延遲卻比A使用者的低了幾秒，A使用者看到可能就會懷疑自己手機、網路、APP是不是哪個有問題，造成不好的體驗反饋。
4.直播延遲是如何產生的？
要搞清楚延遲是如何產生的，我們勢必要了解到其中哪些程式可能出現延遲，並且是可最佳化的。
主播 --> 雲伺服器 --\> CDN節點 --> 使用者
雲伺服器 --\> 主播: 直播內容轉碼、壓縮等處理
CDN節點 --> 使用者: 直播內容分發到多個邊緣節點
使用者 --> 裝置: 接收直播內容 --\> 顯示直播內容
4.1 在這些過程中，可能會產生延遲的地方
(部分解釋來源第三方文獻)
- 主播端所使用的採集編碼裝置可能存在延遲
主要包含編碼延遲以及傳送快取引入的延遲，這個環節的延遲最佳化空間不多，雖然透過調節編碼器引數可有效降低編碼延遲，但帶來的是畫質的損失，同時也影響壓縮效果，因此多數集中在最佳化弱網傳輸，出發點是為了提供使用者觀看流暢體驗，而不僅限於降低延遲
- 雲伺服器對直播內容的轉碼、壓縮等處理的時間
對於直播平臺而言，實時轉碼是非常必要的一項技術。透過對影片流進行實時轉碼，可以將高畫質影片流最佳化為多個解析度，滿足不同終端裝置的相容性和頻寬需求，並且減小了網路傳輸的開銷。但是，實時轉碼過程中必然會帶來一定的延遲，這是因為：
- 轉碼過程需要對影片流進行分析和處理，比如壓縮、格式轉換等。這個過程需要一定的計算資源和時間。
- 轉碼後的影片需要重新傳輸到CDN節點中，再由觀眾裝置進行播放。這個過程可能會受到網路頻寬、傳輸速率等因素的影響，導致一定的延遲。
因此，針對轉碼延遲的問題，需要在減小延遲和提高影片質量之間進行權衡。採用一些高階的轉碼演算法、減少圖片質量降低對影片畫質的傷害、最佳化編碼引數等方法，但也同樣會帶來畫質與壓縮率的損失，因此這部分延遲需要根據實際場景綜合來考慮，如果對延遲要求很高，可以略微調整下。
- CDN節點的網路傳輸延遲
不考慮回源的情況，這個環節主要影響延遲的是 gop cache 策略，各類 CDN 廠商稱呼都不一致，有的又叫（RTMP、FLV、HLS...）Delay，即在邊緣節點快取一路流最新的幾個 gop(一般媒體時長平均為 5 ～ 7s)，目的是為了在拉流請求建立時，可以有媒體資料即時傳送，最佳化首幀和卡頓，這樣也就導致了播放端收到的第一幀資料就是 5 ～ 7s 前的舊資料，第一幀的延遲就達到了 5 ～ 7s，這個環節是端到端延遲過大的根因。
- 播放器的防卡頓快取buffer固定延遲n(s)
在直播拉流播放過程中，為了提高播放的流暢度和使用者體驗，通常進行快取一部分buffer。快取是指在播放器開始播放之前，預先載入一定量的影片資料到本地快取中，以便後續播放時能夠快速讀取快取中的資料，避免卡頓和不流暢的現象。這種“預載入”的快取被稱為“快取buffer”。
快取buffer大小不同可能會導致延遲時間也不同，常見的快取buffer大小為2秒或者更小，這意味著播放器會預先從影片源中載入2秒到本地快取中，等播放器播放到接近快取末尾時，會再次預載入2秒內容到快取中，以保證播放的流暢性。
固定延遲是指播放器在接收到網路資料之後，為保證資料正常播放而需要等待一定的固定時間，一般用於防止影片播放過程中的卡頓和不流暢。例如，如果設定的固定延遲為1秒，那麼從資料包到達手機端再到資料包真正播放出來這個過程，就需要多等待1秒左右的時間，這就是固定延遲產生的效果。
通常情況下，播放器會自動根據當前的網路環境動態調整快取buffer大小和固定延遲時間，以保證最佳的播放效果。不過，如果網路環境不太理想，仍有可能出現影片卡頓和不流暢的情況，此時可以透過配置和最佳化快取buffer大小和固定延遲時間來改善播放效果。
- 使用者裝置的接收、解碼等操作產生的延遲
假設使用者的裝置硬體效能較為低端，在接收和解碼直播資料時出現卡頓等問題。為此，可以透過最佳化碼流引數，如對位元速率、解析度等進行調節，使其更加適應使用者裝置的硬體效能；或者採用儘量少的傳輸協議，以減少解碼時間和相關計算資源的使用。
- 綜合所述
其中任何一個環節出現問題，都有可能導致直播過程中產生延遲。為了減少這種延遲，可以最佳化各個環節的處理效率，並最佳化網路傳輸等方面的引數和設定。
在直播的傳輸環節裡，對延遲影響大的主要是CDN的傳輸、轉碼、分發和播放緩衝，使用實時的轉碼模式，轉碼器引入的延遲一般在 300ms 以內甚至更短。CDN 的分發環節也會帶來一定的延遲，但相對也較短。而為了對抗網路抖動引入的播放緩衝區引入的延遲播放緩衝引入的延遲常常會有 5s 甚至更多。
4.2 如何知道具體延遲？
方法一：
採用端到端的測試方法，即計算播放端到推流端的時間差作為延遲。
找一個線上的精確到毫秒的時鐘：http://www.daojishiqi.com/bjtime.asp
A. 開啟上述網頁，推流端對準該網頁或者抓取視窗
B. 播放端：到對應直播間觀看對應的時間差
對A、B（螢幕）進行對比，截圖計算時間差。
方法二：
編碼的時候把時間戳寫到 SEI 資訊中，播放器透過拉流成功後解析 SEI 資訊然後與當前時間戳做差值對比。
SEI 需要涉及到推拉流側底層開發，所以暫選的方法一進行測試，測試結果發現現階段最保守以及快速的解決方式是直接調整雲直播控制檯的延遲檔位。如果要調整延遲檔位，那勢必要了解到調整之後會帶來什麼影響以及變化，這其中就涉及到了 GOP 相關的知識點。
4.3 GOP 以及 GOP cache 是什麼？我們為什麼要了解它？
顧名思義 GOP cache，是一組存於 CDN 服務端的 GOP 快取，GOP cache 越大延遲影響也越大。透過了解 GOP cache 我們能在直播延遲鏈路中能做出更精準的最佳化。GOP cache 是某一方廠商提出的名詞，各大 CDN 的稱呼也不一致，有的雲廠商又稱之為（RTMP、FLV、HLS...）Delay。與推流 GOP 或者 轉碼播流 GOP 配合，就形成完整的端到端延遲。
GOP（Group of Pictures）
而 GOP 是一組連續的影片幀，通常包括一個I幀（關鍵幀）和若干個P幀（預測幀）和B幀（雙向預測幀）。在直播過程中，如果 GOP 的大小過大，會導致接收端在等待I幀的到來時需要等待相對較長的時間，這就會增加影片的延遲。因此，降低 GOP 大小可以在一定程度上減小影片的延遲。
直播控制檯的延遲（GOP cache） 配置路徑 （域名配置->直播延遲配置） 選項中選擇
推流 GOP & 轉碼 GOP 關係
<!---->
- 無轉碼的情況下，推流 GOP == 播流的 GOP
- 有轉碼的情況下，如果轉碼模板配置了 GOP ，則播流的 GOP == 轉碼配置的 GOP
- 如果轉碼模板未指定具體的 GOP，則推流 GOP == 轉碼後的 GOP
<!---->
延遲配置的描述，強調的都是推流 gop，是否有誤導問題？
不算完全算誤導，一方面不是所有直播流都走轉碼，甚至修改 GOP。另一方面推流 GOP 對流傳輸效率可能存在一定影響。主要描述沒有把轉碼 GOP 的影響和區別包括進去。
快取的單位 duration or size?
得物使用的直播快取的單位是 duration
在直播延遲中，快取的單位可以是時間(duration)或大小(size)。
以時間(duration)為單位的快取指的是，在影片採集、編碼和推送到雲伺服器的過程中，影片資料會先被存放在緩衝區中，等待一定的時間（也就是快取時間）後，才會被推送到CDN分發節點上進行播放。
以大小(size)為單位的快取則是根據快取容量進行控制，影片在採集、編碼和推送到雲伺服器的過程中，每當影片資料達到一定的大小，就會被推送到CDN分發節點上進行播放。
在實際的直播過程中，通常會綜合使用時間和大小兩種快取單位來進行延遲控制。如果對延遲比較在意，可以適當增加快取時間和大小，保證接收端有足夠的快取時間進行播放，減少出現卡頓和停頓的機率。如果實時性比較重要的話，可以適當降低快取時間和大小，縮短延遲時間，保證直播的實時性。
需要注意的是，快取時間和快取大小是直播平臺最佳化延遲的兩個關鍵因素。合理的設定能夠顯著減小延遲，提升使用者體驗。但同時，快取過多或者過少都可能會帶來一定的問題，因此需要根據實際情況進行調整和最佳化。
快取的 gop 數?
不固定，且沒有 GOP 數量的概念，是以時長論大小，取決於 CDN 側的 buffer ，不管 buffer 多大，傳送資料是按照至少一個 delay, 最多 delay + gop 傳送的，流資料是不斷產生新資料的，傳送的時候內容不斷在滑動。對延遲沒有直接的影響關係。
基礎時間值
RTMP ：低（2s）中（4s）高（8s）
FLV ：低（2s）中（4s）高（8s）
計算延遲方式：[RtmpDelay, RtmpDelay + GOP] 這裡的 GOP，轉碼前用的推流設定的 GOP，轉碼後用的轉碼模板配置的 GOP自定義模版配置的 1080p，gop = 10s = 200楨 的情況下 理論上最小最大值就下面的幾種範圍[2，12]，[4，14]，[8，18]
flv 播放的話，delay設定2秒，gop 設定1秒，理論上端到端的延遲基本在3秒左右，如果位元速率高的情況下，還得適當提升 delay 的值保證直播的流暢。另外除了 CDN 快取延遲以外，播放器快取策略也需要考慮。
如果要實現穩定2秒，可以考慮超低延遲直播的方案。
5.後續可實施的有效降低直播延遲手段
降低 CDN 正式環境的 gopCache 至低檔位
調整完之後端到端延遲預計能從 5s-8s 降低至 3s-5s
推流 GOP 調整為 1s，平均端到端延遲再下降 1s
理論上來說降低推流 GOP，是對延遲有幫助的，將 GOP 降至1秒，則每秒會推送一個關鍵幀，接收端就可以在接收到關鍵幀後直接播放，進一步減小延遲。同時，由於每秒會推送更多關鍵幀，對影片的畫質和穩定性也會產生積極的影響。
推流 GOP 的大小不是唯一的影響直播延遲的因素。還有影片編碼、推流伺服器的 配置、網路環境等因素都會對延遲產生影響，因此只有在綜合考慮到各種因素後，合理設定推流GOP大小，才能夠最大程度地降低直播延遲。
增加 buffer 中影片資料的消費速度，有效降低延遲，例如倍速播放或者直接丟幀，策略需要更精細化
也就是說增加拉流側的消費速度，在有需求的情況下配合倍速追楨的策略，加快影片的播放速度，在某一個閥值中開啟或者停止。
推流側在推流的過程中把關鍵幀打入時間戳到 SEI 資訊裡去
拉流側在拉流的過程中解碼成功之後把對應的 SEI 資訊裡的時間戳解析出來
然後根據服務端的線上時間對比兩者之差，決定播放器的播放器倍速，例如 (1.0 ~ 1.4s) 之間逐漸增加和遞減，最終在符合預期的延遲時間停止加速消費
確認自研播放器 buffer 快取當前現狀是多少秒，對齊競品至少 2s buffer
常見的直播播放器快取buffer大小為2秒，主要是出於減少卡頓和停頓的機率，提升使用者體驗的考慮。播放器快取buffer是指播放器預先快取一定量的影片資料進行播放。當網路狀況不好、影片流傳輸中斷或者延遲過高時，播放器快取就會派上用場，保證播放過程的連續性和流暢性。一般來說，播放器快取buffer大小會根據網路環境和頻寬等因素而不同。如果快取過小，會導致卡頓和停頓；如果快取過大，會增加延遲，影響實時性。經過最佳化，常見的直播播放器快取buffer大小為2秒左右，既能夠保證播放過程的流暢性，又不會過度增加延遲。不同的直播平臺（PC、移動端）、不同的網路（WIFI、4G、5G）和裝置（不同廠商）可能會有不同的播放器快取 buffer 大小設定，因此在實際使用中需要根據具體情況進行調整和最佳化。
使用阿里雲的 RTS 或者，位元組的 RTM 協議，如果使用超低延時方案還需確認使用場景（例如頭部熱門直播間有需要的才採用）
阿里雲的 RTS（Real-Time Streaming）和位元組的 RTM（RTM，Real Time Media）都是超低延時商業化方案，有著使延遲降低至<=1s的效果， 在具體的應用場景和功能方面都差不多。
- RTS全鏈路延時監控、CDN 傳輸協議改造、UDP 等底層技術優，可以提供低延遲的流媒體資料傳輸和處理服務，支援高併發、低卡頓、秒開流暢的直播體驗。
- RTM透過鏈路傳輸協議改造為 UDP 等底層技術最佳化，解決 TCP 協議自身侷限和網路抖動引起延遲累加，支援高併發、高可靠性的優質直播觀看體驗。
以上兩種商業化方案都需要配合播放器SDK使用，且 RTM 需要配合火山 CDN 環境使用，兩者費用也不一樣。需要針對我們當前架構和現狀作出權衡考慮。
使用 QUIC 協議（底層UDP協議理論上延遲會更低），已在三方播放器上驗證過。普通 flv <=5s 下降到 <=2s
常規直播推流底層協議是基於TCP的，理論上極限在3秒左右已經是最低的了。
而 QUIC（Quick UDP Internet Connections）是一種基於使用者資料包協議（UDP）的協議，它在傳輸上相比於傳統的傳輸層協議（TCP）有以下優勢，導致延遲更低:
- 連線建立時間短, TCP 協議需要經過三次握手的過程來建立連線，而QUIC協議只需要一次握手，這樣就大大減少了連線建立的時間，提高了通訊效率。
- 報文傳輸方式不同, TCP 協議在傳送資料之前首先需要進行慢啟動過程，以逐步增加傳送速率並監測網路擁塞。QUIC 協議透過動態地調整視窗大小和傳輸速率，使得資料傳輸更加高效。
- 多路複用支援度更好, QUIC 協議支援多路複用，這意味著可以在單個連線上同時傳輸多個流，從而保證更高的頻寬利用率和更低的延遲。
- 減少網路服務的依賴, QUIC協議能夠在連線失效或者網路服務不可用的情況下，進行快速恢復，從而保證了穩定的資料傳輸。
綜上所述，由於QUIC協議在連線建立、報文傳輸、多路複用和網路故障處理等方面都有著比. TCP協議更好的表現，因此它可以提供更低的延遲，更高的速率以及更可靠的連線。另外一個使用QUIC（UDP）也需要綜合考慮一些問題，它帶來更低的延遲後，會不會有一些其他方面受到負面影響，例如拉流成功率、穩定性問題之類的。所以最終實施方案還需要做更詳細的測試權衡利弊。
6.一些思考
直播延遲問題涉及的因素較多，包括推流端和播放端的快取設定、傳輸協議、GOP控制等方面。為了解決延遲問題，在實際開發中，為了達到更好的使用者體驗，我們需要對這些因素進行綜合考慮和最佳化，在不斷的實踐和實驗中尋找最佳方案，透過綜合使用這些技術方案，可以更好地提高直播平臺的實時性和觀看體驗。
活動推薦：得物技術社招開始啦！點選關注得物技術公眾號瞭解詳情！
本文屬得物技術原創，來源於：得物技術官網
得物技術文章可以任意分享和轉發，但請務必註明版權和來源：得物技術官網