你負責看比賽，其他的放著我來 | 蘇寧體育賽事直播頻道化運營關鍵技術

頻道化直播背景介紹

蘇寧體育近年來購買了大量的體育賽事版權，尤其是足球賽事版權，囊括了歐洲五大聯賽、中超、亞冠等頂級版權。此外還有 WWE、UFC、NFL 等熱門賽事版權。

運營這些優質的賽事資源，給使用者提供優質且方便的直播服務，我們依託蘇寧視訊雲 (PP 雲) 的直播編碼平臺，提出了頻道化直播運營理念。根據賽事類別分門別類的建立專業化頻道，比如：英超頻道、亞冠頻道、中超頻道等，把同類比賽直播及其相關的花絮、新聞短視訊集中在一個頻道，通過高質量的節目編排，提供 24 小時連續直播服務。給使用者提供優質服務的同時，一站化服務可節省使用者精力，消除其選擇困難。

PP 雲直播平臺介紹

PP 雲直播平臺架構

直播平臺由管理後臺、分散式直播轉碼系統、流媒體服務叢集組成。

管理後臺：面向運營人員提供頻道管理面板，且與轉碼叢集的 Master 通過 HTTP API 互動。

分散式直播轉碼系統：由 Master 和轉碼節點 Node 組成叢集，Master 與 Node 間通過 WebSocket 進行通訊，Master 控制任務的分發與排程。Master 通過主備實現高可用，Node 基於 FFMpeg API 開發，可通過加機器橫向擴充套件算力。

流媒體服務叢集：與 Node 間通過 RTMP 進行推拉流，作為直播源站為後續的切片服務或 CDN 平臺提供直播源。三者間互動及架構如下圖：

PP 雲直播平臺主要功能

直播平臺提供直播流轉碼、本地視訊轉成直播進行輪播、無縫切換直播源、動態切換 logo、動態改變節目編排、多碼流輸出、動態改變頻道引數等。

直播轉碼節點實現

直播轉碼節點基於 FFMpeg API 實現，其大致流程如下：對視訊源進行解封裝、解碼，然後把音視訊原始資料送入 Filter Graph，對音訊進行重取樣、變換聲道等濾鏡操作，對視訊進行遮標、縮放、FPS 變換等濾鏡操作，然後進行時戳調整、變換，最後加上 Logo 並分別送入不同檔次的編碼器進行編碼、推流，流程如下圖所示：

後臺管理頁面實現

後臺管理頁是供運營人員進行頻道管理的操作面板，提供了頻道新建 / 刪除、引數配置、Logo 更換、節目列表更新、頻道啟用 / 禁用、直播流監控面板等功能，見下圖：

頻道化直播關鍵技術點

無縫切源

切換直播源時，要使使用者端無感，不出現卡頓，就需要切換視訊源時，儘量縮短開啟下一個視訊源的耗時。開啟視訊源最耗時的部分在於獲取視訊資訊，在 FFMpeg 中對應 avformat_find_stream_info 函式，對有些無法從視訊資訊頭中獲取所需引數的視訊，該函式會嘗試解碼音視訊資料來獲取，會大幅增加耗時，尤其是直播源，因此可優化該函式，如果一直某路直播源的一些資訊，就可直接填充相關結構體而無需呼叫該函式，可降低耗時。

如果是迴圈直播某個本地檔案時，可不重新開啟該檔案，而是通過 Rewind 的方式，seek 到檔案開頭重新解碼，這時需要注意處理時戳。

時戳處理

時戳處理在直播轉碼中尤其重要，是消除直播卡頓或花屏的關鍵點。首先是切換視訊源時的時戳處理，其過程如下：首先建立一個參考時間軸，記錄直播流當前的時間點，該時間為視訊源當前音訊 / 視訊時間戳的較大者，並變換到參考時間軸的時基，假設音視訊時戳變換到參考時間的變換函式為 f(t)，則當前時間為： T_max=Max(f(t_a ),f(t_v )) 。當切換新的視訊源時，以視訊軌為例，當前時戳應為上個視訊源的最大時戳加上當前視訊的相對時戳，然後反變換到視訊軌時基，假設視訊軌起始時戳變換到參考時間軸為：T_start，經過整理得到視訊軌當前時戳為：V_t=ftv(T_max-T_start )+t，同理可得音訊軌的時戳。

當視訊源中存在時戳突變時，也需要時戳處理，我們知道，直播中音視訊時戳應該是單調遞增的，如果直播過程中時戳突然變小，會導致直播花屏，如果時戳突然變大，雖然不會導致視訊畫面出問題，但會導致時戳變大，減小 RTMP 連續直播的時長，因為 RTMP 的時戳由於欄位取值範圍限制，最多能支援連續 24 天的直播。切換視訊源的時戳處理過程如下圖所示：

