# 一、概述

2019年vivo直播平臺立項，初期與優秀的頂部直播平臺進行聯運直播開發，進行市場，產品和技術的初步探索；再到後來為了豐富直播的內容和形式，開始自己獨立探索；之後，我們結合vivo現階段的直播業務，陸續完成了泛娛樂，互動，公司事件直播等多種直播形式的落地，相信後續根據業務的規劃，我們會給使用者帶來更好的直播體驗。

今天和大家分享一下，vivo直播平臺這兩年相關的技術發展歷程，希望大家對直播有一個基礎的瞭解，如果有相關的同學剛剛開始從事直播相關業務的開發，能夠給大家帶來一些啟發。

# 二、業務背景介紹

截止到目前為止，vivo直播平臺支援三個大類的直播，第一個就是經典的泛娛樂秀場直播，平臺提供秀場直播一些標準的功能，例如互動聊天，PK，送禮等基礎功能。泛娛樂直播市場起步比較早，相關的功能玩法也比較豐富和多樣，例如主播連麥PK,主播與使用者連麥互動，禮物連擊，事件榜單，你畫我猜等等相關的娛樂功能，目前平臺正在持續迭代相關經典的功能，持續給使用者帶來更好的使用者體驗。

第二種型別的直播就是目前基於實時音影片技術的低時延互動直播，低時延直播的特點就是互動性強，使用者的參與感強，與之而來的就是較強的技術挑戰和較高的維護成本。

第三種，就是目前在疫情的大背景下，誕生了公司資訊分發的事件直播，例如公司年會，校招宣講會直播，品牌文化直播，疫情防護知識直播。這類直播的最大特點就是靈活、多變、且內容形式多樣。對於直播平臺來說，我們需要為其提供一站式的直播解決方案，方便公司利用直播這種形式進行更好更穩定的品牌，文化的宣發。

