H264關(guān)于RTP協(xié)議的實現(xiàn)

1、H264 關(guān)于 RTP 協(xié)議的實現(xiàn)2010-07-22 13:35完整的C/S架構(gòu)的基于RTP/ RTCP的H . 264視頻傳輸方案。此方案 中，在服務(wù)器端和客戶端分別進行了 功能模塊設(shè)計 。服務(wù)器端 ：RTP 封裝模塊主 要是對 H264 碼流進行打包封裝； RTCP 分析模塊負責產(chǎn)牛和發(fā)送 RTCP 包并 分析接收到的RTCP包;QoS反饋控制模塊則根據(jù)RR報文反饋信息動態(tài)的對發(fā) 送速率進行調(diào)整；發(fā)送緩沖模塊則設(shè)置端口發(fā)送 RTP、RTCP 包。 客戶端 ：RTP 模塊對接收到的RTP包進行解析判斷；RTCP模塊根據(jù)SR報文統(tǒng)計關(guān)鍵信息， 產(chǎn)牛并發(fā)送RR包。然后，在VC+6 . 0下用S

2、ocket編程，完成基于RTP/ UDP/IP 的 H264 視頻傳輸，并在局域網(wǎng)內(nèi)運行較好?；?RTP/ UDP /lP 的 H264 視頻傳輸結(jié)構(gòu)設(shè)計對于 H264 視頻的實時傳輸應(yīng)用來說， TCP 的重傳機制引入的時延和抖 動是無法容忍的， 因此我們采用 UDP 傳輸協(xié)議。 但是 UDP 協(xié)議本身是面向無連 接的，不能提供質(zhì)量保證。而基于 UDP之上的高層協(xié)議RTP/RTCP可以一起 提供流量控制和擁塞控制服務(wù)。圖給出了基于RTP/UDP/IP的H . 264視頻 傳輸?shù)目蚣?。圖4T基于RTP/UDP/1P的出264衩頻（專輸框圖H. 264視頻流的RTP封裝策略從圖4 1可以看出，H

3、 . 264視頻數(shù)據(jù)首先經(jīng)RTP進行封裝，打包成適合網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)包才能進行傳輸。所以，如何設(shè)計合適的 RTP封裝策略對H . 264視頻數(shù)據(jù)進行封裝是十分重要的。 一般來說，在H .264中，RTP封裝應(yīng)該遵循幾個設(shè)計原則：I、較低的開銷，因此 MTU的尺寸應(yīng)該限制在100 64K字節(jié)范圍內(nèi)。2、易于區(qū)分分組的重要性，而不必對分組內(nèi)的數(shù)據(jù)解碼。3、應(yīng)能檢測到數(shù)據(jù)的類型，而不需解碼整個數(shù)據(jù)流，并能根據(jù)編碼流之間的相關(guān)性丟棄無用數(shù)據(jù)，如網(wǎng)關(guān)應(yīng)能檢測 A型分割的丟失，并能丟棄相應(yīng)的B型和C型分割。4、應(yīng)支持將一個NALU拆分為若干個RTP包：不同大小的輸入圖片決定了 NALU的 長度可能會大于MT

4、U，只有拆分后才會避免IP層在傳輸時出現(xiàn)分片。5、支持將多個NALU匯集在一個RTP分組中，即在一個RTP包中傳輸超過一個 NALU , 當多個圖片的編碼輸出小于 M1IU時就考慮此模式，以提高網(wǎng)絡(luò)傳輸效率。RTP載荷封裝設(shè)計本文的網(wǎng)絡(luò)傳輸是基于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é)。TP報頭UDP報頭RTP報頭有效載荷（20字節(jié)）（8字節(jié)）（12字節(jié)）表4-2網(wǎng)絡(luò)傳輸中26

5、4的封裝格式一方面，如果每個IP分組都填滿1500字節(jié)，那么協(xié)議頭的開銷為 2 . 7 %，如 果RTP載荷的長度為730字節(jié)，協(xié)議頭的開銷仍達到 5 . 3 %，而假設(shè) RTP載荷的長 度不到40字節(jié)，那么將有50 %的開銷用于頭部，這將對網(wǎng)絡(luò)造成嚴重資源浪費。另 一方面，如果將要封裝進 RTP載荷的數(shù)據(jù)大于1460字節(jié)，并且我們沒有在應(yīng)用層數(shù) 據(jù)裝載迸RTP包之前進行載荷分割，將會產(chǎn)生大于MTU的包。在IP層其將會被分割 成幾個小于MTU尺寸的包，這樣將會無法檢測數(shù)據(jù)是否丟失。因為IP和UDP協(xié)議都沒有提供分組到達的檢測，如果分割后第一個包成功接收而后續(xù)的包丟失，由于只有第一個包中包含有完

