直播特效的實(shí)現(xiàn)原理
直播的具體流程，包括：采集、前處理、編碼、傳輸、解碼、后處理、播放。通常情況下，我們會(huì)在攝像頭采集到視頻圖像后，開始對其進(jìn)行特效處理，也就是在前處理的過程中進(jìn)行。
實(shí)現(xiàn)直播特效的流程如下：
采集：視頻的采集源主要有三種：攝像頭采集、屏幕錄制和從視頻文件推流。直播中常見的是通過攝像頭采集的圖像。以Android為例，由于需要進(jìn)行圖像的二次處理（濾鏡、特效），所以使用 SurfaceTexture來處理圖像流，給采集到的圖像增添特效、濾鏡等。SurfaceTexture 是一個(gè)紋理，可以想象成一個(gè) View 的中間件。Camera 把視頻采集的內(nèi)容交給 SurfaceTexture，SurfaceTexture 進(jìn)行美顏處理，然后把內(nèi)容交給 SurfaceView，渲染出來。
前處理：對采集到的圖像進(jìn)行處理：比如通過均值模糊、高斯模糊和中值濾波等去噪算法，給原始視頻進(jìn)行“磨皮”；或者利用 GPUImage 庫，增加濾鏡；又或者是利用 ARCore、ARKit 等工具，為視頻添加實(shí)時(shí)的 AR 特效。
在完成圖像的處理后，按照合適碼率、格式進(jìn)行編碼。
最后，推流到 CDN。
要實(shí)現(xiàn)美顏效果，不論是基于 WebRTC 的移動(dòng)端還是Web端，都可以通過 GPUImage 來實(shí)現(xiàn)。如果是基于 WebRTC 與 React Native、GPUImage 相結(jié)合即可，不過需要修改 react-native-webrtc 的源碼。
開發(fā)中的難點(diǎn)
在直播中實(shí)現(xiàn)特效、濾鏡，甚至AR特效的例子，我們可以在網(wǎng)上找到很多，我們也曾分享過基于 ARCore、ARKit 來實(shí)現(xiàn)。不過其中有很多需要開發(fā)者注意的難點(diǎn)。
一、缺乏可擴(kuò)展性、靈活性
如果通過 WebRTC 來進(jìn)行開發(fā)，WebRTC 提供的渲染器是基于 GLSurfaceView 的 View 組件。與SurfaceView 相比，它沒有動(dòng)畫或者變形特效，因?yàn)?GLSurfaceView 是窗口 （window）的一部分。 因此，如果想往其他地方繪制，或者獲取視頻數(shù)據(jù)，就會(huì)比較麻煩。
二、需要大量修改源碼
通過 WebRTC 的 Native API 是無法獲取攝像頭數(shù)據(jù)的，如果要做美顏，需要做大量改動(dòng)，比如上述提到的修改 react-native-webrtc 源碼，也只是其中一部分工作。另外可能還需要調(diào)整 WebRTC 源碼，并不是拿來即用，這就要求開發(fā)者要熟悉 WebRTC。
三、性能與功耗問題
性能與功耗問題在 Android 平臺(tái)上比較明顯。通常情況下，對圖像進(jìn)行處理時(shí)，我們可以選擇輸入 YUV 數(shù)據(jù)，讓 CPU 進(jìn)行圖像處理，然后交給軟件/硬件編碼器進(jìn)行編碼。但這樣做會(huì)產(chǎn)生較高的 CPU 占用率，功耗隨之增加，App 響應(yīng)速度受到影響。所以我們需要盡量使用 GPU 來完成圖形處理，更多地利用硬件性能。
在編碼上也存在相同問題。軟件編碼的優(yōu)點(diǎn)是靈活度高，但是缺點(diǎn)是功耗高，影響性能。硬件編碼則相對速度更快、功耗更低，是更優(yōu)的選擇。但它的問題在于，能做的優(yōu)化和參數(shù)調(diào)整，取決于硬件廠商開放的接口。而且硬件編碼在部分 Android 手機(jī)上的兼容性也存在問題。
四、硬件兼容性問題
WebRTC 等自研方案還需要考慮硬件的兼容性問題。iOS 設(shè)備相對簡單，但是在 Android 設(shè)備上，不同芯片、系統(tǒng)版本等因素，存在兼容問題。
Agora SDK 2.1版：實(shí)現(xiàn)直播特效更靈活
相對于這種自研來講，聲網(wǎng)Agora SDK 將采集和渲染開放，開發(fā)者可以更靈活的處理視頻數(shù)據(jù)。如下圖綠色部分所示，處理權(quán)限開放給開發(fā)者，帶來更大的靈活性與擴(kuò)展性。
Capture（采集）：聲網(wǎng)Agora SDK 支持自定義的視頻源類型，可以方便利用我們提供的輔助類構(gòu)建 camera 視頻源，或者屏幕共享視頻源，或者文件視頻源等。
添加特效：Agora SDK 的新接口直接利用 Android 系統(tǒng)組件Surface Texture 處理，并傳遞給 GPU，最后通過Agora SDK 硬件編碼器進(jìn)行視頻編碼。整條鏈路上最大限度發(fā)揮硬件性能，不經(jīng)過內(nèi)存拷貝，不僅可以獲得更好的性能與功耗表現(xiàn)，避免影響 App 響應(yīng)速度，也無需擔(dān)心硬件編解碼問題。
Renderer（渲染）：聲網(wǎng)Agora SDK 開放了視頻渲染器的接口，用戶可以靈活的根據(jù)現(xiàn)有的業(yè)務(wù)，向 Android 標(biāo)準(zhǔn)的 SurfaceView，TextureView組件上或者是自定義的 View 組件上渲染。
開放新功能帶來的差異
升級2.1版之前：
在2.1之前的版本中，開發(fā)者需要通過 pushExternalVideoSource 接口，以共享Texture id 的方式來實(shí)現(xiàn)特效、美顏等功能，即需要傳入texture 所在的 EGL Context，以及Texture 的id。
升級2.1之后：
通過2.1版的自定義視頻源、自定義渲染器兩個(gè)新功能，能更靈活地實(shí)現(xiàn)想要的效果。通過它們，開發(fā)者可以使用原有的共享 texture id 的方式，也可以利用系統(tǒng)組件，如 SurfaceTexture 或者 Surface 來傳遞 texture。例如，TextureSource 類封裝了 SurfaceTexture 對象，開發(fā)者可以利用它創(chuàng)建出 EglSurface，美顏處理后得到紋理數(shù)據(jù)，直接繪制到 EglSurface 上即可。
這兩個(gè)功能給了我們在視頻、圖像渲染方面提供更開放的想象空間，可以在直播中實(shí)現(xiàn)更多場景，比如我們此前結(jié)合 ARCore、ARKit 實(shí)現(xiàn)的 AR 場景，再比如類似抖音跳舞機(jī)的游戲也能放到直播中。
在 Agora SDK 2.1 中，我們?yōu)樽远x視頻源與自定義渲染器增加了多個(gè)新接口，更多原文查看。
