758
林誌玲送衣直播的背後，阿裏工程師下了哪些功夫？
2016年中國的智能手機覆蓋率已達58%，移動網絡接入中4G+Wifi的占比也接近90%，這是移動直播能迅速爆發的一個重要的前提條件。在當前全民參與全民娛樂的大背景下，移動直播能隨時隨地的發起和參與的產品特點，也充分滿足了用戶自我表達塑造個人品牌的需求，加上移動支付的快速普及，願意為優質內容付費的觀眾已經成為了大多數，按照這樣的鏈路在直播場景下內容變現的商業模式已經非常清晰，基本上具備流量資源的各大互聯網廠商都在今年殺入了移動直播的領域。
另一方麵，移動直播作為一個連接用戶的平台，實時性極強，借助移動設備隨時接入的特性，可切入的場景也更多，雙向的交互方式對於包括電商在內的其他業務模式來說也是值得探索的新玩法，所以隨著這波浪潮的興起，我們也快速啟動淘寶直播來探索電商+直播的各種可能的方向，經過大半年的探索也得到很好的收獲，同時也為2016年雙11直播會場的上線打下了基礎。
整個過程對產品和技術上均帶來很大的挑戰，本文將為大家解析整個過程中所遇到關鍵問題和解決方案。
1.1 雙11直播
從互動來看，需要支持多營銷場景，典型如：九牛與二虎以及雙十一晚會直播間。九牛與二虎是一場精心設計的PGC製作的欄目，九個商家的同時直播，2位明星隨機走訪明星各個直播間進行PK的玩法，直播間需要提供9個房間的實時互通以及切換的能力。雙11晚會對直播的互動的玩法要求非常高了，除了常規的評論、紅包、關注小卡等，還有AB劇，紅黑PK，點讚場景化等具體的業務需求外，還需要支持多屏互動。
從規模來看，要支持50W~100W的同時觀看，同時要具備靈活的切換能力，對權益發放（如紅包雨、砸金蛋）引發的QPS峰值要保障穩定的服務能力，這些也都需要從業務鏈路整體來梳理優化。總結一下核心麵臨的挑戰主要有：
- 穩定性 50W~100W的同時觀看 卡頓率的優化
- 實時性 播放的時延控製在<2s（排除人工引入的60s時延） 首屏打開時間小於1s
- 同步性 互動的實時推送能力 內容和互動的同步
- 帶寬成本 在不降低畫質的情況，節約帶寬30%~40%
下麵將分別對這些問題進行分別分析和方案解析。
直播作為一個實時係統，首要的目標是要將從主播端實時采集的音視頻內容從網絡推送到觀眾端，並保證整個鏈路的時延控製在1s-2s的範圍內，整個流程上時延的優化是貫穿全局的重點。
2.1 基礎架構
從架構圖上可以看出，整個係統主要分為三個部分：
- 主播端：音視頻的采集、編碼、推流
- 阿裏雲：轉碼、截圖、水印、錄製
- 觀眾端：音視頻數據的下載、解碼、播放
- 架構重構
對直播業務進行了流程優化，使其具有更好的可擴展性和性能，主要體現在以下幾方麵：
- 開放性 支持1688、航旅、天貓係的直播接入，進行單獨計費、結算。
- 可配置性 直播管理流程化，一個流程有若幹處理節點組成，不同的個性化接入需求，配置不同的流程。
- 可複用性 每個業務流程中，對通用組件進行複用，不同的接入需求隻需新增個性化的節點就可以快速支持。
- 高性能 優化了業務流程，增加本地緩存和前置緩存，雙十一晚會直播詳情接口響應時間從14ms降低到7ms，直播列表頁從114ms降低為54ms。
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.1 技術框架
互動是直播的關鍵功能，為了滿足豐富的玩法，直播互動玩法的框架必須具備良好的開放性和定製化。一個典型的互動玩法交互的框架圖如下：
實現互動玩法的開發和直播間功能完全解耦，承接雙十一期間紅包、優惠券、進店小卡、關注小卡等多種玩法。
最終的數據包括評論、點讚在內的總互動次數達到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 直播連麥
直播的應用場景主要是兩個重要的參與角色：主播與觀眾，而直播應用相比點播等傳統應用的最大優勢是：主播與觀眾的實時互動能力能給觀眾帶來的更多的參與感，是除了傳統互動方式包括文字，點讚，禮物等方式之外一種重要的互動能力，也是直播領域在未來的競爭重點。
直播互動連麥的流程是指：主播在直播過程中，可以邀請一個或多個觀眾或者其他主播進入直播間，可以和主播進行雙向音視頻通話，所有的觀眾在直播間可以看到他們的互動過程。而引入連麥功能，最大的技術難點：在對現有直播係統架構不做太大調整的情況下，提供低延遲的視頻通話體驗，同時兼顧未來的功能和架構演變，比如提供多方連麥功能等。經過綜合考慮後設計的架構如下：
連麥中主播和連麥粉絲各推一路音視頻流到服務器，同時拉取對方的音視頻流進行播放，觀眾則觀看連麥雙方合並後的流。需要注意的一點是，為了保證連麥雙方低延遲，主播和連麥粉絲拉取對方的音視頻流均是低延遲流，而觀眾為了保證流暢度，拉取的是有延遲的流。
方案的優點：
1、並流功能在服務端來實現，可以降低手機端的性能壓力和帶寬壓力，同時也更容易擴展連麥人數。
2、對現有直播架構改動不大，基本采用和現有直播架構相同的協議體係，開發成本低，穩定性有保證。
3、延遲低。實測端到端雙方延遲可以達到500ms，其中服務端延遲平均隻有幾十毫秒，實測數據打破大家一直以來對rtmp協議延遲過大的認識。
連麥的延遲是雙方通話的一項重要指標。整個過程的延遲主要有兩類：
- 固有延遲，包括采集延遲、數據處理延遲、編碼延遲、解碼延遲、係統處理延遲、展現延遲等
針對固有延遲，在保證質量的情況下盡量降低部分參數的設置。如在H264算法可以采用延遲更低的baseline（會降低一些視頻質量），采用延遲更低音頻算法代替AAC等降低固定延時。
- 動態延遲，包括網絡傳輸過程中由於丟包、擁塞等原因引起的延遲。
為了解決網絡抖動引發的播放卡頓，在播放端引入一定的緩衝平滑播放過程避免頻繁的卡頓。為了能根據網絡情況動態確定延遲和流暢的最佳平衡點，我們引入了兩個算法來解決：音頻變速不變調算法和jitterbuffer控製算法。
在解決了上述問題後，最終的基礎連麥能力得以完成，在雙十一造勢期間我們也提供“全民連連看”作為直播的一種創新玩法，主打“一個正經的交友視頻在線互動遊戲”，取得了非常好的效果。連連看最終效果如下：
4.4 整體穩定性
互動權益在直播間的推送到達成功率是互動穩定性的最重要的指標，下圖是整個直播互動在雙十一期間的數據表現：
為了達到整體穩定性的要求，主要在下麵幾個方麵來進行優化：
- 全鏈路埋點監控
從消息的推送到互動層的渲染都進行完整的數據埋點，快速定位整體成功率。
- 消息的push&pull結合
將高頻的評論消息和低頻的狀態消息區別開，用不同的策略來拉取
- H5互動玩法的優化
除了對“紅包雨“頁麵的占用內存進行優化外，將常用的資源通過zcache進行提前推送降低渲染時因資源拉取失敗導致互動玩法無法展示。
帶寬成本
為了滿足帶寬節約的目標，在播放端引入H265的解碼算法，推流端不受影響依然保持H264推流，H265轉碼由雲端轉碼服務完成，整體架構如下：
雙十一晚會開啟H265轉碼後，整體節約帶寬30%左右。
總 結
淘寶直播在2016年雙11的首次亮相，整個平台高峰時支持近50W的同時在線，同時支持了包括在會場和直播間內豐富多樣的互動玩法，表現穩定。未來除了在功能上進一步加強整體運營的能力外，也需要完善全鏈路的數據監控能力，持續優化核心體驗。基於阿裏雲底層的直播服務共同打造完整移動直播解決方案，提供包括直播SDK、消息通道、互動玩法等一體化開放平台。
最後更新：2017-06-16 15:32:54