H264關於RTP協議的實現

完整的C/S架構的基於RTP/RTCP的H.264視頻傳輸方案。此方案中,在服務器端和客戶端分別進行了功能模塊設計服務器端:RTP封裝模塊主要是對H.264碼流進行打包封裝;RTCP分析模塊負責產牛和發送RTCP包並分析接收到的RTCP包;QoS反饋控制模塊則根據RR報文反饋信息動態的對發送速率進行調整;發送緩衝模塊則設置端口發送RTP、RTCP包。客戶端:RTP模塊對接收到的RTP包進行解析判斷;RTCP模塊根據SR報文統計關鍵信息,產牛併發送RR包。然後,在VC++6.0下用Socket編程,完成基於RTP/UDP/IP的H.264視頻傳輸,並在局域網內運行較好。

基於RTP/UDP/lP的H.264視頻傳輸結構設計

        對於H.264視頻的實時傳輸應用來說,TCP的重傳機制引入的時延和抖動是無法容忍的,因此我們採用UDP傳輸協議。但是UDP協議本身是面向無連接的,不能提供質量保證。而基於UDP之上的高層協議RTP/RTCP可以一起提供流量控制和擁塞控制服務。圖給出了基於RTP/UDP/IP的H.264視頻傳輸的框架。

  

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

        從圖4—1可以看出,H.264視頻數據首先經RTP進行封裝,打包成適合網絡傳輸的數據包才能進行傳輸。所以,如何設計合適的RTP封裝策略對H.264視頻數據進行封裝是十分重要的。一般來說,在H.264中,RTP封裝應該遵循幾個設計原則:
1、較低的開銷,因此MTU的尺寸應該限制在100—64K字節範圍內。
2、易於區分分組的重要性,而不必對分組內的數據解碼。
3、應能檢測到數據的類型,而不需解碼整個數據流,並能根據編碼流之間的相關性丟棄無用數據,如網關應能檢測A型分割的丟失,並能丟棄相應的B型和C型分割。

4、應支持將一個NALU拆分爲若干個RTP包:不同大小的輸入圖片決定了NALU的長度可能會大於MTU,只有拆分後纔會避免IP層在傳輸時出現分片。
5、支持將多個NALU彙集在一個RTP分組中,即在一個RTP包中傳輸超過一個NALU,當多個圖片的編碼輸出小於M1IU時就考慮此模式,以提高網絡傳輸效率。

RTP載荷封裝設計

         本文的網絡傳輸是基於IP協議,所以最大傳輸單元(MTU)最大爲1500字節,在使用IP/UDP/RTP的協議層次結構的時候,這其中包括至少20字節的IP頭8字節的UDP頭,以及12字節的RTP頭。這樣,頭信息至少要佔用40個字節,那麼RTP載荷的最大尺寸爲1460字節。

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

NAL單元單一打包

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

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


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

NAL單元的分割

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

爲了適應網絡MTU的尺寸,可以使用編碼器來選擇編碼Slice NALU的大小,從而使其提供較好的性能。一般是對編碼Slice的大小進行調整,使其小於1460字節,以免IP層的分割。


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

 

RTP包的封裝流程設計

根據H.264NAL單元的分割重組的性質以及RTP打包規則,本文實行的對RTP打包的設計如下:
1、若接收到的NAL單元小於MAX—SIZE(此時MAX-sIZE爲設定的最大傳輸單元),則對它進行單一打包,也就是將此NAL單元直接放進RTP包的載荷部分,生成一個RTP包。
2、若接收到的NAL單元大於MAx—SIZE字節,則對它進行分割,然後對分割後的NAL單元進行步驟1方式打包。分割方案如下:

 

 

其中Nsize是分割前的NAL單元大小,N是分割後NAL單元的大小K分割後的單元數。分割後最後一個單元的大小可能會小於N,這時必須使用RTP載荷填充是其同前面的分塊大小相同,此時RTP頭中的填充標識位值爲1。

3、對SEI,參數集等小NAL單元重組,將它們合併到一個RTP包中。雖然步驟3中的重組方案可以減小IP/UDP/RTP頭部開銷,但是對於包丟失率比較高的網絡環境,這意味着一個RTP包的丟失可能會導致多片的丟失,往往一個片中就有一個P圖像,解碼後的視頻質量必然會嚴重下降。因此,在丟失率的網絡中可以採用NAL單元的重組方案,而在高丟失率的網絡環境中採用NAL單元重組時要進行有效的差錯控制.在本文中不使用重組方案。

