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