一、NAL全稱Network Abstract Layer, 即網絡抽象層。
在H.264/AVC視頻編碼標準中,整個系統框架被分爲了兩個層面:視頻編碼層面(VCL)和網絡抽象層面(NAL)。其中,前者負責有效表示視頻數據的內容,然後者則負責格式化數據並提供頭信息,以保證數據適合各類信道和存儲介質上的傳輸。所以咱們平時的每幀數據就是一個NAL單元(SPS與PPS除外)。在實際的H264數據幀中,每每幀前面帶有00 00 00 01 或 00 00 01分隔符,通常來講編碼器編出的首幀數據爲PPS與SPS,接着爲I幀……算法
以下圖:網絡
二、如何判斷幀類型(是圖像參考幀仍是I、P幀等)?架構
NALU類型是咱們判斷幀類型的利器,從官方文檔中得出以下圖:框架
咱們仍是接着看最上面圖的碼流對應的數據來層層分析,以00 00 00 01分割以後的下一個字節就是NALU類型,將其轉爲二進制數據後,解讀順序爲從左往右算,以下:
(1)第1位禁止位,值爲1表示語法出錯
(2)第2~3位爲參考級別
(3)第4~8爲是nal單元類型dom
例如上面00000001後有67,68以及65ide
其中0x67的二進制碼爲:
0110 0111
4-8爲00111,轉爲十進制7,參考第二幅圖:7對應序列參數集SPS工具
其中0x68的二進制碼爲:
0110 1000
4-8爲01000,轉爲十進制8,參考第二幅圖:8對應圖像參數集PPSoop
其中0x65的二進制碼爲:
0110 0101
4-8爲00101,轉爲十進制5,參考第二幅圖:5對應IDR圖像中的片(I幀)post
因此判斷是否爲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
profile_idc和level_idc是指比特流所遵照的配置和級別。
constraint_set0_flag 等於1是指比特流聽從某節中的全部規定。constraint_set0_flag 等於0是指該比特流能夠聽從也能夠不聽從某節中的全部規定。當profile_idc等於100、1十、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先進視訊編譯碼標準
郭其昌/工研院電通所
在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的應用現況。
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)保護機制,來保證傳輸的正確性。
視頻壓縮的原理是利用影像在時間與空間上存有類似性,這些類似的數據通過壓縮算法處理以後,能夠將人眼沒法感知的部分抽離出來,這些稱爲視覺冗餘(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可再分割成多個16x八、8x1六、8x八、8x四、4x八、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)的方法:16x1六、16x八、8x1六、8x八、8x四、4x八、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最強大的挑戰者。