本文由字節跳動技術團隊李晨光、匡建鑫、陳鑒平分享，本文有修訂和改動。
1、引言
新媒體互動直播已成為了廣大網民最重要的休閑娛樂方式之一。豐富的傳統文化、新聞、競技體育、法律、知識共享等內容，通過移動端互動直播的形式得以更加高效的展現傳播，既讓優質的直播內容可以實現爆發式傳播擴散，又可以讓用戶有更多的機會感受，學習甚至主動參與直播互動。超低延時視頻直播技術正在走上一條全新的發展之路。
本文將帶您了解超低延時視頻直播技術的優化和演進歷程。
2、系列文章
本文是系列文章中的第 11 篇，本系列總目錄如下：
3、低延時直播技術的作用
網絡基礎設施升級、音視頻傳輸技術迭代、WebRTC 開源等因素，驅動音視頻服務時延逐漸降低， 使超低延時直播技術成為炙手可熱的研究方向。實時音視頻業務在消費互聯網領域蓬勃發展， 并逐漸向產業互聯網領域加速滲透。經歷了行業第一輪的紅利爆發期，我國實時音視頻行業的場景效能逐漸深化，步入到理性增長階段。
延時的指標選擇很大程度上取決于用戶與內容制作方的交互耦合程度，場景豐富多樣。
在這些極端場景下，延時在用戶側希望越小越好，接近于實時通信的低延遲模式可以最大化地激發用戶的參與感，無縫地與內容生產方產生互動效應，調動用戶所見即所得的積極性。比如在主播秀場的PK、送禮、工會沖榜、打賞的活動關鍵環節，競爭雙方的儲值大戶都希望實時地觀察到自身主播在禮物刷榜后的反應，為后臺運營決策團隊或者后續活動策略提供第一時間的信息反饋。
下圖體現了從技術/產品/運營的三方角度來綜合思考低延時直播技術的作用；從外部-內部綜合因素考慮技術的變遷對整個生態正向循環的影響。
4、傳統直播技術中RTMP協議的延遲問題
RTMP 協議是最傳統的直播協議，主播端采用 RTMP 協議推送 H.264/5 和 AAC 編碼的視音頻數據到云廠商 CDN 服務器進行轉封裝分發，端到端延遲一般控制在 3 到 7 秒。
問題是 RTMP 的可擴展性存在缺陷，同時對于延遲的進一步下探存在一定的技術困難。
RTMP 協議情況下：為了滿足延時降低必然壓縮播放器的下載緩沖區，這樣會引發顯著的卡頓問題，使得播放的觀感產生不舒適的感受（延時下探至 2 秒以下）。
5、傳統直播技術在實時互動場景中的不足
1）視頻延時和彈幕交互的延時存在顯著差異，問題聊天內容互動與視頻傳輸圖像節奏不匹配：
2）觀眾與主播互動形式單一，是單向內容傳導無法做到雙向（在 RTC 技術引入之前無法顯著解決）。
3）單向傳導的局限第一個方面表現在：觀眾端拉流傳輸無法做到根據網絡情況自適應調節。用戶只能以固定的碼率進行流媒體傳輸無法做到動態感知，在網絡情況實時變化的場景（比如弱網，移動基站切換等）固定單向碼率傳輸有較大概率造成丟幀卡頓等因素影響觀播體驗。另一方面在網絡條件更好時，固定碼率傳輸無法動態提升視頻傳輸碼率（更高的畫質帶來更加舒適的體驗）
4）在直播和連麥場景共存的互動直播場景下，主播采用傳統RTMP推流在遇到連麥PK場景時，會產生推流/本地連麥合流/服務器連麥合流的切換問題，這種場景變換的切換會使得觀眾端產生瞬間的卡頓問題。如果采用基于webRTC直播技術的超低延時直播方案，這種推流--連麥邏輯的合流切換問題可以得到比較友好的解決（只需要改變服務器轉發-訂閱流通道的分發邏輯，不涉及推流媒體數據流的旁路調度切換）。
6、 超低延時直播與標準直播的區別
6.1超低延時直播
超低延時直播是近年來新興起的一類應用。
如電商直播、賽事直播等場景，兼具高并發與低延時的特性，傳統直播 3-20s 的時延難以滿足其需求，但對實時互動的要求又不及視頻會議等典型的實時音視頻應用，無需將時延降低至 400ms 以下。
為此，超低延時直播融合了傳統直播與實時音視頻的技術架構，通過取長補短的方式實現了介于二者之間的端到端時延。
盡管針對超低延時直播廠商尚無一套標準的技術路徑，但大體可以歸納為拉流協議、網絡架構和推流協議三個方面的改造， 在實際應用過程中，廠商會平衡成本及性能指標等因素，在不同的協議和網絡架構之間進行選擇。
6.2傳輸層協議的差異
基于 UDP 協議的可靠性優化，為弱網對抗策略提供依據。
傳統直播 FLV/RTMP 等采用的是 TCP 協議（或者 QUIC 協議）TCP 是犧牲傳輸實時性來換取數據完整性的可靠傳輸協議。
弱網環境下，其在數據傳輸前的“三次 握手”連接會帶來較大延時。
而 UDP 作為不可靠的傳輸協議，其最大的優點為高實時性，但不保證數據的到達和排序。
實時音視頻 產品（如 RTM 超低延時直播）往往采用 UDP 協議，并在此之上進行協議層與算法層的優化，來提高傳輸的可靠性與邏輯性。
相關文章可閱讀：
- 《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
- 《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
- 《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
- 《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
6.3UDP 協議的優化
UDP 協議往往和 RTP/RTCP 協議一起在實際應用中出現。
RTP 負責數據傳輸，其協議頭中的序列號、 端口類型、時間戳等字段，可為數據包的分組、組裝、排序提供邏輯依據。
RTCP 作為 RTP 的控制協議，負責對 RTP 的傳輸質量進行統計反饋，并為弱網對抗策略提供控制參數。
7、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
RTP 使用 RTP 私有擴展頭攜帶 DTS/CTS 值，每一幀 RTP 數據包通過 RFC5285-Header-Extension 擴展頭攜帶該幀的 DTS 值，每一幀首個 RTP 包和 VPS/SPS/PPS 包通過 RFC5285-Header-Extension 擴展頭攜帶該幀的 CTS 值，通過 PTS = DTS + CTS 計算當前幀的時間戳。用于啟播快速音畫同步和播放器播控邏輯精準音畫同步。
擴展頭攜帶幀的起始/結束序號：如果首幀的前幾個包丟失，那么可根據起始序號快速發起重傳加快首幀；如果當前幀的后幾個包丟失，那么可根據該幀的結束序號快速發起重傳，降低延時，減少卡頓。
擴展頭攜帶幀的類型：如果攜帶并解析了正確的幀類型，客戶端可以不用解析 metadata ；同時在弱網情形，客戶端可以跳過 B 幀直接解碼 P 幀，加速出幀并減少潛在卡頓。
擴展頭攜帶 P 幀的參考幀信息：如果發生弱網情形，那么客戶端可以依照擴展頭指定的參考幀關系及其對應時間戳，跳過 B 幀解碼 ，減少卡頓發生。
為了加速信令交互的速度，CDN 可以在某些條件下不去查詢媒體信息，直接向客戶端返回支持的音視頻能力；此時 SDP 的媒體描述中將不包含有具體的音視頻配置詳細信息。在音頻層面，此時AnswerSDP 中不包含 aac 解碼所需的頭信息；此時我們需要采取 RTP 擴展頭模式攜帶 AAC-Config 供客戶端在 RTP 收包時刻自行解析處理完成解碼動作，作用是減少信令交互時間，提升拉流成功率。
miniSDP 信令標準實現部分（抖音)。
CDN 信令異步回源。
RTP 攜帶擴展頭組成部分。
8、WebRTC 協議在直播播放器的移植
RTM 低延時直播基于 WebRTC 技術衍生，基于 WebRTC 標準構建點到點傳輸一般有如下幾個步驟：
- 1）通信雙方要進行媒體協商，會話詳細規范即 SDP(Session Description Protocol) 交互；
- 2）隨后進行交互式網絡地址協商（查詢對端真實 IP 地址）準備構建媒體傳輸通道；
- 3）當上述條件準備完畢即進入最終的 Peer to Peer 點對點媒體數據傳輸。
信令部分客戶端-服務器單獨開發，利用了 SDP 標準報文模式。媒體傳輸部分采用開源的 WebRTC 框架和字節自研的實時音視頻媒體引擎進行媒體傳輸。
9、RTC 信令協議的改造升級
MiniSDP壓縮協議：https://github.com/zhzane/mini_sdp。
標準 SDP 比較冗長（5-10KB 左右），不利于快速高效傳輸。在直播場景下，會尤其影響首幀時間。
MiniSDP 對標準 SDP 文本協議進行高效能壓縮，將原生 SDP 轉換成更小的二進制格式，使其能夠通過一個 UDP 包來傳輸。
降低信令交互時間，提高網絡傳輸效能，降低直播拉流首幀渲染時間，提高拉流秒開率/成功率等 QoS 統計指標。
10、CDN對RTM 信令的異步回源優化
降低 RTM 信令交互時間，降低 RTM 拉流首幀渲染時間。
原來的流程在服務端緩存不命中時需要等待回源拿到數據，才能返回帶有 AacConfig 信息的 AnswerSDP。客戶端收到 AnswerSDP 后發送 STUN，而服務端只能在收到 STUN 才能開始下發數據。
如下圖左：當異步回源情況下，服務端不再等待回源結果直接返回 AnswerSDP，之后回源和WebRTC 建連流程同步進行。
如上圖右：等到 WebRTC 建連成功且回源拿到數據立即下發 RTP 數據。
11、視頻渲染卡頓的優化（百秒卡頓平均降低4秒）
改善人均看播時長，改變 RTC 引擎的組幀/解碼策略；禁止 RTC 在低延時模式下的丟幀，改善直播的視頻渲染卡頓。
傳統的 RTC 場景優先保時延，全鏈路會觸發各種丟幀（包括但不限于解碼模塊，網絡模塊），FLV 直播場景會優先保證觀播體驗（不丟幀，良好的音畫同步效果）。
RTM 要想減少卡頓，取得 qoe 的收益，播控策略需進行定制化，定制邏輯修改點：
1）確保不會由于軟解的解碼耗時或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ，內核層有一層強制的音畫同步邏輯，可以確保音視頻的播放體驗；
2）同時上層在監控網絡模塊和解碼模塊的緩存長度，有相應的兜底邏輯：
- a. 判斷硬解確實解不過來，dec_cache_frames 過多，上報錯誤，會降級到軟解；
- b. jitterbuffer 異常，緩存的 frame_list 過多，觸發播放器異常邏輯，上報錯誤，重新拉流。
12、RTM播控邏輯的優化
改善移動端看播滲透，RTC 統一內核方案天生存在缺陷（ MediaCodec 硬件解碼器初始化耗時久）。將 RTM 視頻解碼模塊從 RTC 內核中遷移至 TTMP 播放內核，復用了 FLV 的視頻解碼模塊（ MediaCodec 避免重新初始化）。顯著的降低了安卓平臺的首幀渲染時間，提升了拉流的成功率。
RTC 內核通用邏輯：
改進的 RTM 內核播控邏輯：
13、相關文章
[1] TCP/IP詳解 - 第11章·UDP：用戶數據報協議
[2] TCP/IP詳解 - 第17章·TCP：傳輸控制協議
[3] 零基礎入門：基于開源WebRTC，從0到1實現實時音視頻聊天功能
[4] 實時音視頻入門學習：開源工程WebRTC的技術原理和使用淺析
[5] 零基礎快速入門WebRTC：基本概念、關鍵技術、與WebSocket的區別等
[6] 學習RFC3550：RTP/RTCP實時傳輸協議基礎知識
[7] 基于RTMP數據傳輸協議的實時流媒體技術研究（論文全文）
[8] 技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解
[9] 讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享
[10] 實時音視頻面視必備：快速掌握11個視頻技術相關的基礎概念
[11] 實時音視頻開發理論必備：如何省流量？視頻高度壓縮背后的預測技術
[12] 移動端實時音視頻直播技術詳解（一）：開篇
[13] 直播系統聊天技術(九)：千萬級實時直播彈幕的技術實踐
[14] 在線音視頻直播室服務端架構最佳實踐(視頻+PPT) [附件下載]
[15] 視頻直播技術干貨：一文讀懂主流視頻直播系統的推拉流架構、傳輸協議等
（本文已同步發布于：http://www.52im.net/thread-4587-1-1.html）