【播放器】播放器/短視訊 SDK 架構設計

Android中，我們可以直接使用MediaRecord來進行錄像，但是在很多适合MediaRecord并不能滿足我們的需求，比如我們需要對錄制的視訊加水印或者其他處理後，所有的平台都按照同一的大小傳輸到伺服器等。 用Android4.1增加的API MediaCodec和 Android 4.3增加的API MediaMuxer進行Mp4視訊的錄制。

音視訊編解碼用到的MediaCodec是Android 4.1新增的API，音視訊混合用到的MediaMuxer是Android 4.3新增的API。

github上十二款最著名的Android播放器開源項目-https://www.jianshu.com/p/53581512ba3f

VideoPlayerManager- https://github.com/danylovolokh/VideoPlayerManager 介紹：幫助控制MediaPlayer類的項目。可以友善的在ListView和RecyclerView中使用MediaPlayer。它還能跟蹤滾動清單目前可視範圍最大的item，并提供回調的api。

推流拉流同時進行- https://github.com/huangjingqiang/jjdxm_ijkplayer-master

清單上自動播放視訊： JiaoZiVideoPlayer,autovideoplayer播放器；

– SDK 性能的名額 Android：

GC ：可以通過 GC 日志記錄，Mirror GC 和 Full GC 的頻次和時間，Full GC * 會造成比較明顯的卡頓，需要評估

UI Loop 就是 VSync Loop ：反映 SDK 對 App 流暢度的影響，理論上 60 fps 是最流暢的值。

Memory ：反映 SDK 占用記憶體的大小

CPU Usage ：反映 SDK 占用計算資源的大小

• SDK 性能的名額 iOS：

  UI Loop ：反映 SDK 對 App 流暢度的影響，理論上 60 fps 是最流暢的值。

  Memory ：反映 SDK 占用記憶體的大小

  CPU Usage ：反映 SDK 占用計算資源的大小

1)影響視訊清晰度的名額：幀率；碼率；分辨率；量化參數（壓縮比）

2)影響視訊流暢度的名額：碼率；幀率

3)其他重要名額，直播是流量和性能的消耗大戶：耗電量；發熱（不好量化，大部分情況發熱和耗電量正比，可以使用耗電量暫時替代）。

短視訊 SDK

如何設計一款優秀的短視訊 SDK- http://blog.51cto.com/ticktick/1955243

移動視訊播放SDK架構ijkplayer: https://github.com/Bilibili/ijkplayer

七牛推出免費Android 平台的播放器 SDK- https://github.com/pili-engineering/PLDroidPlayer

Video-recorder項目- https://github.com/zhanxiaokai/Android-as_video_recorder

Video-Player項目- https://github.com/zhanxiaokai/Android-as_video_player

– 短視訊 SDK 架構設計實踐- http://blog.csdn.net/dev_csdn/article/details/78683826

短視訊開發需要的預備知識及難點：貼紙，特效/美顔/混音/内置濾鏡等SO，不使用 ffmpeg 的軟解軟編，而是盡量使用 Android 和 iOS 的系統 API 進行硬編硬解。水印、文字特效、背景音樂、多音頻混音等

1. 音視訊領域固有門檻

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

2. 圖形圖像、OpenGL 處理

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

3. 平台相關

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

4. 進階功能

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

5. 系統版本，機型等相容性問題

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

6. 性能以及資源占用的優化

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

   快手、秒拍、美拍等短視訊 App。當時我正好在 YY 從事短視訊 App 相關的工作，來到七牛後，在用戶端團隊先後參與直播、連麥 SDK 的開發，後面開始主研短視訊 SDK，緻力做最優秀最好用的短視訊 SDK。

   短視訊的生産模式：從 UGC 到 PGC，再到最新的 MCN（Multi-Channel Network），内容的産能和品質均得到了巨大提升。

   短視訊 SDK 的架構設計，包括架構設計理念、架構圖、整體資料流程、子產品架構設計等。

   輸入子產品支援通過兩種方式采集資料，一種是通過攝像頭和麥克風采集資料，采集到的資料可以進行資料處理（美顔、人臉識别等），另一種則是通過檔案導入并進行解碼處理；編輯子產品有着十分豐富的功能比如添加字幕、MV 特效、添加背景音樂等等；編碼子產品主要支援 H.264 軟編/硬編以及 ACC 軟編/硬編；編碼之後的資料會進行 MP4 封包，此後進入輸出子產品，可以存儲到本地也可以使用 HTTP 進行上傳。

   目前 MediaMuxer 在 Android 7.0+ 才支援對 B 幀封包，是以除非你的 APP 最低相容到 7.0，否則建議選擇使用 FFMpeg 進行封包。

