到更低的延遲，是一個(gè)巨大的挑戰(zhàn)。本文主要介紹世界杯期間火山引擎視頻云和相關(guān)團(tuán)隊(duì)在低延遲上的工作和優(yōu)化，作為低延遲方向上的總結(jié)。

本文主要討論生產(chǎn)和傳輸環(huán)節(jié)的延遲。生產(chǎn)環(huán)節(jié)的延遲主要受視頻流供應(yīng)商控制，技術(shù)團(tuán)隊(duì)可以實(shí)現(xiàn)的是，盡可能準(zhǔn)確地測(cè)量出生產(chǎn)的每一個(gè)環(huán)節(jié)的實(shí)際延遲，并在發(fā)現(xiàn)不合理的情況時(shí)推動(dòng)供應(yīng)商解決。傳輸環(huán)節(jié)的延遲技術(shù)團(tuán)隊(duì)更可控，也是本次優(yōu)化的重點(diǎn)。這部分技術(shù)能力可以作為火山引擎視頻云的優(yōu)勢(shì)能力積累并對(duì)外提供服務(wù)。在優(yōu)化的過程中，一個(gè)越來越清晰的認(rèn)知是：降低延遲并不困難，難的是延遲降低之后，怎么通過優(yōu)化保證播放體驗(yàn)不下降甚至變得更好。

1. 背景信息

首先簡(jiǎn)單介紹下世界杯直播的整個(gè)分發(fā)鏈路，還有每個(gè)環(huán)節(jié)的延遲的測(cè)量方法，讓大家對(duì)整體的鏈路有初步的全局認(rèn)識(shí)。

1.1 抖音世界杯信號(hào)分發(fā)鏈路

1.2 全鏈路延遲測(cè)量以及方法

測(cè)算方法：?

• 拍照

• 視頻畫面上有時(shí)鐘展示的(比如畫面左上角或者右上角的北京時(shí)間或者比賽持續(xù)時(shí)間，一般精確到秒)，可以通過同時(shí)拍照兩個(gè)播放畫面的方式，記錄同一時(shí)刻兩個(gè)畫面，然后通過照片中的時(shí)鐘做差來計(jì)算。

• 手動(dòng)秒表計(jì)算

• 如果視頻畫面中無時(shí)鐘相關(guān)內(nèi)容，那么可以從延遲低的視頻畫面中選取具有標(biāo)志性易識(shí)別的幀啟動(dòng)秒表，然后觀察延遲高的畫面出現(xiàn)同樣的幀畫面時(shí)，停止秒表，記錄秒表結(jié)果為延遲對(duì)比結(jié)果。

• 僅適用演播室推流到抖音播放鏈路

  
  

• 計(jì)算方法：端到端延遲 = 觀眾當(dāng)前系統(tǒng)時(shí)間戳 - SEI 中的時(shí)間戳，單位 ms。
• 統(tǒng)計(jì)頻度：每 2s 計(jì)算一次，每 10s 上報(bào)一次當(dāng)前計(jì)算結(jié)果。

• 每個(gè) I 幀前會(huì)有一個(gè) SEI，流規(guī)格設(shè)置為 I 幀間隔為 2s，因此每 2s 演播室推流側(cè)會(huì)生成一個(gè) SEI 幀。

• 前置要求：演播室推流前進(jìn)行 NTP 本地時(shí)鐘校準(zhǔn)。

延遲測(cè)量手冊(cè)：

2. 生產(chǎn)環(huán)節(jié)的低延遲

2.1 信號(hào)源

網(wǎng)絡(luò)流信號(hào)源在給到抖音之前存在多個(gè)環(huán)節(jié)，每個(gè)環(huán)節(jié)都可能會(huì)對(duì)最終的延遲有影響，但這一部分技術(shù)團(tuán)隊(duì)可以影響的比較少，主要是運(yùn)營(yíng)同學(xué)在溝通。

2.2 演播室制作環(huán)節(jié)

演播室在收到央視的源流之后，需要加上解說和包裝，所以也會(huì)引入一定的延遲。這次抖音的多個(gè)演播室是由多家第三方公司負(fù)責(zé)的，第三方公司的制作規(guī)格不一，在正式比賽之前經(jīng)過大量的溝通，基本確認(rèn)最重要的兩個(gè)演播室的技術(shù)方案和使用的編碼系統(tǒng)是一致的。

