短視頻 SDK 架構設計實踐

作者簡介

孔維樂,七牛雲客戶端團隊 Android 平臺高級開發工程師,專注音視頻,圖形圖像領域。OpenGL 專家,先後參與直播推流及連麥 SDK 的開發,主導短視頻 SDK 的架構設計與實現, 對客戶端架構設計及性能優化有豐富經驗。

短視頻發展史


圖 1

圖 1 所示是短視頻及直播的發展史,衆所周知,2016 年是直播元年,在這期間誕生了很多直播平臺,比如熊貓、映客、鬥魚等;而在 2017 年,短視頻的火爆程度並不亞於直播,可能大家都以爲短視頻是從 2017 年開始火爆起來的,但其實早在 2015 年就已經誕生出快手、秒拍、美拍等短視頻 App。當時我正好在 YY 從事短視頻 App 相關的工作,來到七牛後,在客戶端團隊先後參與直播、連麥 SDK 的開發,後面開始主研短視頻 SDK,致力做最優秀最好用的短視頻 SDK。

圖 2

2016 年中國移動短視頻用戶數爲 1.5 億,今年預計會達到 2.4 億,增長率高達 58.2%,可見短視頻的熱度在一直提升;近幾年,短視頻的生產模式在不斷演進,從 UGC 到 PGC,再到最新的 MCN(Multi-Channel Network),內容的產能和質量均得到了巨大提升。

圖 2 所示是短視頻在各個行業的綜合應用。


研發短視頻 App 的難點

前面介紹完有關短視頻的歷史以及發展趨勢,下面着重介紹一下關於短視頻開發需要的預備知識及難點:

1、音視頻領域固有門檻
深刻理解音視頻編碼格式 H.264 和 AAC 的編碼細節;混音時如何將兩個音頻調整到一致的參數,使用什麼樣的算法去混合等等。

2、圖形圖像、OpenGL 處理
攝像頭預覽數據,圖像處理,音視頻編解碼都需要了解 RGB 和 YUV 色彩空間的數據格式,以及它們之間轉換的方式等等;其中部分操作可以利用更高效的 OpenGL 去完成,如美顏濾鏡,圖層混合,放大/縮小,旋轉,還有圖像裁剪等等。

3、平臺相關
要對相應平臺的攝像頭、麥克風、編解碼、多媒體處理等 API 十分熟悉,否則它們的一些坑會耗費你大量時間。

4、高級功能
視頻編輯少不了特色和高級的功能,例如美顏,濾鏡,MV 特效,倍數拍攝,文字特效等,每一個高級功能都對各方面技術提出很高的要求。

5、系統版本,機型等兼容性問題
這算是一個老生常談的問題,無論 iOS 還是 Android,機型和系統版本都越來越多了,必然會帶來兼容性問題。比如會有小部分 Android 機型編碼的視頻在 iOS 端播放不了的情況,類似這種兼容性問題都是需要進行解決的。

6、性能以及資源佔用的優化
移動應用的計算資源受到相應系統的嚴格制約,在進行音視頻採集,渲染,編碼等複雜計算的同時,還要確保應用有足夠的資源流暢運行,這要求開發人員有豐富的調優能力。

解決以上的難點是首要的事情,但開發時間也是研發人員必須考慮的問題,開發一款優秀的短視頻 App,從熟悉音視頻領域開始,到解決系統兼容性問題,緊接着去編寫複雜業務邏輯,還有相應的UI界面這些工作需要耗費3-6個月的時間,是非常耗費時間和精力的。最開始我們團隊進行短視頻 SDK 開發時也踩過很多坑,用了將近一個月的時間才真正穩定下來,經過沉澱,現在我們針對一款 App 進行短視頻 SDK 的對接,基本一週時間就可以完全搞定。


短視頻 SDK 架構設計

接下來介紹一下我們團隊在進行短視頻 SDK 實踐中主要做的一些事情,這其中最重要的就是短視頻 SDK 的架構設計,包括架構設計理念、架構圖、整體數據流程、模塊架構設計等。

