作者 ｜ 張東輝 

延遲是怎么產(chǎn)生的？

傳統(tǒng)直播方案(http-flv、RTMP 等)的架構(gòu)以及延遲量級(jí)如下圖所示：

以抖音直播為例，直播鏈路各環(huán)節(jié)延遲貢獻(xiàn)如下：

• 推流端——網(wǎng)絡(luò)延遲平均 20 ～ 30ms，編碼延遲依賴編碼參數(shù)設(shè)置而定
• 流媒體服務(wù)——在拉流轉(zhuǎn)碼的場(chǎng)景下，會(huì)額外引入 300ms ～ 2s 的轉(zhuǎn)碼延遲(大小與轉(zhuǎn)碼參數(shù)相關(guān))，如果直接播放源流，則不存在轉(zhuǎn)碼延遲
• 播放端——網(wǎng)絡(luò)延遲 100ms ～ 200ms 左右，主要是鏈路分發(fā)節(jié)點(diǎn)之間的傳輸延遲；防抖 buffer——5 ～ 8s

從各環(huán)節(jié)延遲貢獻(xiàn)看，容易得出一個(gè)直觀的結(jié)論：端到端延遲過大主要是播放器的防抖 buffer 造成，這個(gè)表面現(xiàn)象也經(jīng)常會(huì)導(dǎo)致很多同學(xué)，認(rèn)為降低播放器的 buffer，就能降低延遲。這個(gè)說法的對(duì)錯(cuò)，取決于從什么角度解釋。在辯證這個(gè)結(jié)論前，我們先詳細(xì)拆解介紹下直播全鏈路的延遲：

上圖主要更細(xì)致地拆解了流媒體服務(wù)環(huán)節(jié)，即 CDN 傳輸鏈路，拆解為上行(收流節(jié)點(diǎn)和上層節(jié)點(diǎn))、源站、下行(上層節(jié)點(diǎn)和拉流邊緣節(jié)點(diǎn))。各環(huán)節(jié)延遲歸因如下：

主播端(推流器)

主要包含編碼延遲以及發(fā)送緩存引入的延遲（多數(shù)主播網(wǎng)絡(luò)情況良好，發(fā)送緩存延遲平均只有 20 ～ 30ms），這個(gè)環(huán)節(jié)的延遲可優(yōu)化空間不多，雖然通過調(diào)節(jié)編碼器參數(shù)可有效降低編碼延遲，但帶來的是畫質(zhì)的損失，同時(shí)也影響壓縮效果，因此多數(shù)集中在優(yōu)化弱網(wǎng)傳輸(不過出發(fā)點(diǎn)是為了提供用戶觀看流暢體驗(yàn)，而不在于降低延遲)

收流邊緣節(jié)點(diǎn)&中間鏈路

針對(duì) http-flv 不需要分片的協(xié)議，CDN 傳輸各節(jié)點(diǎn)都是在收到流數(shù)據(jù)就直接轉(zhuǎn)發(fā)到下一個(gè)節(jié)點(diǎn)，這個(gè)環(huán)節(jié)主要的延遲是由鏈路傳輸引起的，與鏈路長度正相關(guān)，一般平均不超過 200ms。

如果播放端拉轉(zhuǎn)碼流，那么在網(wǎng)絡(luò)傳輸延遲基礎(chǔ)之上，會(huì)額外增加轉(zhuǎn)碼延遲(目前各大 CDN 廠商編碼延遲大概分布在 300ms ～ 2s)，包括解碼延遲和轉(zhuǎn)碼延遲，其中對(duì)于無 B 幀的場(chǎng)景，解碼延遲較小，主要是編碼延遲。編碼延遲主要是受編碼器緩存幀數(shù)影響，假設(shè) FPS=15，那么緩存 6 幀，延遲就 400ms，該部分延遲與推流編碼延遲一樣，同樣可以通過調(diào)整轉(zhuǎn)碼參數(shù)來降低轉(zhuǎn)碼延遲，但也同樣會(huì)帶來畫質(zhì)與壓縮率的損失，因此這部分延遲需要根據(jù)實(shí)際場(chǎng)景綜合來考慮，如果對(duì)延遲要求很高，可以調(diào)整下。

