??????? 完整的C／S架構的基于RTP／RTCP的H．264視頻傳輸方案。此方案中，在服務器端和客戶端分別進行了功能模塊設計。服務器端：RTP封裝模塊主要是對H．264碼流進行打包封裝；RTCP分析模塊負責產(chǎn)牛和發(fā)送RTCP包并分析接收到的RTCP包；QoS反饋控制模塊則根據(jù)RR報文反饋信息動態(tài)的對發(fā)送速率進行調(diào)整；發(fā)送緩沖模塊則設置端口發(fā)送RTP、RTCP包。客戶端：RTP模塊對接收到的RTP包進行解析判斷；RTCP模塊根據(jù)SR報文統(tǒng)計關鍵信息，產(chǎn)牛并發(fā)送RR包。然后，在VC++6．0下用Socket編程，完成基于RTP／UDP／IP的H．264視頻傳輸，并在局域網(wǎng)內(nèi)運行較好。

基于RTP／UDP／lP的H．264視頻傳輸結構設計

??????? 對于H．264視頻的實時傳輸應用來說，TCP的重傳機制引入的時延和抖動是無法容忍的，因此我們采用UDP傳輸協(xié)議。但是UDP協(xié)議本身是面向無連接的，不能提供質(zhì)量保證。而基于UDP之上的高層協(xié)議RTP／RTCP可以一起提供流量控制和擁塞控制服務。圖給出了基于RTP／UDP／IP的H．264視頻傳輸?shù)目蚣堋?/span>

??

H．264視頻流的RTP封裝策略

??????? 從圖4—1可以看出，H．264視頻數(shù)據(jù)首先經(jīng)RTP進行封裝，打包成適合網(wǎng)絡傳輸?shù)?strong>數(shù)據(jù)包才能進行傳輸。所以，如何設計合適的RTP封裝策略對H．264視頻數(shù)據(jù)進行封裝是十分重要的。一般來說，在H．264中，RTP封裝應該遵循幾個設計原則：
1、較低的開銷，因此MTU的尺寸應該限制在100—64K字節(jié)范圍內(nèi)。
2、易于區(qū)分分組的重要性，而不必對分組內(nèi)的數(shù)據(jù)解碼。
3、應能檢測到數(shù)據(jù)的類型，而不需解碼整個數(shù)據(jù)流，并能根據(jù)編碼流之間的相關性丟棄無用數(shù)據(jù)，如網(wǎng)關應能檢測A型分割的丟失，并能丟棄相應的B型和C型分割。

4、應支持將一個NALU拆分為若干個RTP包：不同大小的輸入圖片決定了NALU的長度可能會大于MTU，只有拆分后才會避免IP層在傳輸時出現(xiàn)分片。
5、支持將多個NALU匯集在一個RTP分組中，即在一個RTP包中傳輸超過一個NALU，當多個圖片的編碼輸出小于M1IU時就考慮此模式，以提高網(wǎng)絡傳輸效率。

RTP載荷封裝設計

???????? 本文的網(wǎng)絡傳輸是基于IP協(xié)議，所以最大傳輸單元(MTU)最大為1500字節(jié)，在使用IP／UDP／RTP的協(xié)議層次結構的時候，這其中包括至少20字節(jié)的IP頭，8字節(jié)的UDP頭，以及12字節(jié)的RTP頭。這樣，頭信息至少要占用40個字節(jié)，那么RTP載荷的最大尺寸為1460字節(jié)。

????????? 一方面，如果每個IP分組都填滿1500字節(jié)，那么協(xié)議頭的開銷為2．7％，如果RTP載荷的長度為730字節(jié)，協(xié)議頭的開銷仍達到5．3％，而假設RTP載荷的長度不到40字節(jié)，那么將有50％的開銷用于頭部，這將對網(wǎng)絡造成嚴重資源浪費。另一方面，如果將要封裝進RTP載荷的數(shù)據(jù)大于1460字節(jié)，并且我們沒有在應用層數(shù)據(jù)裝載迸RTP包之前進行載荷分割，將會產(chǎn)生大于MTU的包。在IP層其將會被分割成幾個小于MTU尺寸的包，這樣將會無法檢測數(shù)據(jù)是否丟失。因為IP和UDP協(xié)議都沒有提供分組到達的檢測，如果分割后第一個包成功接收而后續(xù)的包丟失，由于只有第一個包中包含有完整的RTP頭信息，而RTP頭中沒有關于載荷長度的標識，因此判斷不出該RTP包是否有分割丟失，只能認為完整的接收了。并且在IP層的分割無法在應用層實現(xiàn)保護從而降低了非平等包含方案的效果。由于UDP數(shù)據(jù)分組小于64K字節(jié)，而且一個片的長度對某些應用場合來說有點太小，所以應用層的打包也是RTP打包機制的一個必要部分。最新的RFC3984標準中提供了針對H．246媒體流的RTP負載格式，主要有三種：
單個NAL單元分組、聚合分組、片分組。

NAL單元單一打包

將一個NAL單元封裝進一個包中，也就是說RTP負載中只包含一個NAL單元，NAL頭部兼作RTP頭部。RTP頭部類型即NAL單元類型1-23，如下圖所示：

