Apsara Video SDK：基本概念

產品定義

MediaBox音視頻SDK

MediaBox音視頻SDK整合了直播推流SDK、播放器SDK、短視頻SDK、美顏特效SDK等產品，為AUI Kits低代碼應用方案提供端側音視頻能力，例如推流、連麥、播放、IM互動等功能。您可以一站式擷取完備的音視頻能力，實現業務敏捷創新。更多資訊，請參見什麼是音視頻終端SDK。

AUI Kits

AUI Kits低代碼整合工具是阿里雲基於豐富的音視頻實踐沉澱，提供的aPaaS產品，對MediaBox音視頻SDK進行模組化封裝，提供標準化的開源UI組件。您可以根據業務需求直接使用AUI Kits進行接入，降低研發成本和周期，提升業務效果。

AppServer

AppServer基於Function Compute（FC）等方式為AUI Kits低代碼整合工具提供了一套快捷部署、靈活定製的後台服務。直播間AppServer為AUI Kits互動直播情境SDK提供了房間管理、連麥管理、使用者鑒權、信令管理等功能，只需要5~10分鐘即可完成後台服務搭建。您也可以通過容器鏡像或原始碼構建等方式進行部署。

RTS 1.0與RTS 2.0的區別

流媒體

點播、直播和推流的區別

• 推流：主播將本地音視頻源推送到阿里雲視頻雲端服務器。

• 直播：直接觀看主播用戶端或直播中心即時推送過來的音視頻資料，時間延遲一般不會太長。

• 點播：視頻源已經事先儲存於阿里雲視頻雲媒資庫內，觀眾隨時可以觀看。

常見的點播協議

目前常見的點播格式有3種：MP4、HLS和FLV。

• MP4：MP4是一種經典的檔案格式，廣泛支援移動終端和瀏覽器（包括iOS和大部分Android裝置上的系統瀏覽器以及PC上的FLASH控制項）。然而，MP4的視頻檔案格式相對複雜，處理成本較高，並且由於其複雜的索引表結構，導致較長時間長度（如半小時）的MP4檔案線上播放時載入速度較慢，更適用於點播短視頻情境。

• HLS：由蘋果公司推出的標準，在移動終端的瀏覽器上具有很好的支援。但在IE上的支援情況取決於FLASH的二次開發工作（建議使用阿里雲播放器SDK Web端）。HLS採用簡潔的M3U8索引結構，能夠避免MP4索引慢的問題，常用於點播中長視頻情境。

• FLV：Adobe公司推出的標準，目前是直播平台最常用的封裝格式，在PC端具有強大的FLASH支援，但在移動終端只有通過App實現播放器才能支援，大部分手機端瀏覽器均不支援。

常見的直播協議

目前常見的直播協議有3種：RTMP、FLV和HLS。

• RTMP：RTMP協議是一種功能強大的協議，可以用於推送和直播。核心理念是將視訊框架和音訊框架分割成小資料包，並在互連網上進行傳輸。此外，RTMP協議還支援加密，因此具有較高的隱私性。然而，由於拆包和組包的複雜性，當面對海量並發時，可能會出現一些不可預測的穩定性問題。

• FLV：Adobe公司推出的標準，該協議的格式非常簡單。它只是在視訊框架和視頻頭部添加了一些標記頭資訊。由於其極簡的設計，FLV協議在延遲表現和大規模並發方面非常成熟。唯一的缺點是在移動端瀏覽器上的支援非常有限。然而，作為移動端App直播協議，FLV協議非常適用。

• HLS：由蘋果公司推出的標準，將視頻分割為5~10秒的小切片，並使用M3U8索引表進行管理。用戶端下載到的視頻都是5~10秒的完整資料，因此視頻的流暢性很好。然而，這種方法也會引入較大的延遲，一般為10~30秒（HLS的常見延遲範圍）。與FLV相比，HLS在iPhone和大多數Android手機瀏覽器上的支援非常好。

常見的推流協議