拉流邊緣節(jié)點(diǎn)

不考慮回源的情況，這個(gè)環(huán)節(jié)主要影響延遲的是 gop cache 策略(有的 CDN 廠商也叫做快啟 buffer 策略或者快啟 cache)，即在邊緣節(jié)點(diǎn)緩存一路流最新的幾個(gè) gop(一般媒體時(shí)長平均為 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é)才是端到端延遲過大的根因)。

CDN gopCache 的邏輯

字節(jié)與 CDN 廠商溝通約定 gop cache 按照下限優(yōu)先來下發(fā)數(shù)據(jù)，比如下限 6s，表示先在緩存數(shù)據(jù)中定位最新 6s 的數(shù)據(jù)，然后向 6s 前的舊數(shù)據(jù)查找第一個(gè)關(guān)鍵幀下發(fā)，保證下發(fā)第一幀距離最新幀之間的時(shí)長不低于 6s：

如上圖，如果不考慮生產(chǎn)端和中間鏈路的延遲，那么 buffer 長度 7.2s 可以近似看作播放的初始端到端延遲，在播放器正常播放且無卡頓的前提下，這個(gè)延遲會(huì)一直持續(xù)到退出直播間，不會(huì)變化。這里介紹幾個(gè)初始延遲計(jì)算的通用公式：

• 延遲分布區(qū)間[M,M+gop]s，
• 平均延遲為 M+gop/2，其中 M 為 gopCache 策略的下限，gop 即為編碼 gop 的固定大小值

例如抖音秀場(chǎng) gop 大小是固定的 2s，假設(shè) gopCache 下限為 6s，那么觀眾的合理端到端延遲分布區(qū)間為：[6, 8]s，根據(jù)用戶請(qǐng)求的時(shí)間點(diǎn)，所有觀眾的延遲都會(huì)均勻分布在這個(gè)區(qū)間內(nèi)，因此不同觀眾間的延遲 diff 最大不超過一個(gè) gop 的長度 2s(這點(diǎn)是優(yōu)化設(shè)備間延遲差的理論基礎(chǔ))

觀眾(播放器)

播放器在 io 模塊有分配緩存 buffer(抖音線上分配 buffer 最大為 20s，也就是最多可容納 20s 的媒體數(shù)據(jù)，這個(gè) buffer 其實(shí)越大越好，抗網(wǎng)絡(luò)抖動(dòng)能力也越強(qiáng))，用于存放從 CDN 邊緣節(jié)點(diǎn)下載到的流媒體數(shù)據(jù)。播放器下載是主動(dòng)下載，在可分配的 buffer 隊(duì)列未充滿的前提下，io 線程是連續(xù)下載流媒體數(shù)據(jù)并存放到 buffer 中，直到?jīng)]有空閑 buffer 可利用為止。因此，觀眾網(wǎng)絡(luò)狀況良好的情況下，在用戶請(qǐng)求播放，建立鏈接后，CDN 的邊緣節(jié)點(diǎn)的快啟 buffer，會(huì)很快都被下載到播放器的 buffer 中，后續(xù)渲染環(huán)節(jié)消費(fèi)速度遠(yuǎn)低于 i/o 下載的速度，這樣端到端的延遲就主要分布到了播放器的 buffer 中。但只說明啟播后，直播鏈路的延遲從 CDN 的 gopCache，轉(zhuǎn)移到了播放器，播放器 buffer 并不是延遲的根因，因此，降低播放器的最大緩存 buffer，并不能降低延遲。如果換個(gè)角度理解，降低播放器 buffer 中實(shí)際緩存的數(shù)據(jù)，會(huì)降低延遲這個(gè)說法是正確的，比如通過倍速播放或者丟幀。