1、SDK 架構設計理念


圖 3

說到 SDK 的設計理念必定要提到命名規範,就跟七牛的企業理念「簡單.可信賴」一樣,我們的命名規範是統一、簡單並且精煉的,比如我們將對外的核心類統一以 PLShortVideo 爲前綴,如圖 3 所示分別是錄製、編輯以及剪輯等模塊的命名;參數配置類則均以 PLxxxSetting 爲標準進行命名(圖 4);接口回調類則均以 PLxxxListener 爲標準命名。


圖 4

第二點我們遵循的是高模塊化、模塊可插拔的一個理念;高模塊化必須要保證每個類每個方法都「名副其實」並「各司其職」,這樣才能編寫更清晰的邏輯;高模塊化同時可以促進高複用,減少重複代碼;圖 5 所示是 SDK 內的轉碼核心類,因爲編輯、剪輯在最後保存的時候都需要一個解碼並重新編碼的過程,在這裏,轉碼核心類可以達到一個高複用。


圖 5

圖 6

圖 6 所示爲短視頻 SDK 的包體劃分,從表中我們可以清晰地看到每個包體的功能劃分,不同的功能放在了不同的包體當中。我們並沒有使用 ffmpeg 的軟解軟編,而是儘量使用 Android 和 iOS 的系統 API 進行硬編硬解,這樣不僅減少了包體大小,而且速度要快很多,儘管在技術層面上會增加很多難度,會踩很多坑,但我們還是堅持選用這個方案。在引入第三方庫時,我們也都是會經過充分配置和裁剪去嚴格控制包體的大小,這樣一來,所有包體總和纔能有現在「小而精」(1.5M)的成果。表中最後的內置濾鏡模塊,其中的濾鏡資源可以選擇性拷貝,SDK 內部會自動判斷。這是關於模塊設計方面的一些理念。

圖 7

第三點是要和 UI 解耦,如圖 7 所示,是從不同 App 中截圖得到的畫面,可以看出每一個App 都有各自的設計,作爲一款短視頻 SDK,是絕對不可以在 UI 方面限制客戶發揮的。市面上有些短視頻 SDK 將 UI 寫死並作爲 SDK 的一部分,這樣對於客戶在設計 UI 界面上來說,是非常不友好的;我們採用的是另一種方法,SDK 與 UI 進行解耦,客戶的 UI 是可自定義的,整個 SDK 中接受 view 的地方只有一處:

PLShortVideoRecorder:prepare(GLSurfaceView preview, …)

接着是擴展性這一塊,我們遵循高擴展,開放性的理念。在錄製以及編輯過程中,都會有數據的回調並支持第三方庫進行美顏,濾鏡,貼紙,特效等功能。

最後是關於可配置參數方面的設計,除了常規參數,比如攝像頭分辨率和幀率、麥克風採樣率等可以進行配置之外,包括美顏等參數也都是可以進行配置的。

2、短視頻SDK架構


圖 8

圖 8 所示爲 Android 短視頻 SDK 的架構圖,可以劃分爲四層。第一層爲應用層(基於 SDK 開發的應用);第二層爲 SDK 對外的接口層(均以 PLShortVideo 爲前綴);第三層爲核心層,主要是內部的一些模塊(其中分 Java 和 Native 兩塊);第四層主要是 Android 系統層。


圖 9

圖 9 所示是整體數據流程圖;輸入模塊支持通過兩種方式採集數據,一種是通過攝像頭和麥克風採集數據,採集到的數據可以進行數據處理(美顏、人臉識別等),另一種則是通過文件導入並進行解碼處理;編輯模塊有着十分豐富的功能比如添加字幕、MV 特效、添加背景音樂等等;編碼模塊主要支持 H.264 軟編/硬編以及 ACC 軟編/硬編;編碼之後的數據會進行 MP4 封包,此後進入輸出模塊,可以存儲到本地也可以使用 HTTP 進行上傳。下面將着重就幾個模塊進行介紹。