Buffer 管理

Buffer 管理分兩部分：一是在 Encoder 裡維護一個 Frame Buffer，解碼執行緒與編碼執行緒的互動即可通過該 Buffer 進行。當上行網路不好時，編碼器需做丟幀處理，丟幀時，優先保障音訊，先丟視訊幀，這樣可使直播中音訊保持流暢且連續。

另外一個 Buffer 是在釋出流的時候，維護一個 packet buffer，用於控制流的時延，有些應用場景，有延播需求，比如電視臺的直播一般都會延遲 50 秒左右播出。

Logo 動態更換

採用 Front/Back 兩個 Frame Buffer 來儲存 Logo 影象，在往視訊幀上疊加 Logo 的函式 (Render) 時，採用 Front Buffer，當接收到更換 Logo 的命令式，啟動執行緒來載入新的 Logo 到 Back Buffer，載入完成時，通知 Render 函式交換 Buffer，Front Buffer 就是新的 Logo 影象 Buffer 了，就完成了 Logo 切換。這樣可保證 Logo 切換無縫，做到讓使用者無感。

錯誤處理

直播過程中不可避免的會遇到錯誤，常見的有以下幾類：

1. 時戳無效或突變問題，可用上述時戳處理的方法加以修正。
2. 推流遇到網路錯誤，比如 -10053、-10054、-104 等錯誤，這些錯誤需要重啟編碼器，但解碼器保持不變。其中 -10054 可能是流媒體伺服器宕機，這時重啟編碼器時需改變推流目標機器。
3. 遇到解碼錯誤，重啟解碼器，保持編碼器不變。
4. 遇到非致命錯誤時，可設定該錯誤連續出現 10 次再當做錯誤處理。

另外，當出現錯誤，經過處理恢復直播時，需全速轉碼，追趕處理錯誤消耗的時間，保證直播的流暢性。

穩定性與可靠性

高可用性

高可用性可由以下的架構及部署來保證：

1. 直播轉碼叢集多機房部署，從更高的層次上來保證服務的高可用性。
2. 叢集內的 Master 要有熱備，方案為：用 zookeeper 服務 (ZK)，部署於兩臺機器上的 Master 向 ZK 搶主，成功者作為叢集 Master，且定期向 ZK 傳送心跳，當主 Master 掛掉後，備用 Master 則會搶主成功，這樣可保證 Master 的高可用性。
3. 流媒體伺服器也用叢集部署，防止單點。

故障轉移

直播轉碼叢集內，Master 會感知各個節點的狀態，如果某個節點掛掉，則 Master 會自動將這個節點上的任務轉移到其他空閒節點，保證任務及時恢復，故障轉移可以在數秒內完成，基本不影響直播觀感。

監控

對整個叢集的服務狀況及直播流的狀態監控是保證系統可靠性的重要且必要的手段。

首先在 Master 及各個節點執行過程中產生日誌，每個 5 秒鐘記錄一次各個輸入流及輸出流的位元速率及幀率狀況，然後彙報給監控平臺，再由監控平臺進行計算分析，輸出報表或者產生報警。如果系統中發生致命錯誤則直接報警，可最大限度的實時報出致命錯誤，比如宕機，以便運維人員及時處理。日誌、監控及報警流程如下圖所示：

監控例項

直播平臺中的某個頻道的幀率監控報表如下圖所示：

直播平臺中的某個頻道的位元速率監控報表如下圖所示：

穩定性實測

直播平臺實施以上的架構及處理措施後，系統表現出了預期的穩定性，以其中一個頻道為例，無故障的連續直播了約 122W 秒，大約為 14 天，穩定性及可靠性達到了設計目的，實際播放測試結果如下圖所示：

總結

直播平臺上線後，極大的方便了運營蘇寧體育的優質賽事資源，在直播平臺上建立電視化的直播頻道。平臺的穩定性、高可用性及方便的運維性，保證了直播頻道給使用者提供優質穩定的直播服務。

作者簡介

朱明亮，同濟大學計算機模擬方向碩士畢業，蘇寧易購視訊雲資深架構師，主要負責蘇寧視訊雲的音視訊基礎平臺架構設計及研發。在音視訊編解碼、流媒體應用等領域有十餘年的架構設計及研發經驗，對視訊編解碼、流媒體、WebRTC 低延時直播、編解碼與 AI 結合方面深有研究。

感謝張嬋對本文的審校。