文|常高偉
整理|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 标準。
▐ 兩種接入方式對比
标準 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、現在各廠商的低延遲直播協定大都存在私有協定，對使用者來說，從一個廠商切換到另一個廠商時成本會很高。低延遲直播協定的統一、标準化對直播行業非常重要。我的一個基本判斷是，随着低延遲直播技術的方案和普及，低延遲直播協定在未來一定會走向統一化和标準化。我希望我們國家的技術廠商能夠在推動低延遲直播标準化的過程中發出自己的聲音，貢獻自己的力量。
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~