現(xiàn)在了解了全鏈路延遲是怎么產(chǎn)生的，我們可以確認(rèn)以下幾點(diǎn)：

• 端到端延遲，在 CDN 邊緣節(jié)點(diǎn)收到 http-get 請(qǐng)求那一刻起，流數(shù)據(jù)未達(dá)到客戶端 buffer 前，初始延遲的大小就已經(jīng)確定了，這個(gè)延遲對(duì)應(yīng)于我們的 QoS 指標(biāo)-首幀延遲
• 影響延遲大小的因素主要有兩點(diǎn)：CDN 邊緣節(jié)點(diǎn) gop cache 策略(5~7s 延遲)以及視頻流 gop 大小(會(huì)造成一個(gè) gop 大小的延遲 diff)
• 客戶端 buffer 大小與延遲大小之間沒有因果關(guān)系，buffer 的大小只會(huì)影響延遲全鏈路的分布，但降低播放器 buffer 大小只會(huì)降低防抖能力，惡化卡頓，并不會(huì)降低延遲
• 較低延遲的有效手段包括：

• 降低 CDN 的 gopCache，是根本手段
• 增加 buffer 中視頻數(shù)據(jù)的消費(fèi)速度，也可以有效降低延遲，例如倍速播放或者直接丟棄媒體數(shù)據(jù)
• 在 gopCache 不變的前提下，降低 gop，也可以降低平均端到端延遲，比如 gop=4s 調(diào)整為 2s，平均端到端延遲下降 1s

為什么要優(yōu)化延遲？

傳統(tǒng)的直播技術(shù)延遲非常大，從觀眾評(píng)論到看到主播給出反饋一般要在 5-10 秒以上。幾個(gè)典型的尷尬場(chǎng)景：

單一用戶延遲大，導(dǎo)致體驗(yàn)差

在線教育，學(xué)生提問，老師都講到下一個(gè)知識(shí)點(diǎn)了，再返回來回答。

電商直播，詢問寶貝信息，主播“視而不理”。

打賞后遲遲聽不到主播的口播感謝。

假設(shè)端到端延遲為 6s，那么在線教育和電商直播兩個(gè)場(chǎng)景，互動(dòng)延遲由面對(duì)面的 0s，增加到了 12s，如下圖所示：

打賞場(chǎng)景，互動(dòng)延遲由面對(duì)面的 0s，增加到了 6s，如下圖所示：

不同用戶延遲 diff 大，導(dǎo)致體驗(yàn)差

在別人的吶喊聲知道球進(jìn)了，你看的還是直播嗎？

?這個(gè)場(chǎng)景的延遲體驗(yàn)問題，并不是某次拉流請(qǐng)求端到端高延遲導(dǎo)致的，主要是因?yàn)椴煌脩糸g的延遲不一致導(dǎo)致，如下圖：

可見，高延時(shí)影響了直播互動(dòng)體驗(yàn)，阻礙了直播在一些場(chǎng)景的落地，特別在電商直播，直播間的評(píng)論提問是觀眾和主播互動(dòng)的一個(gè)重要手段，主播的實(shí)時(shí)互動(dòng)反饋對(duì)直播間的活躍度和交易達(dá)成至關(guān)重要。

?以上兩類由于延遲導(dǎo)致體驗(yàn)差的場(chǎng)景，分別對(duì)應(yīng)我們 QoS 指標(biāo)中的平均端到端延遲、延遲設(shè)備差兩個(gè)指標(biāo)，延遲相關(guān)的優(yōu)化也會(huì)以這兩個(gè)指標(biāo)為標(biāo)準(zhǔn)。

延遲體驗(yàn)優(yōu)化實(shí)踐案例

百萬英雄答題

直播流鏈路

延遲需求

• 所有觀眾端到端時(shí)延在 6s 以內(nèi)——對(duì)應(yīng)首幀延遲和平均端到端延遲指標(biāo)
• 不同觀眾 A，B，C 之間直播流時(shí)延差在 2s 以內(nèi)，避免答題不同步——對(duì)應(yīng)設(shè)備延遲差指標(biāo)

