利用衛(wèi)星IP網(wǎng)絡(luò)實現(xiàn)外地到演示中心的遠(yuǎn)程視頻傳

引言

TCP／IP是目前應(yīng)用最廣泛的Internet通信協(xié)議，各種通信媒介都被用來傳輸IP數(shù)據(jù)，由于衛(wèi)星通信具有覆蓋而廣、組網(wǎng)靈活、建網(wǎng)快和不受地理環(huán)境限制等優(yōu)點，因此Internet與衛(wèi)星的聯(lián)姻成為必然。隨著Internet的迅猛發(fā)展和多媒體通信技術(shù)的進(jìn)步，網(wǎng)絡(luò)業(yè)務(wù)不僅支持文字、語音等慕本業(yè)務(wù)，靜態(tài)圖像、動態(tài)圖像、音頻、視頻復(fù)合等多媒體業(yè)務(wù)的需求也逐漸增多。IP技術(shù)是寬帶網(wǎng)絡(luò)的骨干技術(shù)，基于IP的開發(fā)具有普遍性。而且通過協(xié)議的增強(qiáng)，IP網(wǎng)絡(luò)適合作為廣泛的多媒體通信介質(zhì)。

1 系統(tǒng)構(gòu)成

整個傳輸系統(tǒng)由遠(yuǎn)程現(xiàn)場(外地實驗場地等)和視頻演示中心組成，遠(yuǎn)程現(xiàn)場的圖像通過寬帶衛(wèi)星IP網(wǎng)絡(luò)傳回視頻演示中心進(jìn)行顯示，可供監(jiān)控及觀看。其中衛(wèi)星IP網(wǎng)絡(luò)可提供單向的2 Mbit／s高速信道，雙向9.6 khit／s低速信道。系統(tǒng)結(jié)構(gòu)如圖1所示。

2 視頻壓縮算法的選擇

由攝像頭或其他視頻采集設(shè)備采到的視頻原始信息帶寬很大，一般的傳輸信道很難滿足要求，必須對視頻信息進(jìn)行壓縮編碼。對視頻數(shù)據(jù)進(jìn)行壓縮算法有很多，有的著重速度，有的著重壓縮比。常用的視頻壓縮標(biāo)準(zhǔn)有H.263，M-JPEG，MPEG-1，MPEG-4等。MPEG-4是MPEG(活動圖像專家組)在1999年制定的一個國際標(biāo)準(zhǔn)，名稱為“甚低速率視聽編碼”，是針對低速率(小于640 kbit／s)下的視頻、音頻編碼和交互播放開發(fā)的算法和工具，其顯著特點是基于內(nèi)容的編碼，更加注重多媒體系統(tǒng)的交互性、操作性和靈活性。與其他壓縮標(biāo)準(zhǔn)相比，MPEG-4具有節(jié)約存儲空間、占用網(wǎng)絡(luò)傳輸帶寬少、錯誤恢復(fù)能力強(qiáng)、圖像質(zhì)量高等優(yōu)點。本方案選擇的視頻壓縮算法就為MPEG-4標(biāo)準(zhǔn)。

3 視頻傳輸協(xié)議

為了保證數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)膶崟r性和圖像的質(zhì)量，傳輸層協(xié)議的選擇是整個設(shè)計和實現(xiàn)的關(guān)鍵。Internet在IP層上使用兩種傳輸協(xié)議：一種是TCP(傳輸控制協(xié)議)，它是面向連接的網(wǎng)絡(luò)協(xié)議；另一種是UDP(用戶數(shù)據(jù)報協(xié)議)，它是無連接的網(wǎng)絡(luò)協(xié)議。

TCP／IP最初是為提供非實時數(shù)據(jù)業(yè)務(wù)而設(shè)計的。IP負(fù)責(zé)主機(jī)之間的數(shù)據(jù)傳輸，不進(jìn)行檢錯和糾錯。因此，經(jīng)常發(fā)生數(shù)據(jù)丟失或失序現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，人們將TCP用于IP數(shù)據(jù)的傳輸，以提高接收端的檢錯和糾錯能力。當(dāng)檢測到數(shù)據(jù)包丟失或錯誤時，就會要求發(fā)送端重新發(fā)送，這樣就不可避免地引起了傳輸延時和耗用網(wǎng)絡(luò)的帶寬。鑒于TCP本身的重傳機(jī)制、擁塞控制機(jī)制、報頭長且不提供時間戳及啟動速度慢等特點，用傳統(tǒng)的TCP／IP實現(xiàn)實時傳輸視頻數(shù)據(jù)是不適合的。為了實現(xiàn)音視頻數(shù)據(jù)的實時傳輸，需要尋求其他途徑。