目前常見的推流協議是RTMP，阿里雲視頻雲還支援超低延時直播RTS推流。

• RTMP：由主播端向直播中心伺服器推流一般採用RTMP協議。

• RTS：超低延時直播RTS是阿里雲ApsaraVideo for Live的重要增值功能，可以提供用戶端易接入、超低延時、高並發、高清流暢的ApsaraVideo for Live服務。

SDK整合與使用

SDK License

MediaBox音視頻SDK是阿里雲視頻雲推出的終端SDK，提供情境化的終端音視頻能力，您可以通過申請免費License、付費購買或消費達標贈送擷取SDK的使用授權。

SDK License通過與應用標識一一綁定以實現對該應用調用SDK進行授權。例如，當一個播放器SDK的License與應用A綁定後，應用A就可以使用播放器SDK的功能，每一個License最多可以綁定一款Android應用和iOS應用。您也可以在ApsaraVideo for Live、ApsaraVideo for VOD控制台上新增和續期License，計費詳情請參見計費項目。

在控制台上完成建立應用並綁定License後，會產生一套License File（認證檔案）和License Key。在MediaBox音視頻SDK整合過程中，您需要將License File和Key配置到對應的應用中。MediaBox音視頻SDK將通過License File和Key來校正當前應用的授權情況。每個阿里雲帳號下預設產生唯一的License Key，按照應用維度產生License File，不論License授權的內容和類型，這組License File和Key都是唯一且不會變更。

命名衝突（duplicate symbol）

在整合MediaBox音視頻SDK時常遇到的一種編譯錯誤，因為一個進程中不能有重名函數（編譯器會將函數編譯成symbol），如果出現重複的，就會給連結器帶來“選擇困難症”。

目前，阿里雲視頻雲終端SDK之間，由於媒體組件化架構設計，不同SDK之間會存在衝突。如果需要用到兩個業務功能情境，請使用功能情境一體化包。例如短視頻和播放器業務，請使用AliVCSDK_UGC包，不僅在功能上一致，而且做到更小的包體積。

直播推流SDK

碼率控制

一種編碼的最佳化演算法，用於控制視頻流碼流的大小。同樣的視頻編碼格式，碼流越大，包含的資訊越多，對應的映像也就越清晰，反之亦然。

視頻丟幀

發送視訊框架時，如果網路非常差，導致視訊框架堆積嚴重，可以通過丟棄視訊框架來縮短推流的延時。

耳返

指主播可以通過耳機即時聽到自己的聲音。例如，當主播帶上耳機唱歌時，需要把握音調，這時就需要開啟耳返功能。因為聲音通過網路傳入耳朵和通過空氣傳入耳朵差異很大，而主播需要直接聽到觀眾端的效果。

混音

把多種來源的聲音整合至一個立體音軌或單音音軌中，推流SDK支援音樂和人聲的混音。

合流

把多種來源的視頻映像資料根據位置疊加到同一個視頻畫面中。目前僅Android推流SDK支援。

動態庫

即動態連結程式庫，與常用的靜態庫相反。動態庫在編譯時間並不會被拷貝到目標程式中，目標程式中只會儲存指向動態庫的引用。在程式運行時，動態庫才會被真正載入進來。

短視頻SDK

視頻解析度、碼率

視頻解析度指的是視頻橫向和縱向上的有效像素，理論上視頻解析度越高，映像越清晰。但解析度越高也意味著檔案越大，處理越耗時。考慮到移動端不同裝置效能差異，不建議直接使用螢幕像素值作為視頻解析度，建議設定解析度720P及以下。

碼率又叫位元速率，指的是每秒傳送的位元（bit）數。單位為bps（Bit Per Second）。壓縮視頻時給視頻指定碼率參數，用以告訴視頻編碼器期望的壓縮後視頻的大小。在一定範圍內，碼率越高，視頻越清晰，檔案也越大。

常見的視頻解析度及建議碼率如下：

幀率