需求分析

• 對(duì)于答題類活動(dòng)直播場(chǎng)景，用戶主要集中精力在聽題、讀題、答題，與主播的互動(dòng)不是強(qiáng)需求，因此端到端延遲不是優(yōu)化重點(diǎn)，只要滿足需求的 6s 即可
• 用戶使用場(chǎng)景多數(shù)是面對(duì)面或者實(shí)時(shí)語音組團(tuán)答題，會(huì)對(duì)彼此之間延遲不一致的現(xiàn)象很敏感，因此保證設(shè)備延遲差盡可能小是核心需求點(diǎn)

解決方案

滿足時(shí)延 6s 以內(nèi)——調(diào)整 gopCache 以及 gop 大小

gop=2s，gopCache 下限為 5s，那么首幀延遲分布在[5s, 5+2s]內(nèi)，平均延遲為(5+(5+2))/2=6s，具體措施如下：

1. 各家 CDN 快啟策略需要設(shè)置為下限優(yōu)先，并且快啟 buffer 閾值為 5s
2. 推流參數(shù)設(shè)置需要設(shè)置 gop=2s，且保持穩(wěn)定：保證觀看同一路流的用戶，時(shí)延 diff 在 2s 內(nèi)
3. 轉(zhuǎn)碼配置需要保持 gop=2s 的配置，并且 I 幀對(duì)齊：保證觀看不同轉(zhuǎn)碼流的用戶，時(shí)延 diff 在 2s 內(nèi)

延遲差在 2s 以內(nèi)

調(diào)整 gop=2s 后，僅能保證一直流暢播放無卡頓的 vv，彼此直接的延遲 diff 在 2s 以內(nèi)，但對(duì)于觀播過程中發(fā)生卡頓的用戶，累計(jì)延遲增加的情況，延遲 diff 會(huì)越來越大，例如用戶 A 卡 4s 后，恢復(fù)正常播放，那么 A 的端到端延遲會(huì)增加 4s，如果 A，B，C 是一個(gè)組隊(duì)答題的小伙伴，A 的題目解說會(huì)一直落后 B 和 C，這樣的體驗(yàn)很不好。因此需要針對(duì)這類場(chǎng)景的設(shè)備延遲差做優(yōu)化：這時(shí)候需要播放器追幀微調(diào)，使 A 的播放速度追上 B 和 C。具體措施如下：

1. 追幀的原則是：在 A 的播放器 buffer 超過 6s 時(shí)，就開始倍速播放，直到 buffer 低于 6s，這時(shí)候 A 就追上了 B 和 C
2. 追幀閾值 6s，追幀速度是 1.4，這樣設(shè)置的效果時(shí)，A 觀眾在延遲落后 4s 的情況下，追幀 10s 即可趕上 B 和 C，實(shí)際閾值的設(shè)置，可以根據(jù)需求來確定，原則上是在延遲滿足需求時(shí)，盡量不觸發(fā)追幀，保持正常速度播放

效果驗(yàn)收

相對(duì)于第一屆百萬英雄答題，延遲不同步的用戶反饋大量減少

4s 低延遲字節(jié)內(nèi)購會(huì)

直播流鏈路

類似于百萬英雄

延遲需求

• 所有觀眾端到端時(shí)延在 4s 以內(nèi)——對(duì)應(yīng)首幀延遲和平均端到端延遲指標(biāo)
• 不同用戶在聽到主播說上鏈接時(shí)，與購物鏈接彈出時(shí)間盡量一致——對(duì)應(yīng)設(shè)備延遲差指標(biāo)

需求分析

• 內(nèi)購會(huì)有電商主播帶貨環(huán)節(jié)，因此對(duì)互動(dòng)延遲敏感
• 內(nèi)購會(huì)是大型組團(tuán)搶購活動(dòng)，員工都在工位面對(duì)面參與，因此對(duì)設(shè)備延遲差也會(huì)很敏感

