關於rtp264

好文,轉了: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打包完畢時,時間戳更一次。


RTP與RTCP協議介紹

 

   由上圖可知,如果只有系列號,並不能完整按照順序的將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類型一致。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章