H264簡介

來自百度百科的介紹：

H.264是國際標準化組織（ISO）和國際電信聯盟（ITU）共同提出的繼MPEG4之后的新一代數字視頻壓縮格式。
H.264是ITU-T以H.26x系列為名稱命名的視頻編解碼技術標準之一。H.264是ITU-T的VCEG（視頻編碼專家組）和ISO/IEC的MPEG（活動圖像編碼專家組）的聯合視頻組（JVT：joint video team）開發的一個數字視頻編碼標準。

H.264是在MPEG-4技術的基礎之上建立起來的，其編解碼流程主要包括5個部分：幀間和幀內預測（Estimation）、變換（Transform）和反變換、量化（Quantization）和反量化、環路濾波（Loop Filter）、
熵編碼（Entropy Coding）。

H.264標準的主要目標是：與其它現有的視頻編碼標準相比，在相同的帶寬下提供更加優秀的圖象質量。通過該標準，在同等圖象質量下的壓縮效率比以前的標準（MPEG2）提高了2倍左右。

H264編碼原理

在了解H264編碼原理之前，我們先來了解一下H264碼流的數據。

H.264原始碼流(裸流)是由一個接一個NALU組成，它的功能分為兩層，VCL(視頻編碼層)和 NAL(網絡提取層)。

VCL：包括核心壓縮引擎和塊，宏塊和片的語法級別定義，設計目標是盡可能地獨立于網絡進行高效的編碼。

NAL：負責將VCL產生的比特字符串適配到各種各樣的網絡和多元環境中，覆蓋了所有片級以上的語法級別。

在VCL進行數據傳輸或存儲之前，這些編碼的VCL數據，被映射或封裝進NAL單元。（NALU）

一個NALU = 一組對應于視頻編碼的NALU頭部信息 + 一個原始字節序列負荷(RBSP,Raw Byte Sequence Payload).

NALU結構單元的主體結構如下所示；一個原始的H.264 NALU單元常由StartCode + NALU Header + RBSP三部分組成，
其中 Start Code 用于標示這是一個NALU 單元的開始，必須是"00 00 00 01" 或"00 00 01"開頭。

NALU結構組成

既然H164中的都是NALU數據，那么NALU是怎么來的呢？

首先我們來看兩張圖：

H264編碼數據

從圖中我們看到一幀圖片經過 H.264 編碼器之后，就被編碼為一個或多個片（slice），而裝載著這些片（slice）的載體，就是 NALU 了。

h264碼流結構

H264碼流組成，從大到小排序依次是:

H264視頻序列、圖像、片組、片、NALU、宏塊、像素。

H264壓縮技術主要采用了以下幾種方法對視頻數據進行壓縮。包括：

• 幀內預測壓縮，解決的是空域數據冗余問題。
• 幀間預測壓縮（運動估計與補償），解決的是時域數據冗余問題。
• 整數離散余弦變換（DCT），將空間上的相關性變為頻域上無關的數據然后進行量化。
• CABAC壓縮。

下面我們就來分析一下H264的編碼原理：

宏塊劃分

當每一幀圖像被送到 H264 編碼器的緩沖區中。編碼器先要為每一幅圖片劃分宏塊。

我們以下面這張圖為例

H264默認是使用 16X16 大小的區域作為一個宏塊，也可以劃分成更小的 8X8的大小。

宏塊劃分好了之后，就會計算宏塊內的像素值

依次循環劃分，等到將一幀圖像宏塊劃分和像素計算完畢后就是這樣子的：

劃分子塊

H264對比較平坦的圖像使用 16X16 大小的宏塊。但為了更高的壓縮率，還可以在 16X16 的宏塊上更劃分出更小的子塊。

子塊的大小可以是 8X16? 16X8? 8X8? 4X8? 8X4? 4X4非常的靈活。

幀分組

宏塊劃分好后，就可以對H264編碼器緩存中的所有圖片進行分組了。

我們知道視頻的壓縮原理就是去掉冗余數據，而視頻的冗余數據主要是時間冗余和空間冗余兩大類，而時間冗余又是最大的。

為什么時間冗余的數據是最大的呢？因為我們通過攝像頭每秒中抓取幾十幀的畫像，而這些畫像大部分情況下都是有相關性的，這些關聯特別密切的幀，其實我們只需要保存一幀的數據，其它幀都可以通過這一幀再按某種規則預測出來，所以說視頻數據在時間上的冗余是最多的。這也是為什么會有I幀、P幀以及B幀的緣由。

那么為了達到通過某幾幀圖像來預測后面幾幀圖像的目的，那么我們就需要對幀進行分組，將一些相似的幀劃分在一組。

那么如何判定某些幀關系密切，可以劃為一組呢？我們來看一下例子，下面是捕獲的一組運動的臺球的視頻幀，臺球從右上角滾到了左下角。

H264編碼器會按順序，每次取出兩幅相鄰的幀進行宏塊比較，計算兩幀的相似度，如圖：

宏塊比較

通過宏塊掃描與宏塊搜索如果發現這兩個幀的關聯度是非常高的，那么這幾幀就可以劃分為一組。

其算法是：在相鄰幾幅圖像畫面中，一般有差別的像素只有10%以內的點,亮度差值變化不超過2%，而色度差值的變化只有1%以內，我們認為這樣的圖可以分到一組。