解決方案

推流&轉(zhuǎn)碼流配置

CDN 側(cè)

相對(duì)于百萬英雄答題場(chǎng)景，內(nèi)購會(huì)對(duì)互動(dòng)延遲敏感，因此這里相對(duì)于百萬英雄答題需要做特殊配置，由于各家廠商默認(rèn) gopCache 策略，平均端到端延遲在 6s 左右，不滿足需求的 4s，需要通過配置 url query 參數(shù)控制廠商的 gopCache 策略，保證延遲在 4s 左右

播放端參數(shù)配置詳情

1. 延遲等級(jí)：4s
2. 參數(shù)配置目標(biāo)：降低不同設(shè)備間延遲差，控制用戶延遲分布在[3000ms, 4000ms]內(nèi)，這樣保證設(shè)備間延遲差最大不超過 1s——延遲低的用戶慢放，延遲高的用戶追幀，從而更精確的控制設(shè)備延遲差低于 gop 長度 2s

倒計(jì)時(shí)確認(rèn)時(shí)機(jī)

內(nèi)購會(huì)上鏈接或者答題，是根據(jù)現(xiàn)場(chǎng)助理觀播的延遲來確定上鏈接或者發(fā)題的倒計(jì)時(shí)時(shí)機(jī)，由于有快慢放對(duì)齊設(shè)備延遲差的過程，建議助理看播 1min 后，延遲穩(wěn)定后，再確定倒計(jì)時(shí)

效果驗(yàn)收

• 線下演練以及正式場(chǎng)不同設(shè)備間的流內(nèi)容延遲，進(jìn)入觀播后通過快慢放調(diào)整后，延遲基本都穩(wěn)定在 4s，且 diff 不超過 1s
• 主播口播“上鏈接”與實(shí)際鏈接彈出延遲 diff 在 1s 內(nèi)，搶購體驗(yàn)良好
• 基本無卡頓反饋 case

抖音直播-FLV 低延遲-3s

直播流鏈路

需求目標(biāo)

• 平均延遲達(dá)到 3s
• 播放時(shí)長、看播滲透、留存等核心業(yè)務(wù)指標(biāo)顯著正向
• 電商 GMV、充值打賞等營收指標(biāo)顯著正向

需求分析

• 傳統(tǒng)直播場(chǎng)景，不同觀眾同一時(shí)刻經(jīng)常觀看不同主播的流，且經(jīng)常是個(gè)人獨(dú)立觀播，對(duì)同一直播間，不同觀眾延遲一致的訴求基本不存在，因此延遲設(shè)備差不是優(yōu)化重點(diǎn)指標(biāo)
• 秀場(chǎng)直播、直播帶貨等場(chǎng)景，是強(qiáng)互動(dòng)場(chǎng)景，對(duì)互動(dòng)延遲要求高，本需求核心優(yōu)化點(diǎn)是端到端延遲

解決方案

本次需求場(chǎng)景的受眾是抖音的所有直播用戶，網(wǎng)絡(luò)質(zhì)量的優(yōu)劣也是參差不齊的，在保證滿足降低延遲的需求目標(biāo)，我們還需要保證觀播的流暢性不要負(fù)向太多。

延遲解決方案

1. gop 下調(diào)為 2s
2. 配置 gopCache 下限參數(shù)為 1800ms，延遲區(qū)間為[1800+200ms，3800+200ms]，平均 3s?

卡頓優(yōu)化方案

1. 先驗(yàn)知識(shí)科普

• 啟播 buffer 策略：表示首幀渲染后，需要等到播放器 audio buffer 達(dá)到一定閾值后，再繼續(xù)播放，這樣可以增加網(wǎng)絡(luò)抗抖能力
• 網(wǎng)絡(luò)分級(jí) 1 ～ 8：