不過這次在演播室環(huán)節(jié)引入的延遲仍然偏高，達(dá)到了 1.5s 左右，和供應(yīng)商工程師溝通后，短期內(nèi)為了保證穩(wěn)定，沒有再進(jìn)一步壓縮了，這部分引入的延遲和競(jìng)品也是一致的。

3. 傳輸環(huán)節(jié)的低延遲

下圖是一次直播的簡(jiǎn)化的流程：

直播的傳輸環(huán)節(jié)里，對(duì)延遲影響大的主要是轉(zhuǎn)碼、分發(fā)和播放緩沖，使用實(shí)時(shí)的轉(zhuǎn)碼模式，轉(zhuǎn)碼器引入的延遲一般在 300ms 以內(nèi)甚至更短。CDN 的分發(fā)環(huán)節(jié)也會(huì)帶來一定的延遲，但相對(duì)也較短。為了對(duì)抗網(wǎng)絡(luò)抖動(dòng)引入的播放緩沖區(qū)引入的延遲播放緩沖引入的延遲常常會(huì)有 5s 甚至更多，所以本文主要討論怎么在減少播放緩沖的情況下，通過不斷地優(yōu)化延遲降低的同時(shí)不影響整體的播放體驗(yàn)(不僅僅是卡頓) 。在調(diào)優(yōu)過程中，大家對(duì)播放體驗(yàn)也有了更細(xì)致、更深的理解，逐漸弄清楚了哪些 QoS 指標(biāo)可以對(duì)關(guān)鍵的 QoE 指標(biāo)產(chǎn)生直接的影響，對(duì)以后要優(yōu)化的方向也更明確了。

3.1 FLV 方案

FLV 是現(xiàn)在國內(nèi)主流直播播放使用的協(xié)議，火山引擎對(duì)低延遲直播的探索也是從 FLV 開始的。在百萬英雄、內(nèi)購會(huì)等活動(dòng)中，F(xiàn)LV 低延遲方案也多次得到了驗(yàn)證。

之前詳細(xì)介紹過 FLV-3s 方案在抖音落地的詳細(xì)實(shí)踐過程(細(xì)節(jié)內(nèi)容可跳轉(zhuǎn)到 ??基于 http-FLV 的抖音直播端到端延遲優(yōu)化實(shí)踐??），同時(shí)提出過基于 FLV 方案做更低延遲下探，所面臨的挑戰(zhàn)也會(huì)更大：更低延遲的場(chǎng)景對(duì)直播全鏈路的傳輸穩(wěn)定性要求苛刻程度會(huì)幾何倍數(shù)增加，由于端到端鏈路的整體 buffer 更低，生產(chǎn)環(huán)節(jié)或者觀眾網(wǎng)絡(luò)抖動(dòng)，就更容易發(fā)生卡頓。只要發(fā)生一次卡頓，延遲就會(huì)秒級(jí)增加，最終累積延遲會(huì)越來越大。而世界杯賽事延遲要求達(dá)到 2s，繼續(xù)延續(xù) FLV-3s 方案顯然達(dá)不到要求，需要配合精細(xì)的追幀或者丟幀策略。

3.1.1 基于 buffer & 卡頓信息的雙閾值延遲追趕策略

音視頻數(shù)據(jù)流轉(zhuǎn)時(shí)序

• 在展開描述延遲追趕策略方案細(xì)節(jié)前，先簡(jiǎn)單介紹播放器音視頻數(shù)據(jù)流轉(zhuǎn)時(shí)序：網(wǎng)絡(luò) IO 下載音視頻數(shù)據(jù)到播放器緩存 buffer->解碼器從 buffer 中取數(shù)據(jù)解碼并降解碼后的數(shù)據(jù)存入待播放緩存->音畫同步等播控策略->渲染播放音視頻幀。

數(shù)據(jù)驅(qū)動(dòng) QoE & QoS 優(yōu)化

• 由于進(jìn)一步下探延遲，卡頓也會(huì)隨之惡化，反而延遲逐漸累積增加達(dá)不到低延遲的效果，因此延遲下探必須配合延遲追趕播控策略來確保延遲增大后可及時(shí)追趕恢復(fù)到低延遲。是否只要在延遲增加后立即倍速追趕就能滿足業(yè)務(wù)的需求呢？對(duì)于延遲 QoS 指標(biāo)來說的確是，但對(duì)于用戶主觀體驗(yàn)的 QoE 指標(biāo)，這樣的策略反而可能是負(fù)向的。
• 結(jié)合歷史 AB 實(shí)驗(yàn)以及 DA 詳細(xì)數(shù)據(jù)分析，有以下幾點(diǎn)倍速追趕與 QoE 指標(biāo)之間的關(guān)聯(lián)現(xiàn)象：

• 倍速追趕帶來的播放速度變化本身就是負(fù)面的體驗(yàn)
• 倍速時(shí)長(zhǎng)超過2秒，用戶即可有感知且負(fù)向反饋
• 倍速速度越大，播放速度前后變化 diff 越大，負(fù)向越嚴(yán)重
• 倍速與正常速度的切換過于頻繁，會(huì)帶來負(fù)向反饋
  綜上，需要一套精細(xì)的播控策略兼顧延遲與 QoE 指標(biāo)的平衡。

• 詳細(xì)方案設(shè)計(jì)

• 輸入：播放器當(dāng)前 Buffer 時(shí)長(zhǎng)、歷史 Ns 內(nèi) buffer 抖動(dòng)方差、歷史 Ns 內(nèi)卡頓信息以及追幀參數(shù)配置。

• 策略可配置參數(shù)以及含義映射：

  
  









• 輸出：目標(biāo)播放速度。

  
  

• 原理：

  
  

• 基于 buffer 抖動(dòng)方差 & 歷史卡頓信息，來定性衡量網(wǎng)絡(luò)質(zhì)量，判斷是否可以追趕，只有在網(wǎng)絡(luò)質(zhì)量良好是才能觸發(fā)追趕邏輯避免卡頓。

• 追幀采用雙閾值，并且支持可配置，可以控制追幀持續(xù)時(shí)長(zhǎng)不超過 2s，同時(shí)也可以保證不頻繁變速。

• 追幀速度可配置，保證倍速變化不超過一定輻度。

3.1.2 FLV 2s 低延遲方案在抖音上調(diào)優(yōu)總結(jié)

收益總結(jié)

• FLV 2s 低延遲已在抖音驗(yàn)證收益：核心 QoE 波動(dòng)，電商指標(biāo)顯著正向，成本也有一定比例的節(jié)省，目前已全量。
• 世界杯：雙端 FLV-2s 方案作為世界杯低延遲方案之一，支持了開幕賽到?jīng)Q賽的全部賽事。

