本文由百度智能云音視頻SDK產(chǎn)品技術(shù)負責人李明路在LiveVideoStack線上分享的演講內(nèi)容整理而成，內(nèi)容從音視頻數(shù)據(jù)角度出發(fā)，梳理了音視頻SDK的發(fā)展和技術(shù)演進。詳細分析數(shù)據(jù)在常見音視頻模塊上遇到的問題與挑戰(zhàn)，并提出相應(yīng)的解決思路和技術(shù)實踐。

本次分享的主題是移動音視頻SDK開發(fā)工程實踐，內(nèi)容主要分為以下五個部分：

音視頻SDK的技術(shù)演進

數(shù)據(jù)采集管線的設(shè)計與實現(xiàn)

特效模塊數(shù)據(jù)中間件設(shè)計和實現(xiàn)

連麥模塊數(shù)據(jù)中間件設(shè)計和實現(xiàn)

渲染模塊數(shù)據(jù)中間件設(shè)計和實現(xiàn)

01音視頻SDK的技術(shù)演進1.1 數(shù)字化進程

多媒體技術(shù)是一項傳統(tǒng)技術(shù)，但同時也是在不斷發(fā)展與進步的，我們可以形象的用細胞分裂來表示，即多媒體技術(shù)內(nèi)部也在不斷發(fā)生分裂，而音視頻SDK則是其中的一個分系。

以下大致列出了音視頻技術(shù)演進的幾個重要進展。首先，在互聯(lián)網(wǎng)化前期多媒體技術(shù)就已經(jīng)開始出現(xiàn)廣泛的應(yīng)用，得益于通訊技術(shù)的發(fā)展，我們可以借助于廣播、有線電視、衛(wèi)星等等，將數(shù)字信號傳輸給用戶。

解碼器其實在整個多媒體技術(shù)的發(fā)展當中也起到非常重要的作用，只不過當時解碼器的能力與現(xiàn)在相比還是有些不同，但同樣可以實現(xiàn)解碼和容器的分離。

此后，隨著互聯(lián)網(wǎng)的出現(xiàn)，我們可以實現(xiàn)基于一些IP網(wǎng)絡(luò)協(xié)議、光纖的廣泛使用，通過WiFi、蜂窩網(wǎng)絡(luò)，傳輸數(shù)據(jù)到設(shè)備終端（此時終端更多的還是指PC端）。因此產(chǎn)生了一些在線類的音視頻服務(wù)，例如點播、在線語音等典型的音視頻場景。在這些場景中，SDK更多的還是以服務(wù)端為主。

2010-2015年期間，隨著手機硬件的發(fā)展，終端的算力不斷提升，編解碼芯片也得以快速發(fā)展，再加上消費者使用習慣的變化，出現(xiàn)了更多碎片化的場景和產(chǎn)品，像直播、短視頻等。此時，隨著手機等移動設(shè)備的普及，移動端SDK也慢慢進入到消費級領(lǐng)域，逐漸發(fā)展成獨立技術(shù)棧。 近年來， 隨著5G、AI人工智能的發(fā)展，VR/AR、語音交互等技術(shù)也在發(fā)生著新的變化，應(yīng)用場景變得更加廣泛，音視頻SDK已經(jīng)不僅僅局限于移動端，未來會出現(xiàn)在各種設(shè)備屏幕、產(chǎn)品形態(tài)當中。 1.2 移動端音視頻框架

移動端的音視頻框架與其它移動端框架相比有很大不同。音視頻框架首先要立足移動端提供的系統(tǒng)能力，包括系統(tǒng)框架和硬件能力。如圖，系統(tǒng)框架層有iOS/Android的一些多媒體框架、硬件的編解碼、硬件的處理能力如CPU、GPU、NPU的處理模塊，以及一些開源圖像庫。

系統(tǒng)框架層之上是第三方框架，如FFmpeg、OpenSSL（加解密）；在點播場景用的比較多的Ijkplayer/Exoplayer；用于底層通訊的技術(shù)：雙向的，低延時的WebRTC技術(shù)，用于單向點播的RTMP，目前比較火的SRT低延時方案；除此之外，還會有一些圖像處理方面的框架如GPUImage等。

