完整的C/S架構(gòu)的基于RTP/RTCP的H.264視頻傳輸方案。此方案中,在服務(wù)器端和客戶端分別進(jìn)行了 功能模塊設(shè)計(jì) 。 服務(wù)器端 :RTP封裝模塊主要是對(duì)H.264碼流進(jìn)行打包封裝;RTCP分析模塊負(fù)責(zé)產(chǎn)牛和發(fā)送RTCP包并分析接收到的RTCP包;QoS反饋控制模塊則根據(jù)RR報(bào)文反饋信息動(dòng)態(tài)的對(duì)發(fā)送速率進(jìn)行調(diào)整;發(fā)送緩沖模塊則設(shè)置端口發(fā)送RTP、RTCP包。 客戶端 :RTP模塊對(duì)接收到的RTP包進(jìn)行解析判斷;RTCP模塊根據(jù)SR報(bào)文統(tǒng)計(jì)關(guān)鍵信息,產(chǎn)牛并發(fā)送RR包。然后,在VC++6.0下用Socket編程,完成基于RTP/UDP/IP的H.264視頻傳輸,并在局域網(wǎng)內(nèi)運(yùn)行較好。
基于RTP/UDP/lP的H.264視頻傳輸結(jié)構(gòu)設(shè)計(jì)
對(duì)于H.264視頻的實(shí)時(shí)傳輸應(yīng)用來(lái)說(shuō),TCP的重傳機(jī)制引入的時(shí)延和抖動(dòng)是無(wú)法容忍的,因此我們采用UDP傳輸協(xié)議。但是UDP協(xié)議本身是面向無(wú)連接的,不能提供質(zhì)量保證。而基于UDP之上的高層協(xié)議RTP/RTCP可以一起提供 流量控制和擁塞控制 服務(wù)。圖給出了基于RTP/UDP/IP的H.264視頻傳輸?shù)目蚣堋?
H.264視頻流的RTP封裝策略
從圖4—1可以看出,H.264視頻數(shù)據(jù)
首先經(jīng)RTP進(jìn)行封裝
,打包成適合網(wǎng)絡(luò)傳輸?shù)?
數(shù)據(jù)包才能進(jìn)行傳輸
。所以,如何設(shè)計(jì)合適的RTP封裝策略對(duì)H.264視頻數(shù)據(jù)進(jìn)行封裝是十分重要的。一般來(lái)說(shuō),在H.264中,RTP封裝應(yīng)該遵循幾個(gè)設(shè)計(jì)原則:
1、較低的開(kāi)銷(xiāo),因此MTU的尺寸應(yīng)該限制在100—64K字節(jié)范圍內(nèi)。
2、易于區(qū)分分組的重要性,而不必對(duì)分組內(nèi)的數(shù)據(jù)解碼。
3、應(yīng)能檢測(cè)到數(shù)據(jù)的類型,而不需解碼整個(gè)數(shù)據(jù)流,并能根據(jù)編碼流之間的相關(guān)性丟棄無(wú)用數(shù)據(jù),如網(wǎng)關(guān)應(yīng)能檢測(cè)A型分割的丟失,并能丟棄相應(yīng)的B型和C型分割。
4、應(yīng)支持將一個(gè)NALU拆分為若干個(gè)RTP包:不同大小的輸入圖片決定了NALU的長(zhǎng)度可能會(huì)大于MTU,只有拆分后才會(huì)避免IP層在傳輸時(shí)出現(xiàn)分片。
5、支持將多個(gè)NALU匯集在一個(gè)RTP分組中,即在一個(gè)RTP包中傳輸超過(guò)一個(gè)NALU,當(dāng)多個(gè)圖片的編碼輸出小于M1IU時(shí)就考慮此模式,以提高網(wǎng)絡(luò)傳輸效率。
RTP載荷封裝設(shè)計(jì)
本文的網(wǎng)絡(luò)傳輸是基于IP協(xié)議,所以 最大傳輸單元(MTU )最大為1500字節(jié),在使用IP/UDP/RTP的協(xié)議層次結(jié)構(gòu)的時(shí)候,這其中包括至少 20字節(jié)的IP頭 , 8字節(jié)的UDP頭 ,以及 12字節(jié)的RTP頭 。這樣,頭信息至少要占用40個(gè)字節(jié),那么RTP載荷的最大尺寸為1460字節(jié)。
一方面,如果每個(gè)IP分組都填滿1500字節(jié),那么協(xié)議頭的開(kāi)銷(xiāo)為2.7%,如果RTP載荷的長(zhǎng)度為730字節(jié),協(xié)議頭的開(kāi)銷(xiāo)仍達(dá)到5.3%,而假設(shè)RTP載荷的長(zhǎng)度不到40字節(jié),那么將有50%的開(kāi)銷(xiāo)用于頭部,這將對(duì)網(wǎng)絡(luò)造成嚴(yán)重資源浪費(fèi)。另一方面,如果將要封裝進(jìn)RTP載荷的數(shù)據(jù)大于1460字節(jié),并且我們沒(méi)有在應(yīng)用層數(shù)據(jù)裝載迸RTP包之前進(jìn)行
載荷分割
,將會(huì)產(chǎn)生大于MTU的包。
在IP層其將會(huì)被分割成幾個(gè)小于MTU尺寸的包
,這樣將會(huì)無(wú)法檢測(cè)數(shù)據(jù)是否丟失。因?yàn)镮P和UDP協(xié)議都沒(méi)有提供分組到達(dá)的檢測(cè),如果分割后第一個(gè)包成功接收而后續(xù)的包丟失,由于只有第一個(gè)包中包含有完整的RTP頭信息,而RTP頭中沒(méi)有關(guān)于載荷長(zhǎng)度的標(biāo)識(shí),因此判斷不出該RTP包是否有分割丟失,只能認(rèn)為完整的接收了。并且在IP層的分割無(wú)法在應(yīng)用層實(shí)現(xiàn)保護(hù)從而降低了非平等包含方案的效果。由于UDP數(shù)據(jù)分組小于64K字節(jié),而且一個(gè)片的長(zhǎng)度對(duì)某些應(yīng)用場(chǎng)合來(lái)說(shuō)有點(diǎn)太小,所以
應(yīng)用層的打包
也是RTP打包機(jī)制的一個(gè)必要部分。最新的RFC3984標(biāo)準(zhǔn)中提供了針對(duì)H.246媒體流的RTP負(fù)載格式,主要有三種:
單個(gè)NAL單元分組、聚合分組、片分組。
NAL單元單一打包
將一個(gè)NAL單元封裝進(jìn)一個(gè)包中,也就是說(shuō)RTP負(fù)載中只包含一個(gè)NAL單元,NAL頭部兼作RTP頭部。RTP頭部類型即NAL單元類型1-23,如下圖所示:
NAL單元的重組
此分組類型用于將
多個(gè)NAL單元聚合在一個(gè)RTP分組
中。一些H.264的NAL單元的大小,如
SEI NAL單元
、參數(shù)集等都非常小,有些只有幾個(gè)字節(jié),因此應(yīng)該把它們組合到一個(gè)RTP包中,將會(huì)有利于減小頭標(biāo)(RTP/UDP/IP)的開(kāi)銷(xiāo)。目前存在著兩種類型聚合分組:
NAL單元的分割
將一個(gè)NAL單元分割,使用
多個(gè)RTP分組
進(jìn)行傳輸。共有兩個(gè)類型FU—A和FU—B,單元類型中分別為28和29。根據(jù)IP層MTU的大小,對(duì)大尺寸的NALU必須要進(jìn)行分割,可以在分別在兩個(gè)層次上進(jìn)行分割:
1)視頻編碼層
VCL上的分割
為了適應(yīng)網(wǎng)絡(luò)MTU的尺寸,可以使用編碼器來(lái)選擇 編碼Slice NALU 的大小,從而使其提供較好的性能。一般是對(duì)編碼Slice的大小進(jìn)行調(diào)整,使其小于 1460字節(jié) ,以免IP層的分割。
2)網(wǎng)絡(luò)提取層
NAL上的分割
在網(wǎng)絡(luò)提取層上對(duì)NALU的分割主要是采用
分片單元方案
,H.264標(biāo)準(zhǔn)中提出了分割機(jī)制,可以使NAL單元的尺寸小于1460字節(jié)。注意:此方式是針對(duì)
同一個(gè)NAL單元進(jìn)行分割的
,不適用于聚合分組。一個(gè)NAL單元采用分割分組后,每個(gè)RTP分組序列號(hào)依次遞增l,
RTP時(shí)間戳相同且惟一
。NAL單元的分割是RTP打包機(jī)制的一個(gè)重要環(huán)節(jié),總結(jié)其分割機(jī)制主要有如下幾個(gè)特點(diǎn):
①分割NALU時(shí),是以RTP次序號(hào)
升序進(jìn)行
傳輸。在序列號(hào)不循環(huán)的前提下,屬于前一幀圖像的所有圖像片包以及A/B/C數(shù)據(jù)分割包的序列號(hào)要小于后幀圖像中的圖像片及數(shù)據(jù)分割包的序列號(hào)。
②一個(gè)符號(hào)機(jī)制來(lái)標(biāo)記一個(gè)分割的NALU是第一個(gè)還是最后一個(gè)NAL單元。
3.存在另外一個(gè)符號(hào)機(jī)制用來(lái)檢測(cè)是否有丟失的分塊。
④輔助增強(qiáng)信息包和頭信息包可以任意時(shí)間發(fā)送。
⑤同一幀圖像中的圖像片可以以任意順序發(fā)送,但是對(duì)于低時(shí)延要求的網(wǎng)絡(luò)系統(tǒng),最好是以他們?cè)嫉木幋a順序來(lái)發(fā)送。
1)
單一時(shí)間聚合分組
(STAP):包括單一時(shí)間聚合分組A(STAP—A)和單一時(shí)間聚合分組B(STAP—B),按時(shí)間戳進(jìn)行組合,他們的NAL單元具有相同的時(shí)間戳,一般用于低延遲環(huán)境。STAP—ASTAP—B的單元類型分別為24和25。
2)
多時(shí)間聚合分組
(MTAP):包括16比特偏移多時(shí)間聚合分組(MTAPl6)和24比特偏移多時(shí)間聚合分組(MTAP24)不同時(shí)間戳也可以組合,一般用于高延遲的網(wǎng)絡(luò)環(huán)境,比如流媒體應(yīng)用.它的打包方案相對(duì)復(fù)雜,但是大大增強(qiáng)了基于流媒體的H.264的性能。MTAPl6 MTAP24的單元類型分別為26和27。
RTP包的封裝流程設(shè)計(jì)
根據(jù)H.264NAL單元的分割重組的性質(zhì)以及RTP打包規(guī)則,本文實(shí)行的對(duì)
RTP打包的設(shè)計(jì)
如下:
1、若接收到的NAL單元小于MAX—SIZE(此時(shí)MAX-sIZE為設(shè)定的
最大傳輸單元
),則對(duì)它進(jìn)行單一打包,也就是將此NAL單元直接放進(jìn)RTP包的載荷部分,生成一個(gè)RTP包。
2、若接收到的NAL單元大于MAx—SIZE字節(jié),則對(duì)它進(jìn)行分割,然后對(duì)分割后的NAL單元進(jìn)行步驟1方式打包。分割方案如下:
其中 Nsize是分割前的NAL單元大小 ,N是 分割后NAL單元的大小 。 K分割后的單元數(shù) 。分割后最后一個(gè)單元的大小可能會(huì)小于N,這時(shí)必須使用 RTP載荷填充 是其同前面的分塊大小相同,此時(shí)RTP頭中的 填充標(biāo)識(shí)位值為 1。
3、對(duì)SEI,參數(shù)集等小NAL單元重組,將 它們合并到一個(gè)RTP 包中。雖然步驟3中的重組方案可以減小IP/UDP/RTP頭部開(kāi)銷(xiāo),但是對(duì)于包丟失率比較高的網(wǎng)絡(luò)環(huán)境,這意味著一個(gè)RTP包的丟失可能會(huì)導(dǎo)致多片的丟失,往往一個(gè)片中就有一個(gè)P圖像,解碼后的視頻質(zhì)量必然會(huì)嚴(yán)重下降。因此,在丟失率的網(wǎng)絡(luò)中可以采用 NAL單元的重組方案 ,而在高丟失率的網(wǎng)絡(luò)環(huán)境中采用NAL單元重組時(shí)要進(jìn)行有效的差錯(cuò)控制.在本文中不使用重組方案。
RTP/RTCP包的封裝實(shí)現(xiàn)
RTP包封裝設(shè)計(jì)
RTcP包的封裝設(shè)計(jì)
RTCP報(bào)文封裝在 UDP數(shù)據(jù)報(bào) 中進(jìn)行傳輸,發(fā)送時(shí)使用比它所屬的RTP流的 端口號(hào)大1 的協(xié)議號(hào)(RTP使用偶數(shù)號(hào),RTCP使用奇數(shù)號(hào))。以下是RTCP頭部數(shù)據(jù)結(jié)構(gòu):
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

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