調(diào)優(yōu)經(jīng)驗(yàn)總結(jié)

• 無論播放過程中丟幀方式追趕延遲，還是卡頓后立即丟幀追趕延遲，只要是丟幀，QoE 都是負(fù)向。
• iOS 端對(duì)倍速負(fù)向沒有 Android 敏感，對(duì)倍速容忍度高。
• 精細(xì)化倍速追幀策略可以滿足 FLV-2s 的延遲需求，但再進(jìn)一步下探延遲，就需要同時(shí)配合卡頓優(yōu)化方案從源頭避免延遲增加。

3.2 RTM 方案

RTM 的方案參考了 WebRTC，可以讓端到端延遲直接進(jìn)入 1s 以內(nèi)，已經(jīng)持續(xù)在抖音上打磨了一年多，整體來說遇到的困難很大，在推進(jìn)的過程也不斷地發(fā)現(xiàn)了新的問題，也逐漸認(rèn)識(shí)到，直接把 RTC 在視頻會(huì)議上的方案應(yīng)用到直播播放場(chǎng)景的效果并不好，需要做大量的改造才能讓直播的體驗(yàn)得到抖音用戶的認(rèn)可。同時(shí)評(píng)測(cè)的同學(xué)也持續(xù)對(duì)行業(yè)內(nèi)已經(jīng)上線的類似方案進(jìn)行了跟蹤和測(cè)試，經(jīng)過線上測(cè)試后，也發(fā)現(xiàn)現(xiàn)有多方案也存在很多問題, 所以一直也沒有停止自研。RTM 優(yōu)化的目標(biāo)是在延遲降低的情況下，用戶核心體驗(yàn)指標(biāo)對(duì)齊或者優(yōu)于大盤的 FLV 方案。但是由于 FLV 低延遲方案的持續(xù)優(yōu)化并拿到結(jié)果，一定程度上 RTM 的優(yōu)化目標(biāo)的 bar 是在不斷提高的。

