七牛直播云服務技術揭秘

以下根據七牛云首席布道師何李石現場演講內容整理。

直播模型及其實現

一個通用的直播模型一般包括三個模塊：主播方、服務器端和播放端。

首先是主播方，它是產生視頻流的源頭，由一系列流程組成：

第一，通過一定的設備來采集數據；
第二，將采集的這些視頻進行一系列的處理，比如水印、美顏和特效濾鏡等處理；
第三，將處理后的結果視頻編碼壓縮成可觀看可傳輸的視頻流；
第四，分發推流，即將壓縮后的視頻流通過網絡通道傳輸出去。

其次是播放端，播放端功能有兩個層面，第一個層面是關鍵性的需求；另一層面是業務層面的。

先看第一個層面，它涉及到一些非常關鍵的指標，比如秒開，在很多場景當中都有這樣的要求，然后是對于一些重要內容的版權保護。為了達到更好的效果，我們還需要配合服務端做智能解析，這在某些場景下也是關鍵性需求。再來看第二個層面也即業務層面的功能，對于一個社交直播產品來說，在播放端，觀眾希望能夠實時的看到主播端推過來的視頻流，并且和主播以及其他觀眾產生一定的互動，因此它可能包含一些像點贊、聊天和彈幕這樣的功能，以及禮物這樣更高級的道具。

我們知道，內容產生方和消費方一般都不是一一對應的。對于一個直播產品來講，最直觀的體現就是一個主播可能會有很多粉絲。因此，我們不能直接讓主播端和所有播放端進行點對點通信，這在技術上是做不到或者很有難度。主播方播出的視頻到達播放端之前，需要經過一系列的中間環節，也就是我們這里講的直播服務器端。

直播服務器端提供的最核心功能是收集主播端的視頻推流，并將其放大后推送給所有觀眾端。除了這個核心功能，還有很多運營級別的訴求，比如鑒權認證，視頻連線和實時轉碼，自動鑒黃，多屏合一，以及云端錄制存儲等功能。另外，對于一個主播端推出的視頻流，中間需要經過一些環節才能到達播放端，因此對中間環節的質量進行監控，以及根據這些監控來進行智能調度，也是非常重要的訴求。?

實際上無論是主播端還是播放端，他們的訴求都不會僅僅是拍攝視頻和播放視頻這么簡單。在這個核心訴求被滿足之后，還有很多關鍵訴求需要被滿足。比如，對于一個消費級的直播產品來說，除了這三大模塊之外，還需要實現一個業務服務端來進行推流和播放控制，以及所有用戶狀態的維持。如此，就構成了一個消費級可用的直播產品。

但是正如剛才所說的直播通用模型一樣，實際上這里很多功能都可以抽象成一個通用功能，也就是說各家直播產品的需求和實現方式都類似。我們再來看，如果把這些抽象出來的需求交給七牛這樣的第三方去實現，會有多大的差異。

七牛直播云解決方案

首先，對于推流端的功能，我們可以用一個 SDK 去覆蓋所有功能點，包括采集、處理、編碼和推流等工作，若有一些功能無法通過官方提供的 SDK 來滿足，可以通過自定義擴展的形式來實現。

其次，對于播放端，我們可以將其功能分類，和視頻播放相關的功能可以通過一個播放器 SDK 去實現。而其它功能如實時聊天，可以直接使用其它第三方服務。?

在直播服務器端，幾乎所有的工作都集中于如何更好的處理、分發視頻流，比如出于審核的目的對視頻進行自動鑒黃，為了更好的適配客戶端的網絡需要對視頻進行實時轉碼。?

我們發現，對于這三個模塊，幾乎所有直播產品的訴求都是類似的。因此七牛提供了一個這樣覆蓋主播端到播放端的直播云解決方案，它包括推流端 SDK 和播放端 SDK，以及一個強大的直播網絡，它既能滿足推流端和播放端在拍攝和播放方面的體驗訴求，也能夠通過定制化的方式來滿足在產品運營方面的訴求，比如給播放器加上彈幕和點贊等功能。

