第八章 交互技術，8.2 淘寶直播在雙11的互動實踐(做者：豐火)

8.2 淘寶直播在雙11的互動實踐

1. 簡介

2016年中國的智能手機覆蓋率已達58%，移動網絡接入中4G+Wifi的佔比也接近90%，這是今年移動直播能迅速爆發的一個重要的前提條件。在當前全民參與全民娛樂的大背景下，移動直播能隨時隨地的發起和參與的產品特色，也充分知足了用戶自我表達塑造我的品牌的需求，加上移動支付的快速普及，願意爲優質內容付費的觀衆已經成爲了大多數，按照這樣的鏈路在直播場景下內容變現的商業模式已經很是清晰，基本上具有流量資源的各大互聯網廠商都在今年殺入了移動直播的領域。

另外一方面，移動直播做爲一個鏈接用戶的平臺，實時性極強，藉助移動設備隨時接入的特性，可切入的場景也更多，雙向的交互方式對於包括電商在內的其餘業務模式來講也是值得探索的新玩法，因此隨着這波浪潮的興起，咱們也快速啓動淘寶直播來探索電商+直播的各類可能的方向，通過大半年的探索也獲得很好的收穫，同時也爲今年雙11直播會場的上線打下了基礎。

整個過程對產品和技術上均帶來很大的挑戰，本文將爲你們解析整個過程當中所遇到關鍵問題和解決方案。

 

1.1 雙11直播

從互動來看，須要支持多營銷場景，典型如：九牛與二虎以及雙11晚會直播間。九牛與二虎是一場精心設計的PGC製做的欄目，九個商家的同時直播，2位明星隨機走訪明星各個直播間進行PK的玩法，直播間須要提供9個房間的實時互通以及切換的能力。雙11晚會對直播的互動的玩法要求很是高了，除了常規的評論、紅包、關注小卡等，還有AB劇，紅黑PK，點贊場景化等具體的業務需求外，還須要支持多屏互動。

從規模來看，要支持50W~100W的同時觀看，同時要具有靈活的切換能力，對權益發放（如紅包雨、砸金蛋）引起的QPS峯值要保障穩定的服務能力，這些也都須要從業務鏈路總體來梳理優化。總結一下核心面臨的挑戰主要有：

• 穩定性

          50W~100W的同時觀看
          卡頓率的優化

• 實時性

           播放的時延控制在<2s（排除人工引入的60s時延）
           首屏打開時間小於1s

• 同步性

          互動的實時推送能力
          內容和互動的同步

• 帶寬成本

           在不下降畫質的狀況，節約帶寬30%~40%

下面將分別對這些問題進行分別分析和方案解析。

 

2. 技術架構

直播做爲一個實時系統，首要的目標是要將從主播端實時採集的音視頻內容從網絡推送到觀衆端，並保證整個鏈路的時延控制在1s-2s的範圍內，整個流程上時延的優化是貫穿全局的重點。

 

2.1 基礎架構

     從架構圖上能夠看出，整個系統主要分爲三個部分：

• 主播端：音視頻的採集、編碼、推流
• 阿里雲：轉碼、截圖、水印、錄製
• 觀衆端：音視頻數據的下載、解碼、播放

 

2.2 架構重構

對直播業務進行了流程優化，使其具備更好的可擴展性和性能，主要體如今如下幾方面：

• 開放性

           支持168八、航旅、天貓系的直播接入，進行單獨計費、結算。

• 可配置性

           直播管理流程化，一個流程有若干處理節點組成，不一樣的個性化接入需求，配置不一樣的流程。

• 可複用性

           每一個業務流程中，對通用組件進行復用，不一樣的接入需求只需新增個性化的節點就能夠快速支持。

• 高性能

           優化了業務流程，增長本地緩存和前置緩存，雙11晚會直播詳情接口響應時間從14ms下降到7ms，直播列表頁從114ms下降爲54ms。

 

3. 核心優化

3.1首屏秒開

首屏秒開是指播放端用戶從進入淘寶直播間到出現視頻畫面的時間在1秒鐘以內，在極短的時間內呈現直播視頻畫面、已縮短用戶的等待時間；在這1秒鐘以內須要經歷DNS解析、TCP創建鏈接、RTMP協議握手、流媒體數據接收/解析、視頻解碼、YUV數據渲染等一系列的環節。

推流端視頻H264編碼按照每2s一個I幀進行編碼，而後按照RTMP協議打包發送到CDN邊緣節點服務器，CDN服務器對視頻數據從I幀開始緩存；只緩存最後一個GOP，即後面的GOP數據覆蓋前面的數據，以保證視頻流的實時性；流程以下：                                                                                                     

CDN會在服務器上緩存最後一個I幀開始的GOP視頻數據，此視頻數據最大爲2s(默認關鍵幀間隔爲2秒)；當播放器端HTTP鏈接到CDN節點服務器後，CDN服務器會將緩存的GOP視頻數據所有發送到播放器端。除了優化GOP緩衝以外，播放段也進行了多項優化：

