完整的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ù)目蚣堋?
H.264視頻流的RTP封裝策略
從圖4—1可以看出,H.264視頻數(shù)據(jù)
首先經(jīng)RTP進行封裝
,打包成適合網(wǎng)絡傳輸?shù)?
數(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ù)結構:
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
