網絡協議之rtp---h264的rtp網絡協議實現

完整的C／S架構的基於RTP／RTCP的H．264視頻傳輸方案。此方案中，在服務器端和客戶端分別進行了功能模塊設計。服務器端：RTP封裝模塊主要是對H．264碼流進行打包封裝；RTCP分析模塊負責產牛和發送RTCP包並分析接收到的RTCP包；QoS反饋控制模塊則根據RR報文反饋信息動態的對發送速率進行調整；發送緩衝模塊則設置端口發送RTP、RTCP包。客戶端：RTP模塊對接收到的RTP包進行解析判斷；RTCP模塊根據SR報文統計關鍵信息，產牛併發送RR包。而後，在VC++6．0下用Socket編程，完成基於RTP／UDP／IP的H．264視頻傳輸，並在局域網內運行較好。
基於RTP／UDP／lP的H．264視頻傳輸結構設計
對於H．264視頻的實時傳輸應用來講，TCP的重傳機制引入的時延和抖動是沒法容忍的，所以咱們採用UDP傳輸協議。可是UDP協議自己是面向無鏈接的，不能提供質量保證。而基於UDP之上的高層協議RTP／RTCP能夠一塊兒提供流量控制和擁塞控制服務。圖給出了基於RTP／UDP／IP的H．264視頻傳輸的框架。

H．264視頻流的RTP封裝策略
從圖4—1能夠看出，H．264視頻數據首先經RTP進行封裝，打包成適合網絡傳輸的數據包才能進行傳輸。因此，如何設計合適的RTP封裝策略對H．264視頻數據進行封裝是十分重要的。通常來講，在H．264中，RTP封裝應該遵循幾個設計原則： 一、較低的開銷，所以MTU的尺寸應該限制在100—64K字節範圍內。 二、易於區分分組的重要性，而沒必要對分組內的數據解碼。 三、應能檢測到數據的類型，而不需解碼整個數據流，並能根據編碼流之間的相關性丟棄無用數據，如網關應能檢測A型分割的丟失，並能丟棄相應的B型和C型分割。
四、應支持將一個NALU拆分爲若干個RTP包：不一樣大小的輸入圖片決定了NALU的長度可能會大於MTU，只有拆分後纔會避免IP層在傳輸時出現分片。 五、支持將多個NALU聚集在一個RTP分組中，即在一個RTP包中傳輸超過一個NALU，當多個圖片的編碼輸出小於M1IU時就考慮此模式，以提升網絡傳輸效率。
RTP載荷封裝設計
本文的網絡傳輸是基於IP協議，因此最大傳輸單元(MTU)最大爲1500字節，在使用IP／UDP／RTP的協議層次結構的時候，這其中包括至少20字節的IP頭，8字節的UDP頭，以及12字節的RTP頭。這樣，頭信息至少要佔用40個字節，那麼RTP載荷的最大尺寸爲1460字節。

一方面，若是每一個IP分組都填滿1500字節，那麼協議頭的開銷爲2．7％，若是RTP載荷的長度爲730字節，協議頭的開銷仍達到5．3％，而假設 RTP載荷的長度不到40字節，那麼將有50％的開銷用於頭部，這將對網絡形成嚴重資源浪費。另外一方面，若是將要封裝進RTP載荷的數據大於1460字 節，而且咱們沒有在應用層數據裝載迸RTP包以前進行載荷分割，將會產生大於MTU的包。在IP層其將會被分割成幾個小於MTU尺寸的包， 這樣將會沒法檢測數據是否丟失。由於IP和UDP協議都沒有提供分組到達的檢測，若是分割後第一個包成功接收然後續的包丟失，因爲只有第一個包中包含有完 整的RTP頭信息，而RTP頭中沒有關於載荷長度的標識，所以判斷不出該RTP包是否有分割丟失，只能認爲完整的接收了。而且在IP層的分割沒法在應用層 實現保護從而下降了非平等包含方案的效果。因爲UDP數據分組小於64K字節，並且一個片的長度對某些應用場合來講有點過小，因此應用層的打包也是RTP打包機制的一個必要部分。最新的RFC3984標準中提供了針對H．246媒體流的RTP負載格式，主要有三種： 單個NAL單元分組、聚合分組、片分組。
NAL單元單一打包
將一個NAL單元封裝進一個包中，也就是說RTP負載中只包含一個NAL單元，NAL頭部兼做RTP頭部。RTP頭部類型即NAL單元類型1-23，以下圖所示：

