雙 11 貓晚直播：看阿里文娛如何「擒住」高併發、多視角、 低卡頓！

簡介： 在全民互動、紅包與優惠券齊飛的雙 11 盛會之下，對於阿里內部而言，實則是「練兵千日 磨一劍，用兵一時見功夫」的實戰訓練場。對此，阿里巴巴集團董事局主席兼首席執行官張勇（逍遙子）也曾說過，「沒有參加過雙 11 的叫同事，參加過雙 11 的叫戰友」。而現在這場以技術爲支撐的「戰役」究竟有多複雜？在面向瞬時的高併發場景時，阿里人又是如何作到無懈可擊的？

做者| 阿里文娛技術專家 泫野

在全民互動、紅包與優惠券齊飛的雙 11 盛會之下，對於阿里內部而言，實則是「練兵千日 磨一劍，用兵一時見功夫」的實戰訓練場。對此，阿里巴巴集團董事局主席兼首席執行官張勇（逍遙子）也曾說過，「沒有參加過雙 11 的叫同事，參加過雙 11 的叫戰友」。而現在這場以技術爲支撐的「戰役」究竟有多複雜？在面向瞬時的高併發場景時，阿里人又是如何作到無懈可擊的？

1、2019 雙 11 貓晚直播的技術戰果

首先回顧下 2019 雙 11 貓晚直播過程當中的一些亮眼成果，主要是四個方向：

第一是高清戰略

今年貓晚直播超高清佔比用戶達到了 93% 。從清晰度檔位投放上，相較於往年的 1080P、 720P 高清檔位，今年咱們還大規模投放了 4K、杜比（720P、1080P、4K）、50 幀等更高畫質音質檔位的內容，爲用戶提供極致的視聽體驗。

第二是節省成本

今年在高清戰略的大背景下，用戶側平均碼率大幅提高，對用戶端的卡頓和帶寬成本帶來 巨大挑戰。咱們爲此增強並引入了新的帶寬節約核心抓手，最終今年帶寬消耗成本不升反降， 節省帶寬成本達到了 35%，同時達成了高畫質和低成本倆個目標。

第三是基礎保障

直播項目整個工程的一大特色，就是實時製做生產內容，而且鏈路很是長。從製做、生產、 傳輸、轉碼、分發任何鏈路上的一個小問題，都會致使用戶體驗上的降低，好比出現卡頓、花 屏、甚至沒法播放等等問題。
今年咱們也在流全鏈路和服務鏈路上作了大量優化工做。最終獲得了 0 故障 0 降級操做的結果。

第四是創新能力

貓晚首次引入杜比全景聲與幀對齊技術，在音頻和視頻兩個層面來提高體驗。

2、目標與挑戰

第一是高體驗目標。

咱們在目標落地過程當中，定義了三個技術方向：

1. 高畫質方向

提高碼率是提高用戶畫質的主要手段，可是在千萬用戶量級下，高碼率的瞬間抖動，很可 能致使帶寬消耗超出咱們準備的帶寬資源水位，形成用戶側出現總體卡頓甚至故障的發生。
歷屆貓晚中常常出現分鐘級別，碼率變化 2-3 倍的狀況發生。這種狀況下，與咱們使用 VBR 轉碼方式是分不開的。VBR 優點在於簡單畫面下轉碼碼率很低，用戶側對於下載網速門檻要求 不高，有助於用戶避免卡頓；可是當出現複雜畫面時，轉碼碼率會快速增高，這種瞬間的碼率 抖動不只影響咱們的帶寬水位，還會致使用戶卡頓提高。
針對這個問題咱們須要有效的峯值碼率控制，和碼率抖動控制手段。

2. 低卡頓方向

用戶側的網絡環境、硬件環境、設備能力良莠不齊，若是隻是一味的提高碼率而投放默認 高清晰度檔位，就會形成用戶側的卡頓問題發生。所以咱們要有效識別端側環境的能力，進而 調整清晰度的手段。
同時直播內容在實時生產過程當中，任何節點發生故障都會形成用戶側的卡頓，甚至沒法播 放的問題發生。咱們須要一套能夠實時、自動的故障容災體系支撐咱們複雜的直播鏈路場景。

3. 提高視聽體驗方向