• 業務依賴優化

          在拉取直播間列表時直接返回播放地址，點擊進入直播間時優先拉取音視頻流來解析播放，收到首幀畫面後進行後續業務邏輯，包括在線人數、評論列表等

• 播放預讀緩衝優化

          爲了判斷視頻流、音頻流的格式，播放器通常會預讀一部分數據來嘗試解碼肯定肯定音視頻的編碼方式，而在淘寶直播中視頻（H264）、音頻（AAC）編碼方式都是肯定，徹底能夠避免這樣的預讀耗時。

雙11期間最終數據以下，其中首屏平均加載 <1000ms

   

 

3.2 變速播放

在移動互聯網絡下，網絡發生卡頓、抖動很是廣泛狀況下會播放器內部緩衝愈來愈大、總體累計延時也就愈來愈大，此時須要提升播放速率(如1.2倍速~1.5倍速)來下降累積延時；當播放器內部緩衝區數據愈來愈低時，須要下降播放速率(如變速到0.7~0.9倍速)來等待緩衝數據，避免頻繁的卡頓與緩衝等待；

播放器的默認同步機制大多都是視頻同步音頻的，即以音頻爲基準時間軸，因此只須要改變音頻的播放速率便可實現此目的，視頻會自動進行同步；前提是在改變音頻播放速率的同時不能下降聲音播放體驗；

播放器緩衝去大小策略數據以下圖：

當網絡發生抖動，播放器內部緩衝的音視頻數據爲5秒，此時累計延時就有5秒；在正常播放速率(1倍速)下，播放完5秒的音視頻數據實際也須要5秒，累計延時不會下降，隨着累計延時愈來愈高用戶體驗也會愈來愈差；當播放器前次發生卡頓恢復後，播放器下載緩衝的音視頻數據達到6秒以上時，播放器會開啓加速播放到倍速播放，播放速率會在1.1~1.5倍速之間浮動，此時緩衝內部的音視頻數據會在短期內播放完畢，如1.2倍速播放6秒視頻數據會在5秒內播放完畢，會縮短1秒鐘的累計延時。

一樣道理，當網絡發生抖動致使播放器內部緩衝的音視頻數據小於5秒時，播放器也會將播放速率調慢至0.8~1.0之間以使緩衝長度恢復到合理長度以免卡頓。

 

4 互動玩法

4.1 技術框架

互動是直播的關鍵功能，爲了知足豐富的玩法，直播互動玩法的框架必須具有良好的開放性和定製化。一個典型的互動玩法交互的框架圖以下：

     

實現互動玩法的開發和直播間功能徹底解耦，承接雙11期間紅包、優惠券、進店小卡、關注小卡等多種玩法

最終的數據包括評論、點贊在內的總互動次數達到42.5億次，互動率超過20%，提高了整個直播間的互動氛圍表現。

 

4.2 幀同步

多屏互動的難點在於如何保證來自媒體流（音視頻數據）和數據流（互動玩法）在時間上是精準匹配，傳統的作法是基因而提高消息推送時間和到達率，但在實際場景因政策管制的緣由最終播放的媒體流實際上有必定的人爲延時（通常是60s），這樣帶來的問題：用戶看到畫面是時可能互動消息已經提早出現或者尚未收到，這都會致使互動效果大打折扣。

爲了解決這個難題咱們提出一套基於視頻幀的解決方案：將互動內容做爲視頻的特殊幀封裝到視頻流裏面。下面詳細介紹下方案實現：

在H264視頻編碼標準中，幀是由一個或者多個NAL單元組成，而NAL單元又分爲多種，其中有一些特殊的NAL單元其自身能夠不攜帶任何音視頻信息，如SEI_NAL。H264標準中，容許SEI_NAL單元由用戶按照標準格式本身定義填充數據，且解碼器在收到用戶自定義的SEI_NAL時，默認不會對其進行處理。所以，咱們將互動信息封裝成一個SEI_NAL，將其打入到視頻幀中並由主播端推送出去，最終播放器配合進行SEI_NAL的解析上報：

NAL_SEI幀的構造以下圖所示：

     

每一次控制信息SEI的大小不會超過255字節，對視頻文件大小的影響很小。

幀同步互動主要包括兩部分：

• 攝像機推流時將控制信息寫入視頻幀

 以下圖所示，在林志玲扔衣服的時候，攝像機採集到扔衣服這一幀畫面，由工做人員手動觸發編碼器，在當前幀寫入控制信息， video數據和控制數據由推流端發送協議發送到服務器，服務器對此控制信息不作任何處理的下發。由此完成控制信息的寫入分發。

     

• 播放端收到控制信息解析上報