RTP/RTCP包的封裝實現

RTP包封裝設計

RTcP包的封裝設計

        RTCP報文封裝在UDP數據報中進行傳輸,發送時使用比它所屬的RTP流的端口號大1的協議號(RTP使用偶數號,RTCP使用奇數號)。以下是RTCP頭部數據結構:



NAL的基本特徵

爲了保證視頻流在不同傳輸環境中能有效地傳輸,單純的高壓縮率是不夠的,必須提供有效的方法,使視頻流能夠與傳輸協議無縫連接,才能應用到各種網絡。在以前的標準中,MPEG標準包含系統層,同時制定了H.320或H.324等獨立的標準來滿足視頻編碼的網絡適應性。然而,對於不同的通信系統來說,只有將網絡適應性與視頻編碼緊密結合起來,纔可能獲得最佳的傳輸性能。因此在制定新一代國際視頻編碼標準H.264/AVC時就考慮了網絡友好性,提出了網絡抽象層NAL(Network Abstraction Layer)的概念。可根據實現的功能不同,將編碼器分成兩層:視頻編碼層VCL(Video Coding Layer)與網絡抽象層NAL(Network Abstraction Layer)。

       NAL層作爲VCL層與傳輸層的接口,主要負責VCL數據的打包、序列和圖像的設置參數(parameter sets)傳輸、IDR(Instantaneous Decoding Refresh)等,使壓縮後的數據能在不同網絡傳輸。NAL層將視頻編碼數據抽象成NAL單元,根據不同的傳輸方式,進行NAL單元封裝,H.264編碼器分層結構圖中的H.324M表示用於移動的H.324系統。

根據傳輸網絡中數據交換方法的不同,有兩種類型的NAL單元:
針對電路交換網,如H.320,MPEG.2等,提出字節流格式NAL單元。NAL層將視頻編碼數據封裝成字節流格式的單元,每一個單元包含3個(或4個)字節的起始前綴,值0x000001

針對分組交換網,如RTP/IP或TCP/IP系統等,提出包傳輸NAL單元。NAL層將編碼數據直接進行協議封裝,而不必進行起始碼填充。

        根據打包的數據類型不同,又可以將NAL單元分爲VCL.NAL單元和非VCL.NAL單元。VCL.NAL單元包含視頻殘差編碼數據,對其解碼後能夠重建圖像。非VCL.NAL單元包含附加信息,如參數集和輔助增強信息(SEI:Supplemental Enhancement Information)等。

        其中參數集包含高層的語法元素,這些信息對解碼而言非常重要。VCL.NAL單元解碼必須參考參數集裏的語法元素,主要有序列參數集和圖像參數集。這些參數如果在傳輸中出錯或丟失,將直接影響其它NAL單元的解碼。通常這些參數集在VCL—NAL單元前傳遞,也可通過重複傳輸來提高其魯棒性,防止數據丟失。在一些應用中,參數集可以和VCL.NAL單元在同一信道傳輸。在一些特殊環境下,可以採用比視頻信道更可靠的傳輸機制來優先傳遞參數集。VCL層編碼集中了近些年來視頻編碼方面的先進技術,並將它們很好結合起來,與以前的標準相比,在同等視覺質量的情況下可節省50%左右的碼率。

        網絡抽象,NAL負責使用下層網絡的分段格式來封裝數據,包括組幀、邏輯信道的信令定時信息的利用或發序列結束信號等。例如,NAL支持視頻在電路交換信道上的傳輸格式,支持視頻在Internet上利用RTP/UDP/IP傳輸的格式。NAL包括網絡提取層的頭信息、段結構信息和實際載荷信息,即上層的VCL數據。NAL提供適當的映射方法將頭部信息和數據映射到傳輸層協議上,可以減少在分組交換傳輸種組幀和重同步所需要的資源開銷。爲了提高在不同特性的網絡上定製VCL數據格式的能力,H.264的網絡提取層在VCL和NAL之間定義了基於分組的接口規範、打包方式等,也包括了相應的信令內容。這樣,高效率編碼任務和網絡友好性任務就由VCL和NAL分別完成。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章