1、NAL全稱Network Abstract Layer, 即網絡抽象層。
在H.264/AVC視頻編碼標准中，整個系統框架被分為了兩個層面：視頻編碼層面（VCL）和網絡抽象層面（NAL）。其中，前者負責有效表示視頻數據的內容，而后者則負責格式化數據並提供頭信息，以保證數據適合各種信道和存儲介質上的傳輸。因此我們平時的每幀數據就是一個NAL單元（SPS與PPS除外）。在實際的H264數據幀中，往往幀前面帶有00 00 00 01 或 00 00 01分隔符，一般來說編碼器編出的首幀數據為PPS與SPS，接着為I幀……
如下圖：
2、如何判斷幀類型（是圖像參考幀還是I、P幀等）？
NALU類型是我們判斷幀類型的利器，從官方文檔中得出如下圖：
我們還是接着看最上面圖的碼流對應的數據來層層分析，以00 00 00 01分割之后的下一個字節就是NALU類型，將其轉為二進制數據后，解讀順序為從左往右算，如下:
（1）第1位禁止位，值為1表示語法出錯
（2）第2~3位為參考級別
（3）第4~8為是nal單元類型
例如上面00000001后有67,68以及65
其中0x67的二進制碼為：
0110 0111
4-8為00111，轉為十進制7，參考第二幅圖：7對應序列參數集SPS
其中0x68的二進制碼為：
0110 1000
4-8為01000，轉為十進制8，參考第二幅圖：8對應圖像參數集PPS
其中0x65的二進制碼為：
0110 0101
4-8為00101，轉為十進制5，參考第二幅圖：5對應IDR圖像中的片(I幀)
所以判斷是否為I幀的算法為： （NALU類型 & 0001 1111） = 5 即 NALU類型 & 31 = 5
比如0x65 & 31 = 5
http://blog.csdn.net/evsqiezi/article/details/8492593
幀格式
H264幀由NALU頭和NALU主體組成。
NALU頭由一個字節組成,它的語法如下:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
F: 1個比特.
forbidden_zero_bit. 在 H.264 規范中規定了這一位必須為 0.
NRI: 2個比特.
nal_ref_idc. 取00~11,似乎指示這個NALU的重要性,如00的NALU解碼器可以丟棄它而不影響圖像的回放,0～3，取值越大，表示當前NAL越重要，需要優先受到保護。如果當前NAL是屬於參考幀的片，或是序列參數集，或是圖像參數集這些重要的單位時，本句法元素必需大於0。
Type: 5個比特.
nal_unit_type. 這個NALU單元的類型,1～12由H.264使用，24～31由H.264以外的應用使用,簡述如下:
0 沒有定義
1-23 NAL單元 單個 NAL 單元包
1 不分區，非IDR圖像的片
2 片分區A
3 片分區B
4 片分區C
5 IDR圖像中的片
6 補充增強信息單元（SEI）
7 SPS
8 PPS
9 序列結束
10 序列結束
11 碼流借宿
12 填充
13-23 保留
24 STAP-A 單一時間的組合包
25 STAP-B 單一時間的組合包
26 MTAP16 多個時間的組合包
27 MTAP24 多個時間的組合包
28 FU-A 分片的單元
29 FU-B 分片的單元
30-31 沒有定義
AUD
一般文檔沒有對AUD進行描敘，其實這是一個幀開始的標志，字節順序為：00 00 00 01 09 f0
從結構上看，有start code, 所以確實是一個NALU，類型09在H264定義里就是AUD（分割器）。大部分播放器可以在沒有AUD的情況下正常播放。
緊隨AUD，一般是SPS/PPS/SEI/IDR的組合或者簡單就是一個SLICE，也就是一個幀的開始。像Flash這樣的播放器，每次需要一個完整的幀數據，那么把2個AUD之間的數據按照格式打包給播放器就可以了。
H.264編碼時，在每個NAL前添加起始碼 0x000001，解碼器在碼流中檢測到起始碼，當前NAL結束。為了防止NAL內部出現0x000001的數據，h.264又提出'防止競爭 emulation prevention"機制，在編碼完一個NAL時，如果檢測出有連續兩個0x00字節，就在后面插入一個0x03。當解碼器在NAL內部檢測到0x000003的數據，就把0x03拋棄，恢復原始數據。
0x000000 >>>>>> 0x00000300
0x000001 >>>>>> 0x00000301
0x000002 >>>>>> 0x00000302
0x000003 >>>>>> 0x00000303
總的來說H264的碼流的打包方式有兩種,一種為annex-b byte stream format 的格式，這個是絕大部分編碼器的默認輸出格式，就是每個幀的開頭的3~4個字節是H264的start_code,0x00000001或者0x000001。
另一種是原始的NAL打包格式，就是開始的若干字節（1，2，4字節）是NAL的長度，而不是start_code,此時必須借助某個全局的數據來獲得編 碼器的profile,level,PPS,SPS等信息才可以解碼。
SPS,PPS的解析
SPS
profile_idc和level_idc是指比特流所遵守的配置和級別。
constraint_set0_flag 等於1是指比特流遵從某節中的所有規定。constraint_set0_flag 等於0是指該比特流可以遵從也可以不遵從某節中的所有規定。當profile_idc等於100、110、122或144時，constraint_set0_flag、constraint_set1_flag和constraint_set2_flag都應等於0。
log2_max_frame_num_minus4的值應在0-12范圍內（包括0和12），這個句法元素主要是為讀取另一個句法元素 frame_num 服務的，frame_num 是最重要的句法元素之一，它標識所屬圖像的解碼順序 。這個句法元素同時也指明了 frame_num 的所能達到的最大值： MaxFrameNum = 2*exp( log2_max_frame_num_minus4 + 4 ) 。
pic_order_cnt_type 是指解碼圖像順序的計數方法。pic_order_cnt_type 的取值范圍是0到2（包括0和2）。
log2_max_pic_order_cnt_lsb_minus4表示用於某節規定的圖像順序數解碼過程中的變量MaxPicOrderCntLsb的值，
num_ref_frames規定了可能在視頻序列中任何圖像幀間預測的解碼過程中用到的短期參考幀和長期參考幀、互補參考場對以及不成對的參考場的最大數量。num_ref_frames 的取值范圍應該在0到MaxDpbSize。
gaps_in_frame_num_value_allowed_flag 表示某節給出的frame_num 的允許值以及在某節給出的frame_num 值之間存在推測的差異的情況下進行的解碼過程。
pic_width_in_mbs_minus1加1是指以宏塊為單元的每個解碼圖像的寬度。
pic_height_in_map_units_minus1 的語義依賴於變量frame_mbs_only_flag，規定如下：-— 如果 frame_mbs_only_flag 等於0，
pic_height_in_map_units_minus1加1就表示以宏塊為單位的一場的高度。-— 否則（frame_mbs_only_flag等於1），pic_height_in_map_units_minus1加1就表示
以宏塊為單位的一幀的高度。變量 FrameHeightInMbs 由下列公式得出：FrameHeightInMbs = ( 2 – frame_mbs_only_flag ) * PicHeightInMapUnits。
mb_adaptive_frame_field_flag 等於0表示在一個圖像的幀和場宏塊之間沒有交換。mb_adaptive_frame_field_flag 等於1表示在幀和幀內的場宏塊之間可能會有交換。當mb_adaptive_frame_field_flag沒有特別規定時，默認其值為0。
direct_8x8_inference_flag 表示在某節中規定的B_Skip、B_Direct_16x16和B_Direct_8x8亮度運動矢量的計算過程使用的方法。當frame_mbs_only_flag 等於0時
direct_8x8_inference_flag 應等於1。
frame_cropping_flag 等於1表示幀剪切偏移參數遵從視頻序列參數集中的下一個值。frame_cropping_flag 等於0表示不存在幀剪切偏移參數。
vui_parameters_present_flag 等於1 表示存在如附錄E 提到的vui_parameters( ) 語法結構。vui_parameters_present_flag 等於0表示不存在如附錄E提到的vui_parameters( ) 語法結構。
PPS
seq_parameter_set_id是指活動的序列參數集。變量seq_parameter_set_id的值應該在0到31的范圍內（包括0和31）。
entropy_coding_mode_flag 用於選取語法元素的熵編碼方式，在語法表中由兩個標識符代表，具體如下：如果entropy_coding_mode_flag 等於0，那么采用語法表中左邊的描述符所指定的方法。
pic_order_present_flag等於1 表示與圖像順序數有關的語法元素將出現於條帶頭中，pic_order_present_flag 等於0表示條帶頭中不會出現與圖像順序數有關的語法元素。
num_slice_groups_minus1加1表示一個圖像中的條帶組數。當num_slice_groups_minus1 等於0時，圖像中所有的條帶屬於同一個條帶組。
num_ref_idx_l0_active_minus1表示參考圖像列表0 的最大參考索引號，該索引號將用來在一幅圖像中num_ref_idx_active_override_flag 等於0 的條帶使用列表0 預測時，解碼該圖像的這些條帶。當MbaffFrameFlag等於1時，num_ref_idx_l0_active_minus1 是幀宏塊解碼的最大索引號值，而2 *num_ref_idx_l0_active_minus1 + 1是場宏塊解碼的最大索引號值。num_ref_idx_l0_active_minus1 的值應該在0到31的范圍內（包括0和31）。
weighted_pred_flag等於0表示加權的預測不應用於P和SP條帶。weighted_pred_flag等於1表示在P和SP條帶中應使用加權的預測。
weighted_bipred_idc等於0表示B條帶應該采用默認的加權預測。weighted_bipred_idc等於1表示B條帶應該采用具體指明的加權預測。weighted_bipred_idc 等於2表示B 條帶應該采用隱含的加權預測。
weighted_bipred_idc 的值應該在0到2之間（包括0和2）。
pic_init_qp_minus26表示每個條帶的SliceQPY 初始值減26。當解碼非0值的slice_qp_delta 時，該初始值在條帶層被修正，並且在宏塊層解碼非0 值的mb_qp_delta 時進一步被修正。pic_init_qp_minus26 的值應該在－(26 + QpBdOffsetY ) 到 +25之間（包括邊界值）。
pic_init_qs_minus26表示在SP 或SI 條帶中的所有宏塊的SliceQSY 初始值減26。當解碼非0 值的slice_qs_delta 時，該初始值在條帶層被修正。pic_init_qs_minus26 的值應該在-26 到 +25之間（包括邊界值）。
chroma_qp_index_offset表示為在QPC 值的表格中尋找Cb色度分量而應加到參數QPY 和 QSY 上的偏移。chroma_qp_index_offset的值應在-12 到 +12范圍內（包括邊界值）。
deblocking_filter_control_present_flag等於1 表示控制去塊效應濾波器的特征的一組語法元素將出現在條帶頭中。deblocking_filter_control_present_flag 等於0 表示控制去塊效應濾波器的特征的一組語法元素不會出現在條帶頭中，並且它們的推定值將會生效。
constrained_intra_pred_flag等於0 表示幀內預測允許使用殘余數據，且使用幀內宏塊預測模式編碼的宏塊的預測可以使用幀間宏塊預測模式編碼的相鄰宏塊的解碼樣值。constrained_intra_pred_flag 等於1 表示受限制的幀內預測，在這種情況下，使用幀內宏塊預測模式編碼的宏塊的預測僅使用殘余數據和來自I或SI宏塊類型的解碼樣值。
redundant_pic_cnt_present_flag等於0 表示redundant_pic_cnt 語法元素不會在條帶頭、圖像參數集中指明（直接或與相應的數據分割塊A關聯）的數據分割塊B和數據分割塊C中出現。redundant_pic_cnt_present_flag等於1表示redundant_pic_cnt 語法元素將出現在條帶頭、圖像參數集中指明（直接或與相應的數據分割塊A關聯）的數據分割塊B和數據分割塊C中。
分包
h264包在傳輸的時候，如果包太大，會被分成多個片。NALU頭會被如下的2個自己代替。
The FU indicator octet has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
別被名字嚇到這個格式就是上面提到的RTP h264負載類型，Type為FU-A
The FU header has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
S bit為1表示分片的NAL開始，當它為1時，E不能為1
E bit為1表示結束，當它為1，S不能為1
R bit保留位
Type就是NALU頭中的Type,取1-23的那個值
http://blog.csdn.net/gl1987807/article/details/11945357
H.264先進視訊編譯碼標准
郭其昌/工研院電通所
1. 前言
在2001年12月，ITU-T VCEG與ISO MPEG共同組成聯合視訊小組(Joint Video Term，JVT)來研訂新的視頻壓縮格式，此新格式在ITU-T組織中稱為H.264，在ISO組織中則納入MPEG-4 Part-10 (ISO/IEC 14496-10)並命名為Advanced VideoCoding (AVC)，通常合並稱為H.264/AVC [1]，其國際標准的第一版於2003年公布，而增修的第二版也於2005年3月定案。相關研究顯示H.264/AVC與MPEG-2及MPEG-4相較之下，無論是壓縮率或視訊質量皆有大幅的提升[2]，而且H.264/AVC也首次將視訊編碼層(Video Coding Layer，VCL)與網絡提取層(Network Abstraction Layer，NAL)的概念涵蓋進來，以往視訊標准着重的是壓縮效能部分，而H.264/AVC包含一個內建的NAL網絡協議適應層，藉由NAL來提供網絡的狀態，可以讓VCL有更好的編譯碼彈性與糾錯能力，使得H.264/AVC非常適用於多媒體串流(multimedia streaming)及行動電視(mobile TV)的相關應用。在第一版的標准規范中，H.264/AVC根據使用的編碼工具種類來提供三種編碼規模(Profile)，如表1所示分別為Baseline Profile、Main Profile、Extension Profile，而相對應的影片尺寸與比特率等級由Level 1至Level 5.1，涵蓋小畫面與高分辨率畫面的應用范圍。Baseline Profile主要是着眼於低比特率的應用(例如：影像通訊)，而且其運算復雜度低，所以也適合應用於個人隨身的多媒體撥放機；Main Profile因為有支持交錯式影片(interlaced content)的編碼，所以適合應用於HDTV數字電視廣播，而且非常容易整合在傳統的MPEG-2 Transport/Program Stream上來傳送H.264/AVC比特流；對於IP-TV或是MOD(Multimedia On Demand)等應用，使用包含高抗錯性編碼工具(error resilient tools)的Extension Profile即可以滿足這些需求。然而，微軟公司在2003年將其視頻壓縮技術向美國的電影電視工程師協會(Society of Motion Picture and Television Engineers，SMPTE)提出公開標准化的申請，並以VC-1(Video Codec 1)為此新標准的命名[3]，由於VC-1在高分辨率影片上的表現出色，導致H.264/AVC在DVD Forum與Blu-ray Disc Association的高分辨率DVD影片測試中敗陣下來，其主要原因是H.264/AVC使用較小尺寸的轉換公式與無法調整的量化矩陣，造成不能完整保留影像的高頻細節信息，因此H.264/AVC於2004年展開標准增修的討論，來納入稱之為Fidelity Range Extensions (FRExt) [4]的新編碼工具，並以先前MainProfile為基礎來擴充增加4個新的等級(Table 1)，期望能夠在高分辨率影片的應用上扳回劣勢，目前增修的H.264/AVC第二版標准已於2005年3月發表。本文后段將探討網絡提取層的相關特性，接着來說明視訊編碼層的原理，最后並討論H.264/AVC的應用現況。
2. 網絡提取層 (Network Abstraction Layer，NAL)
H.264/AVC標准的特色是將網絡提取層的概念涵蓋進來，亦即以NAL封包為單位的方式來做為VCL編譯碼的運算單位，這樣傳輸層拿到NAL封包之后不需要再進行切割，只需附加該傳輸協議的文件頭信息(adding header only)就可以交由底層傳送出去，如圖1所示，可以將NAL當成是一個專作封裝(packaging)的模塊，用來將VCL壓縮過的bitstream封裝成適當大小的封包單位(NAL-unit)，並在NAL-unit Header中的NAL-unit Type字段記載此封包的型式，每種型式分別對應到VCL中不同的編解碼工具。NAL另外一個重要的功能為當網絡發生壅塞而導致封包錯誤或接收次序錯亂(out-of-order)的狀況時，傳輸層協議會在Reference Flag作設定的動作，接收端的VCL在收到這種NAL封包時，就知道要進行所謂的糾錯運算(error concealment)，在解壓縮的同時也會嘗試將錯誤修正回來。如圖2所示，一個完整的H.264/AVC bitstream是由多個NAL-units所組成的，所以此bitstream也稱之為NAL unit stream，一個NAL unit stream內可以包含多個壓縮視訊序列(coded video sequence)，一個單獨的壓縮視訊序列代表一部視訊影片，而壓縮視訊序列又是由多個access units所組成，當接收端收到一個access unit后，可以完整地譯碼成單張的畫面，而每個壓縮視訊序列的第一個access unit必須為Instantaneous Decoding Refresh (IDR) access unit，IDRaccess unit的內容全是采用intra-prediction編碼，所以自己本身即可完全譯碼，不用參考其他access unit的數據。access unit亦是由多個NAL-units所組成，標准中總共規范12種的NAL-unit型式，這些可以進一步分類成VCL NAL-unit及non-VCL NAL-unit，所謂的VCL NAL-unit純粹是壓縮影像的內容，而所謂的non-VCL NAL-unit則有兩種：Parameter Sets與Supplemental Enhancement Information (SEI)，SEI可以存放影片簡介、版權宣告、用戶自行定義的數據…等；Parameter Sets主要是描述整個壓縮視訊序列的參數，例如：長寬比例、影像顯現的時間點(timestamp)、相關譯碼所需的參數…等，這些信息非常重要，萬一在傳送的過程中發生錯誤，會導致整段影片無法譯碼，以往像MPEG-2/-4都把這些信息放在一般的packet header，所以很容易隨着packet loss而消失，現在H.264/AVC將這些信息獨立出來成為特殊的parameter set，可以采用所謂的out-of-band的方式來傳送，以便將out-of-band channel用最高層級的信道編碼(channel coding)保護機制，來保證傳輸的正確性。
3. 視訊編碼層 (Video Coding Layer，VCL)
視頻壓縮的原理是利用影像在時間與空間上存有相似性，這些相似的數據經過壓縮算法處理之后，可以將人眼無法感知的部分抽離出來，這些稱為視覺冗余(visual redundancy)的部分在去除之后，就可以達到視頻壓縮的目的。如圖1所示，H.264/AVC的視訊編碼機制是以圖塊(block-based)為基礎單元，也就是說先將整張影像分割成許多矩形的小區域，稱之為巨圖塊(macroblock，MB)，再將這些巨圖塊進行編碼，先使用畫面內預測(intra-prediction)與畫面間預測(inter-prediction)技術，以去除影像之間的相似性來得到所謂的差余影像(residual)，再將差余影像施以空間轉換(transform)與量化(quantize)來去除視覺冗余，最后視訊編碼層會輸出編碼過的比特流(bitstream)，之后再包裝成網絡提取層的單元封包(NAL-unit)，經由網絡傳送到遠程或儲存在儲存媒體中。H.264/AVC允許視訊影片以frame或是以filed的方式來進行編碼，兩者可以共存，而frame可以是progress或是interlace形式，對同一段影片來說也可使用兩者來混合編碼，這個特性與MPEG-2相同。而在影像色彩格式的支持上，H.264/AVC第一版的標准只支持YCrCb 4:2:0取樣的方式，而在增修的第二版標准中增加4:2:2與4:4:4取樣格式，通常這些格式會被數字電影或HDTV影片所采用。
3.1 H.264/AVC影像格式階層架構
H.264/AVC的階層架構由小到大依序是sub-block、block、macroblock、slice、slicegroup、frame/field-picture、sequence。對一個采用4:2:0取樣的MB而言，它是由16x16點的Luma與相對應的2個8x8點Chroma來組成，而在H.264/AVC的規范中，MB可再分割成多個16x8、8x16、8x8、8x4、4x8、4x4格式的sub-blocks。所謂的slice是許多MB的集合，而一張影像是由許多slice所組成(圖3)，slice為H.264/AVC格式中的最小可譯碼單位(self-decodable unit)，也就是說一個slice單靠本身的壓縮數據就能譯碼，而不必依靠其他slice，這樣的好處是當傳送到遠程時，每接收完一筆slice的壓縮數據就能馬上譯碼，不用等待整張的數據接收完后才能開始，而且萬一傳送的過程中發生數據遺失或錯誤，也只是影響該筆slice，不會對其他slice有所影響，但跟MPEG-2的slice不同處在於它允許slice的范圍可以超過一行MB，也就是說H.264/AVC允許整張影像只由單一個slice組成。H.264/AVC的slice架構還有一項特性稱為Flexible Macroblock Ordering (FMO)，也就是說組成slice的MB可以不必局限於循序掃描(rasterscan)的排列方式，例如：圖3最右側的排法就非常適用於多個前景(foreground) slice groups與一個獨自的背景(background) slice group，好處是對不同的slice group可以用不同質量的壓縮參數，例如：對於前景物件通常是人眼較感興趣的區域，可以用較小的壓縮率來維持較好的質量。
3.2 Slice的編碼模式
H.264/AVC的slice依照編碼的類型可以分成下列種類：(1)I-slice: slice的全部MB都采用intra-prediction的方式來編碼；(2) P-slice: slice中的MB使用intra-prediction和inter-prediction的方式來編碼，但每一個inter-prediction block最多只能使用一個移動向量；(3) B-slice:與P-slice類似，但每一個inter-prediction block可以使用二個移動向量。比較特別的是B-slice的‘B’是指Bi-predictive，與MPEG-2/-4 B-frame的Bi-directional概念有很大的不同，MPEG-2/-4 B-frame被限定只能由前一張和后一張的I(或P)-frame來做inter- prediction，但是H.264/AVC B-slice除了可由前一張和后一張影像的I(或P、B)-slice外，也能從前二張不同影像的I(或P、B)-slice來做inter- prediction，而H.264/AVC另外增加兩種特殊slice類型：(1) SP-slice:即所謂的Switching P slice，為P-slice的一種特殊類型，用來串接兩個不同bitrate的bitstream；(2) SI-slice: 即所謂的Switching I slice，為I-slice的一種特殊類型，除了用來串接兩個不同content的bitstream外，也可用來執行隨機存取(random access)來達到網絡VCR的功能。這兩種特殊的slice主要是考慮當進行Video-On-Demand streaming的應用時，對同一個視訊內容的影片來說，server會預先存放不同bitrate的壓縮影片，而當帶寬改變時，server就會送出適合當時帶寬比特率的影片，傳統的做法是需要等到適當的時間點來傳送新的I-slice (容量較P-slice大上許多)，但因為帶寬變小導致需要較多的時間來傳送I-slice，如此會讓client端的影像有所延遲，為了讓相同content但不同bitrate的bitstream可以較平順地串接，使用SP-slice會很容易來達成(圖4)，不僅可以直接送出新的bitstream，也因為傳送的P-slice的容量較小，所以不會有時間延遲的情形出現。當client端的使用者要切換到新的接收頻道(channel)時，因為與目前傳送的bitstream不但內容不同連比特率也不同，傳統的做法需讓client重新緩沖(buffering)一段新頻道的內容(圖5)，此時是為了要接收新頻道bitstream的I-slice，然后再開始傳送新頻道bitstream后續的P-slice，如此client也會發生延遲接收的現象，而且當client要進行所謂的快轉、倒轉、隨機存取(random access)的動作時，傳統的做法無法達到實時的反應，H.264/AVC利用SI-slice就可以輕易地達到目的。
3.3畫面內預測技術(Intra-frame Prediction)
以往的壓縮標准在進行intra-prediction時，多半只是將轉換系數做差值編碼，而H.264/AVC在空間領域(spatial domain)來進行像點之間的預測，而不是用轉換過的系數，它提供兩種intra-prediction的型式：intra_4x4及intra_16x16，所謂的intra_4x4是以Luma 4x4 sub-block為單位，找出它的參考對象(predictor)后，再將其與參考對象相減后所產生的差余影像(residual)送入轉換算法，而尋找參考對象的模式共有9種預測的方向(圖6)，以mode 0 (vertical)為例，{a,e,i,m}、{b,f,j,n}、{c,g,k,o}、{d,h,l,p}的參考對象分別為A、B、C、D；Luma intra_16x16與Chroma的模式跟Luma intra_4x4類似，詳細的運算公式可以參考[1]。
3.4畫面間預測技術(Inter-frame Prediction)
至於橫跨每張畫面之間的預測技術，H.264/AVC提供了更豐富的編碼模式，計有下述幾種區塊分割(partition)的方法：16x16、16x8、8x16、8x8、8x4、4x8、4x4，多樣的分割方式可以讓移動向量的預測更准確，如圖7所示，畫面中有些移動的區域並不是正方形，使用長方形或較小的4x4分割來做預測的區域，可以大幅降低差余影像的數值來增加了壓縮比，但也因此P-slice中的MB最多可有16個移動向量(motion vector)，而B-slice中的MB最多可擁有32個移動向量，雖然這些會增加移動向量檔頭(header)的容量，但整體來說對壓縮比仍有正面的益處。再者，以往的壓縮標准所使用的動態估測(motion estimation)，只有使用前一張圖像來作為預測的對象，H.264/AVC提供了多重參考圖像(multiple reference frames)的概念，使得移動向量不再只限於前后相鄰的影像，而是可以跨過多張影像，如圖8所示，在時間點t的圖塊，可以使用t-1到t-2圖像中的圖塊來作為預測的對象，當影片有周期重復性的內容時，例如：背景影像周期性的出現或被遮蓋、對象有來回跳動的行為、形狀忽大忽小，或是攝影機在拍攝時，因為有多處的取景點，並且攝影畫面在取景點之間來回移動，這種情形在球類比賽轉播時常出現，這些狀況都能得到較好的動態預測結果，因而提高了壓縮的效能。
3.5 轉換、量化與熵編碼算法 (Transform, Quantization, and EntropyCoding)
H.264/AVC的轉換算法采用所謂的4x4與8x8整數轉換，跟MPEG-2/-4的8x8 DCT(Discrete Cosine Transform)有很大的不同，因為是整數運算的緣故，不像小數運算的DCT有系數還原后無法匹配的問題，而且以4x4的區塊大小來進行轉換也可減低區塊效應的程度。在量化技術方面，H.264/AVC只使用加法與乘法而沒有除法運算，有利於集成電路的實現。跟以往MPEG-2/-4的熵編碼技術(entropy coding)不同的是，H.264/AVC針對量化過的轉換系數與非轉換系數數據(文件頭數據、移動向量…等)，分別使用二個不同的編碼法則。非轉換系數數據使用單一個的編碼表，好處是可以節省編碼表所占用的內存空間；針對量化過的轉換系數數據來說，不像MPEG-2/-4對每種影像都使用固定的編碼表，H.264/AVC使用所謂的內容適應性編碼技術(context-adaptive)，也就是會根據編碼的內容來統計某些代碼(code-word)的出現機率，而產生一個最適合於目前影像的編碼表，好處是能夠提高壓縮比，但要使用額外的帶寬來傳送這些編碼表。H.264/AVC內容適應性編碼技術有兩種：Context Adaptive Variable Length Coding (CAVLC)以及ContextAdaptive Arithmetic Binary Coding (CABAC)，CAVLC的基本原理跟MPEG-2/-4的VLC相同，而CABAC的復雜度比CAVLC高，但卻可以提供較高的壓縮比，尤其是用在壓縮交錯式的數字電視影片。
3.6 內嵌式去區塊效應濾波器(In-Loop De-blocking Filter)
先前有提到H.264/AVC也是一種block-based的壓縮方法，所以會有區塊效應(blocking-effect)的現象，雖然它采用4x4轉換可以稍減區塊效應的程度，但是在影像較平滑的區域，仍需依靠去區塊效應濾波器來做影像質量的修補。通常去區塊效應濾波器分成兩種：post filter及in-loop filter，所謂post filter就是在譯碼的流程之后再進行的，而不在解壓縮標准的規范中，好處是廠商可以依應用的復雜度，有彈性地決定濾波器的實現方式，而所謂的in-loop filter就是直接規范在編譯碼的流程中，雖然會增加復雜度，但由於經過濾波器處理后的影像質量較好，若以此作為畫面間預測的參考圖像，其預測精確度會大幅的提升，因而增加了壓縮比。
4. 結論
由於H.264/AVC在視訊編碼算法上的改進，其壓縮比及視訊質量與MPEG-2/-4相較下有大幅度的提升，而其NAL概念有助於在有限帶寬的傳輸通道上來傳送高質量的視訊內容，此外，對於高畫質數字電視或高畫質DVD，以H.264/AVC的編碼技術都可以很輕易地滿足應用需求，但就市場面來看，VC-1標准憑借着微軟在PC平台的優勢與低價授權的策略，今后將成為H.264/AVC最強大的挑戰者。