今年貓晚進行了多視角的形式進行直播，用戶能夠在 C 端進行多路視角內容間切換，可是 因爲不一樣流的進度不一致，會出現視音頻回跳問題，致使用戶體驗降低。貓晚做爲綜藝類直播， 歷年來音頻體驗同質化嚴重，也是咱們重點須要提高的部分。

第二是低成本目標。

千萬用戶量級下，帶寬消耗巨大，同時會帶來高昂的帶寬成本。另外咱們的帶寬資源有限， 須要嚴格控量使用。所以，咱們要從省帶寬、低碼率上提供有效的技術抓手。保障咱們的直播 過程既能作到高畫質，又能拿到低成本的結果。

3、技術策略：核心抓手 + 基礎保障

第一是高畫質低成本抓手

今年優酷直播首次引入 FPGA H265 轉碼技術，目標提高總體 H265 覆蓋率效果。FGPA H265 具有的能力：
1）提高轉碼壓縮率，可下降峯值碼率，從而下降帶寬成本；
2）碼率波動更小，有效下降帶寬水位風險；
3）針對高分辨率高碼率的實時轉碼能力。

第二是高畫質低卡頓抓手

針對 C 端用戶環境複雜問題，今年貓晚首次從製做域、視頻雲、播放域三域共同能力，落 地了直播智能檔能力：
1）具有基於 QoE 的自適應清晰度能力；
2）流鏈路自動容災預案能力。

第三是視聽體驗提高抓手

1）針對於貓晚的多視角直播場景，自研落地了一套視角幀對齊技術，多路流間也能具有幀 級別平滑切換能力，提高切換過程當中視音頻的連續性與一致性；
2）首次引入杜比全景聲技術，讓用戶體驗身臨其境的效果。技術落地過程當中，建設了一套 SRT 低延遲迴傳鏈路。

第四是基礎保障

在流的生產分發全鏈路中，咱們落地了完整的熱備方案，及對應的故障自動發現自動執行 的預案機制，保障直播過程當中的萬無一失。

4、高畫質低成本：FPGA H265

H.265 轉碼是一種經常使用有效的下降碼率手段，能夠在保障畫質的前提下，壓縮峯值碼率， 從而達到節省帶寬的目的。
提高 H265 覆蓋率的方法，主要從 2 個端進行：

C 端播放器：提高各端播放器 H265 解碼播放能力，作到全端全版本的覆蓋。爲了保證 播放體驗，優酷直播優先採用硬件解碼方式，經過白名單的策略，在測試覆蓋範圍內的 設備開啓 H265 解碼播放，低配機型上咱們會慎重開啓；

S 端轉碼層：所有清晰度檔位，作到 H.265 轉碼。讓任何檔位上播放的用戶均可以有 H.265 的流。可是行業主流採起的 CPU H.265 轉碼方案，在高分辨率高碼率下存在吞吐瓶頸。

如上圖所示：CPU H.265 轉碼在 720P（50 幀）以上清晰度檔位，在保證畫質和壓縮率的前 提下，存在吞吐方面瓶頸，沒法作到實時轉碼。
替換方案上，咱們對比了 GPU 和 FPGA 硬件架構。在 GPU 性能對比中發現，GPU 在同壓 縮碼率下，畫質比 CPU 差不少沒法達到咱們的畫質需求。咱們進一步把選型目標放在 FPGA 上。

畫質對比

結果：FPGA H265 在一樣壓縮碼率下，達到 x265 slow 級別的畫質，符合咱們對於畫質和 壓縮率的要求。

吞吐對比

結果：FPGA H265 吞吐能力是 x265 slow 級別的 12 倍。雙 FPGA 實例可實時轉碼 4K60； 單 FPGA 實例可實時轉碼 4K30/1080p120，或者任意組合成相同吞吐的其餘分辨率。
在作到與 CPU 相同壓縮和畫質效果下，FPGA 轉碼在吞吐能力上遠遠超出預期。雙實例 4K60 的實時轉碼能力，覆蓋了咱們目前因此清晰度檔位對於 H.265 轉碼的需求。下面咱們進一 步驗證了 FPGA H265 在實際轉碼中，對於峯值碼率下降和碼率波動控制方面的效果。

在實際轉碼中的效果：
1）相比 H.264 轉碼，峯值碼率降低超 22%，達到碼率節省效果預期；
2）碼率抖動更平穩，有利於避免用戶卡頓問題；
3）強大的吞吐能力，各檔位 H265 轉碼作到了全覆蓋，總體 H265 覆蓋率獲得了提高。

