基于RTP／UDP／lP的H．264視頻傳輸結構設計
對于H．264視頻的實(shí)時(shí)傳輸應用來(lái)說(shuō)，TCP的重傳機制引入的時(shí)延和抖動(dòng)是無(wú)法容忍的，因此我們采用UDP傳輸協(xié)議。但是UDP協(xié)議本身是面向無(wú)連接的，不能提供質(zhì)量保證。而基于UDP之上的高層協(xié)議RTP／RTCP可以一起提供流量控制和擁塞控制服務(wù)。圖給出了基于RTP／UDP／IP的H．264視頻傳輸的框架。
H．264視頻流的RTP封裝策略
從圖4—1可以看出，H．264視頻數據首先經(jīng)RTP進(jìn)行封裝，打包成適合網(wǎng)絡(luò )傳輸的數據包才能進(jìn)行傳輸。所以，如何設計合適的RTP封裝策略對H．264視頻數據進(jìn)行封裝是十分重要的。一般來(lái)說(shuō)，在H．264中，RTP封裝應該遵循幾個(gè)設計原則：
1、較低的開(kāi)銷(xiāo)，因此MTU的尺寸應該限制在100—64K字節范圍內。
2、易于區分分組的重要性，而不必對分組內的數據解碼。
3、應能檢測到數據的類(lèi)型，而不需解碼整個(gè)數據流，并能根據編碼流之間的相關(guān)性丟棄無(wú)用數據，如網(wǎng)關(guān)應能檢測A型分割的丟失，并能丟棄相應的B型和C型分割。
4、應支持將一個(gè)NALU拆分為若干個(gè)RTP包：不同大小的輸入圖片決定了NALU的長(cháng)度可能會(huì )大于MTU，只有拆分后才會(huì )避免IP層在傳輸時(shí)出現分片。
5、支持將多個(gè)NALU匯集在一個(gè)RTP分組中，即在一個(gè)RTP包中傳輸超過(guò)一個(gè)NALU，當多個(gè)圖片的編碼輸出小于M1IU時(shí)就考慮此模式，以提高網(wǎng)絡(luò )傳輸效率。
RTP載荷封裝設計
本文的網(wǎng)絡(luò )傳輸是基于IP協(xié)議，所以最大傳輸單元(MTU)最大為1500字節，在使用IP／UDP／RTP的協(xié)議層次結構的時(shí)候，這其中包括至少20字節的IP頭，8字節的UDP頭，以及12字節的RTP頭。這樣，頭信息至少要占用40個(gè)字節，那么RTP載荷的最大尺寸為1460字節。
一方面，如果每個(gè)IP分組都填滿(mǎn)1500字節，那么協(xié)議頭的開(kāi)銷(xiāo)為2．7％，如果RTP載荷的長(cháng)度為730字節，協(xié)議頭的開(kāi)銷(xiāo)仍達到5．3％，而假設RTP載荷的長(cháng)度不到40字節，那么將有50％的開(kāi)銷(xiāo)用于頭部，這將對網(wǎng)絡(luò )造成嚴重資源浪費。另一方面，如果將要封裝進(jìn)RTP載荷的數據大于1460字節，并且我們沒(méi)有在應用層數據裝載迸RTP包之前進(jìn)行載荷分割，將會(huì )產(chǎn)生大于MTU的包。在IP層其將會(huì )被分割成幾個(gè)小于MTU尺寸的包，這樣將會(huì )無(wú)法檢測數據是否丟失。因為IP和UDP協(xié)議都沒(méi)有提供分組到達的檢測，如果分割后第一個(gè)包成功接收而后續的包丟失，由于只有第一個(gè)包中包含有完整的RTP頭信息，而RTP頭中沒(méi)有關(guān)于載荷長(cháng)度的標識，因此判斷不出該RTP包是否有分割丟失，只能認為完整的接收了。并且在IP層的分割無(wú)法在應用層實(shí)現保護從而降低了非平等包含方案的效果。由于UDP數據分組小于64K字節，而且一個(gè)片的長(cháng)度對某些應用場(chǎng)合來(lái)說(shuō)有點(diǎn)太小，所以應用層的打包也是RTP打包機制的一個(gè)必要部分。最新的RFC3984標準中提供了針對H．246媒體流的RTP負載格式，主要有三種：
單個(gè)NAL單元分組、聚合分組、片分組。
NAL單元單一打包
將一個(gè)NAL單元封裝進(jìn)一個(gè)包中，也就是說(shuō)RTP負載中只包含一個(gè)NAL單元，NAL頭部兼作RTP頭部。RTP頭部類(lèi)型即NAL單元類(lèi)型1-23，如下圖所示：
NAL單元的重組
此分組類(lèi)型用于將多個(gè)NAL單元聚合在一個(gè)RTP分組中。一些H．264的NAL單元的大小，如SEI NAL單元、參數集等都非常小，有些只有幾個(gè)字節，因此應該把它們組合到一個(gè)RTP包中，將會(huì )有利于減小頭標(RTP／UDP／IP)的開(kāi)銷(xiāo)。目前存在著(zhù)兩種類(lèi)型聚合分組：
NAL單元的分割
將一個(gè)NAL單元分割，使用多個(gè)RTP分組進(jìn)行傳輸。共有兩個(gè)類(lèi)型FU—A和FU—B，單元類(lèi)型中分別為28和29。根據IP層MTU的大小，對大尺寸的NALU必須要進(jìn)行分割，可以在分別在兩個(gè)層次上進(jìn)行分割：
1)視頻編碼層VCL上的分割
為了適應網(wǎng)絡(luò )MTU的尺寸，可以使用編碼器來(lái)選擇編碼Slice NALU的大小，從而使其提供較好的性能。一般是對編碼Slice的大小進(jìn)行調整，使其小于1460字節，以免IP層的分割。
2)網(wǎng)絡(luò )提取層NAL上的分割
在網(wǎng)絡(luò )提取層上對NALU的分割主要是采用分片單元方案，H．264標準中提出了分割機制，可以使NAL單元的尺寸小于1460字節。注意：此方式是針對同一個(gè)NAL單元進(jìn)行分割的，不適用于聚合分組。一個(gè)NAL單元采用分割分組后，每個(gè)RTP分組序列號依次遞增l，RTP時(shí)間戳相同且惟一。NAL單元的分割是RTP打包機制的一個(gè)重要環(huán)節，總結其分割機制主要有如下幾個(gè)特點(diǎn)：
①分割NALU時(shí)，是以RTP次序號升序進(jìn)行傳輸。在序列號不循環(huán)的前提下，屬于前一幀圖像的所有圖像片包以及A／B／C數據分割包的序列號要小于后幀圖像中的圖像片及數據分割包的序列號。
②一個(gè)符號機制來(lái)標記一個(gè)分割的NALU是第一個(gè)還是最后一個(gè)NAL單元。
3.存在另外一個(gè)符號機制用來(lái)檢測是否有丟失的分塊。
④輔助增強信息包和頭信息包可以任意時(shí)間發(fā)送。
⑤同一幀圖像中的圖像片可以以任意順序發(fā)送，但是對于低時(shí)延要求的網(wǎng)絡(luò )系統，最好是以他們原始的編碼順序來(lái)發(fā)送。
RTP包的封裝流程設計
根據H．264NAL單元的分割重組的性質(zhì)以及RTP打包規則，本文實(shí)行的對RTP打包的設計如下：
1、若接收到的NAL單元小于MAX—SIZE(此時(shí)MAX-sIZE為設定的最大傳輸單元)，則對它進(jìn)行單一打包，也就是將此NAL單元直接放進(jìn)RTP包的載荷部分，生成一個(gè)RTP包。
2、若接收到的NAL單元大于MAx—SIZE字節，則對它進(jìn)行分割，然后對分割后的NAL單元進(jìn)行步驟1方式打包。分割方案如下：
其中Nsize是分割前的NAL單元大小，N是分割后NAL單元的大小。K分割后的單元數。分割后最后一個(gè)單元的大小可能會(huì )小于N，這時(shí)必須使用RTP載荷填充是其同前面的分塊大小相同，此時(shí)RTP頭中的填充標識位值為1。
3、對SEI，參數集等小NAL單元重組，將它們合并到一個(gè)RTP包中。雖然步驟3中的重組方案可以減小IP／UDP／RTP頭部開(kāi)銷(xiāo)，但是對于包丟失率比較高的網(wǎng)絡(luò )環(huán)境，這意味著(zhù)一個(gè)RTP包的丟失可能會(huì )導致多片的丟失，往往一個(gè)片中就有一個(gè)P圖像，解碼后的視頻質(zhì)量必然會(huì )嚴重下降。因此，在丟失率的網(wǎng)絡(luò )中可以采用NAL單元的重組方案，而在高丟失率的網(wǎng)絡(luò )環(huán)境中采用NAL單元重組時(shí)要進(jìn)行有效的差錯控制．在本文中不使用重組方案。
RTP／RTCP包的封裝實(shí)現
RTP包封裝設計
RTcP包的封裝設計
RTCP報文封裝在UDP數據報中進(jìn)行傳輸，發(fā)送時(shí)使用比它所屬的RTP流的端口號大1的協(xié)議號(RTP使用偶數號，RTCP使用奇數號)。以下是RTCP頭部數據結構：
為了保證視頻流在不同傳輸環(huán)境中能有效地傳輸，單純的高壓縮率是不夠的，必須提供有效的方法，使視頻流能夠與傳輸協(xié)議無(wú)縫連接，才能應用到各種網(wǎng)絡(luò )。在以前的標準中，MPEG標準包含系統層，同時(shí)制定了H．320或H．324等獨立的標準來(lái)滿(mǎn)足視頻編碼的網(wǎng)絡(luò )適應性。然而，對于不同的通信系統來(lái)說(shuō)，只有將網(wǎng)絡(luò )適應性與視頻編碼緊密結合起來(lái)，才可能獲得最佳的傳輸性能。因此在制定新一代國際視頻編碼標準H．264／AVC時(shí)就考慮了網(wǎng)絡(luò )友好性，提出了網(wǎng)絡(luò )抽象層NAL(Network Abstraction Layer)的概念?？筛鶕?shí)現的功能不同，將編碼器分成兩層：視頻編碼層VCL(Video Coding Layer)與網(wǎng)絡(luò )抽象層NAL(Network Abstraction Layer)。 NAL層作為VCL層與傳輸層的接口，主要負責VCL數據的打包、序列和圖像的設置參數(parameter sets)傳輸、IDR(Instantaneous Decoding Refresh)等，使壓縮后的數據能在不同網(wǎng)絡(luò )傳輸。NAL層將視頻編碼數據抽象成NAL單元，根據不同的傳輸方式，進(jìn)行NAL單元封裝，H．264編碼器分層結構圖中的H．324M表示用于移動(dòng)的H．324系統。 針對分組交換網(wǎng)，如RTP／IP或TCP／IP系統等，提出包傳輸NAL單元。NAL層將編碼數據直接進(jìn)行協(xié)議封裝，而不必進(jìn)行起始碼填充。 根據打包的數據類(lèi)型不同，又可以將NAL單元分為VCL．NAL單元和非VCL．NAL單元。VCL．NAL單元包含視頻殘差編碼數據，對其解碼后能夠重建圖像。非VCL．NAL單元包含附加信息，如參數集和輔助增強信息(SEI：Supplemental Enhancement Information)等。 其中參數集包含高層的語(yǔ)法元素，這些信息對解碼而言非常重要。VCL．NAL單元解碼必須參考參數集里的語(yǔ)法元素，主要有序列參數集和圖像參數集。這些參數如果在傳輸中出錯或丟失，將直接影響其它NAL單元的解碼。通常這些參數集在VCL—NAL單元前傳遞，也可通過(guò)重復傳輸來(lái)提高其魯棒性，防止數據丟失。在一些應用中，參數集可以和VCL．NAL單元在同一信道傳輸。在一些特殊環(huán)境下，可以采用比視頻信道更可靠的傳輸機制來(lái)優(yōu)先傳遞參數集。VCL層編碼集中了近些年來(lái)視頻編碼方面的先進(jìn)技術(shù)，并將它們很好結合起來(lái)，與以前的標準相比，在同等視覺(jué)質(zhì)量的情況下可節省50％左右的碼率。 網(wǎng)絡(luò )抽象,NAL負責使用下層網(wǎng)絡(luò )的分段格式來(lái)封裝數據，包括組幀、邏輯信道的信令、定時(shí)信息的利用或發(fā)序列結束信號等。例如，NAL支持視頻在電路交換信道上的傳輸格式，支持視頻在Internet上利用RTP／UDP／IP傳輸的格式。NAL包括網(wǎng)絡(luò )提取層的頭信息、段結構信息和實(shí)際載荷信息，即上層的VCL數據。NAL提供適當的映射方法將頭部信息和數據映射到傳輸層協(xié)議上，可以減少在分組交換傳輸種組幀和重同步所需要的資源開(kāi)銷(xiāo)。為了提高在不同特性的網(wǎng)絡(luò )上定制VCL數據格式的能力，H．264的網(wǎng)絡(luò )提取層在VCL和NAL之間定義了基于分組的接口規范、打包方式等，也包括了相應的信令內容。這樣，高效率編碼任務(wù)和網(wǎng)絡(luò )友好性任務(wù)就由VCL和NAL分別完成。NAL的基本特征
根據傳輸網(wǎng)絡(luò )中數據交換方法的不同，有兩種類(lèi)型的NAL單元：針對電路交換網(wǎng)，如H．320，MPEG．2等，提出字節流格式NAL單元。NAL層將視頻編碼數據封裝成字節流格式的單元，每一個(gè)單元包含3個(gè)(或4個(gè))字節的起始前綴，值0x000001
聯(lián)系客服
