|
完整的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ù)目蚣堋?/font>
H．264視頻流的RTP封裝策略 從圖4—1可以看出，H．264視頻數(shù)據(jù)首先經(jīng)RTP進(jìn)行封裝，打包成適合網(wǎng)絡(luò)傳輸?shù)?strong>數(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ì)原則： 4、應(yīng)支持將一個(gè)NALU拆分為若干個(gè)RTP包：不同大小的輸入圖片決定了NALU的長(zhǎng)度可能會(huì)大于MTU，只有拆分后才會(huì)避免IP層在傳輸時(shí)出現(xiàn)分片。 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)銷為2．7％，如果RTP載荷的長(zhǎng)度為730字節(jié)，協(xié)議頭的開(kāi)銷仍達(dá)到5．3％，而假設(shè)RTP載荷的長(zhǎng)度不到40字節(jié)，那么將有50％的開(kāi)銷用于頭部，這將對(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ù)載格式，主要有三種： NAL單元單一打包 將一個(gè)NAL單元封裝進(jìn)一個(gè)包中，也就是說(shuō)RTP負(fù)載中只包含一個(gè)NAL單元，NAL頭部兼作RTP頭部。RTP頭部類型即NAL單元類型1-23，如下圖所示：
NAL單元的重組 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。 NAL單元的分割 將一個(gè)NAL單元分割，使用多個(gè)RTP分組進(jìn)行傳輸。共有兩個(gè)類型FU—A和FU—B，單元類型中分別為28和29。根據(jù)IP層MTU的大小，對(duì)大尺寸的NALU必須要進(jìn)行分割，可以在分別在兩個(gè)層次上進(jìn)行分割： 為了適應(yīng)網(wǎng)絡(luò)MTU的尺寸，可以使用編碼器來(lái)選擇編碼Slice NALU的大小，從而使其提供較好的性能。一般是對(duì)編碼Slice的大小進(jìn)行調(diào)整，使其小于1460字節(jié)，以免IP層的分割。
RTP包的封裝流程設(shè)計(jì) 根據(jù)H．264NAL單元的分割重組的性質(zhì)以及RTP打包規(guī)則，本文實(shí)行的對(duì)RTP打包的設(shè)計(jì)如下：
其中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)銷，但是對(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)：
為了保證視頻流在不同傳輸環(huán)境中能有效地傳輸，單純的高壓縮率是不夠的，必須提供有效的方法，使視頻流能夠與傳輸協(xié)議無(wú)縫連接，才能應(yīng)用到各種網(wǎng)絡(luò)。在以前的標(biāo)準(zhǔn)中，MPEG標(biāo)準(zhǔn)包含系統(tǒng)層，同時(shí)制定了H．320或H．324等獨(dú)立的標(biāo)準(zhǔn)來(lái)滿足視頻編碼的網(wǎng)絡(luò)適應(yīng)性。然而，對(duì)于不同的通信系統(tǒng)來(lái)說(shuō)，只有將網(wǎng)絡(luò)適應(yīng)性與視頻編碼緊密結(jié)合起來(lái)，才可能獲得最佳的傳輸性能。因此在制定新一代國(guó)際視頻編碼標(biāo)準(zhǔn)H．264／AVC時(shí)就考慮了網(wǎng)絡(luò)友好性，提出了網(wǎng)絡(luò)抽象層NAL(Network Abstraction Layer)的概念?？筛鶕?jù)實(shí)現(xiàn)的功能不同，將編碼器分成兩層：視頻編碼層VCL(Video Coding Layer)與網(wǎng)絡(luò)抽象層NAL(Network Abstraction Layer)。 NAL層作為VCL層與傳輸層的接口，主要負(fù)責(zé)VCL數(shù)據(jù)的打包、序列和圖像的設(shè)置參數(shù)(parameter sets)傳輸、IDR(Instantaneous Decoding Refresh)等，使壓縮后的數(shù)據(jù)能在不同網(wǎng)絡(luò)傳輸。NAL層將視頻編碼數(shù)據(jù)抽象成NAL單元，根據(jù)不同的傳輸方式，進(jìn)行NAL單元封裝，H．264編碼器分層結(jié)構(gòu)圖中的H．324M表示用于移動(dòng)的H．324系統(tǒng)。 針對(duì)分組交換網(wǎng)，如RTP／IP或TCP／IP系統(tǒng)等，提出包傳輸NAL單元。NAL層將編碼數(shù)據(jù)直接進(jìn)行協(xié)議封裝，而不必進(jìn)行起始碼填充。 根據(jù)打包的數(shù)據(jù)類型不同，又可以將NAL單元分為VCL．NAL單元和非VCL．NAL單元。VCL．NAL單元包含視頻殘差編碼數(shù)據(jù)，對(duì)其解碼后能夠重建圖像。非VCL．NAL單元包含附加信息，如參數(shù)集和輔助增強(qiáng)信息(SEI：Supplemental Enhancement Information)等。 其中參數(shù)集包含高層的語(yǔ)法元素，這些信息對(duì)解碼而言非常重要。VCL．NAL單元解碼必須參考參數(shù)集里的語(yǔ)法元素，主要有序列參數(shù)集和圖像參數(shù)集。這些參數(shù)如果在傳輸中出錯(cuò)或丟失，將直接影響其它NAL單元的解碼。通常這些參數(shù)集在VCL—NAL單元前傳遞，也可通過(guò)重復(fù)傳輸來(lái)提高其魯棒性，防止數(shù)據(jù)丟失。在一些應(yīng)用中，參數(shù)集可以和VCL．NAL單元在同一信道傳輸。在一些特殊環(huán)境下，可以采用比視頻信道更可靠的傳輸機(jī)制來(lái)優(yōu)先傳遞參數(shù)集。VCL層編碼集中了近些年來(lái)視頻編碼方面的先進(jìn)技術(shù)，并將它們很好結(jié)合起來(lái)，與以前的標(biāo)準(zhǔn)相比，在同等視覺(jué)質(zhì)量的情況下可節(jié)省50％左右的碼率。 網(wǎng)絡(luò)抽象,NAL負(fù)責(zé)使用下層網(wǎng)絡(luò)的分段格式來(lái)封裝數(shù)據(jù)，包括組幀、邏輯信道的信令、定時(shí)信息的利用或發(fā)序列結(jié)束信號(hào)等。例如，NAL支持視頻在電路交換信道上的傳輸格式，支持視頻在Internet上利用RTP／UDP／IP傳輸?shù)母袷健AL包括網(wǎng)絡(luò)提取層的頭信息、段結(jié)構(gòu)信息和實(shí)際載荷信息，即上層的VCL數(shù)據(jù)。NAL提供適當(dāng)?shù)挠成浞椒▽㈩^部信息和數(shù)據(jù)映射到傳輸層協(xié)議上，可以減少在分組交換傳輸種組幀和重同步所需要的資源開(kāi)銷。為了提高在不同特性的網(wǎng)絡(luò)上定制VCL數(shù)據(jù)格式的能力，H．264的網(wǎng)絡(luò)提取層在VCL和NAL之間定義了基于分組的接口規(guī)范、打包方式等，也包括了相應(yīng)的信令內(nèi)容。這樣，高效率編碼任務(wù)和網(wǎng)絡(luò)友好性任務(wù)就由VCL和NAL分別完成。 |
|
|
來(lái)自： 燮羽 > 《RTSP/RTP/RTCP》
