H264關于RTP協定的實作
2010-07-22 13:35
完整的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)的開銷。目前存在着兩種類型聚合分組：
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.存在另外一個符号機制用來檢測是否有丢失的分塊。 ④輔助增強資訊包和頭資訊包可以任意時間發送。
⑤同一幀圖像中的圖像片可以以任意順序發送，但是對于低延遲時間要求的網絡系統，最好是以他們原始的編碼順序來發送。
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。
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頭部資料結構：