6、 整的RTP頭信息，而RTP頭中沒有關(guān)于載荷長度的標識，因此判斷不出該RTP包是否有分割丟失，只能認為完整的接收了。并且在IP層的分割無法在應(yīng)用層 實現(xiàn)保護從而降低了非平等包含方案的效果。由于UDP數(shù)據(jù)分組小于64K字節(jié)，而且一個片的長度對某些應(yīng)用場合來說有點太小，所以應(yīng)用層的打包 也是RTP打包機制的一個必要部分。最新的 RFC3984標準中提供了針對 H . 246媒體流的RTP負載 格式，主要有三種：單個NAL單元分組、聚合分組、片分組。NAL單元單一打包將一個NAL單元封裝進一個包中，也就是說 RTP負載中只包含一個 NAL單元，NAL 頭部兼作RTP頭部。RTP頭部類型即NAL單元類

7、型1-23，如下圖所示：NAL單元類 型NAL單元類型名稱0未使用1 1不分區(qū)，非IDR圖橡的片2A型分割3B型分割4(:型分割5IDR圖像中的片6增強信息SEI7序列參數(shù)集8圖像參數(shù)集9分界符10序列結(jié)束11碼流結(jié)束12申充13-23保留24單一時間聚合分組STAP-A25單時間聚合分組STAP-B26多時間聚合分紐WTAP1627多時間聚合分組MTAP2428片分組方式FU-A29片分組方武FtFB30-31為定義|表4-3 NAL單元類型及苴名稱NAL單元的重組此分組類型用于將多個NAL單元聚合在一個RTP分組中。一些H . 264的NAL單元的大小，如SEI NAL單元、參數(shù)集等都非常

8、小，有些只有幾個字節(jié)，因此應(yīng)該把它們組合到一個 RTP包中，將會有利于減小頭標(RTP/UDP/IP)的開銷。 目前存在著兩種類型聚合分組：NAL 單元的分割將一個NAL單元分割，使用 多個RTP分組進行傳輸。共有兩個類型FUA和 FUB,單元類型中分別為28和29。根據(jù)IP層MTU的大小，對大尺寸的NALU 必須要進行分割，可以在分別在兩個層次上進行分割：1) 視頻編碼層 VCL 上的分割為了適應(yīng)網(wǎng)絡(luò) MTU 的尺寸，可以使用編碼器來選擇 編碼 Slice NALU 的大小， 從而使其提供較好的性能。 一般是對編碼 Slice 的大小進行調(diào)整， 使其小于 1460 字節(jié)，以免 IP 層的分割

9、。2) 網(wǎng)絡(luò)提取層 NAL 上的分割在網(wǎng)絡(luò)提取層上對 NALU 的分割主要是采用 分片單元方案 ， H264 標準中提出 了分割機制，可以使 NAL 單元的尺寸小于 1460 字節(jié)。注意：此方式是針對 同 一個NAL單元進行分割的，不適用于聚合分組。一個NAL單元采用分割分組后， 每個RTP分組序列號依次遞增I， RTP時間戳相同且惟一 。NAL單元的分割是 RTP 打包機制的一個重要環(huán)節(jié)，總結(jié)其分割機制主要有如下幾個特點： 分割NALU時，是以RTP次序號升序進行傳輸。在序列號不循環(huán)的前提下， 屬于前一幀圖像的所有圖像片包以及 A/B/C 數(shù)據(jù)分割包的序列號要小于后幀 圖像中的圖像片及數(shù)據(jù)分

10、割包的序列號。 一個符號機制來標記一個分割的 NALU 是第一個還是最后一個 NAL 單元。 3.存在另外一個符號機制用來檢測是否有丟失的分塊。輔助增強信息包和頭信息包可以任意時間發(fā)送。同一幀圖像中的圖像片可以以任意順序發(fā)送， 但是對于低時延要求的網(wǎng)絡(luò)系統(tǒng)， 最好是以他們原始的編碼順序來發(fā)送。1) 單一時間聚合分組(STAP):包括單一時間聚合分組 A(STAPA)和單一時間聚合分組B(STAP B),按時間戳進行組合，他們的 NAL單元具有相同的時間戳，一般用于低延遲環(huán)境。STAPASTAP B的單元類型分別為24和25。2) 多時間聚合分組(MTAP):包括16比特偏移多時間聚合分組(MT

11、AP16)和24比特偏移多時間聚合分組 (MTAP24) 不同時間戳也可以組合，一般用于高延遲 的網(wǎng)絡(luò)環(huán)境， 比如流媒體應(yīng)用 它的打包方案相對復(fù)雜， 但是大大增強了基于流 媒體的 H264 的性 能。 MTAPl6 MTAP24 的單元類型分別為 26 和 27。RTP包的封裝流程設(shè)計根據(jù)H . 264NAL單元的分割重組的性質(zhì)以及 RTP打包規(guī)則，本文實行的對RTP 打包的設(shè)計 如下:1、若接收到的NAL單元小于MAX SIZE(此時MAX-sIZE為設(shè)定的最大傳輸單元)，則對它進行單一打包，也就是將此NAL單元直接放進RTP包的載荷部分， 生成一個 RTP 包。2、若接收到的NAL單元大于