5、高畫質低卡頓：智能檔

智能檔的核心做用就是基於用戶端實際環境，自動爲用戶適配成合適的流進行播放。例如： 用戶側下載網速差，1080P 這種高碼率檔位沒法作到流暢播放，經過端側智能檔的 QoE 智能評 分，能夠發現並幫助用戶自動適配成一個與其網速匹配的流進行流暢的播放。

那麼智能檔具體哪些能力呢？

1）QoE 智能評分 對用戶環境、設備、硬件、網絡、帶寬等等因素進行綜合評分的能力； 2）智能檔播控配置在用戶首次進入直播間時，未對其 QoE 打分前，咱們須要播控提供默認的起播配置；同時 在智能檔自動切換流的過程當中，一樣須要播控提供流的調整範圍。
智能檔 M3u8 相較於普通的 M3u8 文件不一樣，智能檔會在轉碼的 M3u8 文件外再封裝一層 Master M3u8 文件（如圖雲端 Master m3u8 切片），其內部是各個轉碼對應的子 M3u8 文件，調 整範圍配置就是要在這些子M3u8 文件間進行調整。
主要做用：支持針對於播放場景的自定義範圍，例如大屏在 720P 和 1080P 間選擇，小屏則在 720P 和 480P 中選擇，這樣作到雲端生產一份 Master m3u8 文件（緩存），多場景均可以使用。
3）幀級別平滑切換能力 智能檔核心做用是幫助用戶自動適配合適的流進行播放，整個自動切換過程當中對於用戶是無感知的，咱們要保障切換過程當中，用戶在感官上的內容（包括視頻和音頻）連續性，不會產生卡頓的感受。（幀對齊的解決思路會在後文中進行闡述）
4）自動容災預案能力 智能檔對流的探活能力，配合其幀級別平滑切換能力，能夠在流發生故障時，幫用戶快速進行流地址的切換，避免發生卡頓或播放錯誤的狀況。
從轉碼層上，爲了不轉碼鏈路的單點問題，咱們在華東和華北雙機房同時進行熱備轉碼； 從切片層上，封裝 Master M3u8 時會把華東和華北的轉碼 M3u8 文件做爲倆個組封裝在一塊兒。 這樣給到播放器，播放器纔有能力在某一路機房轉碼有問題時，快速切換到另外一路機房轉碼的 m3u8 文件，讓用戶在流故障發生時，也能獲得順暢的播放體驗。

6、視聽體驗：視角幀對齊

首先看一下業務場景：貓晚直播過程當中，咱們在現場舞臺的各個角度架設了攝像機，例如 演員在唱歌，攝像機 1 拍攝側臉，攝像機 2 拍攝正臉。在播放器中用戶能夠經過切換視角方式， 來自主選擇看側面仍是正面。
因爲雙路攝像機的流，同經過不一樣的編碼器、鏈路上傳到雲的，會存在進度不一致的問題。 用戶切換過程就會出現畫面或聲音回跳的問題，例如明星唱了一句歌詞，切換後可能因爲畫面 回跳致使又唱了一遍，形成用戶體驗的降低。
因此，幀對齊的目標就是經過技術解決多路流之間切換，保證畫面先後一致性連續性，從 而提高用戶體驗。主要應用場景包括：自適應碼率、多視角內容切換、雲端畫面合成、異地容 災預案等。

1. 畫面不對齊的緣由

1）不一樣的流，編碼器開始推流時間不一樣，致使同一幀畫面的 PTS 不一樣；
2）同一路流，視頻雲轉碼任務啓動時間有差別，並重寫了 PTS，致使各轉碼的同一幀畫面 PTS 不一樣。

2. 解決思路

