本文由百度智能雲-視頻雲直播技術架構師——朱曉恩 在百度開發者沙龍線上分享的演講內容整理而成。內容從低延時直播背景與機遇出發，分析低延遲直播技術，重點分享百度在低延遲直播技術的實踐工作。
文/ 朱曉恩
整理/ 百度開發者中心
視頻回放：https://developer.baidu.com/live.html?id=10
本次分享的主題是：超低延遲直播架構解析，內容主要分爲以下三個方面：
-
低延遲直播背景與機遇
-
低延遲直播技術分析
-
LSS低延遲直播技術實踐
01
低延遲直播背景與機遇
隨着各行各業直播的普及，加上疫情的強勢推廣。在線教育、直播帶貨、企業培訓、線上招聘等實時互動的場景迅速升溫。直播已成爲企業數字化轉型和內容營銷的必備場景。
在直播中，用戶實時互動體驗一直是商家重點關心的問題。例如直播帶貨過程中，主播已經上完優惠券，10幾秒過去了，用戶卻還在等待優惠券。超低延遲直播可以大大提升邊看邊買的體驗，主播可以結合互動區更好實現控場和互動，並且讓秒殺、抽獎、拍賣等對時效要求高的營銷玩法有了更強的底層支撐，大大優化直播轉換率。
又比如活動賽事直播場景中，電視/文字直播用戶已在吶喊，而視頻直播畫面還未進球。超低延遲可以極大的加深觀衆對於現場實時互動的沉浸感，參與比分和現場的互動，提升用戶對於線下活動的參與感。
而隨着5G時代的到來，網絡條件正快速提升：邊緣帶寬實現Mb向Gb增長，5G網絡時延下降到1~10毫秒；依託於AR、VR技術的直播更是大大提升了用戶的沉浸式體驗。
這些對低延遲直播來技術，都是重大的機遇。
02
超低延遲直播架構解析
RTMP/FLV直播延遲原因分析
接下來，我們以一個簡單的直播架構爲例，分析傳統的 RTMP/FLV 直播產生延遲的原因。
架構介紹：
主播通過 RTMP 推流到流媒體服務器，再從直播流媒體服務器通過 RTMP/HLS/FLV 等技術向觀衆分發包。
而一個視頻直播傳輸過程如下：
視頻輸入攝像頭採集數據——CDN傳輸——視頻解碼
「設備端處理延遲」、「網絡層延遲」和「服務器內部處理延遲」。
1. 緩存策略
緩存策略主要指CND的GOP緩存，但這種緩存策略會增加延遲。碼率過高或 GOP 太短會造成 TCP 累積延遲。
2. TCP累積延遲
編解碼過程中，解碼端在顯示之前的視頻幀緩存和編碼端的緩存都會造成延遲。
3. 編解碼緩存
解碼端在顯示之前的視頻幀緩存和編碼端的緩存都會造成延遲。
4. 編碼
編碼環節中的 B 幀解碼也依賴於前後視頻幀的到達。
由於以上原因，傳統的基於 RTMP/FLV 的視頻直播一般會產生 3-5 秒左右的延遲。延遲高的關鍵在於CDN的傳輸和播放解碼沒有很好地配合和互動。所以要實現低延遲，主要解決這個關鍵問題。
低延遲直播方案簡單比較——基於UDP
基於 TCP 的視頻直播存在較長的延遲。爲此，人們開發出了 SRT、QUIC、WebRTC 等一系列基於 UDP 協議的低延遲直播方案。
下表可以簡單概述一下基於UDP的各項低延遲直播方案的特點：
| UDP協議 |
延遲 |
流媒體特殊 |
生態 |
特點 |
| SRT |
毫秒級別 |
有 |
生態差，瀏覽器基本不支持。 |
擁塞控制較爲簡單，但是 SRT 協議需要對上下行進行改造。 |
| QUIC |
1~10秒 |
無 |
生態差，瀏覽器基本不支持。 |
傳輸層進行了優化，具有優秀的擁塞控制機制。 |
| WebRTC |
毫秒級別 |
有 |
生態好，大部分瀏覽器都支持。 |
專門爲實時音視頻通信設計的端到端解決方案，具有 QoS、低延遲等特性，具有實時雙向的數據通道，爲交互式體驗提供了更多可能，可以擴展到會議、連麥等 RTC 場景下。 |
介於WebRTC生態繁榮，百度選擇了WebRTC做爲低延遲，在下一章節會基於百度智能雲音視頻直播服務LSS，詳細介紹低延遲的直播方案實現。
03
LSS低延遲直播技術實踐
LSS低延遲直播方案設計目標與過程
設計目標:
-
兼容已有直播業務，支持錄製、截圖、轉碼、RTMP/FLV等多協議分發。
-
支持百萬併發，實現直播的CDN分發。
-
將延遲控制在1s以內。
實現過程：
如上圖所示，在典型的 LSS 直播推拉流的流程中
-
主播首先在主播端通過 LSS 推流 SDK 實現 RTMP 推流 ，在該過程中將實現實時美顏、實時濾鏡、視覺特效、硬件加速等功能；
-
視頻流會被推到全球智能接流網絡中，進而接入 LSS 媒體中心，通過服務器端 SDK 實現實時轉碼、自動鑑黃、多碼率輸出、實時水印、實時截圖、內容加密、錄製點播、統計分析等功能，打通與點播、存儲、RTC 等其它雲服務產品的聯繫。
-
接着，通過全球智能分發網絡，基於 RTMP/FLV/HLS/WebRTC 等方案將視頻流分發到客戶端，通過 LSS 播放器 SDK 實現 LSS 播放，在該過程中，將實現首屏秒開、追幀播放、自適應碼率、解密播放等功能。
直播場景改造
WebRTC 本身是面向多人會議的實時通信方案，爲了使其更好地適用於直播場景，我們需要對其進行一系列的改造，從而支持大規模的低延遲直播分發。
-
就組件協議而言，採用 AAC、H.264 音視頻引擎、UDP 傳輸層協議、RTP 媒體協議、RTCP 數據協議。通過 STUN/ICE 實現建聯，並且通過 HTTP 請求實現 SDP 協商。
-
就QoS 方案而言，通過 NACK 的方式實現丟包重傳。在播放側進行基於 Jitter Buffer 的緩衝，在發送側基於 PACING 機制調整發送的頻率和碼率，通過 GCC 實現擁塞控制，進而估計並反饋帶寬。
-
就具體的改造點而言，仍然使用上行 RTMP 協議，支持非加密傳輸，音頻轉碼支持 Opus，視頻支持 B 幀，實現了 FLV timestamp 透傳和 Metadata 透傳。
直播CDN支持與質量
WebRTC 低延遲方案需要考慮對直播 CDN 的支持與質量。
首先，採用與 RTMP/FLV 等協議相同的多級直播 CDN 分發拓撲，實現回源與推流。
這套方案通過了大規模併發的考驗，更加穩定成熟。在CDN 邊緣節點上進行封裝協議的轉換，例如：WebRTC/FLV 協議可以複用節點回源數據，如果某條直播流上已經存在 WebRTC/FLV 的播放回源數據，就可以實現更快的響應。
此外，百度 WebRTC 低延遲方案依託於百度 CDN 的海量資源節點以及優質骨幹傳輸網絡，建立了覆蓋全國的實時節點質量撥測系統與智能流量調度系統，實現了更完善的直播流質量監控系統，可以實時監控直播流回源過程中的卡頓等指標。
請求過程
WebRTC 低延遲方案的請求過程主要分爲「媒體協商」、「網絡協商」、「媒體傳輸&信令傳輸」三個階段，我們進行的主要改造包括：
-
在媒體協商階段中，在客戶端通過 HTTP API 訪問節點，從而攜帶播放的 URL、SDP Offer。在服務端，獲得直播流對應的媒體描述，如果直播流已經存在於節點上，可以直接獲得媒體描述，否則將會通過回源拉流來獲取媒體描述。此外，會生成並記錄會話 token，通過 HTTP 協議相應返回，通過 ice-ufrag 字段對應會話的 token。
-
在網絡協商階段中，通過 STUN 在客戶端發起 Binding Request，並在 USERNAME 字段中攜帶會話 token。這樣一來，我們在服務器端就可以通過 USERNAME 映射到 ice-ufrag 字段，從而對應到拉流的進程，返回 Binding Response。
-
在媒體傳輸 & 信令傳輸階段中，實現 RTP 和 RTCP 的複用傳輸。
總結：
綜上所述，LSS實現了基於 WebRTC 的低延遲端到端解決方案，該方案依託於成熟穩定的百度 CDN 直播分發架構，支持百萬併發和多協議併發，能夠兼容直播媒體中心的產品矩陣，接入的成本較低，打通了與 BRTC、BOS 等百度智能雲產品的聯繫，支持更多的使用場景。
歡迎大家在百度智能雲官網體驗：https://cloud.baidu.com/product/lss.html
以上是老師的全部分享內容，有問題歡迎在評論區提出。
掃描二維碼，備註：音視頻開發，立即加入音視頻開發技術交流羣。
