作者 | 火山引擎直播團隊

策劃 | 魯冬雪

世界杯已經結束了，梅西帶領阿根廷時隔三十六年之后終于如愿捧杯。抖音直播提供的 4K 超高清超低延遲看播能力給億萬觀眾留下了深刻的印象，決賽的 PCU 達到 3700w+，在這樣大規模并發下，如何能穩定流暢地做到更低的延遲，是一個巨大的挑戰。本文主要介紹世界杯期間火山引擎視頻云和相關團隊在低延遲上的工作和優化，作為低延遲方向上的總結。

(相關資料圖)

本文主要討論生產和傳輸環節的延遲。生產環節的延遲主要受視頻流供應商控制，技術團隊可以實現的是，盡可能準確地測量出生產的每一個環節的實際延遲，并在發現不合理的情況時推動供應商解決。傳輸環節的延遲技術團隊更可控，也是本次優化的重點。這部分技術能力可以作為火山引擎視頻云的優勢能力積累并對外提供服務。在優化的過程中，一個越來越清晰的認知是：降低延遲并不困難，難的是延遲降低之后，怎么通過優化保證播放體驗不下降甚至變得更好。

一、背景信息

首先簡單介紹下世界杯直播的整個分發鏈路，還有每個環節的延遲的測量方法，讓大家對整體的鏈路有初步的全局認識。

（一）抖音世界杯信號分發鏈路

（二）全鏈路延遲測量以及方法

測算方法：

拍照 視頻畫面上有時鐘展示的(比如畫面左上角或者右上角的 北京時間或者比賽持續時間 ，一般精確到秒)，可以通過同時拍照兩個播放畫面的方式，記錄同一時刻兩個畫面，然后通過照片中的時鐘 做差來計算。 手動秒表計算 如果視頻畫面中無時鐘相關內容，那么可以從延遲低的視頻畫面中選取 具有標志性易識別 的幀啟動秒表，然后觀察延遲高的畫面出現同樣的幀畫面時，停止秒表，記錄秒表結果為延遲對比結果。 僅適用演播室推流到抖音播放鏈路 計算方法： 端到端延遲 = 觀眾當前系統時間戳 - SEI 中的時間戳，單位 ms。 統計頻度：每 2s 計算一次，每 10s 上報一次當前計算結果。 每個 I 幀前會有一個 SEI，流規格設置為 I 幀間隔為 2s，因此每 2s 演播室推流側會生成一個 SEI 幀。 前置要求： 演播室推流前進行 NTP 本地時鐘校準。

延遲測量手冊：

二、生產環節的低延遲

（一）信號源

網絡流信號源在給到抖音之前存在多個環節，每個環節都可能會對最終的延遲有影響，但這一部分技術團隊可以影響的比較少，主要是運營同學在溝通。

（二）演播室制作環節

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

不過這次在演播室環節引入的延遲仍然偏高，達到了 1.5s 左右，和供應商工程師溝通后，短期內為了保證穩定，沒有再進一步壓縮了，這部分引入的延遲和競品也是一致的。

三、傳輸環節的低延遲

下圖是一次直播的簡化的流程：

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

（一）FLV 方案

FLV 是現在國內主流直播播放使用的協議，火山引擎對低延遲直播的探索也是從 FLV 開始的。在百萬英雄、內購會等活動中，FLV 低延遲方案也多次得到了驗證。

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

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

音視頻數據流轉時序

在展開描述延遲追趕策略方案細節前，先簡單介紹播放器音視頻數據流轉時序：網絡 IO 下載音視頻數據到播放器緩存 buffer->解碼器從 buffer 中取數據解碼并降解碼后的數據存入待播放緩存->音畫同步等播控策略->渲染播放音視頻幀。

數據驅動 QoE & QoS 優化

由于進一步下探延遲，卡頓也會隨之惡化，反而延遲逐漸累積增加達不到低延遲的效果，因此延遲下探必須配合延遲追趕播控策略來確保延遲增大后可及時追趕恢復到低延遲。是否只要在延遲增加后立即倍速追趕就能滿足業務的需求呢？對于延遲 QoS 指標來說的確是，但對于用戶主觀體驗的 QoE 指標，這樣的策略反而可能是負向的。

結合歷史 AB 實驗以及 DA 詳細數據分析，有以下幾點倍速追趕與 QoE 指標之間的關聯現象：

倍速追趕帶來的播放速度變化本身就是負面的體驗 倍速時長超過 2 秒，用戶即可有感知且負向反饋 倍速速度越大，播放速度前后變化 diff 越大，負向越嚴重 倍速與正常速度的切換過于頻繁，會帶來負向反饋

綜上，需要一套精細的播控策略兼顧延遲與 QoE 指標的平衡。詳細方案設計如下：

輸入：播放器當前 Buffer 時長、歷史 Ns 內 buffer 抖動方差、歷史 Ns 內卡頓信息以及追幀參數配置。

策略可配置參數以及含義映射：

輸出：目標播放速度。

原理：