圖 10

圖 10 爲錄製模塊的示意圖。錄製模塊的重點在於幀數據獲取,除了可以通過攝像頭獲取視頻幀,還可以通過屏幕錄製獲取視頻幀,而音頻幀數據主要還是通過麥克風進行獲取;虛線部分的 Filter 模塊主要實現了內置美顏/濾鏡功能,另外因爲有紋理和 YUV 數據的 CallBack 回調機制,所以也支持第三方庫的美顏、濾鏡、特效等功能;處理後的數據會經過 OpenGL 進行裁剪,縮放,旋轉等操作,這些工作雖然可以由 CPU 來進行,但是會比較耗時,利用 GPU 是更明智的選擇;最後得到紋理後,會被分成兩路,一路渲染顯示,另一路進行編碼封裝,這兩個線程共享同一個紋理,這樣的處理大大減少了資源的佔用,提高了 SDK 的工作效率。


圖 11

圖 11 所示爲編輯模塊的示意圖。首先需要導入一個視頻文件(使用短視頻 SDK 拍攝或者從外部導入的視頻文件),解包之後會得到相應的幀數據,接着分別通過音視頻解碼器得到 PCM 和紋理,然後把它們送進編輯引擎,在這裏面可以進行各種各樣的處理(水印、文字特效、背景音樂、多音頻混音等)數據經過編輯之後,與錄製相同會分兩路,其中一路進行播放渲染,另一路會進行轉碼保存。


圖 12

圖 12 所示是 MV 特效的實現思路。通過攝像頭採集的數據無需解碼,而 MV 視頻文件的幀數據則需要解碼後纔可以進行處理。SurfaceTexture 的主要作用是將解碼後的數據幀進行回調通知你可以在 OpenGL 線程中更新紋理了,這個通知可以是多線程同時進行的操作,所以在幀回調時一定要對其進行上鎖,防止出現 MV 畫面之間不同步的問題。更新之後得到相應的紋理,將其進行混合就能得出最後的 MV 特效圖。

圖 13

圖 13 爲日誌系統的模塊圖。日誌系統主要是爲了方便排障,快速定位問題以及調試問題,我們會將 SDK 版本、設備機型、系統版本,關鍵配置等一一進行輸出,以方便用戶根據這些信息進行排障。



## 踩過的坑

當然,研發過程不可能一帆風順,總要踩過一些坑才能使整個 SDK 更加完善。下面就列舉一些我們踩過的坑以及排查的過程。

部分視頻剪輯出現花屏


圖 14

我們通過對客戶提供的一些樣本視頻進行分析後,發現出問題的都是帶有雙向引用 B 幀的 High profile 視頻,如圖 14 所示,B 幀(3)位於中間,其引用左右兩邊的 P 幀(2、4)在顯示時是這樣的順序,但是在進行幀存儲以及視頻解碼時,B 幀(3)是在這 2 個 P 幀其後的。

在使用 MediaMuxer 封包時有要求下一幀的 PTS 必須大於等於上一幀的 PTS, 也就是:

i +1 幀 PTS >= i 幀 PTS

而 MediaExtractor 讀出視頻幀是按照 DTS 順序的,也就是 PTS 是會有回退的,所以問題就出在這裏了,按照 DTS 的順序去重新封包,必然會導致後方的 B 幀被丟掉,這樣就導致了花屏的問題。目前 MediaMuxer 在 Android 7.0+ 才支持對 B 幀封包,因此除非你的 APP 最低兼容到 7.0,否則建議選擇使用 FFMpeg 進行封包。

最後給大家分享一句話,也算是對自己的一個鼓勵,就是「Fake it until you make it」。對於我們客戶端團隊,要將 SDK 打磨到最完美的狀態我們進行了很多嘗試,也歷經了很多血淚,最後纔有今天的成果,我們需要努力的地方也還有很多,也會再接再厲,謝謝大家!

-END-

點擊立即體驗[七牛雲短視頻解決方案]

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章