須要從製做域，視頻雲，播放域總體改造，實現幀對齊能力：
1）製做域：多路編碼器間，推流時須要帶入統一參考系，用於雲端對齊。在參考系選擇上， 咱們使用的從 ntp server 獲取絕對時間戳，時間戳自己不會被地域限制，在異地推流場景下也適用；
2）視頻雲：針對不一樣轉碼間，PTS 不一樣的問題。雲端實現了直接使用源流 PTS 透傳（PTS COPY）的方案，這樣各路轉碼任務啓動時間雖然有差別，可是都是使用源流同一幀畫面中的 PTS，從而保證了個轉碼的 PTS 一致；在切片服務中，須要保證同一幀畫面在同一切片內（即保證切片序號一致），所以咱們改進了切片序號的算法，從基於 PTS 計算改造爲 PTS+推流時間 戳來計算的方式；
3）播放域：作到多路流間，同一幀畫面在同一分片內（TS 文件），播放器有能力並作到了 非關鍵幀級別 seek。瞭解編解碼的同窗應該清楚，直接從非關鍵幀起播會出現花屏等沒法播放 的問題，這裏面我就須要從 I 幀進行解碼，但不顯示出來，直到解碼到 seek 的幀後進行解碼並 顯示，經過這個優化來實現非關鍵幀 seek。
總體方案，在貓晚過程當中達到了幀對齊的預期效果。咱們相信這套技術的沉澱，能夠在將來多個場景中應用，並促進直播內容製做的新思路。

7、視聽體驗：杜比全景聲

今天首次採用杜比全景聲能力進行貓晚直播，在音質體驗提高目標上，啓動重要做用。整 體技術方案落地難點，除了 C 端播放器覆蓋杜比 e-ac3 音頻解碼還原成杜比音效的能力，更多問題存在於傳輸鏈路上。
下面先看一下廣電是怎麼作杜比內容傳輸的：

廣電方案中，經過現場編碼杜比音頻，信號經過光纜或衛星迴傳給電視臺的演播室，再經過同軸或光纖傳輸到家庭的機頂盒中進行解碼播放。
總體鏈路上達到廣電級安全標準，可靠性很是高。但對於線路上成本也很是昂貴，並不適用於互聯網方案。

在互聯網直播場景中，咱們分析了友商的方案，基本是基於廣電轉播的模式。 現場編碼杜比音頻，經過光纜或衛星迴傳到本身的演播室，演播室經過 UDP+TS 文件+內網專線回傳給雲端，雲端最終分發給用戶進行播放。
其中的問題：
1）演播室後方人力成本：因爲現場要回傳給演播室，則須要大量後方人力。面向中小型甚 至我的發起的直播場次，是沒法 cover 住這部分紅本的。
2）網絡部署成本：因爲 rtmp 公網協議中，咱們沒法傳輸杜比的 e-ac3 音頻，只能採用原始 的 TS 文件+UDP+內網專線方式回傳。雲部署的機房只能開通白名單方式開通回傳鏈路，這樣 就增長了部署成本，而且沒法作到回傳鏈路的通用性。

爲解決以上方案的成本問題，今年優酷直播協同阿里雲，共同推動落地基於 SRT 公網協議 的低延遲迴傳鏈路。
SRT 是一種能夠在複雜網絡環境下，進行實時傳輸數據流的開源傳輸技術。傳輸層是採用 UDP 協議，具有開銷低、速度快的特色。SRT 具有支持多種流類型的特性，能夠回傳杜比的 e-ac3 音頻，阿里雲收到回傳流會進行雲端解封裝，視頻部分經過 rtmp 協議內部傳輸、轉碼、切片， 杜比音頻部分則會透傳方式進行傳遞。從用戶的體驗來看，用戶聽到的音頻，就是直接從現場 製做好的杜比效果傳來的，保證了杜比效果的原汁原味。
整套回傳落地後，咱們節省了演播室大量的後方人力成本和網絡的部署成本。基於 SRT 協 議公網傳輸鏈路，支撐了中小型直播甚至我的發起的直播，也能製做杜比直播的場景。

8、基礎保障：現場&視頻雲鏈路