基于 buffer 抖動方差 & 歷史卡頓信息，來定性衡量網絡質量，判斷是否可以追趕，只有在網絡質量良好是才能觸發追趕邏輯避免卡頓。 追幀采用雙閾值，并且支持可配置，可以控制追幀持續時長不超過 2s，同時也可以保證不頻繁變速。 追幀速度可配置，保證倍速變化不超過一定輻度。

2、FLV 2s 低延遲方案在抖音上調優總結

（1）收益總結

FLV 2s 低延遲已在抖音驗證收益：核心 QoE 波動，電商指標顯著正向，成本也有一定比例的節省，目前已全量。 世界杯：雙端 FLV-2s 方案作為世界杯低延遲方案之一，支持了開幕賽到決賽的全部賽事。

（2）調優經驗總結

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

（二） RTM 方案

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

每次迭代都要經過分析數據->找到問題點->提出優化方案->完成開發和測試->AB 實驗->分析數據的反復循環，每一次循環的都需要至少一個版本甚至多個版本的周期，所以項目整體耗時較長。關于如何提升實驗的效率，也做了很多思考和探索。最后通過多次的實驗和反復的問題解決，在核心用戶體驗指標基本對齊了 FLV,所以在世界杯的多場比賽中，RTM 方案也承擔了一定量級的 CDN 容量，核心鍵指標上都對齊了大盤，穩定性和質量得到了充分的驗證。

1、RTM 方案優化概述

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

為了讓 RTM 的綜合指標對齊 FLV，從若干角度來進行 RTM 的播控邏輯定制化，所有的優化圍繞著核心用戶體驗指標進行展開：

DNS 節點優選、SDK 信令預加載、UDP 連通性預探測主要解決的拉流成功率相關問題。 SDP 信令相關優化主要解決信令時間消耗的問題(首幀時間)與成功率問題。 RTC 內核播控定制化主要解決播放的卡頓問題。 播放器播控邏輯結合解決的音畫同步與渲染策略的問題。

2、首幀時間的優化

傳統的 RTC 技術采用 SDP 信令方式進行媒體能力協商，SDP 信令通過如下圖方式進行交互參見下圖：

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

采用 MiniSDP 信令進行媒體協商通信的信令交互流程如下圖所示：采用 MiniSDP 壓縮信令方式利用 UDP 網絡傳輸；預期單個 UDP 數據包請求即可完成 SDP 完整壓縮信息的傳輸。

當前 MiniSDP 信令（UDP）信令上線后觀察后續的 QoS 指標發現，信令建聯的成功率和首幀時間得到了大幅度的優化。

3、拉流成功率的優化

經過線上的 AB 實驗發現：RTM 拉流成功率相比 FLV 持續存在著一定的差距，而且這種差距經過觀察得知：用戶的網絡等級質量和用戶的拉流成功率存在一定的正相關性（UDP 協議本身特性），即用戶網絡質量越高成功率越高。

拉流網絡等級篩選

根據網絡質量預估信息綜合評估用戶的 TCP/UDP RTT 和數據下行吞吐率，得出用戶網絡等級；選擇網絡質量優異的用戶采用 RTM 拉流降低失敗率。

當線上 AB 實驗采用網絡等級漏斗進行網絡篩選以后，選擇用戶網絡情況相對較好的這一部分的用戶開啟實驗（這部分用戶占全網用戶的絕大部分，剩余的用戶采用默認 FLV 低延時）,原理就是用戶在拉流前綜合權衡當前網絡狀態，當網絡不適合 RTM 時候通過策略前置回落到 FLV，使得這部分用戶的體驗不受到影響。

UDP 節點探測

拉流前根據用戶請求的 URL 所歸屬的對應 CDN 邊緣節點，發起 UDP 探測；一段時間內發送數據包觀察對應 CDN 節點的數據 RTT 和丟包率，只有滿足一定條件（如 RTT<80ms 且丟包率<10%）的場景才會認為 UDP 傳輸可以保證質量和組幀成功率。

信令預加載

在當前點播/直播房間中，預先加載后一個直播間的信令信息，提前做好 SDP 加載，降低下一個房間的首幀上屏時間。

4、卡頓的優化

內核 JitterBuffer 禁用丟幀優化

未調優時候經過 AB 實驗發現，RTM 的視頻卡頓大幅度上漲，跟預期不匹配，對此團隊分析了線上的大量日志數據觀察。當前的硬解具有核心用戶體驗指標的收益，但卡頓是 FLV 的將近 3 倍,分析了大量線上 badcase，發現部分機型網絡條件較好，但幀率卻極低，類似下表這種：

這種問題在部分高熱機型上的比例也是很高的，但同樣的機型，FLV 播放并無這樣的問題，通過對比 FLV 和 RTM 的播控策略，發現了一個關鍵不同點——傳統的 RTC 場景優先保時延，全鏈路會觸發各種丟幀（包括但不限于解碼模塊，網絡模塊），FLV 直播場景會優先保證觀播體驗（不丟幀，良好的音畫同步效果）。RTM 要想減少卡頓，取得 QoE 的收益， 播控策略需進行定制化， 不影響連麥場景下的邏輯，內部采用新的播控策略，最后上線后卡頓顯著減少。

RTC 內核 JitterBuffer 平滑出幀優化