在此之上，就是一些跟場景相結(jié)合比較多的模塊，這里大致列出了部分核心模塊。 數(shù)據(jù)從多媒體采集模塊出來，會經(jīng)過一路或多路的混音混流（與實際場景相結(jié)合），然后過渡到多媒體編輯模塊：當下短視頻的一些能力都是通過多媒體編輯這個處理單元實現(xiàn)，再到后面的多媒體后處理模塊：例如AR特效，以及一些比較好玩的互動能力等； 內(nèi)容生產(chǎn)完成后，我們會根據(jù)點播、直播或者短視頻等場景的不同，采用不同協(xié)議進行分發(fā)。再下面就是消費側(cè)，這里可以直接讀取數(shù)據(jù)，也可以間接讀取數(shù)據(jù)作為緩存加快二次讀取數(shù)據(jù)的載入。獲取數(shù)據(jù)后會根據(jù)不同的封裝格式，如FLV、TS或者是MP4等對數(shù)據(jù)進行解封裝，再進行解碼和渲染操作。 相比與其它移動端框架音視頻框架最特別的地方就是管線部分，因為音視頻SDK的產(chǎn)品與其它產(chǎn)品不太一樣，首先需要的是實時處理，數(shù)據(jù)流是不斷在各個模塊之間穿梭的，如何保證各個模塊間的高效傳輸，這里提出了一個管線的概念。 1.3 唯快不破

簡單介紹了音視頻SDK的框架，接下來介紹下目前框架遇到一些問題和挑戰(zhàn)。目前很多業(yè)務(wù)場景，其實都在追求更多的新玩法。這里可能會有一些追求更大的分辨率，還有一些更高的刷新率，甚至是更極致的體驗。但是我們知道音視頻SDK很大程度上會受制于平臺的能力，由于平臺具有更多的差異性，所以導致音視頻SDK在發(fā)展過程當中，其實遇到很多的問題。另外還涉及到模塊間的數(shù)據(jù)交互，因此性能對于移動端來說是一個最大的瓶頸。

其實在有些場景像點播或短視頻，720p的分辨率已經(jīng)不能滿足場景的使用，甚至在一些運動場景，30fps的刷新率也已經(jīng)沒辦法滿足場景的開發(fā)，當然這些其實更多的是業(yè)務(wù)挑戰(zhàn)。除此之外，剛才也說過整個多媒體技術(shù)的發(fā)展，編碼器一直起到了舉足輕重的作用，所以底層技術(shù)也在追求更高效的編碼效率。

對于這些問題，其實大家都能達成一個共識，就是說速度是音視頻SDK框架要解決的一個問題。但拋開現(xiàn)象看本質(zhì)，速度其實還是來自于數(shù)據(jù)的傳輸，它是一個根本前提條件，因此如何讓數(shù)據(jù)更高效的傳遞和更高效的處理，才是移動端SDK要解決的最根本問題。

02數(shù)據(jù)采集管線的設(shè)計和實現(xiàn)

這里介紹一下目前一些開源產(chǎn)品當中數(shù)據(jù)鏈的設(shè)計和方案，以兩個產(chǎn)品為例，一個是GPUImage。相信做過移動端SDK特效的同學應(yīng)該都是耳熟能詳了，因為它確實是比較好用，可以提供大量的Shader。拋開Shader的不說，我們看一下它在數(shù)據(jù)鏈條的設(shè)計方式。首先GPUImage提供了一個傳輸數(shù)據(jù)的類Output和一個實現(xiàn)接收數(shù)據(jù)的Input，然后通過生產(chǎn)模式，生產(chǎn)模塊像相機采集模塊，以及本地相冊模塊，其實都是實現(xiàn)了Output的類，生產(chǎn)模塊生產(chǎn)完畢后會交由Output進行渲染，這里它的強大之處在于Output可以與可編程的Shader進行強關(guān)聯(lián)，很大程度的驅(qū)動了OpenGL的運行效率。然后將渲染后RGB的數(shù)據(jù)轉(zhuǎn)換成FrameBuffer這個實體的對象，整個鏈條都是通過FrameBuffer進行接收，然后通過鏈條上的組件去實現(xiàn)了Input后，就能拿到Output傳出的FrameBuffer，以此類推將FrameBuffer進一步的傳遞到下個鏈條當中，整個鏈條其實是非常清晰和簡單。