• 8—等效于非常好的 4G 網(wǎng)絡(luò)；
• 7—等效于較好的 4G 網(wǎng)絡(luò)；
• 6—等效于一般的 4G 網(wǎng)絡(luò)；
• 5—等效于較差的 4G 網(wǎng)絡(luò)；
• 1 ～ 4—網(wǎng)絡(luò)質(zhì)量差

2. 基于網(wǎng)絡(luò)質(zhì)量的個(gè)性化啟播 buffer 策略

• 方案設(shè)計(jì)基本原理

• 基于網(wǎng)絡(luò)分級(jí)，自適應(yīng)調(diào)整啟播 buffer
• 設(shè)定啟播 buffer 最大調(diào)整區(qū)間為[0,850ms]
• 不同網(wǎng)絡(luò)分級(jí)映射到不同的啟播 buffer 區(qū)間
• 隨著網(wǎng)絡(luò)分級(jí)的變差，啟播 buffer 檔位遞增速率也加快
• 同一網(wǎng)絡(luò)分級(jí)的不同 vv，根據(jù)重試和卡頓次數(shù)，在該網(wǎng)絡(luò)分級(jí)的啟播 buffer 區(qū)間中進(jìn)行微調(diào)
• 隨著卡頓次數(shù)的增加，啟播 buffer 在對(duì)應(yīng)檔位區(qū)間內(nèi)的微調(diào)幅度逐步下降
• 對(duì)于同一次 app 啟動(dòng)周期內(nèi)，發(fā)生多次直播 vv 的情況，需要考慮最近一次直播播放 session 中的卡頓和重試情況，且卡頓和重試的影響權(quán)重隨著時(shí)間衰減

• QoS 收益：卡頓負(fù)向降低了 20%

3. 基于網(wǎng)絡(luò)質(zhì)量的個(gè)性化延遲策略?

基于數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)：網(wǎng)絡(luò)分級(jí) 1 ～ 4 的 vv 占比為 5.54%，但卡頓指標(biāo)卻貢獻(xiàn)了 47.83%，再結(jié)合本需求場(chǎng)景設(shè)備間延遲差并不是核心指標(biāo)，因此可通過個(gè)性化延遲來優(yōu)化卡頓。

• 方案設(shè)計(jì)基本原理

• 基于網(wǎng)絡(luò)分級(jí)，自適應(yīng)調(diào)整延遲
• 不同網(wǎng)絡(luò)分級(jí)映射不同的 gopCache 下限
• 隨著網(wǎng)絡(luò)分級(jí)的變差，延遲逐漸增大

• QoS 收益：卡頓負(fù)向降低了 30%+

4. 客戶端管控 CDN 卡頓優(yōu)化策略

在需求推進(jìn)過程中發(fā)現(xiàn)兩個(gè)奇怪的現(xiàn)象：

• 在網(wǎng)絡(luò)質(zhì)量足夠好的場(chǎng)景下進(jìn)行線下測(cè)試，發(fā)現(xiàn)低延遲更容易觸發(fā) CDN 的丟幀策略(優(yōu)化卡頓的策略)，從而導(dǎo)致渲染卡頓上漲(和 CDN 溝通后，CDN 側(cè)不愿意透露太多的丟幀策略細(xì)節(jié)，根因無法求證)
• 在 AB 實(shí)驗(yàn)過程中，某一家 CDN 廠商上線了過激的丟幀策略，引起了線上大量反饋，從用戶反饋看，基本都是反饋剛進(jìn)入直播間的卡頓，推測(cè)用戶對(duì)啟播階段的丟幀卡頓，更敏感

結(jié)合以上兩個(gè)現(xiàn)象，基本可以判斷低延遲情況下，CDN 在啟播階段更容易丟幀，且啟播丟幀會(huì)嚴(yán)重影響 QoE 體驗(yàn)，因此管控 CDN 丟幀策略，對(duì) QoS(視頻渲染卡頓)以及 QoE 都是有正向優(yōu)化效果的，管控規(guī)則如下：

• QoS 收益：FLV 低延遲渲染卡頓負(fù)向降低約 30%

