在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

--  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/%E7%9F%AD%E8%A7%86%E9%A2%91%20SDK%20%E5%8A%9F%E8%83%BD%E7%82%B9%E6%8A%80%E6%9C%AF%E5%AE%9E%E7%8E%B0%E6%96%B9%E5%BC%8F%E8%AF%A6%E8%A7%A3.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播放器。