得物直播低延遲探索
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控制等方面。為了解決延遲問題，在實際開發中，為了達到更好的用戶體驗，我們需要對這些因素進行綜合考慮和優化，在不斷的實踐和實驗中尋找最佳方案，通過綜合使用這些技術方案，可以更好地提高直播平臺的實時性和觀看體驗。