– 短視訊用戶端SDK設計與實作- https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/79017326

短視訊SDK核心場景分為錄播場景和直播場景：對于錄播場景，主播端或者内容貢獻者需要錄制一個視訊，後期對視訊和音頻頻添加特效，比如主題、貼紙、混音、BGM等等，最終把視訊上傳到伺服器，觀衆端則需要使用播放器播放以及社互動動即可；而對于直播場景同樣包含這兩個角色，主播端需要将内容進行實時直播，并針對于觀衆的一些行為完成實時互動，觀衆端則需要使用定制的播放器觀看，這個場景下的播放器并非使用系統提供的播放器即可，必須加以定制化。

針對于錄播和直播兩個場景，他們的共同特點都包含視訊錄制器和視訊播放器；差別則主要展現在是否具有實時互動性；他們需要在各自場景下做一些特殊的配置，比如對于直播來說推流的穩定性和拉流的秒開，對于錄播則是後期視訊處理和上傳。

音頻軌、視訊軌以及字幕軌拆解出來，然後進行解碼過程，一般采用采用硬體+軟體解碼的方案。開源音頻Lame或者視訊FFmpeg等。

視訊播放器中中間處理過程使用的并不算很多，音頻處理上可以做一些混音或者EQ處理，畫面處理則是畫質增強，如自動對比度、去塊濾波器等，當然播放器進行中非常重要的一環就是音視訊同步，目前一般有三種模式：音頻向視訊同步、視訊向音頻同步以及統一向外部時鐘同步。我們一般會選擇視訊向音頻同步，這主要是由于兩方面的原因：一方面是由人的生理特性決定的，相比于畫面，人對聲音的感受會更加強烈；另一方面音頻PCM是線性的，我們可以信賴播放器也是線性的播放，是以在用視訊幀向音頻幀同步時，我們允許對視訊幀進行丢幀或重複幀渲染。最後，輸出則主要包含音頻渲染和視訊渲染兩部分。

SDK中技術含量較高的主要有兩點：跨平台的視訊處理系統和跨平台的推流系統建構。跨平台的視訊處理系統實際可以說是跨平台的圖檔濾鏡系統，它所應用的場景主要有實作美顔、瘦臉這種單幀圖檔的處理，也有如雨天、老照片等主題效果，以及貼紙效果這幾種。為了達到效果，我們通過OpenGL ES來實作，如果用軟體(CPU中計算)做視訊處理是非常消耗性能的，尤其在移動端無法接受。是以它的輸入是紋理ID和時間戳，時間戳主要用于主題和貼紙場景的處理。輸出則是處理完畢的紋理ID。

–短視訊 SDK 功能點技術實作方式詳解- https://tech.upyun.com/article/230/短視訊 SDK 功能點技術實作方式詳解.html

自定義背景音樂功能實作，首先需要将視訊源分離成兩個軌道：音頻軌道和視訊軌道。背景音樂素材剝離出音頻軌道，将背景音樂音頻軌道插入原聲的音頻軌道中。可以通過 AVMutableAudioMixInputParameters 來調整原聲和背景音樂的音量。背景音樂插入成功之後，再将得到的音頻軌道與之前的視訊軌道通過調用 AVMutableComposition 相關類進行合成，最後導出為短視訊。

攝像預覽其實就是Android的Camera開發，對于Android的Camera開發，一般有兩種方式，一種是借助Intent和MediaStroe調用系統Camera App程式來實作拍照和攝像功能，另外一種是根據Camera API自寫Camera程式，自然第一種不能作為我們的濾鏡開發，是以我們采用第二種方式。

– 移動平台（iOS/Android）播放器以及主站HTML5播放器等。視訊編解碼技術、移動視訊技術開發、流媒體技術、應用于多媒體領域的雲計算/大資料/模式識别/資料挖掘、視訊異構開發等領域。以視訊編解碼算法作為主要研究方向。

其實無論是多麼複雜精密的多媒體系統，其整體架構都離不開這幾個結構，以視訊信号為例，視訊采集→視訊預處理→視訊編碼與封裝→資料的存儲/傳輸→視訊解封裝/解碼→視訊後處理→視訊輸出。根據系統的規模和需求不同，每一個子產品的複雜度和規模可能有非常巨大的不同。

最常用的有像視訊的去噪、圖像增強等。對于各種直播軟體，各種美顔工具也極為重要。

視訊的編碼和封裝可謂是整個系統的心髒，很多時候甚至直接決定了整個系統的性能和使用體驗。編碼/封裝器用于将資料量龐大的圖像資料壓縮為某種格式的視訊碼流，壓縮的性能直接影響後期進行存儲和傳輸的代價，編碼的運算速度又影響了整個系統的輸入——輸出延遲。是以，這一步驟的工作常常成為整個系統的焦點所在。