我們再來看一下右邊的FFmpeg，除了提供很多的數(shù)據(jù)鏈條的處理機制、數(shù)據(jù)的分包，它還可以在不進行解碼的情況下進行轉(zhuǎn)包，也可以把數(shù)據(jù)進行解碼，做一些后處理等等，整個鏈條其實也是比較清晰的。

介紹了兩種多媒體框架，接下來看一下我們團隊是怎么去考慮這些問題。實際開發(fā)中，音視頻SDK框架中管線其實是不可控的，我們來看一下這兩種方案的一些優(yōu)勢和問題。

首先GPUImage的優(yōu)勢是顯而易見的，就是協(xié)議相對簡單清晰，另外通過可編程Shader驅(qū)動了OpenGL，這樣它的運行效率變的非?？?，通過大量的Shader可以讓開發(fā)同學去進一步學習這門語言，是一個優(yōu)秀的圖像處理 開源框架。但同樣存在一些問題，首先我們看到它提供的這些Shader其實大多數(shù)都是圖像處理，并且基本上都是同步處理的。所以可能導致在使用GPUImage跟一些框架進行結(jié)合的時候，當你的某個模塊涉及到耗時處理，這個時候有可能會出現(xiàn)某個對象被其它釋放掉或怎么樣，會造成整個線程的不安全。

FFmpeg的優(yōu)勢特別多，簡單說一下它的函數(shù)指針，其實也是FFmpeg的一個最佳實踐，它通過指針的方式，把數(shù)據(jù)進行一層層的拆分跟傳遞。但是它也同樣存在一些問題，比如說FFmpeg是面向過程的，它的鏈路設(shè)計對于不熟悉FFmpeg的同學來說，可能會覺得鏈路非常復雜，使用起來可能并不是那么的得心應(yīng)手。

所以我們經(jīng)過多輪討論跟思考，就希望得到一個數(shù)據(jù)管線，它首先像GPUImage，協(xié)議比較簡單，用起來比較容易上手，對開發(fā)者來說是友好的；另外需要它是可控的，因為隨著SDK的模塊越來越多，我們發(fā)現(xiàn)在很多場景下，會出現(xiàn)不可控的問題；除此之外我們還希望它是支持同步或者是異步的，調(diào)度是安全的，鏈路配置是簡單可依賴的。

我們也總結(jié)了自己的一些方法論跟實踐：專注鏈式，這主要還是考慮到音視頻框架，鏈式是它的一個核心思想，所以我們遵從這種法則自研數(shù)據(jù)管線。

首先是制定數(shù)據(jù)協(xié)議，主要解決的是最基本的模塊間數(shù)據(jù)的高效、穩(wěn)定的傳遞。這里可以看到左圖，它的方案跟剛才介紹的GPUImage有些相似，但是也有些不同。我們也提供了類似的AVOutput的模塊和AVInput的數(shù)據(jù)傳輸接收的協(xié)議。但是我們并沒有跟GPUImage的OpenGL進行綁定，只是單純的去記錄和管理這條鏈條上的各個的組件，我們叫target。然后通過Dispatcher的機制，分發(fā)從生產(chǎn)端上報的視頻幀，通過視頻幀不斷的傳遞到各個鏈路的target當中，而每個target實現(xiàn)AVInput其中的協(xié)議方法。例如frame跟type兩個函數(shù)，frame就是從raiseFrame Output傳遞下來的數(shù)據(jù)；type主要是做一些音視頻的音頻跟視頻的區(qū)分。

