為應對愈發多樣化的音視訊互動場景下的挑戰，Agora 開始設計自己的下一代視訊處理引擎，在過程中關于引擎架構、性能調優、插件系統設計等方面總結了很多經驗，希望與各位音視訊領域的愛好者、行業從業者分享。
5月26日下午，QCon全球軟體開發大會「實時音視訊專場」活動中，聲網Agora 架構師李雅琪帶來了以《聲網下一代視訊處理引擎》為主題的大量幹貨分享，本文是對分享内容的整理。
今天的分享主要會分三部分來進行：
一，為什麼我們要打造下一代視訊處理引擎，以及引擎的設計原則和目标是什麼；
二，我們是如何達到設計原則和目标的；
三，下一代視訊引擎的實際落地效果如何。
随着音視訊技術快速發展，實時音視訊互動在各種各樣的領域，如社交娛樂、線上直播、醫療中都得到了廣泛的應用和發展。疫情以來，越來越多的場景遷移到線上，不少讀者可能也都有觀看直播帶貨，或是陪小孩參加線上教育的經曆。
那麼這兩個場景中會有哪些痛點呢？在視訊直播場景中，處理多路視訊源的需求越來越廣泛。比如電商直播場景中，主播通常需要使用多個機位進行多角度拍攝，以達到更好的帶貨效果。這類直播可能還會同步搭配使用導播台，在多個視訊源中進行多種實時直播組合和無縫切換。
而對于線上教育場景來說，比較傳統的方式是攝像頭拍攝老師，老師進行螢幕分享。為了豐富線上教育的手段，我們還可以增加一路視訊拍攝，拍攝老師在手寫闆上的書寫，甚至額外增加一個功能，支援老師播放本地課件或者線上課件。
在多路視訊源的基礎上，還會衍生出來對多路視訊源的實時編輯和合圖的需求。在直播助手的應用場景中，主播可能需要對多路視訊源的采集進行實時合圖和編輯，再添加本地素材和動态表情包來豐富直播效果，同時降低上行帶寬壓力。在多人互動場景中，為了降低接收端的帶寬壓力和性能損耗，需要在雲端将多路主播視訊合成一路流再發送給各個接收端。
随着 AI 技術在圖像處理的快速發展，融合 AI 算法的進階視訊前處理功能也得到越來越多的應用，諸如一些進階美顔功能、背景分割、背景替換。結合這三個場景我們可以看到，下一代視訊引擎的靈活可擴充能力被提出了更高的要求。
另外，随着我們公司業務和團隊規模的不斷增長，下一代視訊引擎的使用者體量也在劇增，不同使用者對內建開發的需求也各異。對于研發團隊規模較小的開發者或個人開發者，他們需要的是引擎的內建簡易度，低代碼量，快速上線。而對于企業業務中台的開發者，會要求引擎開放更多的基礎視訊處理功能，進而可以定制化的實作視訊處理業務。
面向各開發者群體的需求，聲網的下一代視訊處理引擎需要一個有彈性的設計來滿足差異化的內建需求。
不僅是彈性的設計，視訊直播體驗也是很重要的名額。随着 5G 時代的到來，網絡基礎設施足夠支援使用者對更清晰更流暢直播的體驗需求，下一代 SDK 必須在性能優化方面做到極緻，支援更高的視訊分辨率，更高的幀率。考慮到實時互動業務場景不斷擴充，使用者分布也越來越廣，為了在網絡基礎設施較弱的國家和地區、性能較差的低端機型上，引擎都可以提供比較好的視訊直播體驗，我們就要支撐更好的弱網抗性，并優化性能資源消耗。
結合上面提到的場景豐富性、使用者差異性，以及對視訊直播體驗的需求。我們将下一代視訊處理引擎設計原則和目标可以總結為四個方面：
1. 滿足不同的使用者對內建的差異化需求；
2. 靈活可擴充，可快速支撐各種新業務和新技術場景落地；
3. 視訊處理引擎的核心系統要提供豐富強大的功能，降低開發人員的心智負擔，做到快速可靠；
4. 性能優越可監控，需要持續優化視訊直播處理引擎性能，同時提高監控手段，形成閉環并不斷疊代優化引擎的處理性能。
接下來我們進入第二部分，針對上面所提到的四個設計目标，聲網具體采用了哪些軟體設計的方法來進行實施落地。
前面提到的第一個設計目标，我們要滿足不同使用者差異化的內建需求：引擎的使用者是天然分層的，一部分使用者追求低代碼快速上線，需要引擎盡可能提供貼近他業務的功能；另外一部分使用者，需要我們提供更多的核心視訊基礎能力，在這之上客戶可以按照自己的需要定制視訊處理業務。
根據這個使用者形态我們的架構也采取分層業務設計，分成 High Level 和 Low Level。Low level 部分是面向視訊處理核心功能進行模組化，抽象出了視訊源處理單元，前/後處理單元、渲染器單元、編解碼器單元、核心基礎設施單元等。通過這些基礎子產品的組合和開發，在 Low level 的基礎上，我們又抽象出面向客戶業務的視訊源 Track 的概念，網絡視訊流 Stream 的概念和場景的概念，在這上面封裝了更貼近使用者業務的 High Level API 。
我們來通過實際例子看一下 High Level 和 Low Level 兩者在使用上的差别：假設現在要實作一個非常簡單的場景，打開本地攝像頭開啟預覽，釋出到遠端。
如果使用 High Level API，可以隻通過 2 個簡單 API 的調用，完成這個實時互動業務場景的搭建。首先通過 StartPreview API 開啟本地攝像頭并預覽，然後通過 JoinChannel API 加入頻道并釋出視訊流。若使用者想在這一簡單場景上實作更多定制業務功能，就可以使用 Low Level API。首先建立本地相機采集管線 CreateCameraTrack，這個 Track 提供了多種多樣進行形态組建和狀态控制的接口。同時我們将本地媒體處理和網絡釋出節點進行了解耦，視訊流可以釋出到聲網自研的 RTC 系統中去或釋出到 CDN 網絡。
通過上面的例子可以看出。為了滿足使用者差異化需求我們采用了分層設計，High Level 面向業務提供易用性，Low Level 提供核心功能和靈活性。
我們看第二個目标，靈活可擴充這一點我們是如何做到的呢？在這之前我簡單介紹一下關于視訊處理當中的基本概念，視訊處理的過程是以視訊幀作為視訊資料的載體。以本地發送處理流程為例，視訊資料被采集之後會經過一系列的前處理單元，然後送到編碼器單元進行壓縮編碼，最後根據不同網絡協定通過封裝之後發送到遠端網絡。接收的處理流程是從網絡當中接收到視訊流後進行解封裝操作，送到解碼器當中，經過一系列後處理單元後，再到渲染器進行展示。
我們把以視訊幀為資料載體的序列化視訊處理 稱為視訊處理管線，每一個視訊處理單元我們把它稱為一個子產品。每個具體的視訊處理單元可以有不同的實作，比如說視訊源子產品，可以是自采集的視訊源，可以是攝像頭采集的視訊源或者螢幕共享的視訊源。不同編碼器根據編碼标準和編碼器實作也是可以有不同的擴充功能。網絡發送節點可以根據不同協定發送到自研的 RTC 網絡或者 CDN。不同的視訊業務其實是基礎視訊處理單元根據業務靈活編排形成的。我們希望可以把靈活編排的能力作為我們視訊處理引擎的基礎能力開放給到開發者，這樣開發者就可以通過靈活自由的 API 組合，搭建滿足自己業務需求的處理管線。
為了做到這一點，我們的視訊處理引擎核心架構是采用了 Microkernel Architecture 的架構，分離了整個引擎的變量和不變量。如圖所示分兩個部分，中間的 Core System 和外圍的 Pluggable modules。中間黃色的部分是整個的核心系統部分，對應着整個下一代視訊處理引擎的不變量。在核心系統中，我們抽象出來了各個基礎視訊處理單元的子產品，以及提供了統一的控制面和資料面的接口。同時，引擎還提供了對這些基礎視訊子產品進行組裝和靈活編排的控制接口。此外，核心系統還提供了一系列基礎設施功能，比如跟視訊處理相關的視訊資料格式轉換，基礎的視訊處理算法，針對視訊處理特征進行記憶體管理優化的記憶體池以及線程模型，日志系統和消息總線等。
利用核心系統底層能力，各個子產品可以友善地進行業務擴充，比方說視訊源子產品，可以有推流模式視訊源子產品，也可以支援拉流模式的視訊源子產品，甚至支援一種特殊的視訊源，即在轉碼的過程我們可以把遠端使用者的視訊解碼後的視訊幀作為新的視訊源加入到本地發送的管線當中去。前處理子產品和後處理子產品也可以擴充出各種各樣的實作，如基礎的裁減縮放功能、美顔、水印功能等。編解碼子產品更為複雜，一方面要支援多種編碼标準，還有相應多種實作，軟硬編等。同時，編解碼選擇還是一個比較複雜的動态決策過程，我們在編解碼基礎子產品當中内置了根據能力協商、機型和實時視訊編碼品質進行動态選擇切換的編碼器選擇政策。
接下來，結合實際運用場景看我們如何靈活的搭建視訊處理管線滿足不同的業務組合場景。回到線上教育場景當中，假設現在在一個複雜的線上教育場景當中，需要一個攝像頭拍攝老師黑闆書寫，再有一路攝像頭拍攝老師的人像，同時老師會通過螢幕共享進行課件分享，或者使用媒體播放器來播放本地或者線上的多媒體視訊檔案。一些進階場景當中，老師為了更好的直播效果，會開啟背景分割和背景替換模式，把老師的頭像和課件疊加在一起，達到更好的效果。老師還可以在本地開啟錄制功能，将自己直播上課的視訊錄制到本地。
針對複雜的組合應用都可以通過管線搭建來實作，上圖是一個本地處理管線的概念圖，對于剛才所說的拍攝黑闆，老師人像和課件分享，我們可以通過動态替換采集源子產品的具體實作來做。背景分割是特殊的前處理子產品，可以将老師頭像實時分析出來，然後再疊加到螢幕共享的采集源上。本地錄制是一種特殊形态的渲染器子產品，它是将本地視訊幀按照檔案格式封裝、存儲到本地路徑當中，我們将整個媒體處理和最後網絡發送進行解耦，它可以動态選擇是推送到我們的 RTC 網絡中還是推送到 CDN。
接下來看一個接收管線組合應用的場景，我們背景有一個背景媒體進行中心，可以根據使用者業務處理器需求去進行實時的流媒體處理服務，其中包括雲錄制（對接收到的視訊進行轉儲）雲端進行視訊鑒黃，低碼高清處理，合圖轉碼服務等。還有 Cloud Player 功能，将遠端視訊拉取下來之後推到 RTC 頻道當中去。以及旁路推流，可以在我們 RTC 網絡當中将接收到的視訊流轉推到 CDN 當中去。
那接下來我們看一下是如何通過搭建接收管線來滿足不同運用場景的。
首先是我們網絡接收源的子產品，它可以通過動态切換來接收來自 RTN 網絡或者 CDN 的視訊流。通過解碼器子產品之後送到一系列後處理子產品當中去，包括剛才提到的鑒黃子產品、低碼高清後處理子產品等等。接收的渲染器子產品的數量和位置都是可以靈活定制的，比如剛才雲錄制的功能，它實際上就是一個特殊的渲染器子產品。
剛才介紹的是我們通過微核心式架構設計實作了靈活擴充目标，各個子產品功能可以快速擴充的。視訊處理管線也可以通過搭積木式的組合來實作業務的靈活編排。接下來我們看一下快速可靠這個目标，我們是想說我們核心系統要提供豐富且穩定的功能，在這基礎上可以極大降低開發從業人員的心智負擔，提升研發效能。
介紹這個之前，我們先想一個問題，如果我們沒有一個穩定可靠的核心系統，一個開發人員要從零開始在我們的管線上開發一個美顔插件，需要思考哪些問題。
首先毫無疑問是要開發美顔本身的業務邏輯。除此之外，在跟管線內建的時候，首先要考慮子產品在管線當中是否可以加載到正确的位置，前序處理子產品對它有哪些影響，以及它的業務子產品對後續功能産生哪些影響。
第二是資料格式問題，當管線上流轉的資料格式不是美顔子產品需要用到的格式的時候，它要對資料格式進行轉換，這個資料轉換算法實作的業務邏輯也需要子產品的開發者來實作。
接下來是和管線內建過程當中，它需要了解整個管線的線程模型和記憶體管理模式。在配合管線的狀态切換當中，美顔子產品自身也要實作相應的狀态控制的業務邏輯。同時，在一個管線當中，如果後續節點根據視訊品質對前序節點有回報的話，譬如後續節點說你需要調節你的吞吐量，它也需要有一種機制來接收和處理後續子產品回報的消息。同時，當美顔插件運作的時候，有一些消息通知要發送給使用者的話，就需要設計一套消息通知機制。
由于美顔插件是內建到提供了核心功能的 SDK 當中，插件的開發就會變得特别簡單，插件作者隻要按照核心系統的接口協定的約定去實作相關的接口即可，核心系統會自動根據它的功能以及從全局性能優化的角度，把它加載到正确的位置，那我們 SDK 的使用者就可以使用這個插件了。
總結一下，關于快速可靠這一塊實作了豐富強大的核心系統功能，可以極大降低子產品開發者的心智負擔，進而提升研發效能。
最後，我們來看一下性能優越可監控這一塊，首先我們對整個視訊處理管線在移動端上資料傳遞效率進行優化，實作了對移動端原生資料格式全鍊路支援，包括采集子產品、渲染子產品、前處理子產品，使用硬體的情況下可以實作整個處理鍊路的零拷貝，同時根據各個子產品處理特性協商，可以把相應子產品在管線上的位置進行優化，減少 CPU 和 GPU 跨越，進而更好的提高資料傳輸效率。
另外，我們在剛才也提到了通過基礎視訊處理單元，将控制面和資料面進行了一定分離，這樣有一定的好處，比如使用者對子產品控制可以得到及時的響應，對于錄影機這類裝置操作，是屬于比較重的操作。當使用者頻繁切換前置後置攝像頭時，這類操作會阻塞使用者 UI 造成較大延時。通過進行控制面和資料面的分離，我們可以在保證最後狀态正确性的前提下實作快速響應的相機操作。并讓控制路徑不再阻塞資料流轉。同時控制路徑可以不阻塞資料流轉，我們可以做到對本地圖源進行實時編輯和發送。
降低系統資源消耗方面，我們建構了适用于視訊資料存儲格式的記憶體池，支援多種視訊格式的幀間記憶體複用，同時，可以根據系統記憶體使用情況和管線負載情況、動态調整達到動态平衡的狀态，這樣可以減少頻繁的記憶體配置設定和釋放，進而降低 CPU 使用率。
最後，為了形成一個性能優化閉環回報的通路，我們實作了全鍊路的性能品質監控機制，對每一個基礎視訊處理單元，都會統計和上報入幀和出幀的分辨率和和幀率，以及一些子產品特有的資料。系統層面上對耗時較長的任務也有監控和上報，根據不同問題調查的需求，我們将這部分資料按需導入使用者本地日志，并将體驗相關的資料上報線上品質監控系統，達到對問題快速定位以及優化性能回報的效果。
總結一下，在性能優越可監控方面，我們首先優化了移動端資料處理鍊路，分離了控制面和資料面，提升了整體視訊資料的傳輸效率。另外建構了視訊處理特性相關的記憶體池來降低系統資源消耗。最後，實作了全鍊路視訊品質監控機制，來對視訊優化性能達到閉環回報的效果。
實際上，我們現在下一代視訊處理引擎已經進入到了落地和打磨階段。架構優越性在實踐中也得到了驗證，我們現在就來看一下實際應用案例。
下一代視訊引擎具有高度的靈活性和可擴充性。基于這個視訊引擎，通過業務組合方式搭建了前後端統一的合圖轉碼通用架構，基于這個架構基礎上，我們可以快速響應前端和後端的各類合圖需求。比如線上視訊相親場景，這是典型的多人互動實時場景，傳統一個嘉賓需要訂閱紅娘以及其他嘉賓視訊流，對下行帶寬和機器處理性能造成很大的壓力，為了解決這個問題，我們快速運用合圖轉碼通用架構上線雲端合圖項目，在雲端将各個嘉賓和紅娘視訊合成一路流再推送給觀衆。同時合圖布局和背景圖、嘉賓視訊中斷顯示政策可以根據使用者業務進行定制: 比如顯示最後一幀、背景圖、占位圖等等。