“多專全能”型的人才，從數學基礎、網絡技術、多端開發（server/client/web）、多種不同的程式設計語言（如C/C++/asm/Java/Objective-C/JS等）、多種不同系統平台（如Windows/Linux/MacOS/iOS/Android）等。還需要了解多種不同的系統架構等知識。可以說，任何一個合格的多媒體技術工程師，都有成為全棧/架構師的潛質。

讀書和教育訓練都已經傳統的方式，隻采用這樣的方式在現在已經不夠。個人感覺其實目前對自身提高最有效率的方式莫過于分享。分享有多種形式，包括在技術研讨會上做報告、寫部落格和開源項目都是很好的方式。比如CSDN的部落格/論壇、微信公衆号、微網誌文章等媒體都是相當有效的管道。

– SDK設計中的技術細節

1.OpenGL實作美顔 Android? 直播時美顔濾鏡，拍照美顔濾鏡

Android 關于美顔/濾鏡 從OpenGl錄制視訊的一種方案- http://www.jianshu.com/p/12f06da0a4ec

Android+JNI+OpenGL開發自己的美圖秀秀-http://blog.csdn.net/oshunz/article/details/50537631

Android 關于美顔/濾鏡 利用PBO從OpenGL錄制視訊- http://www.jianshu.com/p/3bc4db687546

寫死無法設定fps？BGRA轉ARGB轉YUV420

最先找到的就是GPUImage - https://github.com/CyberAgent/android-gpuimage

後來找到了MagicCamera-https://github.com/a483210/MagicCamera-ImageReader https://github.com/wuhaoyu1990/MagicCamera

MagicCamera采用的是錄制方案來自于grafika- https://github.com/google/grafika

MediaCodec就可以通過這個Surface錄制出H264，具體代碼可以看VideoEncoderCore- MediaCodec錄制出來的是H264，而ImageReader拿出來的是BGRA的。

Yasea is an Android streaming client. It encodes YUV and PCM data from camera and microphone to H.264/AAC, encapsulates in FLV and transmits over RTMP. https://github.com/begeekmyfriend/yasea

濾鏡的開發主要是寫opengl片段着色器,進而實作各種濾鏡效果。水印通過canvas畫draw上去

GPUImage詳細解析（六）-用視訊做視訊水印,文字水印和動态圖像水印.

2.AAC 的編碼細節?

AAC最多的是LC和HE(适合低碼率)。流行的Nero AAC編碼程式隻支援LC，HE，HEv2這三種規格，編碼後的AAC音頻，規格顯示都是LC。HE其實就是AAC（LC）+SBR技術，HEv2就是AAC（LC）+SBR+PS技術；AAC的音頻檔案格式有ADIF ＆ ADTS：

無噪解碼實際上就是哈夫曼解碼，通過反量化(Dequantize)、聯合立體聲（Joint Stereo），知覺噪聲替換（PNS）,瞬時噪聲整形（TNS），反離散餘弦變換（IMDCT），頻段複制 （SBR）這幾個子產品之後，得出左右聲道的PCM碼流，再由主要子產品将其放入輸出緩沖區輸出到聲音播放裝置。

FFmpeg 可以支援 4 個 AAC-LC 編碼器 (aac, libfaac, libfdk_aac, libvo_aacenc) 與兩個 AAC-HE 編碼器 (libaacplus, libfdk_aac)。

3.彈幕？

關于直播的技術細節其實就是兩個方面一個是推流一個是拉流，而彈幕的實作核心在即時聊天，使用聊天室的就能實作，隻是消息的展示方式不同而已。

JieCaoVideoPlayer是基于MediaPlayer的寫的，不是基于ijkplayer封裝的-https://github.com/lipangit/JiaoZiVideoPlayer

直播播放器+彈幕 Demo 直播的播放器+彈幕的解決方案- https://github.com/Hemumu/HLiveDemo/tree/master

libndkbitmap.so(ndk)源碼：https://github.com/Bilibili/NativeBitmapFactory

4.RGB 和 YUV 色彩空間的資料格式？

5.代碼去解析音視訊檔案？視訊資料與視訊頭、頭檔案？

6.拍照的API？濾鏡相機GPUImage性能更新成純GPU + GPUImageRenderer

7.模拟視訊信号、數字視訊信号？

8.音視訊同步？

采樣頻率是指将模拟聲音波形進行數字化時，每秒鐘抽取聲波幅度樣本的次數。每一幀音頻或視訊都有一個持續時間：duration。正常人聽覺的頻率範圍大約在20Hz~20kHz之間，根據奈奎斯特采樣理論，為了保證聲音不失真，采樣頻率應該在40kHz左右。