除此之外我們還支持一些二進制場景的分發(fā)，主要是為了配合像直播這種對數(shù)據(jù)有分發(fā)要求的場景做了一些協(xié)議的升級。在鏈條的最末端，可以看到我們也實現(xiàn)了AVControl，跟之前不太一樣是我們制定了一個控制協(xié)議，這個控制協(xié)議主要是為了控制數(shù)據(jù)的流入和流出。為什么要做這個事情呢？我們知道音視頻SDK最核心的就是數(shù)據(jù)在不斷的傳遞，如果說某個模塊出現(xiàn)異常，數(shù)據(jù)沒有一種機制能保護它，可能會導致整個SDK的運行出現(xiàn)不穩(wěn)定的情況。比如在直播場景分發(fā)的時候，我們發(fā)現(xiàn)網(wǎng)絡(luò)有抖動，此時我們可以調(diào)整發(fā)送的速率、速度等。

這里簡單的畫了一下我們的數(shù)據(jù)流向，一個是推的方式，就是直接從相機這種模塊采集數(shù)據(jù)，直接著向后面的某個模塊去傳遞。一個是拉的方式，主要是指讀取本地文件或者說是間接的獲取數(shù)據(jù)，比如從網(wǎng)絡(luò)讀取數(shù)據(jù)首先需要將數(shù)據(jù)讀下來，然后再傳遞到各個模塊。這里其實相對于之前說了GPU在異步線程的一些處理，我們也做了一些兼容和保護，就是防止異步處理時對象被釋放的情況發(fā)生。所以說我們基本上也是沿用了GPUImage協(xié)議簡單的這種思想，然后在此基礎(chǔ)上又增加了一些像控制協(xié)議的實現(xiàn)機制，讓整個鏈路變得可控。

除此之外，我們也發(fā)現(xiàn)在日常過程當中，只是簡單的設(shè)計數(shù)據(jù)管線，其實并不能很好的對業(yè)務(wù)場景開發(fā)提供幫助，原因什么呢？

其實我們只是解決了各個模塊數(shù)據(jù)之間的傳遞問題，但是并不能對最終產(chǎn)品的場景開發(fā)落地解決所有的問題，因為場景跟模塊是有很大差異的。我們所了解的像點播、直播，甚至是特效等，它其實都是通用性的能力。但是實際場景就涉及到各個模塊之間的組合，所以數(shù)據(jù)的傳遞并不能說傳遞一個數(shù)據(jù)，就能把一個場景串聯(lián)起來。

這里也舉了幾個日常過程中典型的例子，比如對于點播的畫質(zhì)優(yōu)化，會發(fā)現(xiàn)類型轉(zhuǎn)換不是那么通暢和簡單。對于連麥場景，如何讓我們的SDK或者產(chǎn)品用起來更簡單，像人臉特效，比如說涉及到能力的多樣化，如何做到兼容性等，這些都不只是靠數(shù)據(jù)鏈路或模塊搭載就能解決的。因此我們提到了一個中間件的概念，就是把數(shù)據(jù)進行橋接實現(xiàn)資源的共享，在各個模塊或業(yè)務(wù)輸出或使用的時候，就能提高整體數(shù)據(jù)采集或處理的應(yīng)用性。所以說應(yīng)用性也是我們數(shù)據(jù)采集管線的另一個考量指標。

03特效模塊數(shù)據(jù)中間件設(shè)計和實現(xiàn) 接下來我們來看一下，在實際過程當中遇到的一些問題跟解決方案。

特效模塊通常是典型的PaaS結(jié)構(gòu)，它上面存在多種模型，而且模型之間是可以進行插拔；它還有另外一個特點就是耗資源。那么如何在音視頻SDK中將這個模塊更好的運用起來，去對外提供能力呢？我們這里以人臉特效的高級美顏接口為例，高級美顏中涉及到的特征點非常多，像大眼、瘦臉、下巴等，而且這些特征點并不是通過一次迭代或是一個模型就能解決的，它可能會涉及到多次的迭代和多種模型的組合疊加。這樣就會帶來一個問題，在集成特效模塊的時候，如果這些能力都是不斷變化的，對于模塊的使用來說，就存在一個不安全不穩(wěn)定的因素。那么我們該如何把這個問題解決，或者說屏蔽掉呢？

