H.264/H265碼流解析
一．H.264碼流解析
一個原始的H.264 NALU 單元常由 [StartCode] [NALU Header] [NALU Payload] 三部分組成
一個原始的H.264 NALU 單元常由 [StartCode] [NALU Header] [NALU Payload] 三部分組成
NALU組成.jpeg
- StartCode : Start Code 用於標示這是一個NALU 單元的開始，必須是”00 00 00 01” 或”00 00 01”
- NALU Header
下表為 NAL Header Type
NAL Header Type.png
例如,下面幅圖分別代表IDR與非IDR幀具體的碼流信息:
2.IDR
在一個NALU中，第一個字節（即NALU header）用以表示其包含數據的類型及其他信息。我們假定一個頭信息字節為0x67作為例子：
| 十六進制 |
二進制 |
| 0x67 |
0 11 00111 |
如表所示，頭字節可以被解析成3個部分，其中：
1>. forbidden_zero_bit = 0：占1個bit，禁止位，用以檢查傳輸過程中是否發生錯誤，0表示正常，1表示違反語法；
2>. nal_ref_idc = 3：占2個bit，用來表示當前NAL單元的優先級。非0值表示參考字段/幀/圖片數據，其他不那么重要的數據則為0。對於非0值，值越大表示NALU重要性越高
3>. nal_unit_type = 7：最后5位用以指定NALU類型，NALU類型定義如上表
從表中我們可以獲知,NALU類型1-5為視頻幀，其余則為非視頻幀。在解碼過程中，我們只需要取出NALU頭字節的后5位，即將NALU頭字節和0x1F進行與計算即可得知NALU類型，即：
NALU類型 = NALU頭字節 & 0x1F
注意: 可以將start code理解為不同nalu的分隔符,header是某種類型的key,payload是該key的value.
碼流格式
H.264標准中指定了視頻如何編碼成獨立的包，但如何存儲和傳輸這些包卻未作規范，雖然標准中包含了一個Annex附件，里面描述了一種可能的格式Annex B，但這並不是一個必須要求的格式。
為了針對不同的存儲傳輸需求，出現了兩種打包方法。一種即Annex B格式，另一種稱為AVCC格式。
- Annex B
從上文可知，一個NALU中的數據並未包含他的大小（長度）信息，因此我們並不能簡單的將一個個NALU連接起來生成一個流，因為數據流的接收端並不知道一個NALU從哪里結束，另一個NALU從哪里開始。
Annex B格式用起始碼（Start Code）來解決這個問題，它在每個NALU的開始處添加三字節或四字節的起始碼0x000001或0x00000001。通過定位起始碼，解碼器就可以很容易的識別NALU的邊界。
當然，用起始碼定位NALU邊界存在一個問題，即NALU中可能存在與起始碼相同的數據。為了防止這個問題，在構建NALU時，需要將數據中的0x000000,0x000001,0x000002,0x000003中插入防競爭字節（Emulation Prevention Bytes)0x03，使其變為：
0x000000 = 0x0000 03 00
0x000001 = 0x0000 03 01
0x000002 = 0x0000 03 02
0x000003 = 0x0000 03 03
解碼器在檢測到0x000003時，將0x03拋棄，恢復原始數據。
由於Annex B格式每個NALU都包含起始碼，所以解碼器可以從視頻流隨機點開始進行解碼，常用於實時的流格式。在這種格式中通常會周期性的重復SPS和PPS，並且經常時在每一個關鍵幀之前。
- AVCC
AVCC格式不使用起始碼作為NALU的分界，這種格式在每個NALU前都加上一個指定NALU長度的大端格式表示的前綴。這個前綴可以是1、2或4個字節，所以在解析AVCC格式的時候需要將指定的前綴字節數的值保存在一個頭部對象中，這個都通常稱為extradata或者sequence header。同時，SPS和PPS數據也需要保存在extradata中。
H.264 extradata語法如下：
| bits |
line by byte |
remark |
|
| 8 |
version |
always |
0x01 |
| 8 |
avc profile |
sps[0][1] |
|
| 8 |
avc compatibility |
sps[0][2] |
|
| 8 |
avc level |
sps[0][3] |
|
| 6 |
reserved |
all bits on |
|
| 2 |
NALULengthSizeMinusOne |
||
| 3 |
reserved |
all bits on |
|
| 5 |
number of SPS NALUs usually |
1 |
|
| 16 |
SPS size |
||
| N |
variable SPS NALU data |
||
| 8 |
number of PPS NALUs usually |
1 |
|
| 16 |
PPS size |
||
| N |
variable PPS NALU data |
其中第5字節的后2位表示的就是NAL size的字節數。需要注意的是，這個NALULengthSizeMinusOne是NALU前綴長度減一，即，假設前綴長度為4，那么這個值應該為3。
這里還需要注意的一點是，雖然AVCC格式不使用起始碼，但防競爭字節還是有的。
AVCC格式的一個優點在於解碼器配置參數在一開始就配置好了，系統可以很容易的識別NALU的邊界，不需要額外的起始碼，減少了資源的浪費，同時可以在播放時調到視頻的中間位置。這種格式通常被用於可以被隨機訪問的多媒體數據，如存儲在硬盤的文件。
二. H.265碼流解析
HEVC全稱High Efficiency Video Coding(高效率視頻編碼，又稱H.265)，是比H.264更優秀的一種視頻壓縮標准。HEVC在低碼率視頻壓縮上，提升視頻質量、減少容量即節省帶寬方面都有突出表現。
H.265標准圍繞H.264編碼標准,保留原有的某些技術，同時對一些技術進行改進，編碼結構大致上和H.264的架構類似。這里着重講一下兩者編碼格式的區別。
同H.264一樣，H.265也是以NALU的形式組織起來。而在NALU header上，H.264的HALU header是一個字節，而H.265則是兩個字節。我們同樣假定一個頭信息為0x4001作為例子：
| 十六進制 |
二進制 |
| 0x4001 |
0 100000 000000 001 |
如表所示，頭信息可以被解析成4個部分，其中：
- forbidden_zero_bit = 0：占1個bit，與H.264相同，禁止位，用以檢查傳輸過程中是否發生錯誤，0表示正常，1表示違反語法；
- nal_unit_type = 32：占6個bit，用來用以指定NALU類型
- nuh_reserved_zero_6bits = 0：占6位，預留位，要求為0，用於未來擴展或3D視頻編碼
- nuh_temporal_id_plus1 = 1：占3個bit，表示NAL所在的時間層ID
對比H.264的頭信息，H.265移除了nal_ref_idc，此信息被合並到了nal_unit_type中，H.265NALU類型規定如下:
| nal_unit_type |
NALU類型 |
備注 |
| 0 |
NAL_UNIT_CODE_SLICE_TRAIL_N |
非關鍵幀 |
| 1 |
NAL_UNIT_CODED_SLICE_TRAIL_R |
|
| 2 |
NAL_UNIT_CODED_SLICE_TSA_N |
|
| 3 |
NAL_UINT_CODED_SLICE_TSA_R |
|
| 4 |
NAL_UINT_CODED_SLICE_STSA_N |
|
| 5 |
NAL_UINT_CODED_SLICE_STSA_R |
|
| 6 |
NAL_UNIT_CODED_SLICE_RADL_N |
|
| 7 |
NAL_UNIT_CODED_SLICE_RADL_R |
|
| 8 |
NAL_UNIT_CODED_SLICE_RASL_N |
|
| 9 |
NAL_UNIT_CODE_SLICE_RASL_R |
|
| 10 ~ 15 |
NAL_UNIT_RESERVED_X |
保留 |
| 16 |
NAL_UNIT_CODED_SLICE_BLA_W_LP |
關鍵幀 |
| 17 |
NAL_UNIT_CODE_SLICE_BLA_W_RADL |
|
| 18 |
NAL_UNIT_CODE_SLICE_BLA_N_LP |
|
| 19 |
NAL_UNIT_CODE_SLICE_IDR_W_RADL |
|
| 20 |
NAL_UNIT_CODE_SLICE_IDR_N_LP |
|
| 21 |
NAL_UNIT_CODE_SLICE_CRA |
|
| 22 ~ 31 |
NAL_UNIT_RESERVED_X |
保留 |
| 32 |
NAL_UNIT_VPS |
VPS(Video Paramater Set) |
| 33 |
NAL_UNIT_SPS |
SPS |
| 34 |
NAL_UNIT_PPS |
PPS |
| 35 |
NAL_UNIT_ACCESS_UNIT_DELIMITER |
|
| 36 |
NAL_UNIT_EOS |
|
| 37 |
NAL_UNIT_EOB |
|
| 38 |
NAL_UNIT_FILLER_DATA |
|
| 39 |
NAL_UNIT_SEI |
Prefix SEI |
| 40 |
NAL_UNIT_SEI_SUFFIX |
Suffix SEI |
| 41 ~ 47 |
NAL_UNIT_RESERVED_X |
保留 |
| 48 ~ 63 |
NAL_UNIT_UNSPECIFIED_X |
未規定 |
| 64 |
NAL_UNIT_INVALID |
具體type含義可以參考這篇文檔type類型
H.265的NALU類型是在信息頭的第一個字節的第2到7位，所以判斷H.265NALU類型的方法是將NALU第一個字節與0x7E進行與操作並右移一位，即：
NALU類型 = (NALU頭第一字節 & 0x7E) >> 1
與H.264類似，H.265碼流也有兩種封裝格式，一種是用起始碼作為分界的Annex B格式，另一種則是在NALU頭添加NALU長度前綴的格式，稱為HVCC。在HVCC中，同樣需要一個extradata來保存視頻流的編解碼參數，其格式定義如下：
| bits |
line by byte |
remark |
| 8 |
configurationVersion |
always 0x01 |
| 2 |
general_profile_space |
|
| 1 |
general_tier_flag |
|
| 5 |
general_profile_idc |
|
| 32 |
general_profile_compatibility_flags |
|
| 48 |
general_constraint_indicator_flags |
|
| 8 |
general_level_idc |
|
| 4 |
reserved |
‘1111’b |
| 12 |
min_spatial_segmentation_idc |
|
| 6 |
reserved |
‘111111’b |
| 2 |
parallelismType |
|
| 6 |
reserved |
‘111111’b |
| 2 |
chromaFormat |
|
| 5 |
reserved |
‘11111’b |
| 3 |
bitDepthLumaMinus8 |
|
| 5 |
reserved |
‘11111’b |
| 3 |
bitDepthChromaMinus8 |
|
| 16 |
avgFrameRate |
|
| 2 |
constantFrameRate |
|
| 3 |
numTemporalLayers |
|
| 1 |
tmporalIdNested |
|
| 2 |
lengthSizeMinusOne |
|
| 8 |
numOfArrays |
Repeated of Array(VPS/SPS/PPS)
1| array_completeness
1| reserved| ‘0’b
6| NAL_unit_type
16| numNalus
16| nalUnitLength
N| NALU data
從上表可以看到，在H.265的extradata后半段是一段格式重復的數組數據，里面需要包含的除了與H.264相同的SPS、PPS外，還需多添加一個VPS。
VPS（Video Parament Set,視頻參數集),在H.265中類型為32。VPS用於解釋編碼過的視頻的整體結構，包括時域子層依賴關系等，主要目的在於兼容H.265標准在系統的多子層方面的擴展。