From:http://www.cnblogs.com/ghw-NO1/archive/2012/08/28/2660848.html

一、概述

本文講述的是對H264編碼且封裝成MP4格式的視頻流進行RTP打包過程時需要了解的一些基本知識。

二、H264的基礎知識

1.H264的編碼格式

H.263 定義的碼流結構是分級結構，共四層。自上而下分別為：圖像層(picturelayer)、塊組層(GOB layer)、宏塊層(macroblock layer)和塊層(block layer)。而與H.263 相比，H.264的碼流結構和H.263 的有很大的區別，它采用的不再是嚴格的分級結構。H.264 支持4:2:0 的連續或隔行視頻的編碼和解碼。H.264 壓縮與H.263、MPEG-4 相比，視頻壓縮比提高了一倍。

H.264 的功能分為兩層：視頻編碼層（VCL, Video Coding Layer）和網絡提取層（NAL,Network Abstraction Layer）。VCL 數據即編碼處理的輸出，它表示被壓縮編碼后的視頻數據序列。在VCL 數據傳輸或存儲之前，這些編碼的VCL 數據，先被映射或封裝進NAL 單元中。每個NAL 單元包括一個原始字節序列負荷（RBSP, Raw Byte Sequence Payload）、一組對應于視頻編碼的NAL 頭信息。RBSP 的基本結構是：在原始編碼數據的后面填加了結尾比特。一個bit“1”若干比特“0”，以便字節對齊。

2.H264的傳輸

H.264 的編碼視頻序列包括一系列的NAL 單元，每個NAL 單元包含一個RBSP，見表1。編碼片（包括數據分割片IDR 片）和序列RBSP 結束符被定義為VCL NAL 單元，其余
為NAL 單元。典型的RBSP 單元序列如圖2 所示。每個單元都按獨立的NAL 單元傳送。單元的信息頭（一個字節）定義了RBSP 單元的類型，NAL 單元的其余部分為RBSP 數據。

3.H264的碼流結構

起始碼：如果NALU 對應的Slice 為一幀的開始，則用4 字節表示，即0x00000001；否則用3 字節表示，0x000001。

一個frame是可以分割成多個Slice來編碼的，而一個Slice編碼之后被打包進一個NAL單元，不過NAL單元除了容納Slice編碼的碼流外，還可以容納其他數據，比如序列參數集SPS。

三、MP4封裝的H264數據

MP4文件中所有數據都封裝在box中，它是由若干個子box組成，每個box還可以包含另外的子box，且每個box都有長度和類型。“ftyp”(66 74 79 70)box:作為MP4格式的標志并包含關于文件的一些信息，有且僅有一個；“moov”(6D 6F 6F 76)box:包含了媒體的metadata信息（特別是avcC中的sps和pps），有且僅有一個；“mdat”(6D 64 61 74)box：包含了MP4的媒體數據，可以有多個，也可以沒有。但是媒體數據的結構由metadata進行描述。MP4中box存儲方式為大端模式。一般，標準的box開頭會有四個字節的box size。

在MP4格式文件中，H264 slice并不是以00 00 00 01來作分割，而是存儲在mdat box中。H264基本碼流由一些列的NALU組成。原始的NALU單元組成：[start code] + [NALU header] + [NALU payload].

MP4數據格式：|"ftyp"box|"moov"box（及其子box）|"mdat"box|....|。

"mdat"box的格式：|box的length（4字節）|box類型(4字節)mdat-6D 64 61 74|NALU的length（4字節）|NALU的header（1字節）|payload|；

MP4封裝結構圖：

box結構圖：

?用MP4info分析的實例分析圖：

四、H264視頻流的RTP封包

1.RTP打包原則

RTP的包長度必須要小于MTU(最大傳輸單元)，IP協議中MTU的最大長度為1500字節。除去IP報頭（20字節）、UDP報頭（8字節）、RTP頭（12字節），所有RTP有效載荷（即NALU內容）的長度不得超過1460字節。

2.RTP協議的報文結構?

?

開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。各段含義如下：?
①版本（V）?
version (V): 2 bits?? 2位，標識RTP版本,協議初始版本為0，RFC3550中規定的版本號為2。。?
②填充標識（P）?
padding (P): 1 bit?? 1位，如設置填充位，在包末尾包含了額外的附加信息，它不屬于有效載荷。附加信息的最后一個字節表示額外附加信息的長度（包含該字節本身）。該字段之所以 存在是因為某些加密算法需要固定大小的填充字，或為在底層協議數據單元中攜帶幾個RTP包。?
③擴展（X）?
extension (X): 1 bit?????????? 1位，如果該位被設置，則在固定的頭部后存在一個擴展頭部，格式定義在RFC3550 5.3.1節。?
④CSRC計數（CC）?
CSRC count (CC): 4 bits??? 4位，CSRC計數包括緊接在固定頭后標識CSRC個數。?
⑤標記（M）?
marker (M): 1 bit???? 1位，標記解釋由設置定義，目的在于允許重要事件在包流中標記出來。設置可定義其他標示位，或通過改變位數量來指定沒有標記位，該位的功能依賴于 profile的定義。profile可以改變該位的長度，但是要保持marker和payload type總長度不變（一共是8 bit）。。