視訊框架率指的是每秒鐘顯示的映像幀數，單位Frame per Second(fps)。幀率越高，映像越流暢，檔案也越大。建議視訊框架率：25~30。

主要畫面格

幀是組成視頻映像的基本單位，視頻檔案是由多個連續的幀組成。主要畫面格也叫I幀，它是幀間壓縮編碼裡的重要幀，解碼時僅用I幀的資料就可重構完整映像，I幀不需要參考其他畫面而產生。主要畫面格可以做為隨機訪問（seek）的參考點，可以當成映像。

GOP

Group of Picture（以下簡稱GOP）顧名思義就是有一組幀組成的一個序列。一個GOP由主要畫面格開始，後面跟隨者一組B幀和P幀。GOP過小，會導致I幀的比例增高，壓縮比降低。GOP過大，會導致隨機訪問（seek）更耗時，同時，會導致倒播卡頓（倒播需要解碼一個GOP才能播放視訊框架）。SDK中GOP預設值為5，建議GOP值為5~30。

填充模式

當素材圖片或視頻的解析度長寬比與匯出視頻解析度長寬比不一致時，會涉及填充模式的選擇。SDK支援兩種填充模式：

編碼方式

編碼方式有以下兩種：

資源說明

SDK資源主要包括Face Service模型資源、濾鏡資源和動效濾鏡資源。SDK資源可以儲存到網路端，也可以直接內資到安裝包中。考慮到SDK下載包的大小，建議您將SDK資源儲存到網路端，在啟動App時下載。

支援格式

支援匯入的媒資格式：

視頻合拍

視頻合拍從產品功能層面是指兩路視頻（一路來自樣本視頻，一路來自裝置網路攝影機採集）按照指定的配置模式（左右分屏、上下分屏、畫中畫等）進行合成，合成的視頻每一幀畫面將會同時包含兩路視頻的畫面，而合拍視頻的音頻部分則採用樣本視頻的音頻。以下為範例視圖，實際上SDK內部支援開發人員自己組織布局，關於如何布局將在後面講述。

多源錄製

多源錄製可以支援View錄製、網路攝影機錄製等多種視頻採集源按需組合的合拍錄製。從產品功能層面是指多個畫面資料來源（例如View錄製採集的畫面資料、網路攝影機採集的畫面資料），按照指定的配置模式（左右分屏、上下分屏、畫中畫等）進行合成，合成出來的視頻每一幀畫面將會同時包含上訴畫面資料來源。以下為範例視圖，實際上可支援開發人員自己組織布局，關於如何布局將在後面講述。

軌道

• 在上述視頻合拍概念中提及的兩路視頻在SDK中被抽象為兩個軌道：A軌道和B軌道，A軌道放裝置採集的視頻，B軌道放樣本視頻，用軌道抽象有利於您理解軌道布局的概念。

• 在上述多源錄製中提及的多路畫面資料來源在SDK中被抽象為多個軌道，如A軌道放網路攝影機採集畫面，B軌道放View錄製採集畫面，用軌道抽象有利於您理解軌道布局的概念。

軌道布局

軌道布局是軌道的屬性之一，用來描述該軌道的視頻畫面，在合拍產生的視頻中如何“擺放”，軌道布局在一個歸一化的座標系中，從兩個緯度來描述軌道布局資訊，分別是中心點的座標和軌道size（即寬高資訊）。

• 視頻合拍的軌道布局如下圖所示：

  

  在該布局畫面中，軌道A和軌道B的畫面各佔一半，因此，兩個軌道的寬度均為0.5，而高度則都為1.0，而軌道A的中心點座標：(0.25,0.5)，軌道B的中心點座標：(0.75,0.5)。

• 多源錄製的軌道布局如下圖所示：

  

  在該布局畫面中，軌道A和軌道B的畫面各佔一半，因此，兩個軌道的寬度均為0.5，而高度則都為1.0，而軌道A的中心點座標：(0.25,0.5)，軌道B的中心點座標：(0.75,0.5)。