常用的音頻采樣頻率有8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz等，如果采用更高的采樣頻率，還可以達到DVD的音質對采樣率為44.1kHz的AAC音頻進行解碼時，一幀的解碼時間須控制在23.22毫秒内。

一幀 1024個 sample；采樣率 Samplerate 44100Hz，每秒44100個sample, 是以根據公式，音頻幀的播放時間=一個AAC幀對應的采樣樣本的個數/采樣頻率；目前AAC一幀的播放時間是= 1024*1000000/44100= 22.32ms(機關為ms)

以音頻的播放時長為基準，将視訊同步到音頻上以實作視音頻的同步播放的。視訊和音頻的同步實際上是一個動态的過程，同步是暫時的，不同步則是常态。以選擇的播放速度量為标準，快的等待慢的，慢的則加快速度，是一個你等我趕的過程。

– 播放速度标準量的的選擇一般來說有以下三種：

1.将視訊同步到音頻上，就是以音頻的播放速度為基準來同步視訊。視訊比音頻播放慢了，加快其播放速度；快了，則延遲播放。

2.将音頻同步到視訊上，就是以視訊的播放速度為基準來同步音頻。

3.将視訊和音頻同步外部的時鐘上，選擇一個外部時鐘為基準，視訊和音頻的播放速度都以該時鐘為标準。

在視音頻流中的包中都含有DTS和PTS；DTS，Decoding Time Stamp，解碼時間戳，告訴解碼器packet的解碼順序；PTS，Presentation Time Stamp，顯示時間戳，訓示從packet中解碼出來的資料的顯示順序。

視訊的編碼要比音頻複雜一些，特别的是預測編碼是視訊編碼的基本工具，這就會造成視訊的DTS和PTS的不同。這樣視訊編碼後會有三種不同類型的幀：

I幀 關鍵幀，包含了一幀的完整資料，解碼時隻需要本幀的資料，不需要參考其他幀。

P幀 P是向前搜尋，該幀的資料不完全的，解碼時需要參考其前一幀的資料。

B幀 B是雙向搜尋，解碼這種類型的幀是最複雜，不但需要參考其一幀的資料，還需要其後一幀的資料。

I幀的解碼是最簡單的，隻需要本幀的資料；P幀也不是很複雜，值需要緩存上一幀的資料即可，總體來說都是線性，其解碼順序和顯示順序是一緻的。B幀就比較複雜了，需要前後兩幀的順序，并且不是線性的，也是造成了DTS和PTS的不同的“元兇”，也是在解碼後有可能得不到完整Frame的原因。

即時通訊，音視訊同步技術。網絡延遲、抖動、網絡傳輸條件變化等因素引起的音視訊不同步的問題。

引起音視訊不同步的原因主要有兩種：一種是終端處理資料引起的，發送端在資料的采集、編碼、打包等子產品和接收端在處了解包、解壓、回放等子產品時，由于音頻和視訊的資料量以及編碼算法不同而引起的時間差。并且發送端沒有統一的同步時鐘；另一種是網絡傳輸延時，網絡傳輸是受到網絡的實時傳輸帶寬、傳輸距離和網絡節點的處理速度等因素的影響，在網絡阻塞時，媒體資訊不能保證以連續的“流”資料方式傳輸，特别是不能保證資料量大的視訊資訊的連續傳輸，進而引起媒體流内和流間的失步。

播放 流程: 擷取流–>解碼–>播放

錄制播放路程: 錄制音頻視訊–>剪輯–>編碼–>上傳伺服器 别人播放.

直播 過程 : 錄制音視訊–>編碼–>流媒體傳輸–>伺服器—>流媒體傳輸到其他app–>解碼–>播放

9.視訊處理功能如美顔、視訊水印、濾鏡、連麥等？

點播服務

點播服務普遍采用了HTTP作為流媒體協定，H.264作為視訊編碼格式，AAC作為音頻編碼格式。采用HTTP作為點播協定有以下兩點優勢：一方面，HTTP是基于TCP協定的應用層協定，媒體傳輸過程中不會出現丢包等現象，進而保證了視訊的品質；另一方面，HTTP被絕大部分的Web伺服器支援，因而流媒體服務機構不必投資購買額外的流媒體伺服器，進而節約了開支。點播服務采用的封裝格式有多種：MP4，FLV，F4V等，它們之間的差別不是很大。視訊編碼标準和音頻編碼标準是H.264和AAC。這兩種标準分别是當今實際應用中編碼效率最高的視訊标準和音頻标準。視訊播放器方面，無一例外的都使用了Flash播放器。