每次迭代都要經(jīng)過分析數(shù)據(jù)->找到問題點(diǎn)->提出優(yōu)化方案->完成開發(fā)和測(cè)試->AB 實(shí)驗(yàn)->分析數(shù)據(jù)的反復(fù)循環(huán)，每一次循環(huán)的都需要至少一個(gè)版本甚至多個(gè)版本的周期，所以項(xiàng)目整體耗時(shí)較長(zhǎng)。關(guān)于如何提升實(shí)驗(yàn)的效率，也做了很多思考和探索。最后通過多次的實(shí)驗(yàn)和反復(fù)的問題解決，在核心用戶體驗(yàn)指標(biāo)基本對(duì)齊了 FLV,所以在世界杯的多場(chǎng)比賽中，RTM 方案也承擔(dān)了一定量級(jí)的 CDN 容量，核心鍵指標(biāo)上都對(duì)齊了大盤，穩(wěn)定性和質(zhì)量得到了充分的驗(yàn)證。

3.2.1 RTM 方案優(yōu)化概述

項(xiàng)目啟動(dòng)后，將 RTC 實(shí)時(shí)通信 SDK 直接集成進(jìn)入播放器后首先進(jìn)行線上 AB 測(cè)試，初期的實(shí)驗(yàn)效果顯得大跌眼鏡：除了端到端延遲指標(biāo)符合預(yù)期以外無論是拉流成功率，首屏秒開時(shí)間，卡頓等指標(biāo)均與 FLV 差距很大；所以 RTC 技術(shù)方案要順利部署到直播場(chǎng)景，還需要配合直播播控策略進(jìn)一步優(yōu)化。

為了讓 RTM 的綜合指標(biāo)對(duì)齊 FLV，從若干角度來進(jìn)行 RTM 的播控邏輯定制化，所有的優(yōu)化圍繞著核心用戶體驗(yàn)指標(biāo)進(jìn)行展開：

• DNS 節(jié)點(diǎn)優(yōu)選、SDK 信令預(yù)加載、UDP 連通性預(yù)探測(cè)主要解決的拉流成功率相關(guān)問題。
• SDP 信令相關(guān)優(yōu)化主要解決信令時(shí)間消耗的問題(首幀時(shí)間)與成功率問題。
• RTC 內(nèi)核播控定制化主要解決播放的卡頓問題。
• 播放器播控邏輯結(jié)合解決的音畫同步與渲染策略的問題。

3.2.2 首幀時(shí)間的優(yōu)化

傳統(tǒng)的 RTC 技術(shù)采用 SDP 信令方式進(jìn)行媒體能力協(xié)商，SDP 信令通過如下圖方式進(jìn)行交互參見下圖：

但是 HTTP SDP 信令交互存在如下方案的弊端：弱網(wǎng)環(huán)境下(如 RTT 較大/網(wǎng)絡(luò)信號(hào)不穩(wěn)定)，HTTP 信令建聯(lián)成功率不理想；導(dǎo)致播放請(qǐng)求響應(yīng)緩慢或超時(shí)（基于信令數(shù)據(jù)包龐大且發(fā)生 TCP 重傳導(dǎo)致信令響應(yīng)速度不理想）；另一方面 SDP 交互傳輸 SDP 文本的內(nèi)容很大（通常 3KB~10KB）建聯(lián)的成本較高導(dǎo)致初始化的成本無法忍受；對(duì)比 FLV 的 HTTP 請(qǐng)求完成后直接完成建聯(lián)和媒體數(shù)據(jù)直接傳輸，可以采用新的信令模式：MiniSDP 信令。這是一種基于二進(jìn)制編碼的壓縮協(xié)議，提供對(duì)標(biāo)準(zhǔn) SDP 協(xié)議進(jìn)行壓縮處理；這種方案可以降低信令交互時(shí)間，提高網(wǎng)絡(luò)傳輸效能，降低直播拉流首幀渲染時(shí)間，提高拉流秒開率/成功率等 QoS 統(tǒng)計(jì)指標(biāo)。其作用原理是將原生 SDP 轉(zhuǎn)換成更小的二進(jìn)制格式（300bytes）通過一個(gè) UDP 包（MTU 限制之內(nèi)）完成整個(gè) C/S 交互。

采用 MiniSDP 信令進(jìn)行媒體協(xié)商通信的信令交互流程如下圖所示：采用 MiniSDP 壓縮信令方式利用 UDP 網(wǎng)絡(luò)傳輸；預(yù)期單個(gè) UDP 數(shù)據(jù)包請(qǐng)求即可完成 SDP 完整壓縮信息的傳輸。

當(dāng)前 MiniSDP 信令（UDP）信令上線后觀察后續(xù)的 QoS 指標(biāo)發(fā)現(xiàn)，信令建聯(lián)的成功率和首幀時(shí)間得到了大幅度的優(yōu)化。

3.2.3 拉流成功率的優(yōu)化