NAL單元的重組
此分組類型用于將多個NAL單元聚合在一個RTP分組中。一些H．264的NAL單元的大小，如SEI NAL單元、參數(shù)集等都非常小，有些只有幾個字節(jié)，因此應該把它們組合到一個RTP包中，將會有利于減小頭標(RTP／UDP／IP)的開銷。目前存在著兩種類型聚合分組：

NAL單元的分割

將一個NAL單元分割，使用多個RTP分組進行傳輸。共有兩個類型FU—A和FU—B，單元類型中分別為28和29。根據(jù)IP層MTU的大小，對大尺寸的NALU必須要進行分割，可以在分別在兩個層次上進行分割：
1)視頻編碼層VCL上的分割

為了適應網(wǎng)絡MTU的尺寸，可以使用編碼器來選擇編碼Slice NALU的大小，從而使其提供較好的性能。一般是對編碼Slice的大小進行調(diào)整，使其小于1460字節(jié)，以免IP層的分割。

2)網(wǎng)絡提取層NAL上的分割
在網(wǎng)絡提取層上對NALU的分割主要是采用分片單元方案，H．264標準中提出了分割機制，可以使NAL單元的尺寸小于1460字節(jié)。注意：此方式是針對同一個NAL單元進行分割的，不適用于聚合分組。一個NAL單元采用分割分組后，每個RTP分組序列號依次遞增l，RTP時間戳相同且惟一。NAL單元的分割是RTP打包機制的一個重要環(huán)節(jié)，總結其分割機制主要有如下幾個特點：
①分割NALU時，是以RTP次序號升序進行傳輸。在序列號不循環(huán)的前提下，屬于前一幀圖像的所有圖像片包以及A／B／C數(shù)據(jù)分割包的序列號要小于后幀圖像中的圖像片及數(shù)據(jù)分割包的序列號。
②一個符號機制來標記一個分割的NALU是第一個還是最后一個NAL單元。
3.存在另外一個符號機制用來檢測是否有丟失的分塊。
④輔助增強信息包和頭信息包可以任意時間發(fā)送。
⑤同一幀圖像中的圖像片可以以任意順序發(fā)送，但是對于低時延要求的網(wǎng)絡系統(tǒng)，最好是以他們原始的編碼順序來發(fā)送。

1)單一時間聚合分組(STAP)：包括單一時間聚合分組A(STAP—A)和單一時間聚合分組B(STAP—B)，按時間戳進行組合，他們的NAL單元具有相同的時間戳，一般用于低延遲環(huán)境。STAP—ASTAP—B的單元類型分別為24和25。
2)多時間聚合分組(MTAP)：包括16比特偏移多時間聚合分組(MTAPl6)和24比特偏移多時間聚合分組(MTAP24)不同時間戳也可以組合，一般用于高延遲的網(wǎng)絡環(huán)境，比如流媒體應用．它的打包方案相對復雜，但是大大增強了基于流媒體的H．264的性能。MTAPl6 MTAP24的單元類型分別為26和27。

RTP包的封裝流程設計

根據(jù)H．264NAL單元的分割重組的性質(zhì)以及RTP打包規(guī)則，本文實行的對RTP打包的設計如下：
1、若接收到的NAL單元小于MAX—SIZE(此時MAX-sIZE為設定的最大傳輸單元)，則對它進行單一打包，也就是將此NAL單元直接放進RTP包的載荷部分，生成一個RTP包。
2、若接收到的NAL單元大于MAx—SIZE字節(jié)，則對它進行分割，然后對分割后的NAL單元進行步驟1方式打包。分割方案如下：

其中Nsize是分割前的NAL單元大小，N是分割后NAL單元的大小。K分割后的單元數(shù)。分割后最后一個單元的大小可能會小于N，這時必須使用RTP載荷填充是其同前面的分塊大小相同，此時RTP頭中的填充標識位值為1。

3、對SEI，參數(shù)集等小NAL單元重組，將它們合并到一個RTP包中。雖然步驟3中的重組方案可以減小IP／UDP／RTP頭部開銷，但是對于包丟失率比較高的網(wǎng)絡環(huán)境，這意味著一個RTP包的丟失可能會導致多片的丟失，往往一個片中就有一個P圖像，解碼后的視頻質(zhì)量必然會嚴重下降。因此，在丟失率的網(wǎng)絡中可以采用NAL單元的重組方案，而在高丟失率的網(wǎng)絡環(huán)境中采用NAL單元重組時要進行有效的差錯控制．在本文中不使用重組方案。

RTP／RTCP包的封裝實現(xiàn)

RTP包封裝設計

RTcP包的封裝設計

??????? RTCP報文封裝在UDP數(shù)據(jù)報中進行傳輸，發(fā)送時使用比它所屬的RTP流的端口號大1的協(xié)議號(RTP使用偶數(shù)號，RTCP使用奇數(shù)號)。以下是RTCP頭部數(shù)據(jù)結構：

總結

以上是生活随笔為你收集整理的H264关于RTP协议的实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。