文|常高偉（長山）
整理|LiveVideoStack
出品|阿裏巴巴新零售淘系技術部
編者按：本次演講來自阿裏巴巴淘系技術部技術專家常高偉在 LiveVideoStack 2019深圳站上的演講，主要面向直播行業從業者，以及對低延遲直播技術、 WebRTC 技術感興趣的技術人員，介紹淘寶直播在低延遲直播技術上的探索，如何基于 WebRTC 實現一秒內的低延遲直播，以及低延遲直播對電商直播的業務價值。
作者簡介：常高偉（長山）淘系技術部技術專家。本文將爲大家分享《淘寶直播低延遲技術探索》，主要內容是介紹淘寶直播如何在電商直播中降低直播的延遲。低延遲直播作爲當下直播技術一個新的方向，我們會重點介紹下我們在這一塊的實踐。下面我將從上圖所示的幾個方面介紹。
關注「淘系技術」微信公衆號，後台回複“低延時”即可獲取本期演講 PPT 內容！
淘寶直播背景
近期淘寶直播越來越被大家所熟知，其實淘寶直播在2016年就已經上線了，到2018年淘寶直播引導成交額就已經突破1000億，今年雙十一當天直播引導成交額將近200億。
電商直播和強互動是淘寶直播的兩個典型特點：
1、電商直播：邊看邊買，觀衆觀看直播過程中可以與主播互動，主播會在直播中介紹商品信息，觀衆可以就商品信息提問。相比傳統的網購方式，它能提供更豐富信息，所以轉化率更高。
2、強互動：是指相對于傳統的電視購物，直播中主播和觀衆可以進行各種互動，包括評論、點贊、關注。其中評論是觀衆和主播互動的一個重要手段，對達成交易至關重要。
傳統的直播技術延遲非常大，從觀衆評論到看到主播給出反饋一般要在十秒以上。通過多媒體技術降低直播延遲、提高主播和粉絲的互動效率是我們研究低延遲直播技術的初衷。
低延遲技術選型
▐ 當前直播技術延遲
我們對當前主流直播技術做了分析，在低延遲直播技術出現前主要有 HLS 和 RTMP/HTTP-FLV 兩個協議。
HLS：延遲主要來自編碼解碼時産生延遲、網絡延遲、CDN 分發延遲。由于它是切片協議，延遲分兩大塊，一個是服務端有切片緩沖延遲，另一個是在播放端防抖緩沖會有延遲。切片的大小和數量都會 HLS 影響延遲大小，一般在十秒以上。
RTMP/HTTP-FLV: 目前國內大部分廠家在用的 RTMP，它相對于 HLS 在服務端做了優化。RTMP 服務端不再進行切片，而是分別轉發每一幀，CDN 分發延遲非常小。RTMP 延遲主要來自播放端防抖緩沖：爲提升弱網環境下抖動時直播的流暢度，緩沖延遲一般有五到十秒。
這兩類協議都是基于 TCP，國內廠商基本上已經將 RTMP over TCP 的延遲做到的極致，如果一個協議仍然基于 TCP 優化延遲，效果上很難優于目前的 RTMP 。
TCP 由于其自身的一些特性，並不適用于低延遲直播場景，主要原因如下：
- 重傳慢：TCP 的 ACK 確認機制，丟包後發送側超時重傳，超時時間一般200ms，會造成接收側幀抖動。
- 擁塞判斷不准確：基于丟包的擁塞控制算法無法准確判斷擁塞，丟包並不等于擁塞；也會造成發送鏈路 bufferbloat，鏈路 RTT 增大，延遲增加。
- 靈活性差：這是最主要原因，TCP 擁塞控制算法在操作系統內核層實現，優化成本較高，移動端只有利用系統已有的優化。
所以我們選擇基于 UDP 的方案實現。
▐ 低延遲直播技術選型
上圖是我們基于 UDP 的兩種方案對比，第一種是可靠UDP方向，比如 Quic ，另一種是 RTC 方案，比如 WebRTC 。
我們從五個維度對兩種方案做了對比：
- 傳輸方式：Quic 是可靠傳輸；而 RTC 是半可靠傳輸，特定情境下可對音視頻有損傳輸，可有效降低延遲。
- 複雜度：Quic 的複雜度非常低，相當于將 TCP 接口換位 Quic 接口即可，RTC方案的複雜很高，涉及一整套的協議設計和QOS保障機制。
- 音視頻友好性：Quic 不關心傳輸內容，對音視頻數據透明傳輸。RTC 對音視頻更友好，可針對音視頻做定制化優化。
- 方案完備性：從方案完備性方面來講，Quic 是針對傳輸層優化，而 WebRTC 可提供端對端優化方案。
- 理論延遲：經我們實驗室測試以及線上數據分析，WebRTC 方案的延遲可以達到 1 秒以內。
綜上，Quic 方案的最大優點是複雜度低，不過這個方案要想達到更低的延遲，也需要引入更多的複雜度。從方案的先進性上看，我們選擇 WebRTC 技術作爲我們的低延遲方案。同時，我們也相信，RTC 技術和直播技術的融合，是未來音視頻傳輸技術的一個趨勢。
阿裏雲RTS
RTS 是由阿裏雲和淘寶直播共建的低延遲直播系統，此系統分兩大塊：
- 上行接入：可接入三種輸入方式，第一種是 H5 終端，使用標准 WebRTC 推流到RTS系統中；第二種是 OBS 等傳統 RTMP 推流軟件，使用 RTMP 協議推流到 RTS 系統中；第三種是低延遲推流端，可以使用我們基于 RTP/RTCP 擴展的私有協議推流到RTS系統中。
- 下行分發：它提供兩種低延遲分發，第一種是標准WebRTC 分發，另一種是我們在 WebRTC 基礎上的私有協議擴展，淘寶直播目前使用最多的就是基于私有協議的分發。
▐ 低延遲直播技術
下面我將重點從流程協議，終端方案介紹低延遲直播技術，主要回答幾個問題：
• 標准 WebRTC 終端如何接入
• Native 終端接入如何獲得更好體驗
• 如何基于 WebRTC 設計低延遲直播端方案
• 播放器如何修改支持低延遲直播
▐ 標准 WebRTC 接入流程
播放流程描述：
• 播放端端發送接入請求：通過 HTTP 發送 AccessRequest ，攜帶播放 URL 和 offer SDP；
• RTS 收到播放的接入請求後，記錄 offerSDP 和 URL ，然後創建 answerSDP，生成一次會話 token 並設置到 SDP 的 ufrag 字段，通過 http 響應發送給客戶端。
• 客戶端設置 answerSDP，發送 Binding Request 請求，請求中 USERNAME 字段攜帶 answerSDP 中的 ufrag（即 RTS 下發的 token ）。
• RTS 收到 Binding Request，根據 USERNAME 中的 token，找到之前 HTTP 請求相關信息，記錄用戶 IP 和端口。
借助 Binding Request 的 USERNAME 傳遞 token 是由于 RTS 是單端口方案，需要根據 UDP 請求中的 token 信息確定是哪個用戶的請求。傳統的 WebRTC 是根據端口區分用戶，RTS 爲每個用戶設置端口會帶來巨大的運維成本。
標准 WebRTC 接入過程會有各種限制：
- 它不支持直播中常用音頻 AAC 編碼和 44.1k 采樣率。
- 其它不支持視頻 B 幀、H265等編碼特性，多 slice 編碼在弱網下也會花屏。
- WebRTC 建聯過程耗時過長，會影響秒開體驗。
基于以上的這些問題，我們設計了更爲高效、兼容性更好的私有協議接入。
▐ 私有協議接入流程
播放流程描述（四次握手建聯）：
- 發送播放請求：通過 UDP 發送 PlayRequest ，攜帶播放 URL ；
- RTS 收到播放請求後，立即返回臨時響應，並且開始回源；
- RTS 回源成功後，發送最終響應，攜帶相關媒體描述（編解碼等）；
- 客戶端發送最終響應 ACK，通知服務端最終響應接收成功；
- RTS 發送媒體數據：RTP/RTCP，連接建立成功；
對流程的幾點說明：
- PlayRequest 的作用是將 URL 告訴 CDN，同時兼具 UDP 打洞功能；
- 協議中信令和媒體在一個 UDP 通道傳輸；
- 四次握手流程設計，保證建聯速度的同時，確保重要信息可靠到達；
- 整個建聯過程只有一個 RTT，建聯速度快；
▐ 私有協議狀態機設計
上圖是私有協議的流程狀態機：
- 初始狀態下發送播放請求，然後會進入等待臨時相應狀態；
- 在臨時響應狀態會啓動毫秒級快速重發定時器，超時未收到臨時響應則快速重傳播放請求，保證建聯速度；
- 收到臨時響應後進入等待最終響應狀態，這時會開始更長的秒級定時器；
- 收到最終響應建聯成功；
過程中臨時響應可能丟失或亂序，可能出現提前收到最終響應的情況，會直接從等待臨時相應狀態直接進入最終狀態。
▐ 私有協議信令設計
私有信令我們選擇使用 RTCP 協議。原因是 RFC3550 定義了 RTCP 的四個功能，其中第四項可選功能描述爲：RTCP 可以用在“松散控制”系統中，傳遞最小會話控制信息。比如，標准定義了 BYE 消息，用于通知源已經不再處于激活狀態。我們在此基礎上擴展了建聯的信令消息，包括請求、臨時響應、最終響應以及最終響應 ACK 。
同時，我們選擇 RTCP 消息中的 APP 消息承載我們的私有信令。APP消息是RTCP 提供的一種爲新應用、新功能使用的一種擴展協議，即它是 RTCP 提供的一種官方擴展方式，應用層可以自己定義消息類型以及內容。此外，選擇此協議也基于以下考慮：
1、使用 RTCP-APP 可以解決私有協議和標准 RTP/RTCP 區分問題。如之前所講，媒體和信令在同一個通道，服務端收到後如何區分私有協議、RTCP 包以及原生 RTCP 包，RFC3550 有清晰的描述，幫助我們解決了這個問題。
2、使用此協議可以直接使用現有包分析工具解析抓包。
3、我們可複用 RTCP 相關定義，例如 payload type、subtype、ssrc 等。
▐ RTCP-APP 消息介紹
介紹下 RTCP-APP 消息的細節，上圖是 RTCP-APP 消息頭，主要字段如下：
1、subtype
消息子類型，可用于定義私有應用擴展消息，我們私有信令的請求、臨時響應、最終響應都是根據 subtype 區分的。subtype 的取值範圍是 0 到 31，其中 31 預留將來做擴展的消息類型。
2、payload type
APP 固定 payload type 是 204。可用于區分其它 RTP 和 RTCP 消息。
3、SSRC
SSRC 是 RTCP sender 的標識。
4、Name
name是應用名稱，用于區分其它應用APP消息。RFC3550 中描述消息類型用兩個字段區分，name 確定應用類型，subtype 用于區分消息類型，同一個 name 下可有多個 subtype 類型。
5、application-dependent data
應用層擴展消息內容，我們使用 TLV 格式，即 type、length、value，是一種靈活的、擴展性高的二進制數據格式，它占用空間低。
▐ 私有協議媒體部分設計
媒體部分協議主體遵循標准 RTP/RTCP 規範以及 WebRTC 的相關規範，其中 H264 采用 rfc6184 規範，H265 采用 rfc7798 規範。
對 RTP 的擴展部分使用標准的RTP擴展，爲了和 WebRTC 兼容，標准 RTP 擴展頭部定義使用了 rfc5285 標准。例如RTP協議是戳使用了 DTS ，標准頭中是無法攜帶 PTS 的，這會導致部分硬解異常，所以我們通過擴展頭部定義攜帶了 CTS 。
▐ 兩種接入方式對比
標准 WebRTC 接入的優點：
- 標准 WebRTC 接入除了 HTTP 建聯請求外，全部符合 WebRTC 規範。
- 標准終端方便接入。
- 可快速實現原型。
標准 WebRTC 接入的缺點：
- 建聯過程耗時長，使用HTTP情況下達到5RTT，選用HTTPS會更長。
- 媒體必須加密傳輸。
- 音視頻有相關限制，使用時需要在服務端轉碼。
私有協議接入優點：
- 基于標准擴展信令和媒體協議，與標准協議差異很小。
- 建聯速度快，秒開體驗非常好。
- 支持直播技術棧，增加了媒體兼容性，減少了服務端轉碼成本。
私有協議接入缺點：
- 雖基于標准擴展，但仍然帶來了部分私有化實現。
- 使用私有協議後，複雜度有所提升。
淘寶直播落地方案中，爲了能夠獲得更好的體驗，Native 端我們使用私有協議接入，目前已在線上大規模運行。
▐ 流程協議設計原則
流程協議設計原則有三個：
1、盡量使用標准，包括 WebRTC 相關規範。這個原則意味著我們和標准 WebRTC 互通，會非常方便。
2、當標准和體驗發生沖突時，優先保障體驗。
3、當需要擴展時，基于標准協議擴展，並且使用標准擴展方式。
我們並沒有將 RTP/RTCP 協議全部推翻，使用完全的私有協議，有兩個原因：首先是工作量問題，重新設計的工作量會比使用標准協議多很多。其次， RTP/RTCP 協議設計非常精簡，久經考驗，自己設計不一定能考慮到所有問題。所以我們選擇基于標准擴展而非重新設計。
終端接入方案
▐ 基于 WebRTC 全模塊的接入方案
基于webrtc全模塊的接入方案，使用webrtc的所有模塊，通過對部分模塊的修改，實現低延遲直播功能。
這個方案的優缺點並存：
優點：
經過多年發展，它非常成熟，很穩定，同時提供了完整的解決方案，包括 NACK、jitterbuffer、NetEQ 等可直接用于低延遲直播。
缺點：
- 它的缺點也很很明顯。如上圖中是WebRTC整體架構，它是一個從采集、渲染、編解碼到網絡傳輸的完備的端對端方案，對現有推流端和播放端侵入性極大，複雜度極高。
- RTC技術棧和直播技術棧存在差異，他不支持B幀、265等特性。在QOS策略方面，WebRTC的原生應用場景是通話，它的基本策略是延遲優于畫質，這個策略在直播中不一定成立。
- 包大小：所有webrtc模塊全部加入到APP中，包大小至少增加3M。
▐ 基于 WebRTC 傳輸層的接入方案
我們目前終端的整體接入方案如上圖，也是基于 WebRTC，但是我們只使用了 WebRTC 幾個核心傳輸相關模塊，包括 RTP/RTCP、FEC、NACK、Jitterbuffer、音視頻同步、擁塞控制等。
我們在這些基礎模塊上進行了封裝，將他們封裝成 FFmpeg 插件注入到 FFmpeg 中。之後播放器可直接調用 FFmpeg 相關方法打開 URL 即可接入我們的私有低延遲直播協議。這樣可極大減少播放器和推流端的修改，降低對低延遲直播技術對原有系統的侵入。同時，使用基礎模塊也極大減少了包大小的占用。
▐ 播放器針對低延遲直播的修改
上圖是普通播放器的架構。播放器使用 FFmpeg 打開網絡連接，讀取音視頻幀後會放入播放器緩沖，之後會依次對它進行解碼、音視頻同步及渲染。
接入低延遲直播系統後，整體架構如圖下面部分：FFmpeg 增加低延遲直播插件支持我們的私有協議；將播放器的緩沖設置爲0秒，FFmpeg 輸出的音視頻幀直接送入解碼器進行解碼，然後同步，渲染。我們將播放器原先的緩沖區移動到了我們的傳輸層SDK中，使用jitterbuffer可以根據網絡質量好壞動態的調整緩沖區大大小。
整個方案對播放器的修改很小，基本不影響原有播放器的邏輯。
低延遲直播業務價值
低延遲直播技術目前已在淘寶直播中大規模應用，它的上線降低了淘寶直播的延遲，提升了用戶的互動體驗，這是最直接的價值。
所有的技術優化都是爲了創造業務價值，所有體驗的提升應該對業務提升有幫助。我們經過線上驗證發現，低延遲直播對電商直播的成交有明顯的促進作用，其中 UV 轉化率提升4%，GMV 提升5%。
同時，低延遲直播技術也可支持更多業務形態，例如拍賣直播，客服直播等。
未來展望
我對低延遲直播技術的未來展望有三點：
1、現在的 WebRTC 開源軟件還不能很好支持直播，我希望未來的標准 WebRTC 能很好直播，這樣我們可以很方便的在浏覽器上做低延遲直播。
2、5G 到來後，網絡環境會越來越好，低延遲直播技術會成爲直播行業未來的一個技術方向。
3、現在各廠商的低延遲直播協議大都存在私有協議，對用戶來說，從一個廠商切換到另一個廠商時成本會很高。低延遲直播協議的統一、標准化對直播行業非常重要。我的一個基本判斷是，隨著低延遲直播技術的方案和普及，低延遲直播協議在未來一定會走向統一化和標准化。我希望我們國家的技術廠商能夠在推動低延遲直播標准化的過程中發出自己的聲音，貢獻自己的力量。