![圖片](https://static001.geekbang.org/infoq/67/67a7fcdad495b4ae977447f56539767f.webp)

首先，我們再來看下vivo直播平臺的一個業務架構模型，底層是我們的公司全鏈路監控平臺，會對直播流量、網路、相關直播業務的資料指標進行監控，並提供相關告警服務，便於我們能夠第一時間響應、定位並解決直播在各個模組在分發過程中遇到的一些實際問題。

在此監控之上，我們進行上層業務的邏輯迭代。在直播內容的分發上，主要的方式還是依賴於雲廠商的CDN和我們內部的直播伺服器叢集。一種是C端的直接流量分發，另一種是透過內部轉拉進行相關的業務處理。在業務能力方面，目前我們已經初步具備瞭如下一些基礎能力，例如海量的資訊儲存、影片處理、內容識別、直播影片內容的安全合規實時稽核及直播間事件同步非同步處理等能力。同時基於這些能力進行SDK的封裝，例如推流、播放、IM 等場景化SDK，透過提供標準的SDK進行直播能力的分發和複用，同時也能夠方便業務方進行功能的整合。

在內容產出和對外服務上，我們對自己的手機APP，例如i影片、vivo短影片、i音樂、瀏覽器等APP進行直播能力的賦能，豐富消費者的手機體驗。此外，除了對vivo相關手機APP進行直播能力的支援外，我們也會和第三方直播平臺進行合作，做一些內容的分發和轉播。

![圖片](https://static001.geekbang.org/infoq/51/51aba4bd78b8296664e4da7c30344533.webp)

# 三、技術實踐

## 3.1 泛娛樂秀場直播

首先，我們先介紹一下最經典的泛娛樂秀場直播，如下圖所示，這是一套基於RTMP協議的標準直播流程。

![圖片](https://static001.geekbang.org/infoq/e4/e4d80d9c4b8a22fcad550b8d251e3d14.webp)

一般過程如下，首先進行輸入源的採集，一般由螢幕、攝像頭、麥克風等進行相關採集；接下來對其進行影像加工，例如美顏，濾鏡，水印等；之後進行標準的h264編碼，利用RTMP協議傳輸，傳輸到中心機房對相關事件做好相應的處理後，最後分發到邊緣節點，使用者終端逆向去邊緣節點拉取直播流，最後在終端裝置解碼播放。在此標準觀看流程之上，泛娛樂秀場直播也會提供一些常見的功能，例如互動聊天，直播間小遊戲，PK ，送禮等等。

這一套標準直播流程涉及到的直播技術點也特別多，接下來和大傢俱體聊一聊我們團隊在落地相關直播業務過程中遇到的一些實際問題。

我們遇到如下四個問題，開播工具的推流美顏就是我們遇到的第一個技術難點，主播眾多，對“美”的定義不一，主觀性強，個性化需求多，在貼紙，色溫，畫面的飽和感等方面要求較高，同時在開播過程中，要求面部的不抖動不失真，同時對直播畫面的清晰度，顆粒感也有相關的要求。

第二個問題就是訊息的分發，也就是我們傳統說的IM即時通訊技術，與傳統的即時通訊技術不一樣的是，除了群聊，私聊，廣播這些經典的IM訊息分發場景外，“群”成員不穩定也是我們需要考慮的，使用者頻繁進出直播間，切換直播間，晚高峰的訊息風暴和流量突刺，也是我們需要應對和解決的問題。

第三個問題就是直播時延的問題，這也是直播經典的問題之一，引起時延的因素很多，例如終端裝置，傳輸協議，網路頻寬，編解碼等等。

最後一個問題，就是直播成本的問題，想必做過直播的相關友商，都會清楚地知道，RTMP和CDN不分家，作為基礎的雲服務產品，CDN對於這種流媒體的分發，計費也是相對比較貴的，所以我們也要在確保產品功能和使用者體驗的基礎上，兼顧控制我們的直播成本。

![](https://static001.geekbang.org/infoq/96/964c57e66057187720162c86ea35e6ff.png)

針對第一個技術難點，我們做了如下處理，我們在端上進行了一些技術最佳化。在美顏方面，充分利用了公司影像團隊相關的技術積累，對美顏，濾鏡，貼紙，美妝，風格妝都進行了標準化，通用化，定製化的處理。

同時我們在推流模組也做了一系列的實驗，進行雲端轉碼，超分，銳化等處理，確保每一個主播的畫風具備一定的觀眾吸引力。禮物動畫播放部分，經過多次實驗採用MP4進行特效禮物動畫播放，測試資料表明，MP4相對於svga佔用的記憶體和檔案大小顯著降低。最後在直播間秒開這個重要指標上，播放器核心團隊對播放器進行了定製化處理，透過共享播放器、滑動、點選預建立等方式，使得直播間秒開這個指標能夠達到行業內一流標準。

![](https://static001.geekbang.org/infoq/9f/9f675e169f5cc2d241aae94d6a75ff7b.png)

第二部分，我們再介紹一下直播的另一個問題，就是即時訊息的處理，潛在的問題可以從以下兩個維度進行分析。首先是使用者維度，使用者的主動行為包括送禮，禮物連擊、點贊，互動聊天，以及在開播時瞬間湧入的大量的使用者，這些場景都會引起IM的訊息洪峰，使得伺服器的負載壓力一下子會提高很多，縱使我們把IM模組元件化，進行模組間的隔離，但是突發的IM流量也會影響其他高優先順序或者系統訊息的分發。

第二個方面就是系統維度，在群  發訊息的場景下，也會有一個讀擴散的問題，並且針對直播間這個場景，導致我們IM分發的也都是結構化的資料，有些特別複雜的業務場景，結構化的資料包體積也比較大，在這種情況下如果瞬時分發的訊息比較多，會導致機房的出口頻寬存在一定的壓力；第二個影響因素就是手機終端訊息處理能力也有一定的限制，如果分發過多的訊息，而部分訊息的特效又比較複雜的話，部分低端手機機型會存在無法即時處理的問題。

在這些場景限制下，我們做了如下的三個方案，第一就是訊息推拉結合，業務流量高峰IM長連結和http短輪詢共同作業；第二個就是訊息使用protobuf壓縮和分級限頻，對直播間的訊息進行業務和主播兩個維度分級，限制不同型別不同直播間分發的頻率；最後一個方案就是監控降級，我們可以對指定直播間進行監控，在監控出現問題的時候，能夠自動切換訊息分發的方式，確保訊息的到達率。

![圖片](https://static001.geekbang.org/infoq/64/6405290a9bea56a455e1279217702e06.webp)

第三個就是直播時延問題，其實在直播時延的問題的處理上，我們希望能夠做到在特定的直播場景下規避不必要的時延，從而能夠達到標準的直播時延，而不是一味的追求極致的低時延。要解決直播時延的問題，首先我們要分析出產生時延的幾個環節，並且梳理這些環節上我們能夠做的最佳化。採集端主要受快取策略和資料編碼所影響，同時網路環境、傳輸協議和物理距離也都會對時延產生一定的影響，針對這些問題，我們收集了主播的手機型號和實際網路環境，根據實際情況進行相應清晰度的編碼，弱化機型和網路對直播的影響。

其次我們都知道另外80%的時延是在下游CDN播放環節產生的，在播放端，為了抗卡頓，需要做緩衝自適應，位元速率自適應，前向糾錯，丟包重傳等工作，因為協議本身的限制，我們只能根據不同的使用者終端分發不同協議和不同清晰度的觀看連結，同時我們針對特殊的場景引入新的直播協議，例如WebRTC,QUIC,SRT等。

最後一個方面，就是泛娛樂直播成本問題，作為業務部門，成本也是我們一直關注的，直播的費用主要有儲存和頻寬兩個主要組成部分，我們做了如下三個方面的最佳化，儲存上，我們首先將主播的錄影進行轉碼，降低儲存檔案的大小，其次對主播進行熱度分級，進行不同時間的儲存處理，最後也會剪輯相關的精彩瞬間，在符合國家相關法規的基礎上，刪除原檔案，從而降低儲存的費用。

第二個就是基礎服務CDN費用，雲廠商的收費方式有按照頻寬峰值和流量這兩種，所以我們也會從業務的角度上，進行一定程度的策略最佳化，針對推送場景，我們會分批次分時間段進行推送，防止大量直播觀看使用者同時瞬時湧入直播間，打高直播的頻寬峰值。同時觀看端支援多清晰度，根據業務出現的不同流量時間段，分發不同清晰度的觀看連結，最後從策略上進行限制，在進行主播運營的時候，進行科學的開播時間規劃，防止高流量主播扎堆開播，造成不必要的峰值頻寬而帶來的額外流量費用，最後一個就是監控，對每一個週期的費用進行判斷和計算，透過實際的使用情況，對下一個週期進行階段性調整，確保能夠得到階段收費較優解。

![圖片](https://static001.geekbang.org/infoq/6d/6d057a49a1e65c09b2109509ccd7389c.webp)

## 3.2 互動直播

分析完了泛娛樂秀場直播的幾個經典問題的解決方案後，我們也來也介紹一下目前如火如荼的低時延的互動直播，互動直播核心特點就是超低時延，互動性強，在一定的業務場景下，對各類訊息分發的順序性和實時性的要求也特別高，目前常見的互動直播，目前業界內落地比較好的場景就是電商，教育，連麥互動娛樂，政企直播等。

與互動直播相關的功能和技術主要如上所示，例如多端的資訊同步，媒體處理，與泛娛樂直播相比，在流媒體安全稽核，多使用者終端一致性上，也有更加嚴格的要求，相關的技術棧，很大一部分都是基於實時音影片技術，並且也會結合一下SEI技術，進行資訊順序同步，一般來說，是可以滿足業務的需求。

我們在落地互動直播的時候主要遇到兩個業務痛點，第一個痛點就是，基於RTMP協議的一個冗長的直播鏈路的秒級時延是很難勝任的，並且基於RTMP協議的多終端媒體流畫面處理，例如連麥，混流。靜音等場景，RTMP處理相對複雜，且不利於多終端同步。第二個方面就是資訊管控方面，資訊管控也是我們在實際開發過程中遇到的問題，例如終端一致性管控，流媒體安全管控，異常管控等。在實際生產環境下，因為存在大量的多終端的互動，互動過程中產生大量的訊息，部分業務場景會存在訊息分發的時候出現延遲、順序錯亂、甚至丟失，最終導致各個業務終端出現狀態不一致的問題，這也是目前，互動直播除了時延外，另一個比較明顯的問題。

![](https://static001.geekbang.org/infoq/c9/c93415e44c48009d9317daf9682b30cd.png)

針對互動直播的低時延多互動的業務特點，目前業內的標準解決方案是RTC相關的技術， RTC與RTMP+CDN這兩個解決方案從技術特點上來說，是完全不一樣的，RTMP的技術特點就是與CDN繫結耦合，RTMP需要藉助CDN邊緣網路的能力，使得多地區的使用者能夠就近獲取直播內容，並且能夠提高使用者獲取直播影片流的成功率和秒開率，但是也是因為受限於網路協議等因素，帶來了對應的延遲是RTMP技術協議棧所無法避免的。而RTC的也有兩個比較明顯的技術特點，基於UDP協議的RTC理論時延在百毫秒內，第二個特點就是藉助SFU和MCU通訊方式適合做多端互動，當然，在多端互動的場景下RTC對機器和網路的要求也比較高，所以我們也會針對指定場景，運用不同的相關技術去解決實際問題。

![圖片](https://static001.geekbang.org/infoq/ca/ca174494c0e69b93a66f36e9d0fb81b4.webp)

在互動直播的開發過程中，我們遇到了資訊管控的一系列問題，首當其衝的就是**一致性管控**，互動直播業務內容資訊和流媒體資訊強相關，需要實時進行無差別的資訊順序傳遞，我們做了如下的一些補償控制，進行客戶端單個和批次資訊上報，由服務端糾正個別終端的異常狀態；第二就是合理使用SEI，在影片流資訊攜帶少量的業務資訊，例如K歌房、帶貨、直播答題等，這樣能夠保證資訊的一致性和同步性。

第二個就是**安全性管控**，按照國家相關規定，音影片直播內容是否違規是相關部門重點稽核的物件，在秀場直播這邊，我們目前做了影片流定時截幀稽核，使用機審和人審雙重稽核機制，互動直播方面，則會對每一個終端進行獨立稽核，精確識別出違規的互動終端，最終打造綠色健康的直播環境。最後一個場景也是業務複雜性決定的，正因為互動終端裝置多。人為、網路、裝置等因素導致異常機率也大大增加，所以我們要準備快速識別斷流，有效地利用回撥或者客戶端能力範圍內的上報，在做好業務校驗後，進行相關的異常恢復流程的處理。第二就是利用心跳檢測機制，客戶端定時上報心跳，如果服務端超過指定次數沒有收到相關的心跳，就能識別出該裝置出現異常，同樣進行相關的異常邏輯處理。

## 3.3 事件直播

最後一個模組，我們再重點介紹一下直播平臺給公司內部相關業務進行直播賦能的案例。vivo公司日常也會有很多官方的事件直播，例如技術分享、校招宣講會、疫情知識宣講、品牌形象直播，以及更具有官方性的手機釋出會直播。

**為什麼在這裡會重點提及公司直播呢？**

首先就是官方組織，影響面比較巨大，受眾群體也比其他型別的直播更大，我們投入開發運維和保障直播的精力也會相比其他直播更多。在公司直播這塊也進行了一些技術的歸納和總結。首先需要保證整場直播的穩定性和流暢性，我們對網路進行相關的監控和最佳化，同時搭建多地域的內部直播伺服器做好多地域的流量隔離和負載均衡。另一個方面就是針對靈活性的技術支援，為了節省我們的開發時間，在助力幾場大型公司直播之後，我們也系統地進行整理，歸納出一些通用的功能SDK,透過使用這些多次實踐證明沒有問題的SDK能夠降低直播出錯的機率，也能夠提高整場直播的成功率。

接下來講兩個比較有意思的案例，也是我們在探索實踐公司內部直播幾個比較有趣且實用的案例，第一個案例就是我們去年公司因為疫情的原因，只能舉辦線上直播年會，vivo的員工辦公地點很多，坐落在全國各個地方，所以如何高效地保障國內外多個辦公地點的萬名員工同時高畫質觀看就是我們當時需要解決的問題。

這個問題的根本原因就是每個辦公地區的出口頻寬是有限的，如果公司員工都使用公司無線網路觀看的時候，會導致個辦公地區的出口頻寬被打滿，從而會影響部分員工觀看的體驗，甚至會影響大家的日常辦公。

針對頻寬限制的問題，一般而言，業界有兩個比較通用的解決方案；

-   臨時提高各個辦公地點網路運營商的出口頻寬；
    
-   透過降低直播的位元速率以來降低頻寬的壓力和成本。

其實這兩種方案都不能完全保障直播沒有問題，並且前提還是需要犧牲部分使用者的觀看體驗的基礎上，這種方案也是很難接受的。最後落地併成功實踐的方案就是透過內網轉推，內網伺服器再做負載均衡，並且不同辦公地點的觀看請求透過DNS解析到本地辦公地點的直播伺服器，這樣就可以成功解決頻寬的問題，並且還可以支援高畫質4k的清晰度。目前這個能力已經被多次驗證可行，相關的實踐細節也在多家權威技術網站發表，得到社群的一致好評，如果大家有興趣可以進行相關的查閱。

![圖片](https://static001.geekbang.org/infoq/e2/e28324086b27af74bf1b210ede280192.webp)

第二個有趣的案例，就是公司日常的釋出會、宣講會，需要同時推流到多個第三方直播平臺，例如B站，騰訊直播等等。因為推流裝置推流有個數限制，無法支援多個推流地址，之前的方案都是協調各個直播轉播合作伙伴，拉群同步一個拉流地址，每次都會有大量的協調溝通確認工作，很大程度上影響大家的效率，並且很容易出現部分合作商因為配置錯誤，導致無法正常直播。

在這個大的背景下，我們做出了一些調整，透過整合內部直播伺服器和雲直播伺服器，做好對應的網路容災，在主線網路出現問題的時候，能夠系統自動識別並更換到另一個推流叢集，最終保證直播全程的流暢性和穩定性，此外我們還搭建了人工運營平臺，提前系統的配置好相關的地址，並且透過開放平臺，合作方可以臨時去修改相關的配置，這樣可以大大降低人工配置錯誤的可能性，可以更高效率的對公司相關的直播進行支援。

![](https://static001.geekbang.org/infoq/41/4118fe3c07f107c2186a07b4850a9c86.png)

# 四、總結

![圖片](https://static001.geekbang.org/infoq/0c/0ca2b2162910b5d9f2bd93847cdba955.webp)

目前vivo直播平臺還處於初步搭建和不斷摸索的過程中，不過我們的方向和規劃是清晰的，就是透過不斷地豐富C端直播形式，引入更多形式的直播，給vivo手機使用者帶來更好的使用者體驗，同時進行相關技術的沉澱和積累，最後把這些技術形成一些標準的解決方案，向公司的橫向部門進行內容和技術的產出，例如技術SDK服務，內部直播服務，直播短影片服務等等，形成內外平臺相互反哺的良性迴圈。

> 作者：vivo網際網路伺服器團隊-Li Guolin

vivo直播應用技術實踐與探索

相關文章