本方案的視頻網(wǎng)絡(luò)傳輸協(xié)議結(jié)構(gòu)如圖2所示。

從圖2可以看出，整個系統(tǒng)的通信功能建立在IP協(xié)議上。網(wǎng)絡(luò)層使用IP，為了實現(xiàn)通信，在網(wǎng)絡(luò)層之上分為連接控制和媒體數(shù)據(jù)傳輸兩大部分。為了使通信過程的建立更加可靠，連接控制部分使用TCP提供可靠的分組遞交，而媒體傳輸部分則使用UDP協(xié)議。

媒體數(shù)據(jù)傳輸部分使用UDP的理由是：TCP不適合網(wǎng)絡(luò)多媒體的實時傳輸；使用UDP不必與對方建立連接，因此在多點通信時不必管理過多的連接。

但是，由于UDP沒有差錯控制，屬于不可靠的分組遞交，這就意味著可能會丟包，由于雙方?jīng)]有建立連接，所以發(fā)放無法知道對方的接收情況?？赡苡捎诎l(fā)送過快，導(dǎo)致網(wǎng)絡(luò)堵塞，因而大量的數(shù)據(jù)包被延誤或丟失，或者對方根本就沒有收到任何數(shù)據(jù)包。為了避免這種情況，最好對方能夠向發(fā)送方發(fā)送一個反饋信息以報告其接收情況，必要時發(fā)送方要調(diào)整其數(shù)據(jù)處理方法或發(fā)送速率。例如，當(dāng)發(fā)送方認(rèn)為數(shù)據(jù)發(fā)送得太快，它可以調(diào)整圖像壓縮器的參數(shù)，以較大的量化誤差來降低圖像數(shù)據(jù)的速度。RTP(實時傳輸協(xié)議)和RTCP(實時傳輸控制協(xié)議)是IETF(Internet Engineer-ing Task Force)為實現(xiàn)上述目的而定義的兩個協(xié)議。所有的實時媒體數(shù)據(jù)都使用RTP協(xié)議進(jìn)行傳輸，RTCP協(xié)議提供接收方向發(fā)送方反饋信息的功能，它們都是基于UDP的。

RTP／RTCP是一種應(yīng)用型的傳輸層協(xié)議，并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制。它是由IETF為音視頻的實時傳輸而設(shè)計的傳輸協(xié)議。RTP位于UDP之上，在功能上獨立于下面的傳輸層(UDP)和網(wǎng)絡(luò)層，但不能單獨作為一個層次存在，通常是利用低層的UDP對實時音視頻數(shù)據(jù)進(jìn)行多播或單播，從而實現(xiàn)多點或單點音視頻數(shù)據(jù)的傳輸。一般是在UDP數(shù)據(jù)包之前建立一個RTP包頭，其中包含一些保證數(shù)據(jù)實時連續(xù)性的信息(如序列號、時間戳等)；提供時間信息和流同步。RTP本身不提供流量控制和擁塞控制功能。它靠一個專門的RTCP來實現(xiàn)。RTCP周期性地統(tǒng)計數(shù)據(jù)包傳輸時的丟失情況等信息，服務(wù)器根據(jù)這些反饋信息來制定流量控制的策略。改變傳輸碼率甚至負(fù)載類型，大大提高了實時數(shù)據(jù)的傳輸性能。

UDP是一種無連接的數(shù)據(jù)報投遞服務(wù)，雖然沒有TCP那么可靠，并且無法保證實時音視頻傳輸業(yè)務(wù)的QoS(服務(wù)質(zhì)量)，需要RTCP實時監(jiān)控數(shù)據(jù)傳輸和Qos，但是，由于UDP的傳輸延時低于TCP服務(wù)質(zhì)量，能與音頻和視頻流很好地匹配。因此，在實際應(yīng)用中，RTP／RTCP／UDP用于音視頻媒體，而TCP用于數(shù)據(jù)和控制信令的傳輸。

4 衛(wèi)星IP網(wǎng)絡(luò)的構(gòu)成

