今年的618直播可有點兒不一樣。此前，5月27日天貓618公佈了今年暑期檔明星直播名單：300多明星集體上淘寶直播，將掀起史上最大規模的明星開播潮。
瞅瞅，半個娛樂圈都在暑假裡排隊上直播呢！
朱一龍、趙麗穎、歐陽娜娜、劉濤、姚晨、虞書欣、馬思純、古力娜扎、迪麗熱巴、Angelababy、鄧紫棋、宋茜、佟麗婭、範丞丞、宋威龍、李易峰、許光漢、毛不易、華晨宇、鹿晗、王俊凱、王凱、林更新、吳倩、張雲龍、郭晶晶、張繼科……
明星們的開播形態也很多元：做直播綜藝、為品牌助力、“改行”主播帶貨等。此外，粉絲們可以透過完成一定的互動任務，助力偶像提升人氣值，並抽取與偶像見面的機會。還有明星簽名禮盒、同款禮盒、限量周邊等驚喜福利。
開播前不少人擔心，從未經歷過如此大規模明星輪番開播的淘寶，承受得了粉絲們一波又一波的熱情嗎？能夠及時帶給粉絲與偶像互動的心跳體驗嗎？
答案，妥妥的。
下面，我們想重點分享一下有關提升粉絲體驗的淘寶直播低延時技術。
核心內容來自於阿里巴巴淘系技術部技術專家常高偉在 LiveVideoStack 2019深圳站上的演講，主要面向直播行業從業者，以及對低延遲直播技術、 WebRTC 技術感興趣的技術人員，介紹淘寶直播在低延遲直播技術上的探索，如何基於 WebRTC 實現一秒內的低延遲直播，以及低延遲直播對電商直播的業務價值。
▐ 當前直播技術延遲
傳統的直播技術延遲非常大，從觀眾評論到看到主播給出反饋一般要在十秒以上。透過多媒體技術降低直播延遲、提高主播和粉絲的互動效率是我們研究低延遲直播技術的初衷。
我們對當前主流直播技術做了分析，在低延遲直播技術出現前主要有 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 typeAPP 固定 payload type 是 204。可用於區分其它 RTP 和 RTCP 訊息。
3、SSRCSSRC 是 RTCP sender 的標識。
4、Namename是應用名稱，用於區分其它應用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、現在各廠商的低延遲直播協議大都存在私有協議，對使用者來說，從一個廠商切換到另一個廠商時成本會很高。低延遲直播協議的統一、標準化對直播行業非常重要。我的一個基本判斷是，隨著低延遲直播技術的方案和普及，低延遲直播協議在未來一定會走向統一化和標準化。我希望我們國家的技術廠商能夠在推動低延遲直播標準化的過程中發出自己的聲音，貢獻自己的力量。
原文連結：http://click.aliyun.com/m/1000296624/
本文為阿里雲原創內容，未經允許不得轉載。