經(jīng)過線上的 AB 實(shí)驗(yàn)發(fā)現(xiàn)：RTM 拉流成功率相比 FLV 持續(xù)存在著一定的差距，而且這種差距經(jīng)過觀察得知：用戶的網(wǎng)絡(luò)等級(jí)質(zhì)量和用戶的拉流成功率存在一定的正相關(guān)性（UDP 協(xié)議本身特性），即用戶網(wǎng)絡(luò)質(zhì)量越高成功率越高。

拉流網(wǎng)絡(luò)等級(jí)篩選

• 根據(jù)網(wǎng)絡(luò)質(zhì)量預(yù)估信息綜合評(píng)估用戶的 TCP/UDP RTT 和數(shù)據(jù)下行吞吐率，得出用戶網(wǎng)絡(luò)等級(jí)；選擇網(wǎng)絡(luò)質(zhì)量?jī)?yōu)異的用戶采用 RTM 拉流降低失敗率。
• 當(dāng)線上 AB 實(shí)驗(yàn)采用網(wǎng)絡(luò)等級(jí)漏斗進(jìn)行網(wǎng)絡(luò)篩選以后，選擇用戶網(wǎng)絡(luò)情況相對(duì)較好的這一部分的用戶開啟實(shí)驗(yàn)（這部分用戶占全網(wǎng)用戶的絕大部分，剩余的用戶采用默認(rèn) FLV 低延時(shí)）,原理就是用戶在拉流前綜合權(quán)衡當(dāng)前網(wǎng)絡(luò)狀態(tài)，當(dāng)網(wǎng)絡(luò)不適合 RTM 時(shí)候通過策略前置回落到 FLV，使得這部分用戶的體驗(yàn)不受到影響。

UDP 節(jié)點(diǎn)探測(cè)

• 拉流前根據(jù)用戶請(qǐng)求的 URL 所歸屬的對(duì)應(yīng) CDN 邊緣節(jié)點(diǎn)，發(fā)起 UDP 探測(cè)；一段時(shí)間內(nèi)發(fā)送數(shù)據(jù)包觀察對(duì)應(yīng) CDN 節(jié)點(diǎn)的數(shù)據(jù) RTT 和丟包率，只有滿足一定條件（如 RTT<80ms 且丟包率<10%）的場(chǎng)景才會(huì)認(rèn)為 UDP 傳輸可以保證質(zhì)量和組幀成功率。

信令預(yù)加載

• 在當(dāng)前點(diǎn)播/直播房間中，預(yù)先加載后一個(gè)直播間的信令信息，提前做好 SDP 加載，降低下一個(gè)房間的首幀上屏?xí)r間。

3.2.4 卡頓的優(yōu)化

內(nèi)核 JitterBuffer 禁用丟幀優(yōu)化

• 未調(diào)優(yōu)時(shí)候經(jīng)過 AB 實(shí)驗(yàn)發(fā)現(xiàn)，RTM 的視頻卡頓大幅度上漲，跟預(yù)期不匹配，對(duì)此團(tuán)隊(duì)分析了線上的大量日志數(shù)據(jù)觀察。當(dāng)前的硬解具有核心用戶體驗(yàn)指標(biāo)的收益，但卡頓是 FLV 的將近 3 倍,分析了大量線上 badcase，發(fā)現(xiàn)部分機(jī)型網(wǎng)絡(luò)條件較好，但幀率卻極低，類似下表這種：



• 
  
• 這種問題在部分高熱機(jī)型上的比例也是很高的，但同樣的機(jī)型，F(xiàn)LV 播放并無這樣的問題，通過對(duì)比 FLV 和 RTM 的播控策略，發(fā)現(xiàn)了一個(gè)關(guān)鍵不同點(diǎn):

• 傳統(tǒng)的 RTC 場(chǎng)景優(yōu)先保時(shí)延，全鏈路會(huì)觸發(fā)各種丟幀（包括但不限于解碼模塊，網(wǎng)絡(luò)模塊），F(xiàn)LV 直播場(chǎng)景會(huì)優(yōu)先保證觀播體驗(yàn)（不丟幀，良好的音畫同步效果）。RTM 要想減少卡頓，取得 QoE 的收益，播控策略需進(jìn)行定制化，不影響連麥場(chǎng)景下的邏輯，內(nèi)部采用新的播控策略，最后上線后卡頓顯著減少。

RTC 內(nèi)核 JitterBuffer 平滑出幀優(yōu)化