這里我們提供了一個概念：首先在調(diào)用能力的時候，不直接去調(diào)用，而是把這些能力做進行抽象、封裝，然后這些封裝的模型，用來關(guān)聯(lián)后面的一些不同的算法。因為別人在用SDK的時候，不一定按照你所有東西來集成，可能只使用其中部分能力，這樣就有可能會導致一些特效的SDK存在版本不一致。如果沒有這個代理層，當出現(xiàn)版本不一致的情況，對于上層來說可能就會出現(xiàn)大量接口的調(diào)整和修改，會比較耗時耗力。不過我們做代理的話，可能就給屏蔽上層接口的穩(wěn)定性，然后通過我們的模型跟一些抽象對象，可以去驅(qū)動不同的AR模塊的版本。

通過數(shù)據(jù)管線我們可以看到，從錄制模塊把數(shù)據(jù)傳到effect接口，再把數(shù)據(jù)再給到AR SDK的時候，每個AR SDK都會有一個處理檢測能力，會定時的檢測主屏指標等，為什么要這么做？

我們知道現(xiàn)在的特效，場景、玩法是特別復雜的，處理效果沒辦法完全保證。所以為了保證每幀的處理和整體鏈路的穩(wěn)定，我們需要不斷做一些性能指標的監(jiān)測，這些指標監(jiān)測需要不斷的反饋給上層的調(diào)用。比如當前數(shù)據(jù)傳輸?shù)乃俣容^快，或者傳遞幀太多處理不完，我們就可以通過數(shù)據(jù)管線進行回傳，進行控制。甚至可以調(diào)整錄制模塊采集的幀率等，這樣再把數(shù)據(jù)返回給錄制模塊，錄制模塊再將數(shù)據(jù)傳遞給其它模塊，像預覽進行渲染等。通過數(shù)據(jù)管線加代理的方案，我們就可以很好的整合不同AR版本、能力，對外保持接口的統(tǒng)一。

04連麥模塊數(shù)據(jù)中間件設(shè)計和實現(xiàn)

連麥模塊也是目前音視頻產(chǎn)品中用的比較多的一個能力，如在線教育、直播帶貨、PK、娛樂等等，并且已經(jīng)慢慢成為一個標準化能力，但連麥模塊在使用過程當中還存在比較多的問題。

標準直播是單向通信，且信令相對簡單。融合連麥模塊后，則會變成雙向通信，信令會變得復雜，媒體流從單路流變成了多路流。如左下圖，一個標準的直播SDK加連麥SDK的整合結(jié)構(gòu)，可以看到白色區(qū)域是標準的直播流程，從創(chuàng)建直播間到建鏈、編碼、封包，包括通過隊列進行分發(fā)等等。當融合了連麥能力之后，對整個模塊來說會增加更多的鏈路。首先會引入RTC的服務(wù)端，媒體服務(wù)端與信令服務(wù)端。另外可能還會引入一些類似于業(yè)務(wù)系統(tǒng)的消息機制，IM服務(wù)器等等。

用戶如果發(fā)起連麥，可以看到左圖紅色的箭頭。首先它會向RTC信令服務(wù)器發(fā)送連麥請求，同時也會向IM服務(wù)器發(fā)送一個請求，向IM服務(wù)器發(fā)送請求的原因，主要是為了做一些業(yè)務(wù)上的處理，比如說UI界面或者場景的一些流程處理。實際上信令服務(wù)器主要是為了傳遞加入房間的請求，請求到達主播直播間后，主播直播間會響應(yīng)信令服務(wù)器，選擇同意或者拒絕。如果同意，則會通過信令服務(wù)器將信號返回給小主播/觀眾，小主播/觀眾這個時候就會把數(shù)據(jù)傳遞到RTMP的媒體服務(wù)器，主播也會把媒體流傳到RTMP服務(wù)器，兩路流匯聚到RTMP服務(wù)器后，通過旁路轉(zhuǎn)播等方式來進行對外的轉(zhuǎn)播，此時觀眾就會看到兩個主播或主播和觀眾合流的畫面。