利用TCP／IP協(xié)議，通過衛(wèi)星網(wǎng)與IP網(wǎng)的結(jié)合實現(xiàn)數(shù)據(jù)傳輸，已成為衛(wèi)星通信中的一個重要研究領(lǐng)域。但由于衛(wèi)星網(wǎng)絡(luò)固有的一些特性，如長延時、高誤碼率、網(wǎng)絡(luò)不對稱性，都影響了TCP在高速數(shù)據(jù)傳輸中的性能。為提高衛(wèi)星TCP的性能，人們提出了許多有效的解決方案，這些方案針對長延時、高誤碼率、網(wǎng)絡(luò)不對稱性帶來的不同影響，通過修改流量控制窗口以及改進(jìn)擁塞控制算法，實現(xiàn)了衛(wèi)星TCP的高效傳輸。

衛(wèi)星IP傳輸比較典型的一種解決方案是協(xié)議網(wǎng)關(guān)。協(xié)議網(wǎng)關(guān)的工作原理是采用TCP欺騙技術(shù)與TCP分段技術(shù)，分割端到端的TCP連接，用最適合衛(wèi)星環(huán)境的一種協(xié)議取代衛(wèi)星鏈路上的TCP。見圖3。

網(wǎng)關(guān)1和網(wǎng)關(guān)2把端到端的TCP連接分為3段獨立的連接，而TCP源端認(rèn)為它仍與TCP目的端直接連接，然而實際上是由網(wǎng)關(guān)完成了協(xié)議轉(zhuǎn)換。在圖3中，TCP Reno指擴(kuò)展TCP，它包括慢啟動、擁塞避免、快速重發(fā)、快速恢復(fù)、支持大窗口及延遲的ACK(確認(rèn))。在網(wǎng)關(guān)中，數(shù)據(jù)從TCP Reno轉(zhuǎn)換成DLP(數(shù)據(jù)鏈路協(xié)議)或是從DLP轉(zhuǎn)換成TCP Reno。這種結(jié)構(gòu)的主要優(yōu)點是通過分割端到端的連接，可在衛(wèi)星鏈路上采用最適合于衛(wèi)星條件的協(xié)議，而在地面段繼續(xù)使用TCP。這樣，在對最終用戶保持完全透明的同時，提供了更好的性能。客戶機(jī)或服務(wù)器不需做任何修改，所有的應(yīng)用也無需改變而繼續(xù)有效。TCP避免擁塞控制機(jī)制在地面連接中仍然有效，以保護(hù)Internet的穩(wěn)定性。因此，目前新推出的衛(wèi)星Internet系統(tǒng)幾乎都是基于協(xié)議網(wǎng)關(guān)技術(shù)的。切斷TCP連接帶來的不利足TCP層端到端的語法被破壞，網(wǎng)關(guān)處需設(shè)置大容量的緩存以保存未被接收方確認(rèn)的數(shù)據(jù)，而且由于對每個TCP連接都要進(jìn)行控制，因此，網(wǎng)關(guān)需要強(qiáng)大的處理能力。

網(wǎng)關(guān)協(xié)議轉(zhuǎn)換具體協(xié)議框架如圖4所示。

系統(tǒng)中通信雙方采用非透明傳輸方式，網(wǎng)關(guān)將TCP連接分段。站A和站B之間要通信的網(wǎng)絡(luò)終端之間不直接建立TCP連接，而是與本地的衛(wèi)星網(wǎng)關(guān)建立TCP連接，發(fā)送端(站A的網(wǎng)絡(luò)終端)先將數(shù)據(jù)發(fā)到本地的衛(wèi)星網(wǎng)關(guān)，本地衛(wèi)星網(wǎng)關(guān)在以特定的協(xié)議將數(shù)據(jù)傳遞到站B的衛(wèi)星網(wǎng)關(guān)，此衛(wèi)星網(wǎng)關(guān)再將數(shù)據(jù)通過TCP發(fā)送給接收終端。通信過程包括以下幾個階段：建立TCP連接、接收TCP數(shù)據(jù)、數(shù)據(jù)的緩存、數(shù)據(jù)的拆分、可靠UDP傳輸、數(shù)據(jù)的組裝、發(fā)送TCP數(shù)據(jù)、發(fā)送重傳請求和重傳數(shù)據(jù)。

傳輸過程中，衛(wèi)星鏈路中信息的傳遞通過可靠UDP實現(xiàn)，它是在標(biāo)準(zhǔn)UDP基礎(chǔ)上，通過網(wǎng)關(guān)的協(xié)議轉(zhuǎn)換模塊為其增加應(yīng)答控制、重傳算法和流量控制等功能，在保證網(wǎng)絡(luò)數(shù)據(jù)高效傳輸?shù)耐瑫r保證數(shù)據(jù)正確性的?？煽縐DP在應(yīng)用層實現(xiàn)，所以不用修改操作系統(tǒng)的協(xié)議內(nèi)核，因此協(xié)議代碼容易編寫，移植性強(qiáng)；應(yīng)答控制、重傳算法和流量控制等功能可以根據(jù)需要，靈活定制?？煽縐DP的基本構(gòu)成如圖5所示。