3.2.5 播控邏輯的優(yōu)化

RTM 網(wǎng)絡(luò)傳輸 SDK 的抽象：將內(nèi)核進(jìn)行改造，復(fù)用引擎中的網(wǎng)絡(luò)傳輸-組包-JitterBuffer/NetEQ 模塊；去掉解碼/渲染等模塊；將音視頻的裸數(shù)據(jù)拋出供播放器 demuxer 集成。

解碼器復(fù)用：降低解碼器重新初始化的時(shí)間，降低解碼首幀延時(shí)；復(fù)用解碼器-渲染器的播放緩沖區(qū)控速邏輯。

音畫同步的優(yōu)化：RTC 音視頻出幀之后在播放器側(cè)按照 FLV 的播控邏輯進(jìn)行二次音畫同步處理；按照 audio master clock 主時(shí)鐘進(jìn)行渲染校準(zhǔn)，視頻幀渲染同步到音頻時(shí)間軸上。

3.2.6 RTM 針對(duì)世界杯的優(yōu)化

本次世界杯超高清檔位的分辨率達(dá)到了 4K，對(duì) RTM 方案的性能帶來了很大的挑戰(zhàn)，在前期測(cè)試時(shí)也發(fā)現(xiàn)了一些低分辨率沒有的問題。當(dāng)時(shí)時(shí)間非常緊，不過在正式比賽之前，還是完成了這些問題的修復(fù)，趕上了最后一班車。主要的問題和解決方案如下：

• 4K 高清檔位卡頓嚴(yán)重卡頓: 優(yōu)化 NACK 策略，保證更大的幀的組幀成功率。
• CPU/GPU 內(nèi)存: 優(yōu)化 video 傳輸 pipeline，減少不必要的 raw 數(shù)據(jù)格式轉(zhuǎn)換。

最終在性能和效果都通過了測(cè)試，RTM 在世界杯期間也順利上線，承擔(dān)了一定的流量，上線后穩(wěn)定性和質(zhì)量都符合預(yù)期。

3.3 世界杯中抖音和其它產(chǎn)品平均的延遲對(duì)比

在實(shí)際的世界杯比賽中，抖音的延遲一直領(lǐng)先于相同信號(hào)源的其它產(chǎn)品 30s 左右。即使最后兩場(chǎng)其它產(chǎn)品在個(gè)別直播間上了快速追趕策略比抖音快 0~1s，但追的速度過快且持續(xù)時(shí)間超過 15s+，有明顯感知，體驗(yàn)相對(duì)較差，這種策略在抖音上也曾經(jīng)做過 AB 實(shí)驗(yàn) ，播放時(shí)長(zhǎng)是顯著負(fù)向的，所以最后并沒有跟進(jìn)。

4. 未來的優(yōu)化方向

未來在高清、沉浸、互動(dòng)的直播場(chǎng)景中，針對(duì)高碼率、低延遲的需求，火山引擎視頻云會(huì)繼續(xù)打磨現(xiàn)有的適合不同場(chǎng)景的各種低延遲的方案，同時(shí)也會(huì)不斷地探索新的方案，在延遲、成本、卡頓和其它播放體驗(yàn)上找到適合不同場(chǎng)景的最佳或者最平衡的方案。

在我看來，火山引擎視頻云的最大的優(yōu)勢(shì)，在于可以把先進(jìn)的技術(shù)放到真實(shí)的海量用戶的場(chǎng)景去做線上訓(xùn)練，通過不斷地總結(jié)失敗的教訓(xùn)和成功的經(jīng)驗(yàn)，對(duì)用戶體驗(yàn)有更深更細(xì)微的理解。下面簡(jiǎn)單介紹一下火山引擎視頻云在各個(gè)方案上繼續(xù)努力的方向。

4.1 FLV

• 追幀策略實(shí)現(xiàn)更細(xì)粒度的追幀，做到“按需追幀”，避免不必要的追幀，引起 QoE 的負(fù)向。
• 挖掘合適的傳輸框架，建立與邊緣云節(jié)點(diǎn)(發(fā)送端)交互的通道，實(shí)現(xiàn)云端聯(lián)動(dòng)的擁塞控制算法，優(yōu)化卡頓，避免延遲增加。
• 目前大盤的平均延遲已經(jīng)有了相當(dāng)程度的降低，但有一小部分長(zhǎng)尾用戶的延遲是很大的，后期的優(yōu)化方向也會(huì)適當(dāng)?shù)貍?cè)重到這部分長(zhǎng)尾用戶，讓更多的長(zhǎng)尾用戶能享受到真正的低延遲，降低觀看同一直播流的觀眾間延遲差，滿足基于流內(nèi)容的一些強(qiáng)互動(dòng)玩法，比如倒計(jì)時(shí)跨年。
• FLV 低延遲協(xié)議標(biāo)準(zhǔn)化：沉淀適用不同直播場(chǎng)景(電商、賽事、游戲、演唱會(huì)等)、不同網(wǎng)絡(luò)環(huán)境、可一鍵部署的套餐方案。