這個實現(xiàn)流程其實比較復雜繁瑣，對于用戶（主播）來說可能理解起來非常吃力。首先他要關(guān)心的東西特別多，例如 IM服務(wù)器、旁路直播，旁路直播還會涉及一些模板的設(shè)置等等，他可能都要去關(guān)心，所以使用起來非常的麻煩。而對于消費側(cè)的觀眾來說，也同樣存在一些問題，比如說會出現(xiàn)相同地址，但是會出現(xiàn)不同編碼的兩路流，這種情況下可能對于一些播放器來說會有一些挑戰(zhàn)，可能會出現(xiàn)一些卡頓，因為它在不斷的重置一些編碼參數(shù)，另外這種方案通過旁路轉(zhuǎn)推的方式，可能原始的直播流會斷掉，就在頻繁切換直播流跟混合流的過程當中可能就會出現(xiàn)延遲，可能對于拉流側(cè)來說它就有很多的問題，也不太好。

針對這些問題其實我們也看到，就是用戶在使用過程當中其實有很多的不方便，所以說可以看到說簡單的數(shù)據(jù)傳遞，其實并不能讓這個場景做的特別的簡單和應(yīng)用，后面我們就做了一些大量的端到端的一些數(shù)據(jù)鏈的整合，首先是我們考慮到了就是消費側(cè)的編碼播放器的一些問題，首先是切換編碼參數(shù)，這個方案可能并不是一個適用的方案，所以我們采用了本地混流的技術(shù)方案，其好處在于我的推流各方面的參數(shù)可以保持一致而不發(fā)生變化，而其實對于移動端的處理能力來說，本地的2~3路流的合流，其實對一些硬件來說，壓力并不是特別大。另外我們把IM服務(wù)器跟RTC信令服務(wù)器進行了整合，因為我們覺得讓用戶去關(guān)心這么多的信令其實是沒有必要的，而且用戶也可能會被這些問題所困擾，所以我們內(nèi)部就通過服務(wù)端的方式進行了消息的整合，這樣子就讓用戶使用起來變得更加簡單。通過這種端到端的一些媒體和信令的整合，其實也是讓數(shù)據(jù)流變得簡單，提高了整體接入的應(yīng)用性。

05渲染模塊數(shù)據(jù)中間件設(shè)計和實現(xiàn)

為什么說渲染是音視頻SDK關(guān)鍵技術(shù)之一？從整體技術(shù)鏈路的角度來說，渲染模塊實際上是用戶最能感知到的一個模塊。在一些復雜的場景下，渲染模塊也承載了一些數(shù)據(jù)的交互和處理。因此渲染模塊所包括的處理已經(jīng)不再只是渲染，可能會涉及到某些場景的特殊需求，例如清屏等等：多人會議的時候，相當于一個關(guān)閉畫面的效果；如多路混流，前面提到的RTC混流方案等等，渲染模塊也可以作為其中的一個技術(shù)方案。也包括像小程序，尤其是一些小程序、安卓的同層設(shè)計方案，渲染方案等等。

每個模塊甚至每個處理的節(jié)點，都有可能存在渲染的需求，所以說我們要將渲染模塊進一步拆分。首先通過數(shù)據(jù)管線的一個能力，把各個模塊的數(shù)據(jù)匯聚到渲染模塊，然后再進行數(shù)據(jù)的處理。這里通常會將一些數(shù)據(jù)轉(zhuǎn)換成各個平臺的處理能力，比如CPU的Buffer，還有一些Surface等等。

數(shù)據(jù)加工，相對之前的生產(chǎn)流程這是新增的一個節(jié)點，它主要是為了應(yīng)對一些復雜場景，如安卓的同層渲染、Surface的創(chuàng)建與繪制相分離，比如業(yè)務(wù)模塊持有了Surface，但是渲染模塊會間接引用并繪制。這里可能還會去做多路流混流的一些參數(shù)化配置，可以把每路流作為一個間值進行保存，也會做像圖層跟視頻幀的綁定，然后通過渲染線程同時繪制多路流。

我們都知道渲染必須要獨立于當前的線程，否則對CPU和整體的開銷影響還是比較大的。因此在創(chuàng)建完GL的環(huán)境之后，會按照GL隊列將數(shù)據(jù)進行遍歷拆分，來實現(xiàn)單路流，甚至是多路流的繪制。接下來就是一些標準的渲染流程，包括設(shè)置渲染的頂點，取渲染紋理，然后新增混合模式，通過綁定紋理來實現(xiàn)OpenGL整體的繪制。