NAL單元的重組 此分組類型用於將多個NAL單元聚合在一個RTP分組中。一些H．264的NAL單元的大小，如SEI NAL單元、參數集等都很是小，有些只有幾個字節，所以
應該把它們組合到一個RTP包中，將會有利於減少頭標(RTP／UDP／IP)的開銷。目前存在着兩種類型聚合分組：
NAL單元的分割
將一個NAL單元分割，使用多個RTP分組進行傳輸。共有兩個類型FU—A和FU—B，單元類型中分別爲28和29。根據IP層MTU的大小，對大尺寸的NALU必需要進行分割，能夠在分別在兩個層次上進行分割： 1)視頻編碼層VCL上的分割
爲了適應網絡MTU的尺寸，可使用編碼器來選擇編碼Slice NALU的大小，從而使其提供較好的性能。通常是對編碼Slice的大小進行調整，使其小於1460字節，以避免IP層的分割。
2)網絡提取層NAL上的分割 在網絡提取層上對NALU的分割主要是採用分片單元方案，H．264標準中提出了分割機制，可使NAL單元的尺寸小於1460字節。注意：此方式是針對同一個NAL單元進行分割的，不適用於聚合分組。一個NAL單元採用分割分組後，每一個RTP分組序列號依次遞增l，RTP時間戳相同且唯一。NAL單元的分割是RTP打包機制的一個重要環節，總結其分割機制主要有以下幾個特色： ①分割NALU時，是以RTP次序號升序進行傳輸。在序列號不循環的前提下，屬於前一幀圖像的全部圖像片包以及A／B／C數據分割包的序列號要小於後幀圖像中的圖像片及數據分割包的序列號。 ②一個符號機制來標記一個分割的NALU是第一個仍是最後一個NAL單元。 3.存在另一個符號機制用來檢測是否有丟失的分塊。 ④輔助加強信息包和頭信息包能夠任意時間發送。
⑤同一幀圖像中的圖像片能夠以任意順序發送，可是對於低時延要求的網絡系統，最好是以他們原始的編碼順序來發送。
1)單一時間聚合分組(STAP)：包括單一時間聚合分組A(STAP—A)和單一時間聚合分組B(STAP—B)，按時間戳進行組合，他們的NAL單元具備相同的時間戳，通常用於低延遲環境。STAP—ASTAP—B的單元類型分別爲24和25。 2)多時間聚合分組(MTAP)：包括16比特偏移多時間聚合分組(MTAPl6)和24比特偏移多時間聚合分組 (MTAP24)不一樣時間戳也能夠組合，通常用於高延遲的網絡環境，好比流媒體應用．它的打包方案相對複雜，可是大大加強了基於流媒體的H．264的性 能。MTAPl6 MTAP24的單元類型分別爲26和27。
RTP包的封裝流程設計
根據H．264NAL單元的分割重組的性質以及RTP打包規則，本文實行的對RTP打包的設計以下： 一、若接收到的NAL單元小於MAX—SIZE(此時MAX-sIZE爲設定的最大傳輸單元)，則對它進行單一打包，也就是將此NAL單元直接放進RTP包的載荷部分，生成一個RTP包。 二、若接收到的NAL單元大於MAx—SIZE字節，則對它進行分割，而後對分割後的NAL單元進行步驟1方式打包。分割方案以下：

其中Nsize是分割前的NAL單元大小，N是分割後NAL單元的大小。K分割後的單元數。分割後最後一個單元的大小可能會小於N，這時必須使用RTP載荷填充是其同前面的分塊大小相同，此時RTP頭中的填充標識位值爲1。
三、對SEI，參數集等小NAL單元重組，將它們合併到一個RTP包中。雖然步驟3中的重組方案能夠減少IP／UDP／RTP頭部開銷，可是對於包丟失率比較高的網絡環境，這意味着一個RTP包的丟失可能會致使多片的丟失，每每一個片中就有一個P圖像，解碼後的視頻質量必然會嚴重降低。所以，在丟失率的網絡中能夠採用NAL單元的重組方案，而在高丟失率的網絡環境中採用NAL單元重組時要進行有效的差錯控制．在本文中不使用重組方案。
RTP／RTCP包的封裝實現
RTP包封裝設計

RTcP包的封裝設計
RTCP報文封裝在UDP數據報中進行傳輸，發送時使用比它所屬的RTP流的端口號大1的協議號(RTP使用偶數號，RTCP使用奇數號)。如下是RTCP頭部數據結構：

 

http://www.rosoo.net/a/201108/14896.html