[TOC] ## 概述 H.264標準協議定義了兩種不同的類型： - 一種是VCL即Video Coding Layer,編碼器吐出來的原始編碼數據，沒有考慮傳輸和存儲問題 - 一種是NAL即Network Abstraction Layer,為了展現H.264的網絡親和性，對VCL輸出的slice片數據進行了封裝為NALUs(NAL Units)，然后再封裝為RTP包進行傳輸 ### NALU NALU Header + NALU Data,其中NALU的頭由一個字節組成如下所示 ``` +-----------------+ |0|1|2 |3|4|5|6|7| +-+-+---+-+-+-+ |F| NRI |Type| +-----------------+ ``` - F(1 bit) 如果是壞幀，則置1，其余H.264固定為0。 - NRI(2 bit) 用來指示該NALU 的重要性等級。值越大，表示當前NALU越重要。具體大于0 時取何值，沒有具體規定。例如：如果是00，則表示此幀即使丟失了，也不影響解碼；其他值則表示此幀如果丟失了，會影響解碼，這個字段指明了該NALU的重要性，但是實際我們不太關心這個字段。 - Nalu_Type(5 bit) NAL Unit的類型，這個值指明了NALU的類型， **其中NALU的類型見下表** |Nalu_Type|NALU內容|備注| |---|---|---| |0|未指定| | |1|非IDR圖像編碼的slice|比如普通I、P、B幀| |2|編碼slice數據劃分A|2類型時，只傳遞片中最重要的信息，如片頭，片中宏塊的預測模式等；一般不會用到；| |3|編碼slice數據劃分B|3類型是只傳輸殘差；一般不會用到；| |4|編碼slice數據劃分C|4時則只可以傳輸殘差中的AC系數；一般不會用到；| |5 |IDR圖像中的編碼slice |IDR幀，IDR一定是I幀但是I幀不一定是IDR幀。| |6 |SEI補充增強信息單元 |可以存一些私有數據等；| |7 |SPS 序列參數集 |編碼的參數配置| |8 |PPS 圖像參數集 |編碼的參數配置| |9 |接入單元定界符 || |10 |序列結束|| |11 |碼流結束|| |12 |填充數據|| |24 |STAP-ASingle-time aggregation packet |單一時間聚合包模式，意味著一個RTP包可以傳輸多個NALU，但是這些NALU的編碼時間要一樣才能聚合到一個RTP。| |25 |STAP-BSingle-time aggregation packet| |26 |MTAP 16Muti-time aggregation packet |多個時間聚合包模式：意味著一個RTP包可以傳輸多個NALU，但是這些NALU的編碼時間有可能不一樣。| |27 |MTAP 24Muti-time aggregation packet| |28 |FU-AFragmentation unit |切包模式：當一個RTP容納不下一個NALU時，就需要FUs這種格式。| |29 |FU-BFragmention unit| |30-31 |未指定，保留| 我們看到1-11就是NALU的單個包類型，但是一個NALU的大小是不一樣的，如果是非視頻數據的SPS PPS才十幾個字節，對于IDR幀，則有可能幾十KB。這樣把NALU打包到RTP方式就很多：分為一個RTP包承載一個NALU，多個NALU合并到一個RTP，一個大的NALU切分成多個RTP。同時由于時間戳的問題，就有了24-29幾種類型 <BR/> 但是對于發送端組RTP包的一方來說，盡可能找簡單的打包方式: 1. 我們對于NALU的長度<1400的則采用的是單一NALU打包到單一的RTP包中； 2. 我們對于NALU的長度>=1400的則采用了FU-A的方式進行了打包，這種就是把一個大的NALU進行了切分，最后接收方則進行了合并，把多個RTP包合并成一個完整的NALU即可； 3. 至于為什么NALU的長度大于1400字節就要進行FU-A切片，是因為底層MTU大小值固定為1500，從傳輸效率講，這里用1400作為切分條件 抓包分析