七牛直播云平臺主要包含直播云 API、推流端 SDK 和播放端 SDK 等三大模塊。接下來重點介紹七牛在推流端和播放端 SDK 方面的功能特性，以及它們在性能方面的表現。

SDK 功能特性

1）SDK?處理流程

如果把一個完整的直播流程用一個流水線來表達，它應該是這樣子的，如下圖所示。

七牛?SDK 的開放性表現為兩點：

數據采集源的開放性。我們提供了一個開放式的采集接口來進行視頻內容的采集，目前主要的采集源有手機屏幕采集和攝像頭采集。
可插拔的數據處理模塊。對于視頻內容的處理，目前我們提供了美顏、水印和基本的濾鏡功能，但它其實也提供了一個開放式的處理接口。?

除了開放性，七牛也支持了 H.264 和 H.265?等多種編碼標準。H.265 是一種更為高效的編碼標準，能夠在同等畫質效果下將內容的體積壓縮得更小，傳輸時更快更省帶寬。?

視頻流編碼完成后，則進入另一個常規的流程，進行推流、分發和播放。這樣，我們就完成了一個完整的直播流程，它包含采集、處理、編碼、推流、分發和播放等子流程。其中每一個子流程都是可插拔可替換的，而所有流程的子模塊也都具有靈活開放的輸入輸出接口，子模塊可以被任意的擴展或者替換。

2）SDK?功能點對比

直播流程里面的模塊化處理方式中，每個子流程都包含一系列開放可擴展的子模塊，這些子模塊對應多組不同的功能，以滿足各階段的需求。我們匯總了一些當前主播、觀眾以及 App 實現者最關注的功能，大概有 36 種。從這張圖可以看出，目前七牛的推流端和直播端 SDK 中實現了多達 32 種功能。

3）SDK 包大小對比

但是，對于七牛直播服務來說，要做到這么開放，又具備這么多功能點，需要一個多大的 SDK 呢？我們統計了一下，iOS 端的推流和播放 SDK 加起來，大概需要 5MB 左右，而業界的平均值則是 11MB。Android 端由于需要適配的硬件設備和軟件系統太多，SDK 的大小大概在 18MB 左右，業界的均值則在 42MB。

SDK 性能對比

我們提供了一個開放的 SDK 處理流程，在這個流程中每個環節都提供了非常豐富的關鍵功能，能夠滿足大部分場景下的需求，同時又保證了包含所有這些功能特性的 SDK 不會太大。那么，它在性能方面的表現如何呢？?

1）資源占比?

除了程序 Bug 導致的主動崩潰之外，一個 App 的穩定性主要由兩方面影響：內存和 CPU，因此第三方 SDK 在這兩方面的表現將直接影響 App 的穩定性。而對于一個視頻推流和播放 App 來說，CPU 是其最重要的資源之一。

我們先來看一下七牛 SDK 在 CPU 占比方面的情況。上下兩張圖分別是推流和播放 SDK 在經過多次反復測試后得出的 CPU 占比均值曲線圖。從圖中可以看出，無論是推流端還是播放端，七牛 SDK 在 CPU 使用率方面都占比最少。

我們再來看一下內存占比，上下兩圖也分別給出了推流和播放 SDK 在多次反復測試后得出的內存占比均值曲線圖，從圖中可以看出，我們 SDK 在推流和播放的時候內存使用情況表現非常平穩，而內存的使用量也在業界均值之下，接近于最好的值。這個數據之所以沒有達到最好值，是因為我們經過反復測試發現頻繁的對內存進行回收（Android）會導致編碼的不穩定，實際上這個指標確實可以優化到最好，只不過可能會導致內存和 CPU 波動較大，進而影響整個過程的編碼效率。對于這樣的權衡，我們大多數客戶也非常認可，這也是他們選擇我們的 SDK 原因之一，這點從我們 Github 庫上的關注度就可以看出。