或M：標示位，1 位。如果當前 NALU為一個接入單元最后的那個NALU，那么將M位置 1；或者當前RTP 數據包為一個NALU 的最后的那個分片時（NALU 的分片在后面講述），M位置 1。其余情況下M 位保持為 0。
⑥載荷類型（PT）?
payload type (PT): 7 bits?? 7位，記錄后面資料使用哪種 Codec ， receiver 端找出相應的 decoder 解碼出來，該位標記著RTP packet所攜帶信息的類型，標準類型列出在RFC3551中。如果接收方不能識別該類型，必須忽略該packet。?
⑦系列號?
sequence number:16 bits? 16位，系列號隨每個RTP數據包發送后而增加1，接收方可以根據該序列號重新排列數據包順序，或者探測包損失。系列號初值是隨機的，使對加密的文本攻擊更加困難。?
⑧時間戳
timestamp: 32 bits??? 32位，時標反映RTP數據包中第一個八進制數的采樣時刻，采樣時刻必須從單調、線性增加的時鐘導出，以允許同步與抖動計算。時標可以讓receiver端知道在正確的時間將資料播放出來。實際中當采用”分片封包模式“打包RTP時，當一個NALU打包完畢時，時間戳更一次。

?

?? 由上圖可知，如果只有系列號，并不能完整按照順序的將data播放出來，因為如果data中間有一段是沒有資料的，只有系列號的話會造成錯誤，需搭配上讓它知道在哪個時間將data正確播放出來，如此我們才能播放出正確無誤的信息。?
⑨SSRC?
SSRC: 32 bits???????????????????? 32位，SSRC段標識同步源。此標識不是隨機選擇的，目的在于使同一RTP包連接中沒有兩個同步源有相同的SSRC標識，也就是在一個RTP Session其間每個數據流都應該有一個不同的SSRC。盡管多個源選擇同一個標識的概率很低，所有RTP實現都必須探測并解決沖突。如源改變源傳輸地 址，也必須選擇一個新SSRC標識以避免插入成環行源。?
⑩CSRC列表?
CSRC list: 0 to 15 items???? bits0到15項，每項32位。CSRC列表表示包內的對載荷起作用的源。標識數量由CC段給出。如超出15個作用源，也僅標識15個。CSRC標識由 混合器插入，采用作用源的SSRC標識。只有存在Mixer的時候才有效。如一個將多聲道的語音流合并成一個單聲道的語音流，在這里就列出原來每個聲道的 SSRC。

3.NALU header結構圖

NALU header由一個字節組成, 它的語法如下:

F: 1 個比特.forbidden_zero_bit. 在 H.264 規范中規定了這一位必須為 0.

NRI: 2 個比特.nal_ref_idc. 取 00 ~ 11, 似乎指示這個 NALU 的重要性, 如00的NALU解碼器可以丟棄它而不影響圖像的回放. 不過一般情況下不太關心這個屬性.

Type: 5 個比特.nal_unit_type. 這個 NALU 單元的類型.?但是在h264中只有 1~23 是有效的值.而其他的24~29在RTP封包采用”組合封包模式“和”分片封包模式“時所用的type類型，而非“單一NAL單元模式”時。

簡述如下:

? 0???? 沒有定義
? 1-23? NAL單元? 單個 NAL 單元包.
? 24??? STAP-A?? 單一時間的組合包
? 25??? STAP-B?? 單一時間的組合包
? 26??? MTAP16?? 多個時間的組合包
? 27??? MTAP24?? 多個時間的組合包
? 28??? FU-A???? 分片的單元
? 29??? FU-B???? 分片的單元
? 30-31 沒有定義

4.RTP打包模式

主要分為三種模式：單一NALU模式、分片模式、組合模式，實際中前兩種用的比較多。

(1)單一NALU模式

一個RTP包僅由一個完整的NALU組成。這種情況下RTP NAL頭類型字段和原始的H.264的NALU頭類型字段是一樣的。適合條件是當NALU的長度小于RTP包長減去12時。

特別NALU type 值為 7 和 8 的NALU分別為序列參數集（sps）和圖像參數集（pps）。

(2)組合封包模式

即可能是由多個 NAL 單元組成一個 RTP 包. 分別有4種組合方式: STAP-A, STAP-B, MTAP16, MTAP24.那么這里的類型值分別是 24, 25, 26 以及 27.適合條件當 NALU 的長度特別小時, 可以把幾個 NALU 單元封在一個 RTP 包中.

(3)分片封包模式Fragmentation Units (FUs)

用于把一個 NALU 單元封裝成多個 RTP 包. 存在兩種類型 FU-A 和 FU-B. 類型值分別是 28 和 29。適合條件當 NALU 的長度超過 MTU 時, 就必須對 NALU 單元進行分片封包.?

FU indicator 結構

??
F：當網絡識別此單元存在比特錯誤時，可將其設為 1，以便接收方丟掉該單元。?
NRI:必須根據分片NAL單元的NRI域的值設置，用來指示該NALU的重要性等級。值越大，表示當前NALU越重要。
TYPE:28表示FU-A和29表示FU-B

FU Header 結構：

S:當設置成1,開始位指示分片NAL單元的開始。當跟隨的FU荷載不是分片NAL單元荷載的開始，開始位設為0。?? ??? ??? ??? ?
E:當設置成1,結束位指示分片NAL單元的結束。即荷載的最后字節是分片NAL單元的最后一個字節。當跟隨的FU荷載不是分片NAL單元的最后分片,結束位設置為0。
R:保留位必須設置為0，接收者必須忽略該位。

Type:與NALU的header中的Type類型一致。

總結

以上是生活随笔為你收集整理的H264编码 封装成MP4格式 视频流 RTP封包的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。