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