原文地址
這篇文章是關于 MediaCodec 這一系列類，它主要是用來編碼和解碼音視頻數據。并且包含了一些源碼示例的集合以及常見問題的解答。
在API23之后，官方的文檔 official 就已經十分的詳細了。這里的一些信息可以幫你了解一些編解碼方面的知識，為了考慮兼容性，這里的代碼大部分都是運行在API18及以上的環境中，當然如果你的目標是Lollipop 以上的用戶，你可以有更多的選擇，這些都沒有在這里提及。
概述
MediaCodec 第一次可用是在 Android 4.1版本（API16 ），一開始是用來直接訪問設備的媒體編解碼器。它提供了一種極其原始的接口。MediaCodec類同時存在 Java和C++層中，但是只有前者是公共訪問方法。
在Android 4.3 （API18）中，MediaCodec被擴展為包含一種通過 Surface 提供輸入的方法（通過 createInputSurface 方法），這允許輸入來自于相機的預覽或者是經過OpenGL ES呈現。而且Android4.3也是 MediaCodec 的第一個經過CTS測試（Compatibility Test Suite，CTS是google推出的一種設備兼容性測試規范，用來保證不同設備一致的用戶體驗，同時Google也提供了一份兼容性標準文檔 CDD）的 release 版本。
而且Android4.3還引入了 MediaMuxer，它允許將AVC編解碼器（原始H.264基本流）的輸出轉換為.MP4??格式，可以和音頻流一起轉碼也可以單獨轉換。
Android5.0（API21）引入了“異步模式”，它允許應用程序提供一個回調方法，在緩沖區可用時執行。但是整個文章鏈接里的代碼都沒有用到這個，因為兼容性保持到API 18+。
基本使用
所有的同步模式的 MediaCodec API都遵循一個模式：
- 創建并配置一個
MediaCodec對象 - 循環直到完成:
如果輸入緩沖區就緒，讀取一個輸入塊，并復制到輸入緩沖區中
如果輸出緩沖區就緒，復制輸出緩沖區的數據 - 釋放
MediaCodec對象
MediaCodec的一個實例會處理一種類型的數據，（比如，MP3音頻或H.264視頻），編碼或是解碼。它對原始數據操作，所有任何的文件頭，比如ID3（一般是位于一個mp3文件的開頭或末尾的若干字節內，附加了關于該mp3的歌手，標題，專輯名稱，年代，風格等信息，該信息就被稱為ID3信息）這些信息會被擦除。它不與任何高級的系統組件通信，也不會通過揚聲器來播放音頻，或是通過網絡來獲取視頻流數據，它只是一個會從緩沖區取數據，并返回數據的中間層。
一些編解碼器對于它們的緩沖區是比較特殊的，它們可能需要一些特殊的內存對齊或是有特定的最小最大限制，為了適應廣泛的可能性，buffer緩沖區分配是由編解碼器自己實現的，而不是應用程序的層面。你并不需要一個帶有數據的緩沖區給 MediaCodec，而是直接向它申請一個緩沖區，然后把你的數據拷貝進去。
這看起來和“零拷貝”原則是相悖的，但大部分情況發生拷貝的幾率是比較小的，因為編解碼器并不需要復制或調整這些數據來滿足要求，而且大多數我們可以直接使用緩沖區，比如直接從磁盤或網絡讀取數據到緩沖區中，不需要復制。
MediaCodec的輸入必須在“access units”中完成，在編碼H.264視頻時意味著一幀，在解碼時意味著是一個NAL單元，然而，它看起來感覺更像是流，你不能提交一個單塊，并期望不久后就出現，實際上，編解碼器可能會在輸出前入隊好幾個buffers。
這里強烈建議直接從下面的示例代碼中學習，而不是直接從官方文檔上手。
例子
EncodeAndMuxTest.java (requires 4.3, API 18)
使用OpenGL ES生成一個視頻，通過 MediaCodec 使用H.264進行編碼，而且通過 MediaMuxer 將流轉換成一個.MP4文件，這里通過CTS 測試編寫，也可以直接轉成其他環境的代碼。
CameraToMpegTest.java (requires 4.3, API 18)
通過相機預覽錄制視頻并且編碼成一個MP4文件，同樣通過 MediaCodec 使用H.264進行編碼，以及 MediaMuxer 將流轉換成一個.MP4文件，作為一個擴展版，還通過GLES片段著色器在錄制的時候改變視頻，同樣是一個CTS test，可以轉換成其他環境的代碼。
Android Breakout game recorder patch (requires 4.3, API 18)
這是 Android Breakout v1.0.2版本的一個補丁，添加了游戲錄制功能，游戲是在60fps的全屏分辨率下，通過一個30fps 720p的配置使用AVC編解碼器來錄制視頻，錄制文件被保存在一個應用的私有空間，比如 ./data/data/com.faddensoft.breakout/files/video.mp4。這個本質上和 EncodeAndMuxTest.java 是一樣的，不過這個是完全的真實環境不是CTS test，一個關鍵的區別在于EGL的創建，這里允許通過將顯示和視頻context以共享紋理的方式。
EncodeDecodeTest.java (requires 4.3, API 18)
CTS test，總共有三種test做著相同的事情，但是是不同的方式。每一個都是：
生成video的幀，通過AVC進行編碼，生成解碼流，看看是否和原始數據一樣
上面的生成，編碼，解碼，檢測基本是同時的，幀被生成后，傳遞給編碼器，編碼器拿到的數據會傳遞給解碼器，然后進行校驗，三種方式分別是
Buffer到Buffer，buffers是軟件生成的YUV幀數據，這種方式是最慢的，但是能夠允許應用程序去檢測和修改YUV數據。
Buffer到Surface，編碼是一樣的，但是解碼會在surface中，通過OpenGL ES的 getReadPixels()進行校驗
Surface到Surface，通過OpenGL ES生成幀并解碼到Surface中，這是最快的方式，但是需要YUV和RGB數據的轉換。
DecodeEditEncodeTest.java (requires 4.3, API 18)
CTS test，主要是生成一系列視頻幀，通過AVC進行編碼，編碼數據流保存在內存中，使用 MediaCodec解碼，通過OpenGL ES片段著色器編輯幀數據（交換綠/藍顏色信道），解碼編輯后的視頻流，驗證輸出。
ExtractMpegFramesTest.java (requires 4.1, API 16)
ExtractMpegFramesTest.java (requires 4.2, API 17)
提取一個.mp4視頻文件的開始10幀，并保持成一個PNG文件到sd卡中，使用 MediaExtractor 提取 CSD 數據，并將單個 access units給 MediaCodec 解碼器，幀被解碼到一個SurfaceTexture的surface中，離屏渲染，并通過 glReadPixels() 拿到數據后使用 Bitmap#compress() 保存成一個PNG 文件。
常見問題
Q1:我怎么播放一個由MediaCodec創建的“video/avc”格式的視頻流？
A1.這個被創建的流是原始的H.264流數據，Linux的Totem Movie Player可以播放，但大部分其他的都播放不了，你可以使用 MediaMuxer 將其轉換為MP4文件，看前面的EncodeAndMuxTest例子。
Q2:當我創建一個編碼器時，調用 MediaCodec的configure()方法會失敗并拋出一個IllegalStateException異常？
A2.這通常是因為你沒有指定所有編碼器需要的關鍵命令，可以看一個這個例子 this stackoverflow item。
Q3:我的視頻解碼器配置好了但是不接收數據，這是為什么？
A3.一個比較常見的錯誤就是忽略設置Codec-Specific Data（CSD），這個在文檔中簡略的提到過，有兩個key，“csd-0”，“csd-1”，這個相當于是一系列元數據的序列參數集合，我們只需要直到這個會在MediaCodec 編碼的時候生成，并且在MediaCodec 解碼的時候需要它。
如果你直接把編碼器輸出傳遞給解碼器，就會發現第一個包里面有BUFFER_FLAG_CODEC_CONFIG 的flag，這個參數需要確保傳遞給了解碼器，這樣解碼器才會開始接收數據，或者你可以直接設置CSD數據給MediaFormat，通過 configure() 方法設置給解碼器，這里可以參考 EncodeDecodeTest sample 這個例子。
實在不行也可以使用 MediaExtractor ，它會幫你做好一切。
Q4:我可以直接將流數據給解碼器么？
A4.不一定，解碼器需要的是 "access units"格式的流，不一定是字節流。對于視頻解碼器，這意味著你需要保存通過編碼器（比如H.264的NAL單元）創建的“包邊界”，這里可以參考 DecodeEditEncodeTest sample 是如何操作的，一般不能讀任意的塊數據并傳遞給解碼器。
Q5:我在編碼由相機預覽拿到的YUV數據時，為什么看起來顏色有問題？
A5.相機輸出的顏色格式和MediaCodec 在編碼時的輸入格式是不一樣的，相機支持YV12（平面 YUV 4:2:0） 以及 NV21 （半平面 YUV 4:2:0），MediaCodec支持以下一個或多個：
.#19 COLOR_FormatYUV420Planar (I420)
.#20 COLOR_FormatYUV420PackedPlanar (also I420)
.#21 COLOR_FormatYUV420SemiPlanar (NV12)
.#39 COLOR_FormatYUV420PackedSemiPlanar (also NV12)
.#0x7f000100 COLOR_TI_FormatYUV420PackedSemiPlanar (also also NV12)
I420的數據布局相當于YV12，但是Cr和Cb卻是顛倒的，就像NV12和NV21一樣。所以如果你想要去處理相機拿到的YV12數據，可能會看到一些奇怪的顏色干擾，比如這樣 these images。直到Android4.4版本，依然沒有統一的輸入格式，比如Nexus 7（2012），Nexus 10使用的COLOR_FormatYUV420Planar，而Nexus 4, Nexus 5, and Nexus 7（2013）使用的是COLOR_FormatYUV420SemiPlanar，而Galaxy Nexus使用的COLOR_TI_FormatYUV420PackedSemiPlanar。
一種可移植性更高，更有效率的方式就是使用API18 的Surface input API，這個在 CameraToMpegTest sample 中已經演示了，這樣做的缺點就是你必須去操作RGB而不是YUV數據，這是一個圖像處理的問題，如果你可以通過片段著色器來實現圖像操作，可以利用GPU來處理這些轉換和計算。
Q6: EGL_RECORDABLE_ANDROID flag是用來干什么的？
A6.這會告訴EGL，創建surface的行為必須是視頻編解碼器能兼容的，沒有這個flag，EGL可能使用 MediaCodec 不能理解的格式來操作。
Q7:我是不是必須要在編碼時設置 presentation time stamp （pts）？
A7.是的，一些設備如果沒有設置合理的值，那么在編碼的時候就會采取丟棄幀和低質量編碼的方式。
需要注意的一點就是MediaCodec所需要的time格式是微秒，大部分java代碼中的都是毫秒或者納秒。
Q8:為什么有時輸出混亂（比如都是零，或者太短等等）？
A8.這常見的錯誤就是沒有去適配ByteBuffer的position和limit，這些東西MediaCodec并沒有自動的去做，
我們需要手動的加上一些代碼：
int bufIndex = codec.dequeueOutputBuffer(info, TIMEOUT);
ByteBuffer outputData = outputBuffers[bufIndex];
if (info.size != 0) {
outputData.position(info.offset);
outputData.limit(info.offset + info.size);
}
在輸入端，你需要在將數據復制到緩沖區之前調用 clear() 。
Q9: 有時候會發現 storeMetaDataInBuffers 會打出一些錯誤log？
A9.是的，比如在Nexus 5上，看起來是這樣的
E OMXNodeInstance: OMX_SetParameter() failed for StoreMetaDataInBuffers: 0x8000101a
E ACodec : [OMX.qcom.video.encoder.avc] storeMetaDataInBuffers (output) failed w/ err -2147483648
不過可以忽略這些，不會出現什么問題。
