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 的有很大的區(qū)別，它采用的不再是嚴格的分級結構。H.264 支持4:2:0 的連續(xù)或隔行視頻的編碼和解碼。H.264 壓縮與H.263、MPEG-4 相比，視頻壓縮比提高了一倍。

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

2.H264的傳輸

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

3.H264的碼流結構

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

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

三、MP4封裝的H264數(shù)據(jù)

MP4文件中所有數(shù)據(jù)都封裝在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的媒體數(shù)據(jù)，可以有多個，也可以沒有。但是媒體數(shù)據(jù)的結構由metadata進行描述。MP4中box存儲方式為大端模式。一般，標準的box開頭會有四個字節(jié)的box size。

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

MP4數(shù)據(jù)格式：|"ftyp"box|"moov"box（及其子box）|"mdat"box|....|。

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

MP4封裝結構圖：

box結構圖：

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

四、H264視頻流的RTP封包

1.RTP打包原則

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

2.RTP協(xié)議的報文結構?

?

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

或M：標示位，1 位。如果當前 NALU為一個接入單元最后的那個NALU，那么將M位置 1；或者當前RTP 數(shù)據(jù)包為一個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數(shù)據(jù)包發(fā)送后而增加1，接收方可以根據(jù)該序列號重新排列數(shù)據(jù)包順序，或者探測包損失。系列號初值是隨機的，使對加密的文本攻擊更加困難。?
⑧時間戳
timestamp: 32 bits??? 32位，時標反映RTP數(shù)據(jù)包中第一個八進制數(shù)的采樣時刻，采樣時刻必須從單調、線性增加的時鐘導出，以允許同步與抖動計算。時標可以讓receiver端知道在正確的時間將資料播放出來。實際中當采用”分片封包模式“打包RTP時，當一個NALU打包完畢時，時間戳更一次。

?

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

3.NALU header結構圖

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

F: 1 個比特.forbidden_zero_bit. 在 H.264 規(guī)范中規(guī)定了這一位必須為 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分別為序列參數(shù)集（sps）和圖像參數(shù)集（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:必須根據(jù)分片NAL單元的NRI域的值設置，用來指示該NALU的重要性等級。值越大，表示當前NALU越重要。
TYPE:28表示FU-A和29表示FU-B

FU Header 結構：

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

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

總結

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

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