在這樣一組幀中，經過編碼后，我們只保留第一帖的完整數據，其它幀都通過參考上一幀計算出來。我們稱第一幀為IDR／I幀，其它幀我們稱為P／B幀，這樣編碼后的數據幀組我們稱為GOP。

運動估計與補償與幀間壓縮

我們把運動矢量與補償稱為幀間壓縮技術，它解決的是視頻幀在時間上的數據冗余。

在H264編碼器中將幀分組后，就要計算幀組內物體的運動矢量了。

H264編碼器首先按順序從緩沖區頭部取出兩幀視頻數據，然后進行宏塊掃描。當發現其中一幅圖片中有物體時，就在另一幅圖的鄰近位置（搜索窗口中）進行搜索。
如果此時在另一幅圖中找到該物體，那么就可以計算出物體的運動矢量了。

以上面臺球的例子為例，下面這幅圖就是搜索后的臺球移動的位置。

臺球運動補償

通過兩幀圖像中臺球位置相差，就可以計算出臺圖運行的方向和距離。H264依次把每一幀中球移動的距離和方向都記錄下來就成了下面的樣子：

運動矢量計算出來后，將相同部分（也就是綠色部分）減去，就得到了補償數據。
我們最終只需要將補償數據進行壓縮保存，以后在解碼時就可以恢復原圖了。壓縮補償后的數據只需要記錄很少的一點數據，因而達到了壓縮的目的。

幀內預測壓縮

上面我們說了運動補償解決的是視頻數據在時間上的冗余問題，那么視頻數據在空間上的冗余問題該怎么解決呢？這就是幀內預測壓縮所要解決的問題。

我們知道，人眼對圖象都有一個識別度，對低頻的亮度很敏感，對高頻的亮度不太敏感。所以基于一些研究，可以將一幅圖像中人眼不敏感的數據去除掉。這樣就提出了幀內預測技術。

H264編碼器在對一幅圖像被劃分好宏塊后，對每個宏塊可以進行各種模式的預測。找出與原圖最接近的一種預測模式。

我們通過一張圖看下都有哪些預測模式，針對宏塊大小的不同，有不同的預測模式,注意箭頭的角度大小不同代表不同的預測模式。

H264幀內預測模式

在實際應用中，我們查看圖片的時候，將圖片不斷放大之后會看到圖片會變模糊，有很多小方塊似的馬賽克出現，這大概就是幀內預測的效果。

下面這張圖就是通過采樣宏塊的左邊和上邊的像素值，然后通過9種預測模式預測出來的宏塊像素結果：

幀內預測后的圖像與原始圖像的對比如下：

通過幀內預測之后，將原始圖像與幀內預測后的圖像相減得殘差值。再將我們之前得到的預測模式信息一起保存起來，這樣我們就可以在解碼時恢復原圖了。

這樣通過存取小量的殘差數據和預測模式就解決了視頻數據上的空間冗余問題。

對殘差數據做DCT

經過幀內與幀間的壓縮后，雖然數據有大幅減少，但還有優化的空間。

可以將殘差數據做整數離散余弦變換，去掉數據的相關性，進一步壓縮數據。如下圖所示，左側為原數據的宏塊，右側為計算出的殘差數據的宏塊。

將殘差數據宏塊數字化后如下圖所示：

我們可以看到宏塊數字化后的表格數字是雜亂無章，沒有規律可言的。我們將殘差數據宏塊進行 DCT 轉換，結果如下圖：

我們可以看出經過DCT轉換后，我們的宏塊數據變得有規律了，從左上角到右下角，數據越來越小。對于DCT轉換的原理感興趣的童鞋可以自行搜索了解，這里就不做多的詳細講解了，大概就是經過DCT轉換出來的數據，從左上角到右下角，出現的頻率越來約高。那么根據人眼對低頻敏感對高頻敏感這個原理，省掉右下部分的一些值的話，對人眼來說，看起來實際上是沒什么區別的。

CABAC

幀內壓縮是屬于有損壓縮技術。也就是說圖像被壓縮后，無法完全復原。而CABAC則屬于無損壓縮技術。

無損壓縮技術大家最熟悉的可能就是哈夫曼編碼了，給高頻的詞一個短碼，給低頻詞一個長碼從而達到數據壓縮的目的。MPEG-2中使用的VLC就是這種算法，我們以 A-Z 作為例子，假如A屬于高頻數據，Z屬于低頻數據。
那么我們用一個短碼代表A，為了區分則用一個長碼代表Z，那么VLC這三個字母則可以通過查詢對應的字母碼表示出來。如圖：

在早期的Android系統中，谷歌因為內存原因將圖片的哈夫曼壓縮給屏蔽了，所以如果開發者想要使用哈夫曼算法對圖片進行壓縮的話需要做一些擴展。

CABAC也是給高頻數據短碼，給低頻數據長碼。同時還會根據上下文相關性進行壓縮，這種方式又比VLC高效很多。其效果如圖：

結束

對于H264編碼原理今天就講這么多，希望以上內容能對您有所幫助。對于音視頻開發感興趣的童鞋，請掃碼關注，一起學習一起嗨！！！

轉載地址

https://mp.weixin.qq.com/s?src=11&timestamp=1677637992&ver=4379&signature=q8JuBYx3HSzYXznvCAwTi3bStwsZwWAsSbb2jD0tELIwGvRrRWZJ4u5pEDTuXgpLyChsOlZxXkOf7e7GdEjCQJGz9KEfqcRHJ5QjMAOYntkKvS3dHYcqa0S02*EJuc&new=1