播放器在收到幀以後，會判斷幀中是否有控制信息，若是有，則會將控制信息sei從視頻幀中分離出來上報給業務層，由業務層決定當前控制信息應該作什麼操做。好比在用戶收到林志玲扔衣服的sei時，會上報業務層該control，由業務層決定應該在界面顯示一件林志玲的衣服。從而達到的效果就是視頻裏面林志玲在扔衣服，用戶的界面上顯示出了一件林志玲的衣服。

經過基於視頻關鍵幀的互動方案，可以確保用戶在視頻的同一畫面收到一致的互動數據，達到較好的互動體驗，同時具有良好的擴展性。

 

4.3 直播連麥

直播的應用場景主要是兩個重要的參與角色：主播與觀衆，而直播應用相比點播等傳統應用的最大優點是：主播與觀衆的實時互動能力能給觀衆帶來的更多的參與感，是除了傳統互動方式包括文字，點贊，禮物等方式以外一種重要的互動能力，也是直播領域在將來的競爭重點。

直播互動連麥的流程是指：主播在直播過程當中，能夠邀請一個或多個觀衆或者其餘主播進入直播間，能夠和主播進行雙向音視頻通話，全部的觀衆在直播間能夠看到他們的互動過程。而引入連麥功能，最大的技術難點：在對現有直播系統架構不作太大調整的狀況下，提供低延遲的視頻通話體驗，同時兼顧將來的功能和架構演變，好比提供多方連麥功能等。通過綜合考慮後設計的架構以下：

連麥中主播和連麥粉絲各推一路音視頻流到服務器，同時拉取對方的音視頻流進行播放，觀衆則觀看連麥雙方合併後的流。須要注意的一點是，爲了保證連麥雙方低延遲，主播和連麥粉絲拉取對方的音視頻流均是低延遲流，而觀衆爲了保證流暢度，拉取的是有延遲的流。
方案的優勢：
一、並流功能在服務端來實現，能夠下降手機端的性能壓力和帶寬壓力，同時也更容易擴展連麥人數。
二、對現有直播架構改動不大，基本採用和現有直播架構相同的協議體系，開發成本低，穩定性有保證。
三、延遲低。實測端到端雙方延遲能夠達到500ms，其中服務端延遲平均只有幾十毫秒，實測數據打破你們一直以來對rtmp協議延遲過大的認識。

連麥的延遲是雙方通話的一項重要指標。整個過程的延遲主要有兩類：

• 固有延遲，包括採集延遲、數據處理延遲、編碼延遲、解碼延遲、系統處理延遲、展示延遲等

           針對固有延遲，在保證質量的狀況下儘可能下降部分參數的設置。如在H264算法能夠採用延遲更低的baseline（會下降一些視頻質量），採用延遲更低音頻算法代替AAC等下降固定延時。

• 動態延遲，包括網絡傳輸過程當中因爲丟包、擁塞等緣由引發的延遲。

           爲了解決網絡抖動引起的播放卡頓，在播放端引入必定的緩衝平滑播放過程避免頻繁的卡頓。爲了能根據網絡狀況動態肯定延遲和流暢的最佳平衡點，咱們引入了兩個算法來解決：音頻變速不變調算法和jitterbuffer控制算法。

 

在解決了上述問題後，最終的基礎連麥能力得以完成，在雙11造勢期間咱們也提供「全民連連看」做爲直播的一種創新玩法，主打「一個正經的交友視頻在線互動遊戲」，取得了很是好的效果。連連看最終效果以下：

 

4.4 總體穩定性

互動權益在直播間的推送到達成功率是互動穩定性的最重要的指標，下圖是整個直播互動在雙11期間的數據表現：

     

爲了達到總體穩定性的要求，主要在下面幾個方面來進行優化：

• 全鏈路埋點監控

           從消息的推送到互動層的渲染都進行完整的數據埋點，快速定位總體成功率。

• 消息的push&pull結合

           將高頻的評論消息和低頻的狀態消息區別開，用不一樣的策略來拉取

• H5互動玩法的優化

           除了對「紅包雨「頁面的佔用內存進行優化外，將經常使用的資源經過zcache進行提早推送下降渲染時因資源拉取失敗致使互動玩法沒法展現。

 

5. 帶寬成本

爲了知足帶寬節約的目標，在播放端引入H265的解碼算法，推流端不受影響依然保持H264推流，H265轉碼由雲端轉碼服務完成，總體架構以下：

     

雙11晚會開啓H265轉碼後，總體節約帶寬30%左右。

 

總結

今年是淘寶直播在雙11的首次亮相，整個平臺高峯時支持近50W的同時在線，同時支持了包括在會場和直播間內豐富多樣的互動玩法，表現穩定。將來除了在功能上進一步增強總體運營的能力外，也須要完善全鏈路的數據監控能力，持續優化核心體驗。基於阿里雲底層的直播服務共同打造完整移動直播解決方案，提供包括直播SDK、消息通道、互動玩法等一體化開放平臺。