如圖所示，直播流鏈路很是長，任何節點出現問題都是致使用戶側的沒法播放、卡頓等問 題發生。如何作到絕對的萬無一失？
核心思路有兩點：
1）全鏈路上的熱備
2）故障自動發現和自動預案執行能力如下詳細解釋一下全鏈路上的熱備工做：
1）信號熱備
貓晚的現場信號，是從浙江轉播車中經過線路給出的信號。若是線路或信號源出現問題， 會致使咱們無信號可播的情況。所以咱們在杭州異地，準備了機頂盒的廣電信號進行備份，如 果現場信號有任何問題，咱們有能力直接使用廣電信號爲用戶進行轉播。廣電信號的安全標準 是很是高的，若是出現問題說明電視臺播出也出現了故障，這種狀況基本不會發生。
2）現場硬件熱備 現場導播臺、編碼器等硬件，咱們會準備主備硬件，以熱備的方式，同時進行推流。阿里雲側，實現了高可用的熱備 relay 拉流轉碼能力，能夠實現優先從主編碼器拉流轉碼，當主編碼器流鏈路故障時，能夠在 6 秒內自動切換到備編碼器流鏈路上，繼續爲用戶提供流內容，端側 用戶無明顯感知。
3）網絡熱備
若是現場 Wi-Fi、有線網絡斷掉，致使沒法推流時，咱們現場還準備了 4G 揹包，經過 4G網絡能夠將流推到雲上，保障鏈路暢通。
4）傳輸鏈路熱備
在現場與視頻雲間，咱們拉通了 3 根 VPC 專線，分別是電信、聯通、移動運營商。因爲現 場在上海，咱們優先使用電信的網絡專線，當運營商鏈路出現問題時，能夠作到 2 秒中內自動 切換到其餘運營商鏈路上，持續的保障鏈路暢通。
5）轉碼中心熱備 數據流千里迢迢到達視頻雲後，轉碼任務也會存在單點問題。若是轉碼任務轉出內容畫面有問題，或碼率沒有控制住，此時必須降級並重啓轉碼任務，同時會形成部分用戶播放的中斷。
針對轉碼問題，咱們同時在華東和華北雙機房配置了相同的轉碼任務，並同時開啓轉碼。這樣 當任何一個轉碼機房出現故障時，咱們有能力經過雲端修改鏈路方式，使用另一個備用機房 轉碼爲用戶提供服務，保障用戶側的觀看體驗。
今年貓晚在技術上作到了信號、硬件、網絡、傳輸鏈路、回源中心、轉碼、切片、播放， 實現了全鏈路熱備，以及故障快速發現自動修復能力，保障了今年晚會萬無一失。

9、基礎保障：服務鏈路

除了流鏈路穩定性，咱們在服務鏈路也作了大量優化保障工做。服務鏈路保障的目的是，在千萬級用戶流量涌入到直播間後，用戶能夠正常的進入直播間而且拿到流地址進行播放。 整個優化工做能夠分紅幾步： 梳理流量入口，尤爲是觸達類 PUSH 引流入口。PUSH 引流能力具有快速將入口觸達用戶， 用戶會在短期快速涌入直播間的特色，是影響服務 QPS 峯值的核心穩定性因素。若是多個 PUSH 引流同時發送，QPS 峯值則會出現疊加的狀況； 1）基於實際業務場景，在網關層進行限流和防刷，同時要避免無心義的 QPS 疊加。在需 要投放多個 PUSH 引流入口時，咱們盡力避免同時發送，而是有節奏的間隔一段時間發送，避 免峯值疊加形成的穩定性風險，同時形成服務器資源浪費； 2）除了網關層限流，防止流量穿透致使應用層出現雪崩。應用層自己也要進行限流，防止 網關層出現沒有限住流量的狀況發生，達到雙重保障。另外應用服務咱們要進行多機房部署， 甚至異地部署，規避機房單點問題帶來的穩定性風險； 3）核心鏈路服務的下游依賴，也要作限流防控，避免流量過載致使宕機。同時針對下游依 賴，咱們作到了秒級的自動熔斷能力。整個流量洪峯會在幾秒內到達，經過人工方式發現和進 行熔斷動做是來不及的，存在下游依賴出現超時或錯誤，拖垮核心鏈路的風險。另外，核心鏈 路上的全部下游依賴，咱們都進行了弱依賴改造：即便下游全部依賴，包括存儲都掛掉，咱們 的服務仍然能夠給到用戶一個可播的流地址，從而在服務鏈路上作到絕對的高可用性。 今年貓晚播放服務可用性達到 99.99%以上，服務平均 RT(99) 36ms，0 故障，符合預期。 同時貓晚項目 1 個月內共進行了 5 次全鏈路壓測，10 屢次線上直播鏈路演練。幾乎 1 周 1 次的 全鏈路壓測，隔一天 1 次線上演練，這也是和鏈路上各個團隊的努力分不開的，共同保障了今 年貓晚的萬無一失。