4.2 RTM

在 RTM 方案上，火山引擎視頻云還在不斷地發(fā)掘優(yōu)化點(diǎn)。以下幾點(diǎn)是未來會(huì)繼續(xù)探索的幾個(gè)方向：

拉流成功率的持續(xù)改進(jìn)

• 從 SDK 技術(shù)層面共性差異看，RTM 協(xié)議中的 RTP 包組首幀存在成功率短板，后續(xù)的成功率優(yōu)化需要從引擎的調(diào)優(yōu)持續(xù)探索。

RTP 擴(kuò)展特性的持續(xù)迭代

• 降低首幀時(shí)間縮小和 FLV 的差距：RTM 異步回源的深入探索，目前只有一家 CDN 支持，需要推廣至其它 CDN。
• 進(jìn)一步探索提升 RTM 的拉流成功率（針對(duì)用戶網(wǎng)絡(luò)不佳的場(chǎng)景）：探測(cè) ICE 多模式啟播能力對(duì)成功率的提升，明確各家 CDN 支持 RTM 啟播 TCP/UDP 及混合模式的能力。

RTM 是降低延遲的一種全新方案，為了把在海量用戶的業(yè)務(wù)上積累的經(jīng)驗(yàn)和教訓(xùn)反饋給整個(gè)業(yè)界，火山引擎視頻云也聯(lián)合騰訊和阿里發(fā)起了 RTM 行業(yè)標(biāo)準(zhǔn)的制訂，具體可以參考 https://www.volcengine.com/docs/6469/103014，未來也會(huì)把標(biāo)準(zhǔn)推廣到更多的 CDN，不斷完善的同時(shí)，和業(yè)界一起向更低延遲演進(jìn)。對(duì) RTM 方案感興趣的，可以點(diǎn)擊閱讀原文，進(jìn)入火山引擎視頻云官網(wǎng)了解細(xì)節(jié)和進(jìn)一步試用。

4.3 切片類協(xié)議的延遲優(yōu)化

海外的 CDN 基本都只支持切片式的協(xié)議如 HLS/Dash 等，不支持 FLV 這類“過時(shí)”的傳輸協(xié)議。但 HLS/Dash 因?yàn)榍衅拇嬖?，而且為了保證視頻的壓縮率，切片一般都是秒級(jí)的，且需要切片完全生成才能分發(fā)該分片，并且需要至少兩三個(gè)分片都生成完才能分發(fā)，所以和流式的協(xié)議相比，延遲上天然有一些劣勢(shì)。其實(shí)這也是競(jìng)品使用的方式，如下圖，每個(gè)分片 6s，在三個(gè)分片生成完后才可以分發(fā)，帶來了 23s 的延遲。世界杯期間，在視頻同源的情況下，其它產(chǎn)品的延遲顯著高于 抖音 ，就是因?yàn)槭褂昧祟愃频?HLS 的切片傳輸方案。

但隨著 Akamai 和 Apple 分別提出了 CMAF 和 LL-HLS，引入了 fmp4 和 chunk 的概念，可以實(shí)現(xiàn)分片沒有完全生成的時(shí)候就開始分發(fā)分片的部分 chunk，延遲下限有了很大程度的下降。如下圖，延遲可以降到 1s。

火山引擎視頻云在 Apple 提出 LL-HLS 之前就跟進(jìn)了 CMAF，在 CMAF 的延遲和卡頓、拉流成功率上的優(yōu)化上也持續(xù)有不小的投入?，F(xiàn)在回顧 CMAF 的優(yōu)化的過程，可以發(fā)現(xiàn)其實(shí)要解決的問題和 RTM 有很大的相似性，比如 CMAF 也存在拉流成功率、音畫同步、性能問題，優(yōu)化前在核心 體驗(yàn)指標(biāo) 上同樣顯著差于 FLV。

