深度解析！短視頻如何成爲現象級產品

歡迎你們前往 騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~。

本文由 BestSDK 團隊發佈在騰訊雲+社區

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

短視頻發展史

​圖 1

圖 1 所示是短視頻及直播的發展史，衆所周知，2016 年是直播元年，在這期間誕生了不少直播平臺，好比熊貓、映客、鬥魚等；而在 2017 年，短視頻的火爆程度並不亞於直播，可能你們都覺得短視頻是從 2017 年開始火爆起來的，但其實早在 2015 年就已經誕生出快手、秒拍、美拍等短視頻 App。

​圖 2

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

研發短視頻 App 的難點

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

• 一、音視頻領域固有門檻

深入理解音視頻編碼格式 H.264 和 AAC 的編碼細節；混音時如何將兩個音頻調整到一致的參數，使用什麼樣的算法去混合等等。

• 二、圖形圖像、OpenGL 處理

攝像頭預覽數據，圖像處理，音視頻編解碼都須要瞭解 RGB 和 YUV 色彩空間的數據格式，以及它們之間轉換的方式等等。

• 三、平臺相關

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

• 四、高級功能

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

• 五、系統版本，機型等兼容性問題

這算是一個老生常談的問題，不管 iOS 仍是 Android，機型和系統版本都愈來愈多了，必然會帶來兼容性問題。好比會有小部分 Android 機型編碼的視頻在 iOS 端播放不了的狀況，相似這種兼容性問題都是須要進行解決的。

• 六、性能以及資源佔用的優化

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

短視頻 SDK 架構設計

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

• 一、SDK 架構設計理念

​圖 3

說到 SDK 的設計理念一定要提到命名規範，就跟七牛的企業理念「簡單.可信賴」同樣，咱們的命名規範是統1、簡單而且精煉的，好比咱們將對外的核心類統一以 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 的地方只有一處：

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

• 二、短視頻SDK架構

圖 8​

圖 8 所示爲 Android 短視頻 SDK 的架構圖，能夠劃分爲四層。第一層爲應用層；第二層爲 SDK 對外的接口層；第三層爲核心層，主要是內部的一些模塊；第四層主要是 Android 系統層。

​圖 9

圖 9 所示是總體數據流程圖；輸入模塊支持經過兩種方式採集數據，一種是經過攝像頭和麥克風採集數據，採集到的數據能夠進行數據處理，另外一種則是經過文件導入並進行解碼處理；編輯模塊有着十分豐富的功能好比添加字幕、MV 特效、添加背景音樂等等；編碼模塊主要支持 H.264 軟編/硬編以及 ACC 軟編/硬編。下面將着重就幾個模塊進行介紹。

​圖 10

圖 10 爲錄製模塊的示意圖。錄製模塊的重點在於幀數據獲取，除了能夠經過攝像頭獲取視頻幀，還能夠經過屏幕錄製獲取視頻幀，而音頻幀數據主要仍是經過麥克風進行獲取；虛線部分的 Filter 模塊主要實現了內置美顏/濾鏡功能，另外由於有紋理和 YUV 數據的 CallBack 回調機制，因此也支持第三方庫的美顏、濾鏡、特效等功能；處理後的數據會通過 OpenGL 進行裁剪，縮放，旋轉等操做，這些工做雖然能夠由 CPU 來進行，可是會比較耗時，利用 GPU 是更明智的選擇。

​圖 11

圖 11 所示爲編輯模塊的示意圖。首先須要導入一個視頻文件，解包以後會獲得相應的幀數據，接着分別經過音視頻解碼器獲得 PCM 和紋理，而後把它們送進編輯引擎，在這裏面能夠進行各類各樣的處理數據通過編輯以後，與錄製相同會分兩路，其中一路進行播放渲染，另外一路會進行轉碼保存。

​圖 12

圖 12 所示是 MV 特效的實現思路。經過攝像頭採集的數據無需解碼，而 MV 視頻文件的幀數據則須要解碼後才能夠進行處理。SurfaceTexture 的主要做用是將解碼後的數據幀進行回調通知你能夠在 OpenGL 線程中更新紋理了，這個通知能夠是多線程同時進行的操做，因此在幀回調時必定要對其進行上鎖，防止出現 MV 畫面之間不一樣步的問題。

圖 13​

圖 13 爲日誌系統的模塊圖。日誌系統主要是爲了方便排障，快速定位問題以及調試問題，咱們會將 SDK 版本、設備機型、系統版本，關鍵配置等一一進行輸出，以方便用戶根據這些信息進行排障。固然，研發過程不可能一路順風，總要踩過一些坑才能使整個 SDK 更加完善。下面就列舉一些咱們踩過的坑以及排查的過程。

部分視頻剪輯出現花屏

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

最後給你們分享一句話，也算是對本身的一個鼓勵，就是「Fake it until you make it」。對於咱們客戶端團隊，要將 SDK 打磨到最完美的狀態咱們進行了不少嘗試，也歷經了不少血淚，最後纔有今天的成果，咱們須要努力的地方也還有不少，也會再接再礪，謝謝你們！

問答

短視頻的發展前景以及將來發展方向？

更多與短視頻相關的精華問答，盡在騰訊雲+社區！

相關閱讀

快手爲什麼能成爲現象級產品？還原2017年最火短視頻背後的商業邏輯

開發手遊和視頻直播，這幾款SDK必備

數據告訴你，抖音是怎麼在半年以內逆襲的

此文已由做者受權騰訊雲+社區發佈，轉載請註明文章出處

原文連接：https://cloud.tencent.com/developer/article/1049278