在學習了Android 音視頻的基本的相關知識，并整理了相關的API之后，我們應該對基本的音視頻有一定的輪廓了。
下面開始接觸一個Android音視頻中相當重要的一個API： MediaCodec。通過這個API，我們能夠做很多Android音視頻方面的工作，下面是我們學習這個API的時候，主要的方向：
學習 MediaCodec API，完成音頻 AAC 硬編、硬解
學習 MediaCodec API，完成視頻 H.264 的硬編、硬解
一、MediaCodec 介紹
MediaCodec類可以用于使用一些基本的多媒體編解碼器（音視頻編解碼組件），它是Android基本的多媒體支持基礎架構的一部分通常和 MediaExtractor, MediaSync, MediaMuxer, MediaCrypto, MediaDrm, Image, Surface, and AudioTrack 一起使用。
一個編解碼器可以處理輸入的數據來產生輸出的數據，編解碼器使用一組輸入和輸出緩沖器來異步處理數據。你可以創建一個空的輸入緩沖區，填充數據后發送到編解碼器進行處理。編解碼器使用輸入的數據進行轉換，然后輸出到一個空的輸出緩沖區。最后你獲取到輸出緩沖區的數據，消耗掉里面的數據，釋放回編解碼器。如果后續還有數據需要繼續處理，編解碼器就會重復這些操作。輸出流程如下：
編解碼器支持的數據類型：
編解碼器能處理的數據類型為：壓縮數據、原始音頻數據和原始視頻數據。你可以通過ByteBuffers能夠處理這三種數據，但是需要你提供一個Surface，用于對原始的視頻數據進行展示，這樣也能提高編解碼的性能。Surface使用的是本地的視頻緩沖區，這個緩沖區不映射或拷貝到ByteBuffers。這樣的機制讓編解碼器的效率更高。通常在使用Surface的時候，無法訪問原始的視頻數據，但是你可以使用ImageReader訪問解碼后的原始視頻幀。在使用ByteBuffer的模式下，您可以使用Image類和getInput/OutputImage（int）訪問原始視頻幀。
編解碼器的生命周期：
主要的生命周期為：Stopped、Executing、Released。
Stopped的狀態下也分為三種子狀態：Uninitialized、Configured、Error。
Executing的狀態下也分為三種子狀態：Flushed, Running、End-of-Stream。
下圖是生命周期的說明圖：
如圖可以看到：
當創建編解碼器的時候處于未初始化狀態。首先你需要調用configure(…)方法讓它處于Configured狀態，然后調用start()方法讓其處于Executing狀態。在Executing狀態下，你就可以使用上面提到的緩沖區來處理數據。
Executing的狀態下也分為三種子狀態：Flushed, Running、End-of-Stream。在start() 調用后，編解碼器處于Flushed狀態，這個狀態下它保存著所有的緩沖區。一旦第一個輸入buffer出現了，編解碼器就會自動運行到Running的狀態。當帶有end-of-stream標志的buffer進去后，編解碼器會進入End-of-Stream狀態，這種狀態下編解碼器不在接受輸入buffer，但是仍然在產生輸出的buffer。此時你可以調用flush()方法，將編解碼器重置于Flushed狀態。
調用stop()將編解碼器返回到未初始化狀態，然后可以重新配置。 完成使用編解碼器后，您必須通過調用release()來釋放它。
在極少數情況下，編解碼器可能會遇到錯誤并轉到錯誤狀態。 這是使用來自排隊操作的無效返回值或有時通過異常來傳達的。 調用reset()使編解碼器再次可用。 您可以從任何狀態調用它來將編解碼器移回未初始化狀態。 否則，調用 release()動到終端釋放狀態。
二、MediaCodec API 說明
MediaCodec可以處理具體的視頻流，主要有這幾個方法：
getInputBuffers：獲取需要編碼數據的輸入流隊列，返回的是一個ByteBuffer數組
queueInputBuffer：輸入流入隊列
dequeueInputBuffer：從輸入流隊列中取數據進行編碼操作
getOutputBuffers：獲取編解碼之后的數據輸出流隊列，返回的是一個ByteBuffer數組
dequeueOutputBuffer：從輸出隊列中取出編碼操作之后的數據
releaseOutputBuffer：處理完成，釋放ByteBuffer數據
三、MediaCodec 流控
3.1 流控基本概念
流控就是流量控制。為什么要控制，因為條件有限！涉及到了 TCP 和視頻編碼：
對 TCP 來說就是控制單位時間內發送數據包的數據量，對編碼來說就是控制單位時間內輸出數據的數據量。
TCP 的限制條件是網絡帶寬，流控就是在避免造成或者加劇網絡擁塞的前提下，盡可能利用網絡帶寬。帶寬夠、網絡好，我們就加快速度發送數據包，出現了延遲增大、丟包之后，就放慢發包的速度（因為繼續高速發包，可能會加劇網絡擁塞，反而發得更慢）。
視頻編碼的限制條件最初是解碼器的能力，碼率太高就會無法解碼，后來隨著 codec 的發展，解碼能力不再是瓶頸，限制條件變成了傳輸帶寬/文件大小，我們希望在控制數據量的前提下，畫面質量盡可能高。
一般編碼器都可以設置一個目標碼率，但編碼器的實際輸出碼率不會完全符合設置，因為在編碼過程中實際可以控制的并不是最終輸出的碼率，而是編碼過程中的一個量化參數（Quantization Parameter，QP），它和碼率并沒有固定的關系，而是取決于圖像內容。
無論是要發送的 TCP 數據包，還是要編碼的圖像，都可能出現“尖峰”，也就是短時間內出現較大的數據量。TCP 面對尖峰，可以選擇不為所動（尤其是網絡已經擁塞的時候），這沒有太大的問題，但如果視頻編碼也對尖峰不為所動，那圖像質量就會大打折扣了。如果有幾幀數據量特別大，但仍要把碼率控制在原來的水平，那勢必要損失更多的信息，因此圖像失真就會更嚴重。
3.2 Android 硬編碼流控
MediaCodec 流控相關的接口并不多，一是配置時設置目標碼率和碼率控制模式，二是動態調整目標碼率(Android 19 版本以上)。
配置時指定目標碼率和碼率控制模式：
mediaFormat.setInteger(MediaFormat.KEY_BIT_RATE, bitRate);
mediaFormat.setInteger(MediaFormat.KEY_BITRATE_MODE,
MediaCodecInfo.EncoderCapabilities.BITRATE_MODE_VBR);
mVideoCodec.configure(mediaFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
碼率控制模式有三種：
CQ 表示完全不控制碼率，盡最大可能保證圖像質量；
CBR 表示編碼器會盡量把輸出碼率控制為設定值，即我們前面提到的“不為所動”；
VBR 表示編碼器會根據圖像內容的復雜度（實際上是幀間變化量的大小）來動態調整輸出碼率，圖像復雜則碼率高，圖像簡單則碼率低；
動態調整目標碼率：
Bundle param = new Bundle();
param.putInt(MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bitrate);
mediaCodec.setParameters(param);
3.3 Android 流控策略選擇
質量要求高、不在乎帶寬、解碼器支持碼率劇烈波動的情況下，可以選擇 CQ 碼率控制策略。
VBR 輸出碼率會在一定范圍內波動，對于小幅晃動，方塊效應會有所改善，但對劇烈晃動仍無能為力；連續調低碼率則會導致碼率急劇下降，如果無法接受這個問題，那 VBR 就不是好的選擇。
CBR 的優點是穩定可控，這樣對實時性的保證有幫助。所以 WebRTC 開發中一般使用的是CBR。
