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