超低延時直播技術的前世今生
卷首語：
據中國互聯網絡信息中心發(fā)布的《中國互聯網絡發(fā)展狀況統計報告》顯示，截止到 2022 年 6 月我國網絡直播用戶規(guī)模達到了 7.16 億，占網民整體的 68.1% 。最主要原因是 2020 年度疫情期間導致居家辦公和休閑娛樂的人數呈現激增，新媒體互動直播成為了廣大網民最重要的休閑娛樂方式之一。
隨著直播產業(yè)鏈的不斷擴展完備升級，相關產業(yè)鏈各個環(huán)節(jié)分工逐漸明確且各環(huán)節(jié)參與人數逐步增多；為了滿足不同的就業(yè)需求，引發(fā)相關就業(yè)人數提升，通過直播形式賦能傳統產業(yè)升級轉型，并與高新技術融合創(chuàng)新，優(yōu)化傳統行業(yè)商業(yè)模式，如直播帶貨、新媒體廣告?zhèn)髅睫D型等。
豐富的傳統文化、新聞、競技體育、法律、知識共享等內容，通過移動端互動直播的形式得以更加高效的展現傳播，既讓優(yōu)質的直播內容可以實現爆發(fā)式傳播擴散，又可以讓用戶有更多的機會感受，學習甚至主動參與直播互動，實現內容供給側和需求傳播的多方共贏。
可以說，超低延時直播技術正在走上一條全新的發(fā)展之路。InfoQ將聯合火山引擎視頻直播團隊推出《超低延時直播技術演進之路》系列，帶您探索超低延時直播技術的演進歷程，揭示背后的挑戰(zhàn)和突破，以及對未來直播行業(yè)的影響。
今天這篇文章我們來講一下超低延時直播技術的前世今生~
網絡基礎設施升級、音視頻傳輸技術迭代、WebRTC 開源等因素，驅動音視頻服務時延逐漸降低， 使超低延時直播技術成為炙手可熱的研究方向。實時音視頻業(yè)務在消費互聯網領域蓬勃發(fā)展， 并逐漸向產業(yè)互聯網領域加速滲透。經歷了行業(yè)第一輪的紅利爆發(fā)期，我國實時音視頻行業(yè)的場景效能逐漸深化，步入到理性增長階段。
延時的指標選擇很大程度上取決于用戶與內容制作方的交互耦合程度，場景豐富多樣。
在這些極端場景下，延時在用戶側希望越小越好，接近于實時通信的低延遲模式可以最大化地激發(fā)用戶的參與感，無縫地與內容生產方產生互動效應，調動用戶所見即所得的積極性。比如在主播秀場的PK、送禮、工會沖榜、打賞的活動關鍵環(huán)節(jié)，競爭雙方的儲值大戶都希望實時地觀察到自身主播在禮物刷榜后的反應，為后臺運營決策團隊或者后續(xù)活動策略提供第一時間的信息反饋。
下圖體現了從技術/產品/運營的三方角度來綜合思考低延時直播技術的作用；從外部-內部綜合因素考慮技術的變遷對整個生態(tài)正向循環(huán)的影響。
（一）傳統標準直播技術的局限性
1. RTMP 協議的延遲問題
RTMP 協議是最傳統的直播協議，主播端采用 RTMP 協議推送 H.264/5 和 AAC 編碼的視音頻數據到云廠商 CDN 服務器進行轉封裝分發(fā)，端到端延遲一般控制在 3 到 7 秒。問題是 RTMP 的可擴展性存在缺陷，同時對于延遲的進一步下探存在一定的技術困難。RTMP 協議情況下：為了滿足延時降低必然壓縮播放器的下載緩沖區(qū)，這樣會引發(fā)顯著的卡頓問題，使得播放的觀感產生不舒適的感受（延時下探至 2 秒以下）。
2. 傳統直播技術在實時互動場景中的不足
- 視頻延時和彈幕交互的延時存在顯著差異，問題聊天內容互動與視頻傳輸圖像節(jié)奏不匹配；
- 觀眾與主播互動形式單一，是單向內容傳導無法做到雙向（在 RTC 技術引入之前無法顯著解決）。
- 單向傳導的局限第一個方面表現在：觀眾端拉流傳輸無法做到根據網絡情況自適應調節(jié)。用戶只能以固定的碼率進行流媒體傳輸無法做到動態(tài)感知，在網絡情況實時變化的場景（比如弱網，移動基站切換等）固定單向碼率傳輸有較大概率造成丟幀卡頓等因素影響觀播體驗；另一方面在網絡條件更好時，固定碼率傳輸無法動態(tài)提升視頻傳輸碼率（更高的畫質帶來更加舒適的體驗）
- 在直播和連麥場景共存的互動直播場景下，主播采用傳統RTMP推流在遇到連麥PK場景時，會產生推流/本地連麥合流/服務器連麥合流的切換問題，這種場景變換的切換會使得觀眾端產生瞬間的卡頓問題；如果采用基于webRTC直播技術的超低延時直播方案，這種推流--連麥邏輯的合流切換問題可以得到比較友好的解決（只需要改變服務器轉發(fā)-訂閱流通道的分發(fā)邏輯，不涉及推流媒體數據流的旁路調度切換）。
3. 超低延時直播與標準直播的區(qū)別
- 超低延時直播是近年來新興起的一類應用。如電商直播、賽事直播等場景，兼具高并發(fā)與低延時的特性，傳統直播 3-20s 的時延難以滿足其需求，但對實時互動的要求又不及視頻會議等典型的實時音視頻應用，無需將時延降低至 400ms 以下。為此，超低延時直播融合了傳統直播與實時音視頻的技術架構，通過取長補短的方式實現了介于二者之間的端到端時延。盡管針對超低延時直播廠商尚無一套標準的技術路徑，但大體可以歸納為拉流協議、網絡架構和推流協議三個方面的改造， 在實際應用過程中，廠商會平衡成本及性能指標等因素，在不同的協議和網絡架構之間進行選擇。
- 傳輸層協議的****差異 （基于 UDP 協議的可靠性優(yōu)化，為弱網對抗策略提供依據）
- 傳統直播 FLV/RTMP 等采用的是 TCP 協議（或者 QUIC 協議）TCP 是犧牲傳輸實時性來換取數據完整性的可靠傳輸協議。弱網環(huán)境下，其在數據傳輸前的“三次 握手”連接會帶來較大延時。而 UDP 作為不可靠的傳輸協議，其最大的優(yōu)點為高實時性，但不保證數據的到達和排序。實時音視頻 產品（如 RTM ****超低延時直播 ）往往采用 UDP 協議，并在此之上進行協議層與算法層的優(yōu)化，來提高傳輸的可靠性與邏輯性。
- UDP 協議的優(yōu)化：
- UDP 協議往往和 RTP/RTCP 協議一起在實際應用中出現。RTP 負責數據傳輸，其協議頭中的序列號、 端口類型、時間戳等字段，可為數據包的分組、組裝、排序提供邏輯依據；RTCP 作為 RTP 的控制協議，負責對 RTP 的傳輸質量進行統計反饋，并為弱網對抗策略提供控制參數。
（二）超低延時直播技術的演進歷程
- 基于業(yè)務場景發(fā)展的直播技術演進過程（延遲主線）
- RTM 協議本身的演進歷程
a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"
a=extmap:21 "uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range"
a=extmap:22 "uri:webrtc:rtc:rtp-hdrext:video:frame-type"
a=extmap:23 "uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp"
a=extmap:27 "uri:webrtc:rtc:rtp-hdrext:audio:aac-config"- a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
- a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"
- a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range
- a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type
- a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp
- a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config
- RTP 使用 RTP 私有擴展頭攜帶 DTS/CTS 值，每一幀 RTP 數據包通過 RFC5285-Header-Extension 擴展頭攜帶該幀的 DTS 值，每一幀首個 RTP 包和 VPS/SPS/PPS 包通過 RFC5285-Header-Extension 擴展頭攜帶該幀的 CTS 值，通過 PTS = DTS + CTS 計算當前幀的時間戳。用于啟播快速音畫同步和播放器播控邏輯精準音畫同步。
- 擴展頭攜帶幀的起始/結束序號：如果首幀的前幾個包丟失，那么可根據起始序號快速發(fā)起重傳加快首幀；如果當前幀的后幾個包丟失，那么可根據該幀的結束序號快速發(fā)起重傳，降低延時，減少卡頓。
- 擴展頭攜帶幀的類型：如果攜帶并解析了正確的幀類型，客戶端可以不用解析 metadata ；同時在弱網情形，客戶端可以跳過 B 幀直接解碼 P 幀，加速出幀并減少潛在卡頓。
- 擴展頭攜帶 P 幀的參考幀信息：如果發(fā)生弱網情形，那么客戶端可以依照擴展頭指定的參考幀關系及其對應時間戳，跳過 B 幀****解碼 ，減少卡頓發(fā)生。
- 為了加速信令交互的速度，CDN 可以在某些條件下不去查詢媒體信息，直接向客戶端返回支持的音視頻能力；此時 SDP 的媒體描述中將不包含有具體的音視頻配置詳細信息。在音頻層面，此時AnswerSDP 中不包含 aac 解碼所需的頭信息；此時我們需要采取 RTP 擴展頭模式攜帶 AAC-Config 供客戶端在 RTP 收包時刻自行解析處理完成解碼動作，作用是減少信令交互時間，提升拉流成功率。
- miniSDP 信令標準實現部分（抖音)
- CDN 信令異步回源
- RTP 攜帶擴展頭組成部分
1. WebRTC 協議在直播播放器的移植
- RTM 低延時直播基于 WebRTC 技術衍生，基于 WebRTC 標準構建點到點傳輸一般有如下幾個步驟：
- 通信雙方要進行媒體協商，會話詳細規(guī)范即 SDP(Session Description Protocol) 交互；
- 隨后進行交互式網絡地址協商（查詢對端真實 IP 地址）準備構建媒體傳輸通道；
- 當上述條件準備完畢即進入最終的 Peer to Peer 點對點媒體數據傳輸。
- 信令部分客戶端-服務器單獨開發(fā)，利用了 SDP 標準報文模式；媒體傳輸部分采用開源的 WebRTC 框架和字節(jié)自研的實時音視頻媒體引擎進行媒體傳輸。
2. RTC ****信令 協議的改造升級（ MiniSDP 壓縮 協議）
https://github.com/zhzane/mini_sdp
- 標準 SDP 比較冗長（ 5-10KB 左右），不利于快速高效傳輸。在直播場景下，會尤其影響首幀時間。MiniSDP 對標準 SDP 文本協議進行高效能壓縮，將原生 SDP 轉換成更小的二進制格式，使其能夠通過一個 UDP 包來傳輸。
- 降低信令交互時間，提高網絡傳輸效能，降低直播拉流首幀渲染時間，提高拉流秒開率/成功率等 QoS 統計指標。
播放協議 | RTM-HTTP信令 | RTM-MiniSDP信令 | FLV |
首幀時間（預覽） | 600ms | 510ms | 350ms |
拉流成功率（預覽） | 97.50% | 98.00% | 98.70% |
3. CDN 對 RTM ****信令 的 異步 回源優(yōu)化
- 降低 RTM 信令交互時間，降低 RTM 拉流首幀渲染時間。
- 原來的流程在服務端緩存不命中時需要等待回源拿到數據，才能返回帶有 AacConfig 信息的 AnswerSDP。客戶端收到 AnswerSDP 后發(fā)送 STUN，而服務端只能在收到 STUN 才能開始下發(fā)數據。（如下圖左）；當異步回源情況下：服務端不再等待回源結果直接返回 AnswerSDP，之后回源和WebRTC 建連流程同步進行。等到 WebRTC 建連成功且回源拿到數據立即下發(fā) RTP 數據。（如下圖右）
4. 視頻渲染卡頓的優(yōu)化（百秒卡頓平均降低4秒）
- 改善人均看播時長，改變 RTC 引擎的組幀/解碼策略；禁止 RTC 在低延時模式下的丟幀，改善直播的視頻渲染卡頓。
實驗組 | 視頻渲染百秒卡頓（直播間場景） |
RTM默認JitterBuffer策略 | 8.3s |
RTM改進的JitterBuffer非丟幀策略 | 3.6s |
- 傳統的 RTC 場景優(yōu)先保時延，全鏈路會觸發(fā)各種丟幀（包括但不限于解碼模塊，網絡模塊），FLV 直播場景會優(yōu)先保證觀播體驗（不丟幀，良好的音畫同步效果）。RTM 要想減少卡頓，取得 qoe 的收益，播控策略需進行定制化, 定制邏輯修改點：
- 確保不會由于軟解的解碼耗時或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ，內核層有一層強制的音畫同步邏輯，可以確保音視頻的播放體驗；
- 同時上層在監(jiān)控網絡模塊和解碼模塊的緩存長度，有相應的兜底邏輯：
- 判斷硬解確實解不過來，dec_cache_frames 過多，上報錯誤，會降級到軟解；
- jitterbuffer 異常，緩存的 frame_list 過多，觸發(fā)播放器異常邏輯，上報錯誤，重新拉流。
5. RTM 播控邏輯的優(yōu)化
- 改善移動端看播滲透，RTC 統一內核方案天生存在缺陷（ MediaCodec 硬件解碼器初始化耗時久）；將 RTM 視頻解碼模塊從 RTC 內核中遷移至 TTMP 播放內核，復用了 FLV 的視頻解碼模塊（ MediaCodec 避免重新初始化）；顯著的降低了安卓平臺的首幀渲染時間，提升了拉流的成功率。
- RTC 內核通用邏輯
- 改進的 RTM 內核播控邏輯
圖片
以上為超低延時直播技術演進之路《進化篇》的所有內容，第二篇《實戰(zhàn)篇》我們將聚焦于超低延時直播技術如何大規(guī)模落地實踐，請大家持續(xù)關注~