與 FLV 的流式傳輸不同，CMAF 需要依賴用戶不斷發(fā)起各個(gè)分片的請(qǐng)求來獲取音視頻數(shù)據(jù)，如果繼續(xù)采用 FLV 的請(qǐng)求模式，即建連->請(qǐng)求->響應(yīng)->斷開連接，會(huì)引入大量的建連耗時(shí)，造成卡頓，同時(shí)導(dǎo)致延遲的增大。做一個(gè)簡(jiǎn)單的計(jì)算，假設(shè)每個(gè)切片是 2s，那么平均 1s 就會(huì)有一次音頻或視頻請(qǐng)求的建連，這對(duì)于網(wǎng)絡(luò)較差，尤其是高 RTT 的用戶來說是不可接受的，如果此時(shí)為了低延遲強(qiáng)行降低 buffer 水位，建連時(shí)的緩存消耗將導(dǎo)致頻繁的卡頓。

為此，可以在 CMAF 上采用 QUIC 協(xié)議與連接復(fù)用結(jié)合的方式，首先 QUIC 協(xié)議的 0-RTT 建連允許客戶端在服務(wù)端確認(rèn)握手成功之前就發(fā)出 HTTP 請(qǐng)求，而連接復(fù)用直接省去了后續(xù)請(qǐng)求的建連操作，大幅優(yōu)化了建連耗時(shí)，維持延遲的穩(wěn)定。但即使如此，每個(gè)分片的請(qǐng)求也會(huì)引入 1-RTT 的延遲，未來將與服務(wù)端一起探索預(yù)請(qǐng)求模式，進(jìn)一步壓縮延遲、降低卡頓。

CMAF 優(yōu)化的整體難度較大，團(tuán)隊(duì)同學(xué)也經(jīng)常需要在半夜和海外的 CDN 的工程師對(duì)齊和解決問題。不過經(jīng)過不斷的努力，最近在部分地區(qū)的也已經(jīng)有了階段性的進(jìn)展，在部分場(chǎng)景下核心指標(biāo)已經(jīng)對(duì)齊 FLV，團(tuán)隊(duì)也有信心在最近一段時(shí)間就能去掉機(jī)型和網(wǎng)絡(luò)類型的限制，讓 CMAF 可以承載更多常規(guī)比例的流量。

4.4 XR 直播的延遲優(yōu)化

XR 直播的沉浸感以及高交互性是普通直播無法比擬的，但是這也導(dǎo)致了傳輸層需要承擔(dān)更大的壓力：分辨率為 8K x 4K 或 8K x 8K, 源流碼率達(dá)到 50M 甚至120M、非常容易因?yàn)閾砣麑?dǎo)致卡頓、延遲增大，甚至無法正常解碼播放?；鹕揭嬉曨l云的做法是將 8K 的視頻切分成多個(gè)塊(tile)，只傳輸用戶視角(viewport)內(nèi)的部分超高清塊，其它區(qū)域只傳輸 2K 或 4K 分辨率的縮小后的背景流，在用戶切換視角的時(shí)候再去重新請(qǐng)求新的超高清塊。當(dāng)然這里需要把切換延遲盡可能降到更低，經(jīng)過長(zhǎng)時(shí)間的優(yōu)化，切換延遲已經(jīng)降低到非常低，一般情況下已經(jīng)感受不到切換的過程，未來會(huì)持續(xù)優(yōu)化，讓切換延遲更低。

這兩種做法都引入了優(yōu)先級(jí)的概念，即用戶視角內(nèi)的數(shù)據(jù)優(yōu)先級(jí)高于其他部分，低清數(shù)據(jù)優(yōu)先級(jí)高于高清數(shù)據(jù)?；谶@種特性，火山引擎視頻云將探索基于 UDP 的內(nèi)容優(yōu)先級(jí)感知的傳輸方案，優(yōu)先保障高優(yōu)數(shù)據(jù)的傳輸，對(duì)于低優(yōu)數(shù)據(jù)可選擇非可靠傳輸，即使丟失也無需重傳，保證 XR 直播低延遲的同時(shí)不引入過大的視覺失真。經(jīng)過優(yōu)化后，在傳輸 8K x 8K/8K x 4K 的超高清視頻時(shí)對(duì)播放端的碼率要求從 120M/50M 降低到 20M/10M 左右甚至更低，在用戶側(cè)極大地減少了卡頓發(fā)生的概率，從而也減少了延遲增大的概率。未來火山引擎視頻云也會(huì)持續(xù)優(yōu)化 XR 直播下在更高碼率更高分辨率下的卡頓和延遲，為用戶提供更沉浸的觀看體驗(yàn)。