移動(dòng)音視頻SDK開發(fā)工程實(shí)踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們?cè)賮砜匆幌掠疫叺腇Fmpeg，除了提供很多的數(shù)據(jù)鏈條的處理機(jī)制、數(shù)據(jù)的分包，它還可以在不進(jìn)行解碼的情況下進(jìn)行轉(zhuǎn)包，也可以把數(shù)據(jù)進(jìn)行解碼，做一些后處理等等，整個(gè)鏈條其實(shí)也是比較清晰的。

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

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

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

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

我們也總結(jié)了自己的一些方法論跟實(shí)踐：專注鏈?zhǔn)剑@主要還是考慮到音視頻框架，鏈?zhǔn)绞撬囊粋€(gè)核心思想，所以我們遵從這種法則自研數(shù)據(jù)管線。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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