㈠ android音視頻開發——H264的基本概念
ffmpeg常用命令
封裝格式 。
編碼的本質就是壓縮數據
音頻編碼的作用： 將音頻采樣數據（ PCM 等）壓縮成音頻碼流，從而降低音頻的數據量。 常用的音頻編碼方式有以下幾種：
H264壓縮技術主要採用了以下幾種方法對視頻數據進行壓縮。包括：
經過壓縮後的幀分為：I幀，P幀和B幀:
除了I/P/B幀外，還有圖像序列GOP。
組成碼流的結構中，包含了以下幾個部分，從大到小依次是：
H264視頻序列，圖像，片組，片，NALU，宏塊，像素
H264功能分為兩層：
1.H264視頻序列包括一系列的NAL單元，每個NAL單元包含一個RBSP。
2.一個原始的H.264由 N個NALU單元組成
3.NALU單元由[StartCode][NALU Header][NALU Payload]三部分組成
5.NAL Header
由三部分組成forbidden_bit(1bit)(禁止位)，nal_reference_bit(2bits)（優先順序,，值越大，該NAL越重要），nal_unit_type(5bits)（類型）
nal_unit_type
6.NAL的解碼單元的流程如下
㈡ Android音視頻開發——MediaCodec播放H264視頻
所以67實際就是sps
為什麼視頻編碼採用YUV而不是rgb
MediaCodec概念
大家可能不太容易明白，我畫了一個圖
如果第二個參數設置了surface，那麼在釋放的時候releaseOutputBuffer的第二個參數需要設置為true
如果第二個參數設置為null.那麼在釋放的時候releaseOutputBuffer的第二個參數需要設置為false
因此我們可以設置編碼器的初始化
2、找到可用的byeBuffer，並將bytebuffer塞數據，塞完數據，需要通知dsp去解碼
㈢ 在android 平台實現硬解的大俠們，你們是怎麼實現硬解碼的
1、視頻尺寸
一般都能支持176X144/352X288這種尺寸，但是大一些的，640X480就有很多機子不行了，至於為什麼，我也不知道。當然，這個尺寸必須和攝像頭預覽的尺寸一致，預覽的尺寸可以枚舉一下。
2、顏色空間
根據ANdroid SDK文檔，確保所有硬體平台都支持的顏色，在攝像頭預覽輸出是YUV12，在編碼器輸入是COLOR_FormatYUV420Planar，也就是前面代碼中設置的那樣。 不過，文檔終究是文檔，否則安卓就不是安卓。
在有的平台上，這兩個顏色格式是一樣的，攝像頭的輸出可以直接作為編碼器的輸入。也有的平台，兩個是不一樣的，前者就是YUV12，後者等於I420，需要把前者的UV分量顛倒一下。
byte[] i420bytes = null;
private byte[] swapYV12toI420(byte[] yv12bytes, int width, int height) {
if (i420bytes == null)
i420bytes = new byte[yv12bytes.length];
for (int i = 0; i < width*height; i++)
i420bytes[i] = yv12bytes[i];
for (int i = width*height; i < width*height + (width/2*height/2); i++)
i420bytes[i] = yv12bytes[i + (width/2*height/2)];
for (int i = width*height + (width/2*height/2); i < width*height + 2*(width/2*height/2); i++)
i420bytes[i] = yv12bytes[i - (width/2*height/2)];
return i420bytes;
}
3、輸入輸出緩沖區的格式
SDK里並沒有規定格式，但是，這種情況H264的格式基本上就是附錄B。但是，也有比較有特色的，它就是不帶那個StartCode，就是那個0x000001，搞得把他編碼器編出來的東西送給他的解碼器。
ByteBuffer outputBuffer = outputBuffers[outputBufferIndex];
byte[] outData = new byte[bufferInfo.size + 3];
outputBuffer.get(outData, 3, bufferInfo.size);
if (frameListener != null) {
if ((outData[3]==0 && outData[4]==0 && outData[5]==1)
|| (outData[3]==0 && outData[4]==0 && outData[5]==0 && outData[6]==1))
{
frameListener.onFrame(outData, 3, outData.length-3, bufferInfo.flags);
}
else
{
outData[0] = 0;
outData[1] = 0;
outData[2] = 1;
frameListener.onFrame(outData, 0, outData.length, bufferInfo.flags);
}
}
㈣ Android 音視頻01 --- H264的基本原理01
H264壓縮技術主要採用了以下幾種方法對視頻數據進行壓縮。包括：
解決的是空域數據冗餘問題。
解決的是時域數據冗徐問題
將空間上的相關性變為頻域上無關的數據然後進行量化。
經過壓縮後的幀分為：I幀，P幀和B幀:
關鍵幀，採用幀內壓縮技術。
向前參考幀，在壓縮時，只參考前面已經處理的幀。採用幀音壓縮技術。
雙向參考幀，在壓縮時，它即參考前而的幀，又參考它後面的幀。採用幀間壓縮技術。
除了I/P/B幀外，還有圖像序列GOP。
H264的基本原理其實非常簡單，下我們就簡單的描述一下H264壓縮數據的過程。通過攝像頭採集到的視頻幀（按每秒 30 幀算），被送到 H264 編碼器的緩沖區中。編碼器先要為每一幅圖片劃分宏塊。
劃分好宏塊後，計算宏塊的象素值。以此類推，計算一幅圖像中每個宏塊的像素值。
對於視頻數據主要有兩類數據冗餘，一類是時間上的數據冗餘，另一類是空間上的數據冗餘。其中時間上的數據冗餘是最大的。為什麼說時間上的冗餘是最大的呢？假設攝像頭每秒抓取30幀，這30幀的數據大部分情況下都是相關聯的。也有可能不止30幀的的數據，可能幾十幀，上百幀的數據都是關聯特別密切的。
H264編碼器會按順序，每次取出兩幅相鄰的幀進行宏塊比較，計算兩幀的相似度。如下圖：
在H264編碼器中將幀分組後，就要計算幀組內物體的運動矢量了。
H264編碼器首先按順序從緩沖區頭部取出兩幀視頻數據，然後進行宏塊掃描。當發現其中一幅圖片中有物體時，就在另一幅圖的鄰近位置（搜索窗口中）進行搜索。如果此時在另一幅圖中找到該物體，那麼就可以計算出物體的運動矢量了。
運動矢量計算出來後，將相同部分（也就是綠色部分）減去，就得到了補償數據。我們最終只需要將補償數據進行壓縮保存，以後在解碼時就可以恢復原圖了。壓縮補償後的數據只需要記錄很少的一點數據。
我們把運動矢量與補償稱為 幀間壓縮技術 ，它解決的是視頻幀在時間上的數據冗餘。除了幀間壓縮，幀內也要進行數據壓縮，幀內數據壓縮解決的是空間上的數據冗餘。
人眼對圖象都有一個識別度，對低頻的亮度很敏感，對高頻的亮度不太敏感。所以基於一些研究，可以將一幅圖像中人眼不敏感的數據去除掉。這樣就提出了幀內預測技術。
一幅圖像被劃分好宏塊後，對每個宏塊可以進行 9 種模式的預測。找出與原圖最接近的一種預測模式。然後，將原始圖像與幀內預測後的圖像相減得殘差值。再將我們之前得到的預測模式信息一起保存起來，這樣我們就可以在解碼時恢復原圖了，經過幀內與幀間的壓縮後，雖然數據有大幅減少，但還有優化的空間。
可以將殘差數據做整數離散餘弦變換，去掉數據的相關性，進一步壓縮數據。
上面的幀內壓縮是屬於有損壓縮技術。也就是說圖像被壓縮後，無法完全復原。而CABAC屬於無損壓縮技術。
無損壓縮技術大家最熟悉的可能就是哈夫曼編碼了，給高頻的詞一個短碼，給低頻詞一個長碼從而達到數據壓縮的目的。MPEG-2中使用的VLC就是這種演算法，我們以 A-Z 作為例子，A屬於高頻數據，Z屬於低頻數據。看看它是如何做的。
CABAC也是給高頻數據短碼，給低頻數據長碼。同時還會根據上下文相關性進行壓縮，這種方式又比VLC高效很多。
制定了相互傳輸的格式，將宏快 有組織，有結構，有順序的形成一系列的碼流。這種碼流既可 通過 InputStream 網路流的數據進行傳輸，也可以封裝成一個文件進行保存，主要作用是為了傳輸。
組成H264碼流的結構中 包含以下幾部分 ，從大到小排序依次是：
H264視頻序列，圖像，片組，片，NALU，宏塊 ，像素。
NAL層:（Network Abstraction Layer,視頻數據網路抽象層） ： 它的作用是H264隻要在網路上傳輸，在傳輸的過程每個包乙太網是1500位元組，而H264的幀往往會大於1500位元組，所以要進行拆包，將一個幀拆成多個包進行傳輸，所有的拆包或者組包都是通過NAL層去處理的。
VCL層:（Video Coding Layer,視頻數據編碼層） ： 對視頻原始數據進行壓縮
起始碼0x 00 00 00 01 或者 0x 00 00 01 作為 分隔符 。
兩個 0x 00 00 00 01之間的位元組數據 是表示一個NAL Unit。
I 幀的特點：
1.分組:把幾幀圖像分為一組(GOP，也就是一個序列),為防止運動變化,幀數不宜取多。
2.定義幀:將每組內各幀圖像定義為三種類型,即I幀、B幀和P幀;
3.預測幀:以I幀做為基礎幀,以I幀預測P幀,再由I幀和P幀預測B幀;
4.數據傳輸:最後將I幀數據與預測的差值信息進行存儲和傳輸。
1．更高的編碼效率：同H.263等標準的特率效率相比，能夠平均節省大於50％的碼率。
2．高質量的視頻畫面：H.264能夠在低碼率情況下提供高質量的視頻圖像，在較低帶寬上提供高質量的圖像傳輸是H.264的應用亮點。
3．提高網路適應能力：H.264可以工作在實時通信應用（如視頻會議）低延時模式下，也可以工作在沒有延時的視頻存儲或視頻流伺服器中。
4．採用混合編碼結構：同H.263相同，H.264也使用採用DCT變換編碼加DPCM的差分編碼的混合編碼結構，還增加了如多模式運動估計、幀內預測、多幀預測、基於內容的變長編碼、4x4二維整數變換等新的編碼方式，提高了編碼效率。
5．H.264的編碼選項較少：在H.263中編碼時往往需要設置相當多選項，增加了編碼的難度，而H.264做到了力求簡潔的「回歸基本」，降低了編碼時復雜度。
6．H.264可以應用在不同場合：H.264可以根據不同的環境使用不同的傳輸和播放速率，並且提供了豐富的錯誤處理工具，可以很好的控制或消除丟包和誤碼。
7．錯誤恢復功能：H.264提供了解決網路傳輸包丟失的問題的工具，適用於在高誤碼率傳輸的無線網路中傳輸視頻數據。
8．較高的復雜度：264性能的改進是以增加復雜性為代價而獲得的。據估計，H.264編碼的計算復雜度大約相當於H.263的3倍，解碼復雜度大約相當於H.263的2倍。
H.264的目標應用涵蓋了目前大部分的視頻服務，如有線電視遠程監控、交互媒體、數字電視、視頻會議、視頻點播、流媒體服務等。H.264為解決不同應用中的網路傳輸的差異。定義了兩層：視頻編碼層（VCL：Video Coding Layer）負責高效的視頻內容表示，網路提取層（NAL：Network Abstraction Layer）負責以網路所要求的恰當的方式對數據進行打包和傳送。
㈤ Android -- 音視頻基礎知識
幀，是視頻的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視頻就是由許許多多幀組成的。
幀率，即單位時間內幀的數量，單位為：幀/秒 或fps（frames per second）。一秒內包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。 幀率的一般以下幾個典型值：
24/25 fps：1秒 24/25 幀，一般的電影幀率。
30/60 fps：1秒 30/60 幀，游戲的幀率，30幀可以接受，60幀會感覺更加流暢逼真。
85 fps以上人眼基本無法察覺出來了，所以更高的幀率在視頻里沒有太大意義。
這里我們只講常用到的兩種色彩空間。
RGB的顏色模式應該是我們最熟悉的一種，在現在的電子設備中應用廣泛。通過R G B三種基礎色，可以混合出所有的顏色。
這里著重講一下YUV，這種色彩空間並不是我們熟悉的。這是一種亮度與色度分離的色彩格式。
早期的電視都是黑白的，即只有亮度值，即Y。有了彩色電視以後，加入了UV兩種色度，形成現在的YUV，也叫YCbCr。
Y：亮度，就是灰度值。除了表示亮度信號外，還含有較多的綠色通道量。
U：藍色通道與亮度的差值。
V：紅色通道與亮度的差值。
音頻數據的承載方式最常用的是 脈沖編碼調制 ，即 PCM 。
在自然界中，聲音是連續不斷的，是一種模擬信號，那怎樣才能把聲音保存下來呢？那就是把聲音數字化，即轉換為數字信號。
我們知道聲音是一種波，有自己的振幅和頻率，那麼要保存聲音，就要保存聲音在各個時間點上的振幅。
而數字信號並不能連續保存所有時間點的振幅，事實上，並不需要保存連續的信號，就可以還原到人耳可接受的聲音。
根據奈奎斯特采樣定理：為了不失真地恢復模擬信號，采樣頻率應該不小於模擬信號頻譜中最高頻率的2倍。
根據以上分析，PCM的採集步驟分為以下步驟：
采樣率，即采樣的頻率。
上面提到，采樣率要大於原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。
采樣位數，涉及到上面提到的振幅量化。波形振幅在模擬信號上也是連續的樣本值，而在數字信號中，信號一般是不連續的，所以模擬信號量化以後，只能取一個近似的整數值，為了記錄這些振幅值，采樣器會採用一個固定的位數來記錄這些振幅值，通常有8位、16位、32位。
位數越多，記錄的值越准確，還原度越高。
最後就是編碼了。由於數字信號是由0，1組成的，因此，需要將幅度值轉換為一系列0和1進行存儲，也就是編碼，最後得到的數據就是數字信號：一串0和1組成的數據。
整個過程如下：
聲道數，是指支持能不同發聲（注意是不同聲音）的音響的個數。 單聲道：1個聲道
雙聲道：2個聲道
立體聲道：默認為2個聲道
立體聲道（4聲道）：4個聲道
碼率，是指一個數據流中每秒鍾能通過的信息量，單位bps（bit per second）
碼率 = 采樣率 * 采樣位數 * 聲道數
這里的編碼和上面音頻中提到的編碼不是同個概念，而是指壓縮編碼。
我們知道，在計算機的世界中，一切都是0和1組成的，音頻和視頻數據也不例外。由於音視頻的數據量龐大，如果按照裸流數據存儲的話，那將需要耗費非常大的存儲空間，也不利於傳送。而音視頻中，其實包含了大量0和1的重復數據，因此可以通過一定的演算法來壓縮這些0和1的數據。
特別在視頻中，由於畫面是逐漸過渡的，因此整個視頻中，包含了大量畫面/像素的重復，這正好提供了非常大的壓縮空間。
因此，編碼可以大大減小音視頻數據的大小，讓音視頻更容易存儲和傳送。
視頻編碼格式有很多，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了適應時代發展而出現的。
其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯盟主導
MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導。
當然，他們也有聯合制定的編碼標准，那就是現在主流的編碼格式H264，當然還有下一代更先進的壓縮編碼標准H265。
H264是目前最主流的視頻編碼標准，所以我們後續的文章中主要以該編碼格式為基準。
H264由ITU和MPEG共同定製，屬於MPEG-4第十部分內容。
我們已經知道，視頻是由一幀一幀畫面構成的，但是在視頻的數據中，並不是真正按照一幀一幀原始數據保存下來的（如果這樣，壓縮編碼就沒有意義了）。
H264會根據一段時間內，畫面的變化情況，選取一幀畫面作為完整編碼，下一幀只記錄與上一幀完整數據的差別，是一個動態壓縮的過程。
在H264中，三種類型的幀數據分別為
I幀：幀內編碼幀。就是一個完整幀。
P幀：前向預測編碼幀。是一個非完整幀，通過參考前面的I幀或P幀生成。
B幀：雙向預測內插編碼幀。參考前後圖像幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其後最近的一個P幀。
全稱：Group of picture。指一組變化不大的視頻幀。
GOP的第一幀成為關鍵幀：IDR
IDR都是I幀，可以防止一幀解碼出錯，導致後面所有幀解碼出錯的問題。當解碼器在解碼到IDR的時候，會將之前的參考幀清空，重新開始一個新的序列，這樣，即便前面一幀解碼出現重大錯誤，也不會蔓延到後面的數據中。
DTS全稱：Decoding Time Stamp。標示讀入內存中數據流在什麼時候開始送入解碼器中進行解碼。也就是解碼順序的時間戳。
PTS全稱：Presentation Time Stamp。用於標示解碼後的視頻幀什麼時候被顯示出來。
前面我們介紹了RGB和YUV兩種圖像色彩空間。H264採用的是YUV。
YUV存儲方式分為兩大類：planar 和 packed。
planar如下：
packed如下：
上面說過，由於人眼對色度敏感度低，所以可以通過省略一些色度信息，即亮度共用一些色度信息，進而節省存儲空間。因此，planar又區分了以下幾種格式：YUV444、 YUV422、YUV420。
YUV 4:4:4采樣，每一個Y對應一組UV分量。
YUV 4:2:2采樣，每兩個Y共用一組UV分量。
YUV 4:2:0采樣，每四個Y共用一組UV分量。
其中，最常用的就是YUV420。
YUV420屬於planar存儲方式，但是又分兩種類型：
YUV420P：三平面存儲。數據組成為YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。
YUV420SP：兩平面存儲。分為兩種類型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）
原始的PCM音頻數據也是非常大的數據量，因此也需要對其進行壓縮編碼。
和視頻編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等，音樂發燒友應該對這些格式非常熟悉，特別是後兩種無損壓縮格式。
但是，我們今天的主角不是他們，而是另外一個叫AAC的壓縮格式。
AAC是新一代的音頻有損壓縮技術，一種高壓縮比的音頻壓縮演算法。在MP4視頻中的音頻數據，大多數時候都是採用AAC壓縮格式。
AAC格式主要分為兩種：ADIF、ADTS。
ADIF：Audio Data Interchange Format。音頻數據交換格式。這種格式的特徵是可以確定的找到這個音頻數據的開始，不需進行在音頻數據流中間開始的解碼，即它的解碼必須在明確定義的開始處進行。這種格式常用在磁碟文件中。
ADTS：Audio Data Transport Stream。音頻數據傳輸流。這種格式的特徵是它是一個有同步字的比特流，解碼可以在這個流中任何位置開始。它的特徵類似於mp3數據流格式。
ADIF數據格式：
ADTS 一幀 數據格式（中間部分，左右省略號為前後數據幀）：
AAC內部結構也不再贅述，可以參考AAC 文件解析及解碼流程
細心的讀者可能已經發現，前面我們介紹的各種音視頻的編碼格式，沒有一種是我們平時使用到的視頻格式，比如：mp4、rmvb、avi、mkv、mov...
沒錯，這些我們熟悉的視頻格式，其實是包裹了音視頻編碼數據的容器，用來把以特定編碼標准編碼的視頻流和音頻流混在一起，成為一個文件。
例如：mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。
我們在一些播放器中會看到，有硬解碼和軟解碼兩種播放形式給我們選擇，但是我們大部分時候並不能感覺出他們的區別，對於普通用戶來說，只要能播放就行了。
那麼他們內部究竟有什麼區別呢？
在手機或者PC上，都會有CPU、GPU或者解碼器等硬體。通常，我們的計算都是在CPU上進行的，也就是我們軟體的執行晶元，而GPU主要負責畫面的顯示（是一種硬體加速）。
所謂軟解碼，就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現發熱現象。但是，由於使用統一的演算法，兼容性會很好。
硬解碼，指的是利用手機上專門的解碼晶元來加速解碼。通常硬解碼的解碼速度會快很多，但是由於硬解碼由各個廠家實現，質量參差不齊，非常容易出現兼容性問題。
MediaCodec 是Android 4.1(api 16)版本引入的編解碼介面，是所有想在Android上開發音視頻的開發人員繞不開的坑。
由於Android碎片化嚴重，雖然經過多年的發展，Android硬解已經有了很大改觀，但實際上各個廠家實現不同， 還是會有一些意想不到的坑。
相對於FFmpeg，Android原生硬解碼還是相對容易入門一些，所以接下來，我將會從MediaCodec入手，講解如何實現視頻的編解碼，以及引入OpenGL實現對視頻的編輯，最後才引入FFmpeg來實現軟解，算是一個比較常規的音視頻開發入門流程吧。