5、播控邏輯的優化

RTM 網絡傳輸 SDK 的抽象：將內核進行改造，復用引擎中的網絡傳輸-組包-JitterBuffer/NetEQ 模塊；去掉解碼/渲染等模塊；將音視頻的裸數據拋出供播放器 demuxer 集成。

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

音畫同步的優化：RTC 音視頻出幀之后在播放器側按照 FLV 的播控邏輯進行二次音畫同步處理；按照 audio master clock 主時鐘進行渲染校準，視頻幀渲染同步到音頻時間軸上。

6、RTM 針對世界杯的優化

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

4K 高清檔位卡頓嚴重卡頓: 優化 NACK 策略，保證更大的幀的組幀成功率。 CPU/GPU 內存: 優化 video 傳輸 pipeline，減少不必要的 raw 數據格式轉換。

最終在性能和效果都通過了測試，RTM 在世界杯期間也順利上線，承擔了一定的流量，上線后穩定性和質量都符合預期。

（三）世界杯中抖音和其它產品平均的延遲對比

在實際的世界杯比賽中， 抖音的延遲一直領先于相同信號源的其它產品 30s 左右 。即使最后兩場其它產品在個別直播間上了快速追趕策略比抖音快 0~1s，但追的速度過快且持續時間超過 15s+，有明顯感知，體驗相對較差， 這種策略在抖音上也曾經做過 AB 實驗 ，播放時長是顯著負向的，所以最后并沒有跟進。

四、未來的優化方向

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

在我看來，火山引擎視頻云的最大的優勢，在于可以把先進的技術放到真實的海量用戶的場景去做線上訓練，通過不斷地總結失敗的教訓和成功的經驗，對用戶體驗有更深更細微的理解。下面簡單介紹一下火山引擎視頻云在各個方案上繼續努力的方向。

（一）FLV

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

（二）RTM

在 RTM 方案上，火山引擎視頻云還在不斷地發掘優化點。以下幾點是未來會繼續探索的幾個方向：

拉流成功率的持續改進

從 SDK 技術層面共性差異看，RTM 協議中的 RTP 包組首幀存在成功率短板，后續的成功率優化需要從引擎的調優持續探索。

RTP 擴展特性的持續迭代

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

RTM 是降低延遲的一種全新方案，為了把在海量用戶的業務上積累的經驗和教訓反饋給整個業界，火山引擎視頻云也聯合騰訊和阿里發起了 RTM 行業標準的制訂，具體可以參考https://www.volcengine.com/docs/6469/103014，未來也會把標準推廣到更多的 CDN，不斷完善的同時，和業界一起向更低延遲演進。

（三）切片類協議的延遲優化

海外的 CDN 基本都只支持切片式的協議如 HLS/Dash 等，不支持 FLV 這類“過時”的傳輸協議。但 HLS/Dash 因為切片的存在，而且為了保證視頻的壓縮率，切片一般都是秒級的，且需要切片完全生成才能分發該分片，并且需要至少兩三個分片都生成完才能分發，所以和流式的協議相比，延遲上天然有一些劣勢。其實這也是競品使用的方式，如下圖，每個分片 6s，在三個分片生成完后才可以分發，帶來了 23s 的延遲。 世界杯期間，在視頻同源的情況下，其它產品的延遲顯著高于 抖音 ，就是因為使用了類似的 HLS 的切片傳輸方案。

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

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

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

為此，可以在 CMAF 上采用 QUIC 協議與連接復用結合的方式，首先 QUIC 協議的 0-RTT 建連允許客戶端在服務端確認握手成功之前就發出 HTTP 請求，而連接復用直接省去了后續請求的建連操作，大幅優化了建連耗時，維持延遲的穩定。但即使如此，每個分片的請求也會引入 1-RTT 的延遲，未來將與服務端一起探索預請求模式，進一步壓縮延遲、降低卡頓。

CMAF 優化的整體難度較大，團隊同學也經常需要在半夜和海外的 CDN 的工程師對齊和解決問題。不過經過不斷的努力，最近在部分地區的也已經有了階段性的進展，在部分場景下核心指標已經對齊 FLV，團隊也有信心在最近一段時間就能去掉機型和網絡類型的限制，讓 CMAF 可以承載更多常規比例的流量。

（四）XR 直播的延遲優化

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

這兩種做法都引入了優先級的概念，即用戶視角內的數據優先級高于其他部分，低清數據優先級高于高清數據?；谶@種特性，火山引擎視頻云將探索基于 UDP 的內容優先級感知的傳輸方案，優先保障高優數據的傳輸，對于低優數據可選擇非可靠傳輸，即使丟失也無需重傳，保證 XR 直播低延遲的同時不引入過大的視覺失真。經過優化后，在傳輸 8K x 8K/8K x 4K 的超高清視頻時 對播放端的碼率要求從 120M/50M 降低到 20M/10M 左右甚至更低 ，在用戶側極大地減少了卡頓發生的概率，從而也減少了延遲增大的概率。

未來火山引擎視頻云也會持續優化 XR 直播下在更高碼率更高分辨率下的卡頓和延遲，為用戶提供更沉浸的觀看體驗。