最終效果驗(yàn)收

QoE 指標(biāo)收益

• 核心業(yè)務(wù)指標(biāo)：直播人均看播時(shí)長、看播滲透、留存等顯著正向
• 營收相關(guān)指標(biāo)：電商人均支付訂單數(shù)、付費(fèi)滲透、充值等顯著正向

Qos 指標(biāo)

• 端到端延遲：3.24s
• 卡頓：增加 13%

帶寬成本收益

由于低延遲降低了 gopCache，延遲下降到 3s，相對(duì)于 7s 高延遲 FLV，在啟播時(shí)會(huì)少下載 4s 的數(shù)據(jù)，尤其抖音直播預(yù)覽流占比達(dá)到 70%，因此低延遲 FLV 可以節(jié)省不必要的帶寬成本，成本收益為 10%

關(guān)于延遲的思考

思考一：觀眾對(duì)互動(dòng)延遲的感知是否存在拐點(diǎn)，延遲降到一定程度，用戶感知不到？我們從三個(gè)典型的互動(dòng)場(chǎng)景來思考：

• 觀眾評(píng)論，主播看到評(píng)論進(jìn)行口播回復(fù)互動(dòng)：觀眾對(duì)話框輸入評(píng)論平均耗時(shí)至少 2s 以上，再降低互動(dòng)延遲是否有收益？
• 觀眾打賞送禮，主播進(jìn)行口播感謝互動(dòng)：假設(shè)觀眾打賞耗時(shí)平均 1s 左右，此時(shí)打賞后互動(dòng)延遲 3s 口播感謝，此時(shí)的延遲水平是否已經(jīng)滿足觀眾對(duì)主播感謝響應(yīng)度的需求？
• 直播帶貨場(chǎng)景：無論“上鏈接”口播與鏈接實(shí)際彈窗是否一致，還是秒拍場(chǎng)景，核心的延遲指標(biāo)都是設(shè)備間延遲差指標(biāo)會(huì)影響體驗(yàn)，是否實(shí)際的端到端延遲其實(shí)觀眾并沒有互動(dòng)延遲敏感？

思考二：在傳統(tǒng)標(biāo)準(zhǔn)直播 http-flv 場(chǎng)景下，是否可以依然基于本文中介紹的方法，繼續(xù)下探更低延遲，比如 1s？個(gè)人判斷是可以做到的，但面臨的挑戰(zhàn)也更多，需要更精細(xì)的播控策略來平衡延遲與播放流暢性，比如：

• 在 tcp/quic 等傳輸協(xié)議場(chǎng)景，啟播時(shí) CDN 側(cè)都存在帶寬(最佳的發(fā)送速率)探測(cè)的算法邏輯，基于實(shí)際發(fā)送數(shù)據(jù)探測(cè)結(jié)合 ACK 等反饋信息來增加發(fā)送速率，那么這里就存在一個(gè)問題——繼續(xù)降低 gopCache，滿足延遲下降到 1s 的同時(shí)，也導(dǎo)致 CDN 用于發(fā)送探測(cè)的數(shù)據(jù)量會(huì)變少，不足以探測(cè)到網(wǎng)絡(luò)鏈路實(shí)際的帶寬，這樣會(huì)導(dǎo)致 gopCache 階段平均發(fā)送速率會(huì)降低，抗網(wǎng)絡(luò)抖動(dòng)能力會(huì)急劇下降，同時(shí)也會(huì)影響首幀，因此為進(jìn)一步下探延遲，需要播放端和 CDN 相互配合優(yōu)化啟播發(fā)包速率，這樣才能保證流暢性不負(fù)向過多
• 更低延遲的場(chǎng)景對(duì)延遲的要求也極高，也更容易發(fā)生卡頓，但凡發(fā)生一次卡頓，延遲就很容易成倍增加，最終導(dǎo)致延遲降不下來，進(jìn)一步下探延遲也需要配合精細(xì)的追幀或者丟幀策略。