5 視頻傳輸?shù)能浖崿F(xiàn)

Winsock(Windows Sockets)是微軟WOSA(窗口系統(tǒng)結(jié)構(gòu))的一部分，基于UNIX系統(tǒng)上BSD(BerkeleySoftware Distribution)版本的套接字，并且為Windows系統(tǒng)進(jìn)行了專門的擴(kuò)展，是目前Windows環(huán)境下應(yīng)用最廣泛、開放式、支持多種協(xié)議的網(wǎng)絡(luò)編程接口。

最初，WINSOCK1.1版是專門為Internet設(shè)計的，現(xiàn)在的WINSOCK 2.x版已經(jīng)不再局限于Internet和TCP／IP，它通過提供擴(kuò)展的SPI編程接口，把自己的應(yīng)用范圍擴(kuò)大到現(xiàn)存的和正在出現(xiàn)的各種網(wǎng)絡(luò)和協(xié)議，其中包括PSTN(公共電話交換網(wǎng))、ISDN(綜合業(yè)務(wù)數(shù)字網(wǎng))、無線網(wǎng)、所有的局域網(wǎng)協(xié)議以及ATM(異步傳輸模式)等，并且允許應(yīng)用程序?qū)λ⑦B接的可靠性、冗余度和帶寬進(jìn)行控制。Windows Sockets規(guī)范、定義并記錄了如何使用WINSOCK API與Internet協(xié)議族(IPS，包含IP、ICMP、TCP和UDP等4種不同的協(xié)議)連接。尤其要指出的是，所有Windows Sockets實現(xiàn)都支持流式套接字(stream Socket)和數(shù)據(jù)報套接字(Datagram Socket)。

流式套接字是面向連接的，采用的是TCP，提供了雙向、有序、無重復(fù)并且無報文邊界的數(shù)據(jù)流服務(wù)，在這種方式下，兩個相互通信的應(yīng)用程序之間首先需要建立一種虛擬的連接。流式套接字的特點是：通信可靠，對資料有校驗和重發(fā)機(jī)制，通常用于數(shù)據(jù)文件的傳輸，如ftp、telnet等，適合于大量資料的傳輸。

數(shù)據(jù)報套接字是面向無連接的，采用的是UDP，建立在IP之上，提供無連接的數(shù)據(jù)報傳輸，支持雙向的數(shù)據(jù)流，但并不保證數(shù)據(jù)的可靠、有序和無重復(fù)。也就是說，在一個從數(shù)據(jù)報套接字接收信息的進(jìn)程中有可能發(fā)現(xiàn)信息重復(fù)了，或者與發(fā)出時的數(shù)據(jù)順序有所不同。數(shù)據(jù)報套接字的另一個重要特點是它保留了記錄邊界，對于這一特點，數(shù)據(jù)報套接字采用了與現(xiàn)在許多包交換網(wǎng)絡(luò)(例如以太網(wǎng)等)非常類似的模型。數(shù)據(jù)報文方式由于取消了校驗、重發(fā)機(jī)制，能夠達(dá)到較高的通信速率，可以用做一些對數(shù)據(jù)可靠性要求不高而對數(shù)據(jù)實時性要求較高的網(wǎng)絡(luò)數(shù)據(jù)通信，如實時語音和視頻傳送、消息廣播等。

本方案中的視頻數(shù)據(jù)接收播放模塊需建立控制通道和數(shù)據(jù)通道兩個通信通道?？刂仆ǖ烙脕碓诜?wù)端和客戶端之間建立會話，包括發(fā)送一些數(shù)據(jù)請求和確認(rèn)控制等信息。控制信道采用可靠性較高的TCP，可用流式套接字來實現(xiàn)。數(shù)據(jù)通道用來傳輸視頻圖像數(shù)據(jù)，選用UDP，可用數(shù)據(jù)報套接字來實現(xiàn)。選用Win-dows線程技術(shù)實現(xiàn)接收端播放視頻信息。視頻流的解碼和播放通過調(diào)用DirectShow SDK實現(xiàn)。

6 結(jié)束語

本方案利用衛(wèi)星IP網(wǎng)絡(luò)實現(xiàn)了外地到演示中心的遠(yuǎn)程視頻傳輸，實驗結(jié)果顯示，視頻傳輸流暢，圖像清晰，滿足了實際需要。