作者 | 火山引擎直播團(tuán)隊(duì)
策劃 | 魯冬雪
世界杯已經(jīng)結(jié)束了，梅西帶領(lǐng)阿根廷時(shí)隔三十六年之后終于如愿捧杯。抖音直播提供的 4K 超高清超低延遲看播能力給億萬(wàn)觀眾留下了深刻的印象，決賽的 PCU 達(dá)到 3700w+，在這樣大規(guī)模并發(fā)下，如何能穩(wěn)定流暢地做到更低的延遲，是一個(gè)巨大的挑戰(zhàn)。本文主要介紹世界杯期間火山引擎視頻云和相關(guān)團(tuán)隊(duì)在低延遲上的工作和優(yōu)化，作為低延遲方向上的總結(jié)。
(相關(guān)資料圖)
本文主要討論生產(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)化的過(guò)程中，一個(gè)越來(lái)越清晰的認(rèn)知是：降低延遲并不困難，難的是延遲降低之后，怎么通過(guò)優(yōu)化保證播放體驗(yàn)不下降甚至變得更好。
一、背景信息
首先簡(jiǎn)單介紹下世界杯直播的整個(gè)分發(fā)鏈路，還有每個(gè)環(huán)節(jié)的延遲的測(cè)量方法，讓大家對(duì)整體的鏈路有初步的全局認(rèn)識(shí)。
（一）抖音世界杯信號(hào)分發(fā)鏈路
（二）全鏈路延遲測(cè)量以及方法
測(cè)算方法：
拍照 視頻畫(huà)面上有時(shí)鐘展示的(比如畫(huà)面左上角或者右上角的
北京時(shí)間或者比賽持續(xù)時(shí)間 ，一般精確到秒)，可以通過(guò)同時(shí)拍照兩個(gè)播放畫(huà)面的方式，記錄同一時(shí)刻兩個(gè)畫(huà)面，然后通過(guò)照片中的時(shí)鐘
做差來(lái)計(jì)算。 手動(dòng)秒表計(jì)算 如果視頻畫(huà)面中無(wú)時(shí)鐘相關(guān)內(nèi)容，那么可以從延遲低的視頻畫(huà)面中選取
具有標(biāo)志性易識(shí)別 的幀啟動(dòng)秒表，然后觀察延遲高的畫(huà)面出現(xiàn)同樣的幀畫(huà)面時(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è)：
二、生產(chǎn)環(huán)節(jié)的低延遲
（一）信號(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é)在溝通。
（二）演播室制作環(huán)節(jié)
演播室在收到央視的源流之后，需要加上解說(shuō)和包裝，所以也會(huì)引入一定的延遲。這次抖音的多個(gè)演播室是由多家第三方公司負(fù)責(zé)的，第三方公司的制作規(guī)格不一，在正式比賽之前經(jīng)過(guò)大量的溝通，基本確認(rèn)最重要的兩個(gè)演播室的技術(shù)方案和使用的編碼系統(tǒng)是一致的。
不過(guò)這次在演播室環(huán)節(jié)引入的延遲仍然偏高，達(dá)到了 1.5s 左右，和供應(yīng)商工程師溝通后，短期內(nèi)為了保證穩(wěn)定，沒(méi)有再進(jìn)一步壓縮了，這部分引入的延遲和競(jìng)品也是一致的。
三、傳輸環(huán)節(jié)的低延遲
下圖是一次直播的簡(jiǎn)化的流程：
直播的傳輸環(huán)節(jié)里，對(duì)延遲影響大的主要是轉(zhuǎn)碼、分發(fā)和播放緩沖，使用實(shí)時(shí)的轉(zhuǎn)碼模式，轉(zhuǎn)碼器引入的延遲一般在 300ms 以?xún)?nèi)甚至更短。CDN 的分發(fā)環(huán)節(jié)也會(huì)帶來(lái)一定的延遲，但相對(duì)也較短。為了對(duì)抗網(wǎng)絡(luò)抖動(dòng)引入的播放緩沖區(qū)引入的延遲播放緩沖引入的延遲常常會(huì)有 5s 甚至更多，所以本文主要討論 怎么在減少播放緩沖的情況下，通過(guò)不斷地優(yōu)化延遲降低的同時(shí)不影響整體的播放體驗(yàn)(不僅僅是卡頓) 。在調(diào)優(yōu)過(guò)程中，大家對(duì)播放體驗(yàn)也有了更細(xì)致、更深的理解，逐漸弄清楚了哪些 QoS 指標(biāo)可以對(duì)關(guān)鍵的 QoE 指標(biāo)產(chǎn)生直接的影響，對(duì)以后要優(yōu)化的方向也更明確了。
（一）FLV 方案
FLV 是現(xiàn)在國(guó)內(nèi)主流直播播放使用的協(xié)議，火山引擎對(duì)低延遲直播的探索也是從 FLV 開(kāi)始的。在百萬(wàn)英雄、內(nèi)購(gòu)會(huì)等活動(dòng)中，F(xiàn)LV 低延遲方案也多次得到了驗(yàn)證。
之前詳細(xì)介紹過(guò) FLV-3s 方案在抖音落地的詳細(xì)實(shí)踐過(guò)程(細(xì)節(jié)內(nèi)容可跳轉(zhuǎn)到 基于 http-FLV 的抖音直播端到端延遲優(yōu)化實(shí)踐 ），同時(shí)提出過(guò)基于 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ì)越來(lái)越大。而世界杯賽事延遲要求達(dá)到 2s，繼續(xù)延續(xù) FLV-3s 方案顯然達(dá)不到要求，需要配合精細(xì)的追幀或者丟幀策略。
1、基于 buffer & 卡頓信息的雙閾值延遲追趕策略
音視頻數(shù)據(jù)流轉(zhuǎn)時(shí)序
在展開(kāi)描述延遲追趕策略方案細(xì)節(jié)前，先簡(jiǎn)單介紹播放器音視頻數(shù)據(jù)流轉(zhuǎn)時(shí)序：網(wǎng)絡(luò) IO 下載音視頻數(shù)據(jù)到播放器緩存 buffer->解碼器從 buffer 中取數(shù)據(jù)解碼并降解碼后的數(shù)據(jù)存入待播放緩存->音畫(huà)同步等播控策略->渲染播放音視頻幀。
數(shù)據(jù)驅(qū)動(dòng) QoE & QoS 優(yōu)化
由于進(jìn)一步下探延遲，卡頓也會(huì)隨之惡化，反而延遲逐漸累積增加達(dá)不到低延遲的效果，因此延遲下探必須配合延遲追趕播控策略來(lái)確保延遲增大后可及時(shí)追趕恢復(fù)到低延遲。是否只要在延遲增加后立即倍速追趕就能滿(mǎn)足業(yè)務(wù)的需求呢？對(duì)于延遲 QoS 指標(biāo)來(lái)說(shuō)的確是，但對(duì)于用戶(hù)主觀體驗(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)象：
倍速追趕帶來(lái)的播放速度變化本身就是負(fù)面的體驗(yàn) 倍速時(shí)長(zhǎng)超過(guò) 2 秒，用戶(hù)即可有感知且負(fù)向反饋 倍速速度越大，播放速度前后變化 diff 越大，負(fù)向越嚴(yán)重 倍速與正常速度的切換過(guò)于頻繁，會(huì)帶來(lái)負(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)方差 & 歷史卡頓信息，來(lái)定性衡量網(wǎng)絡(luò)質(zhì)量，判斷是否可以追趕，只有在網(wǎng)絡(luò)質(zhì)量良好是才能觸發(fā)追趕邏輯避免卡頓。 追幀采用雙閾值，并且支持可配置，可以控制追幀持續(xù)時(shí)長(zhǎng)不超過(guò) 2s，同時(shí)也可以保證不頻繁變速。 追幀速度可配置，保證倍速變化不超過(guò)一定輻度。
2、FLV 2s 低延遲方案在抖音上調(diào)優(yōu)總結(jié)
（1）收益總結(jié)
FLV 2s 低延遲已在抖音驗(yàn)證收益：核心 QoE 波動(dòng)，電商指標(biāo)顯著正向，成本也有一定比例的節(jié)省，目前已全量。 世界杯：雙端 FLV-2s 方案作為世界杯低延遲方案之一，支持了開(kāi)幕賽到?jīng)Q賽的全部賽事。
（2）調(diào)優(yōu)經(jīng)驗(yàn)總結(jié)
無(wú)論播放過(guò)程中丟幀方式追趕延遲，還是卡頓后立即丟幀追趕延遲，只要是丟幀，QoE 都是負(fù)向。 iOS 端對(duì)倍速負(fù)向沒(méi)有 Android 敏感，對(duì)倍速容忍度高。 精細(xì)化倍速追幀策略可以滿(mǎn)足 FLV-2s 的延遲需求，但再進(jìn)一步下探延遲，就需要同時(shí)配合
卡頓優(yōu)化方案從源頭避免延遲增加。 （二） RTM 方案
RTM 的方案參考了 WebRTC，可以讓端到端延遲直接進(jìn)入 1s 以?xún)?nèi)，已經(jīng)持續(xù)在抖音上打磨了一年多，整體來(lái)說(shuō)遇到的困難很大，在推進(jìn)的過(guò)程也不斷地發(fā)現(xiàn)了新的問(wèn)題，也逐漸認(rèn)識(shí)到， 直接把 RTC 在視頻會(huì)議上的方案應(yīng)用到直播播放場(chǎng)景的效果并不好，需要做大量的改造才能讓直播的體驗(yàn)得到抖音用戶(hù)的認(rèn)可 。同時(shí)評(píng)測(cè)的同學(xué)也持續(xù)對(duì)行業(yè)內(nèi)已經(jīng)上線的類(lèi)似方案進(jìn)行了跟蹤和測(cè)試，經(jīng)過(guò)線上測(cè)試后，也發(fā)現(xiàn)現(xiàn)有多方案也存在很多問(wèn)題, 所以一直也沒(méi)有停止自研。RTM 優(yōu)化的目標(biāo)是在延遲降低的情況下，用戶(hù)核心體驗(yàn)指標(biāo)對(duì)齊或者優(yōu)于大盤(pán)的 FLV 方案。但是由于 FLV 低延遲方案的持續(xù)優(yōu)化并拿到結(jié)果，一定程度上 RTM 的優(yōu)化目標(biāo)的 bar 是在不斷提高的 。
每次迭代都要經(jīng)過(guò)分析數(shù)據(jù)->找到問(wèn)題點(diǎn)->提出優(yōu)化方案->完成開(kāi)發(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)的效率，也做了很多思考和探索。最后通過(guò)多次的實(shí)驗(yàn)和反復(fù)的問(wèn)題解決，在核心用戶(hù)體驗(yàn)指標(biāo)基本對(duì)齊了 FLV,所以在世界杯的多場(chǎng)比賽中，RTM 方案也承擔(dān)了一定量級(jí)的 CDN 容量，核心鍵指標(biāo)上都對(duì)齊了大盤(pán)，穩(wěn)定性和質(zhì)量得到了充分的驗(yàn)證。
1、RTM 方案優(yōu)化概述
項(xiàng)目啟動(dòng)后，將 RTC 實(shí)時(shí)通信 SDK 直接集成進(jìn)入播放器后首先進(jìn)行線上 AB 測(cè)試，初期的實(shí)驗(yàn)效果顯得大跌眼鏡： 除了端到端延遲指標(biāo)符合預(yù)期以外無(wú)論是拉流成功率，首屏秒開(kāi)時(shí)間，卡頓等指標(biāo)均與 FLV 差距很大 ；所以 RTC 技術(shù)方案要順利部署到直播場(chǎng)景，還需要配合直播播控策略進(jìn)一步優(yōu)化。
為了讓 RTM 的綜合指標(biāo)對(duì)齊 FLV，從若干角度來(lái)進(jìn)行 RTM 的播控邏輯定制化，所有的優(yōu)化圍繞著核心用戶(hù)體驗(yàn)指標(biāo)進(jìn)行展開(kāi)：
DNS 節(jié)點(diǎn)優(yōu)選、SDK 信令預(yù)加載、UDP 連通性預(yù)探測(cè)主要解決的拉流成功率相關(guān)問(wèn)題。 SDP 信令相關(guān)優(yōu)化主要解決信令時(shí)間消耗的問(wèn)題(首幀時(shí)間)與成功率問(wèn)題。 RTC 內(nèi)核播控定制化主要解決播放的卡頓問(wèn)題。 播放器播控邏輯結(jié)合解決的音畫(huà)同步與渲染策略的問(wèn)題。
2、首幀時(shí)間的優(yōu)化
傳統(tǒng)的 RTC 技術(shù)采用 SDP 信令方式進(jìn)行媒體能力協(xié)商，SDP 信令通過(guò)如下圖方式進(jìn)行交互參見(jià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)致初始化的成本無(wú)法忍受；對(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í)間，提高拉流秒開(kāi)率/成功率等 QoS 統(tǒng)計(jì)指標(biāo)。其作用原理是將原生 SDP 轉(zhuǎn)換成更小的二進(jìn)制格式（300bytes）通過(guò)一個(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、拉流成功率的優(yōu)化
經(jīng)過(guò)線上的 AB 實(shí)驗(yàn)發(fā)現(xiàn)：RTM 拉流成功率相比 FLV 持續(xù)存在著一定的差距，而且這種差距經(jīng)過(guò)觀察得知：用戶(hù)的網(wǎng)絡(luò)等級(jí)質(zhì)量和用戶(hù)的拉流成功率存在一定的正相關(guān)性（UDP 協(xié)議本身特性），即用戶(hù)網(wǎng)絡(luò)質(zhì)量越高成功率越高。
拉流網(wǎng)絡(luò)等級(jí)篩選
根據(jù)網(wǎng)絡(luò)質(zhì)量預(yù)估信息綜合評(píng)估用戶(hù)的 TCP/UDP RTT 和數(shù)據(jù)下行吞吐率，得出用戶(hù)網(wǎng)絡(luò)等級(jí)；選擇網(wǎng)絡(luò)質(zhì)量?jī)?yōu)異的用戶(hù)采用 RTM 拉流降低失敗率。
當(dāng)線上 AB 實(shí)驗(yàn)采用網(wǎng)絡(luò)等級(jí)漏斗進(jìn)行網(wǎng)絡(luò)篩選以后，選擇用戶(hù)網(wǎng)絡(luò)情況相對(duì)較好的這一部分的用戶(hù)開(kāi)啟實(shí)驗(yàn)（這部分用戶(hù)占全網(wǎng)用戶(hù)的絕大部分，剩余的用戶(hù)采用默認(rèn) FLV 低延時(shí)）,原理就是用戶(hù)在拉流前綜合權(quán)衡當(dāng)前網(wǎng)絡(luò)狀態(tài)，當(dāng)網(wǎng)絡(luò)不適合 RTM 時(shí)候通過(guò)策略前置回落到 FLV，使得這部分用戶(hù)的體驗(yàn)不受到影響。
UDP 節(jié)點(diǎn)探測(cè)
拉流前根據(jù)用戶(hù)請(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 和丟包率，只有滿(mǎn)足一定條件（如 RTT<80ms 且丟包率<10%）的場(chǎng)景才會(huì)認(rèn)為 UDP 傳輸可以保證質(zhì)量和組幀成功率。
信令預(yù)加載
在當(dāng)前點(diǎn)播/直播房間中，預(yù)先加載后一個(gè)直播間的信令信息，提前做好 SDP 加載，降低下一個(gè)房間的首幀上屏?xí)r間。
4、卡頓的優(yōu)化
內(nèi)核 JitterBuffer 禁用丟幀優(yōu)化
未調(diào)優(yōu)時(shí)候經(jīng)過(guò) AB 實(shí)驗(yàn)發(fā)現(xiàn)，RTM 的視頻卡頓大幅度上漲，跟預(yù)期不匹配，對(duì)此團(tuán)隊(duì)分析了線上的大量日志數(shù)據(jù)觀察。當(dāng)前的硬解具有核心用戶(hù)體驗(yàn)指標(biāo)的收益，但卡頓是 FLV 的將近 3 倍,分析了大量線上 badcase，發(fā)現(xiàn)部分機(jī)型網(wǎng)絡(luò)條件較好，但幀率卻極低，類(lèi)似下表這種：
這種問(wèn)題在部分高熱機(jī)型上的比例也是很高的，但同樣的機(jī)型，F(xiàn)LV 播放并無(wú)這樣的問(wèn)題，通過(guò)對(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)（不丟幀，良好的音畫(huà)同步效果）。RTM 要想減少卡頓，取得 QoE 的收益， 播控策略需進(jìn)行定制化， 不影響連麥場(chǎng)景下的邏輯，內(nèi)部采用新的播控策略，最后上線后卡頓顯著減少。
RTC 內(nèi)核 JitterBuffer 平滑出幀優(yōu)化
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ū)控速邏輯。
音畫(huà)同步的優(yōu)化：RTC 音視頻出幀之后在播放器側(cè)按照 FLV 的播控邏輯進(jìn)行二次音畫(huà)同步處理；按照 audio master clock 主時(shí)鐘進(jìn)行渲染校準(zhǔn)，視頻幀渲染同步到音頻時(shí)間軸上。
6、RTM 針對(duì)世界杯的優(yōu)化
本次世界杯超高清檔位的分辨率達(dá)到了 4K，對(duì) RTM 方案的性能帶來(lái)了很大的挑戰(zhàn)，在前期測(cè)試時(shí)也發(fā)現(xiàn)了一些低分辨率沒(méi)有的問(wèn)題。當(dāng)時(shí)時(shí)間非常緊，不過(guò)在正式比賽之前，還是完成了這些問(wèn)題的修復(fù)，趕上了最后一班車(chē)。主要的問(wèn)題和解決方案如下：
4K 高清檔位卡頓嚴(yán)重卡頓: 優(yōu)化 NACK 策略，保證更大的幀的組幀成功率。 CPU/GPU 內(nèi)存: 優(yōu)化 video 傳輸 pipeline，減少不必要的 raw 數(shù)據(jù)格式轉(zhuǎn)換。
最終在性能和效果都通過(guò)了測(cè)試，RTM 在世界杯期間也順利上線，承擔(dān)了一定的流量，上線后穩(wěn)定性和質(zhì)量都符合預(yù)期。
（三）世界杯中抖音和其它產(chǎn)品平均的延遲對(duì)比
在實(shí)際的世界杯比賽中， 抖音的延遲一直領(lǐng)先于相同信號(hào)源的其它產(chǎn)品 30s 左右 。即使最后兩場(chǎng)其它產(chǎn)品在個(gè)別直播間上了快速追趕策略比抖音快 0~1s，但追的速度過(guò)快且持續(xù)時(shí)間超過(guò) 15s+，有明顯感知，體驗(yàn)相對(duì)較差， 這種策略在抖音上也曾經(jīng)做過(guò) AB 實(shí)驗(yàn) ，播放時(shí)長(zhǎng)是顯著負(fù)向的，所以最后并沒(méi)有跟進(jìn)。
四、未來(lái)的優(yōu)化方向
未來(lái)在 高清、沉浸、互動(dòng) 的直播場(chǎng)景中，針對(duì)高碼率、低延遲的需求，火山引擎視頻云會(huì)繼續(xù)打磨現(xiàn)有的適合不同場(chǎng)景的各種低延遲的方案，同時(shí)也會(huì)不斷地探索新的方案，在 延遲、成本、卡頓和其它播放體驗(yàn) 上找到適合不同場(chǎng)景的 最佳或者最平衡 的方案。
在我看來(lái)，火山引擎視頻云的最大的優(yōu)勢(shì)，在于可以把先進(jìn)的技術(shù)放到真實(shí)的海量用戶(hù)的場(chǎng)景去做線上訓(xùn)練，通過(guò)不斷地總結(jié)失敗的教訓(xùn)和成功的經(jīng)驗(yàn)，對(duì)用戶(hù)體驗(yàn)有更深更細(xì)微的理解。下面簡(jiǎn)單介紹一下火山引擎視頻云在各個(gè)方案上繼續(xù)努力的方向。
（一）FLV
追幀策略實(shí)現(xiàn)更細(xì)粒度的追幀，做到“按需追幀”，避免不必要的追幀，引起 QoE 的負(fù)向。 挖掘合適的傳輸框架，建立與邊緣云節(jié)點(diǎn)(發(fā)送端)交互的通道，實(shí)現(xiàn)云端聯(lián)動(dòng)的擁塞控制算法，優(yōu)化卡頓，避免延遲增加。 目前大盤(pán)的平均延遲已經(jīng)有了相當(dāng)程度的降低，但有一小部分長(zhǎng)尾用戶(hù)的延遲是很大的，后期的優(yōu)化方向也會(huì)適當(dāng)?shù)貍?cè)重到這部分長(zhǎng)尾用戶(hù)，讓更多的長(zhǎng)尾用戶(hù)能享受到真正的低延遲，降低觀看同一直播流的觀眾間延遲差，滿(mǎn)足基于流內(nèi)容的一些強(qiáng)互動(dòng)玩法，比如倒計(jì)時(shí)跨年。 FLV 低延遲協(xié)議標(biāo)準(zhǔn)化：沉淀適用不同直播場(chǎng)景(電商、賽事、游戲、演唱會(huì)等)、不同網(wǎng)絡(luò)環(huán)境、可一鍵部署的套餐方案。
（二）RTM
在 RTM 方案上，火山引擎視頻云還在不斷地發(fā)掘優(yōu)化點(diǎn)。以下幾點(diǎn)是未來(lái)會(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ì)用戶(hù)網(wǎng)絡(luò)不佳的場(chǎng)景）：探測(cè) ICE 多模式啟播能力對(duì)成功率的提升，明確各家 CDN 支持 RTM 啟播 TCP/UDP 及混合模式的能力。
RTM 是降低延遲的一種全新方案，為了把在海量用戶(hù)的業(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，未來(lái)也會(huì)把標(biāo)準(zhǔn)推廣到更多的 CDN，不斷完善的同時(shí)，和業(yè)界一起向更低延遲演進(jìn)。
（三）切片類(lèi)協(xié)議的延遲優(yōu)化
海外的 CDN 基本都只支持切片式的協(xié)議如 HLS/Dash 等，不支持 FLV 這類(lèi)“過(guò)時(shí)”的傳輸協(xié)議。但 HLS/Dash 因?yàn)榍衅拇嬖?，而且為了保證視頻的壓縮率，切片一般都是秒級(jí)的，且需要切片完全生成才能分發(fā)該分片，并且需要至少兩三個(gè)分片都生成完才能分發(fā)，所以和流式的協(xié)議相比，延遲上天然有一些劣勢(shì)。其實(shí)這也是競(jìng)品使用的方式，如下圖，每個(gè)分片 6s，在三個(gè)分片生成完后才可以分發(fā)，帶來(lái)了 23s 的延遲。 世界杯期間，在視頻同源的情況下，其它產(chǎn)品的延遲顯著高于 抖音 ，就是因?yàn)槭褂昧祟?lèi)似的 HLS 的切片傳輸方案。
但隨著 Akamai 和 Apple 分別提出了 CMAF 和 LL-HLS，引入了 fmp4 和 chunk 的概念，可以實(shí)現(xiàn)分片沒(méi)有完全生成的時(shí)候就開(kāi)始分發(fā)分片的部分 chunk，延遲下限有了很大程度的下降。如下圖，延遲可以降到 1s。
火山引擎視頻云在 Apple 提出 LL-HLS 之前就跟進(jìn)了 CMAF，在 CMAF 的延遲和卡頓、拉流成功率上的優(yōu)化上也持續(xù)有不小的投入。現(xiàn)在回顧 CMAF 的優(yōu)化的過(guò)程，可以 發(fā)現(xiàn)其實(shí)要解決的問(wèn)題和 RTM 有很大的相似性，比如 CMAF 也存在拉流成功率、音畫(huà)同步、性能問(wèn)題，優(yōu)化前在核心 體驗(yàn)指標(biāo) 上同樣顯著差于 FLV。
與 FLV 的流式傳輸不同，CMAF 需要依賴(lài)用戶(hù)不斷發(fā)起各個(gè)分片的請(qǐng)求來(lái)獲取音視頻數(shù)據(jù)，如果繼續(xù)采用 FLV 的請(qǐng)求模式，即建連->請(qǐng)求->響應(yīng)->斷開(kāi)連接，會(huì)引入大量的建連耗時(shí)，造成卡頓，同時(shí)導(dǎo)致延遲的增大。做一個(gè)簡(jiǎn)單的計(jì)算，假設(shè)每個(gè)切片是 2s，那么平均 1s 就會(huì)有一次音頻或視頻請(qǐng)求的建連，這對(duì)于網(wǎng)絡(luò)較差，尤其是高 RTT 的用戶(hù)來(lái)說(shuō)是不可接受的，如果此時(shí)為了低延遲強(qiáng)行降低 buffer 水位，建連時(shí)的緩存消耗將導(dǎo)致頻繁的卡頓。
為此，可以在 CMAF 上采用 QUIC 協(xié)議與連接復(fù)用結(jié)合的方式，首先 QUIC 協(xié)議的 0-RTT 建連允許客戶(hù)端在服務(wù)端確認(rèn)握手成功之前就發(fā)出 HTTP 請(qǐng)求，而連接復(fù)用直接省去了后續(xù)請(qǐng)求的建連操作，大幅優(yōu)化了建連耗時(shí)，維持延遲的穩(wěn)定。但即使如此，每個(gè)分片的請(qǐng)求也會(huì)引入 1-RTT 的延遲，未來(lái)將與服務(wù)端一起探索預(yù)請(qǐng)求模式，進(jìn)一步壓縮延遲、降低卡頓。
CMAF 優(yōu)化的整體難度較大，團(tuán)隊(duì)同學(xué)也經(jīng)常需要在半夜和海外的 CDN 的工程師對(duì)齊和解決問(wèn)題。不過(guò)經(jīng)過(guò)不斷的努力，最近在部分地區(qū)的也已經(jīng)有了階段性的進(jìn)展，在部分場(chǎng)景下核心指標(biāo)已經(jīng)對(duì)齊 FLV，團(tuán)隊(duì)也有信心在最近一段時(shí)間就能去掉機(jī)型和網(wǎng)絡(luò)類(lèi)型的限制，讓 CMAF 可以承載更多常規(guī)比例的流量。
（四）XR 直播的延遲優(yōu)化
XR 直播的沉浸感以及高交互性是普通直播無(wú)法比擬的，但是這也導(dǎo)致了傳輸層需要承擔(dān)更大的壓力： 分辨率為 8K x 4K 或 8K x 8K, 源流碼率達(dá)到 50M 甚至 120M、非常容易因?yàn)閾砣麑?dǎo)致卡頓、延遲增大，甚至無(wú)法正常解碼播放 ?；鹕揭嬉曨l云的做法是將 8K 的視頻切分成多個(gè)塊(tile)，只傳輸用戶(hù)視角(viewport)內(nèi)的部分超高清塊，其它區(qū)域只傳輸 2K 或 4K 分辨率的縮小后的背景流，在用戶(hù)切換視角的時(shí)候再去重新請(qǐng)求新的超高清塊。當(dāng)然這里需要把切換延遲盡可能降到更低，經(jīng)過(guò)長(zhǎng)時(shí)間的優(yōu)化，切換延遲已經(jīng)降低到非常低，一般情況下已經(jīng)感受不到切換的過(guò)程，未來(lái)會(huì)持續(xù)優(yōu)化，讓切換延遲更低。
這兩種做法都引入了優(yōu)先級(jí)的概念，即用戶(hù)視角內(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ù)可選擇非可靠傳輸，即使丟失也無(wú)需重傳，保證 XR 直播低延遲的同時(shí)不引入過(guò)大的視覺(jué)失真。經(jīng)過(guò)優(yōu)化后，在傳輸 8K x 8K/8K x 4K 的超高清視頻時(shí) 對(duì)播放端的碼率要求從 120M/50M 降低到 20M/10M 左右甚至更低 ，在用戶(hù)側(cè)極大地減少了卡頓發(fā)生的概率，從而也減少了延遲增大的概率。
未來(lái)火山引擎視頻云也會(huì)持續(xù)優(yōu)化 XR 直播下在更高碼率更高分辨率下的卡頓和延遲，為用戶(hù)提供更沉浸的觀看體驗(yàn)。