12、MAx SIZE字節(jié)，則對它進行分割，然后對分割后的 NAL 單元進行步驟 1 方式打包。分割方案如下:If (MMAXSI2E)0)K=( N* / MAX.SIZE)+1elseK= N>( / MAX3IZEif (NLim %KX»N= Ng %K+1elseN= JU /K其中Nsize是分割前的NAL單元大小，N是分割后NAL單元的大小。K分割后 的單元數(shù)。分割后最后一個單元的大小可能會小于 N，這時必須使用RTP載荷 填充是其同前面的分塊大小相同，此時 RTP頭中的填充標識位值為1。3、對SEI，參數(shù)集等小NAL單元重組，將它們合并到一個RTP包中。雖然步驟3中的

13、重組方案可以減小IP/UDP/RTP頭部開銷，但是對于包丟失率比較高的 網(wǎng)絡(luò)環(huán)境，這意味著一個RTP包的丟失可能會導(dǎo)致多片的丟失，往往一個片中 就有一個P圖像，解碼后的視頻質(zhì)量必然會嚴重下降。 因此，在丟失率的網(wǎng)絡(luò)中 可以采用NAL單元的重組方案，而在高丟失率的網(wǎng)絡(luò)環(huán)境中采用 NAL單元重組 時要進行有效的差錯控制在本文中不使用重組方案。RTP/ RTCP包的封裝實現(xiàn)RTP包封裝設(shè)計將K264碼流進行RTP數(shù)據(jù)封裝.下面是H. 2“中的UTP包頭的數(shù)據(jù)結(jié)構(gòu)Typed色f structunsigned int y； unsigned int p； unsigned int 和 unsigned

14、int cc； unsigned int unsigned int pt： unsigned intunsigned int tinpestfunpi unsigned int ssrc： byte* payload： unsigned int py byt&+ packet； unsigned int packlen： KTPPacketsRTcP包的封裝設(shè)計/版本號 2比特.值為0X2/填充標識1比特值為0/擴充標識.1比特，值為。/ CSRC計數(shù).4比特，值為0/標識位.1比符/標識負戟類型7個比轄/ RTP序列號個比特/時間II32個比特/同步源標識符.32個比持/載荷類型 轂

15、荷的長度NALL Length/把頭部和較荷打包/包的長度RTCP報文封裝在UDP數(shù)據(jù)報中進行傳輸，發(fā)送時使用比它所屬的 RTP流的端口號大1的協(xié)議號（RTP使用偶數(shù)號，RTCP使用奇數(shù)號）。以下是RTCP 頭部數(shù)據(jù)結(jié)構(gòu)：(unsigned int vjunsigned int p：unsigned int rc；unsigned int pt$unsigned int length； RTCP_Header：Typedef struct/發(fā)送竭報吿類堂為200/接收瑞報吿類型為20】/源墻描述報文類型為202/給束報文類型為203/應(yīng)用程序特定報文類型為204/版本號.2比特，儼為0X2 /

16、填充標識，1比特，值為0 /援收報吿計數(shù).5比符/ RTCP包的類型.8比特/包的長度RTCPttf用5個慕本報文類型允許發(fā)送端和搖收端交換有關(guān)會話估息.Typedef enuaRTCP SR-200sRTCP_RR=201：RTCP_SDES 二202$RTCP BYE=203sRTCP_APP=204：1 RTCP_TypeRTCP接收者報文RR的封裝數(shù)據(jù)結(jié)構(gòu):Typedef structunsignedintssrc：unsignedintLostPacket；unsignedinxLostRate；unsignedintMiixSeq?unsignedintJ i tter：unsignedintLsrt/同步源標識符/丟包數(shù)/丟包率/凰大序列號/到達間隔抖動/最后到達的SR的時間戳unsigned int DIsttiRTCPReceiver；RTCPSiSffliSH的封慕數(shù)據(jù)結(jié)構(gòu):Typedef structIunsigned ini TiveStawpunsigned ini Packet