網(wǎng)絡(luò)消費(fèi)網(wǎng) >  5G > > 正文
基于衛(wèi)星IP網(wǎng)絡(luò)的遠(yuǎn)程視頻傳輸方案
時間:2021-12-06 06:22:04

引言TCP/IP是目前應(yīng)用最廣泛的Internet通信協(xié)議,各種通信媒介都被用來傳輸IP數(shù)據(jù),由于衛(wèi)星通信具有覆蓋而廣、組網(wǎng)靈活、建網(wǎng)快和不受地理環(huán)境限制等優(yōu)點(diǎn),因此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)場(外地實(shí)驗(yà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ā)的算法和工具,其顯著特點(diǎn)是基于內(nèi)容的編碼,更加注重多媒體系統(tǒng)的交互性、操作性和靈活性。與其他壓縮標(biāo)準(zhǔn)相比,MPEG-4具有節(jié)約存儲空間、占用網(wǎng)絡(luò)傳輸帶寬少、錯誤恢復(fù)能力強(qiáng)、圖像質(zhì)量高等優(yōu)點(diǎn)。本方案選擇的視頻壓縮算法就為MPEG-4標(biāo)準(zhǔn)。

3 視頻傳輸協(xié)議

為了保證數(shù)字視頻網(wǎng)絡(luò)傳輸?shù)膶?shí)時性和圖像的質(zhì)量,傳輸層協(xié)議的選擇是整個設(shè)計和實(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í)時數(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ī)制、報頭長且不提供時間戳及啟動速度慢等特點(diǎn),用傳統(tǒng)的TCP/IP實(shí)現(xiàn)實(shí)時傳輸視頻數(shù)據(jù)是不適合的。為了實(shí)現(xiàn)音視頻數(shù)據(jù)的實(shí)時傳輸,需要尋求其他途徑。

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

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

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

但是,由于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(實(shí)時傳輸協(xié)議)和RTCP(實(shí)時傳輸控制協(xié)議)是IETF(Internet Engineer-ing Task Force)為實(shí)現(xiàn)上述目的而定義的兩個協(xié)議。所有的實(shí)時媒體數(shù)據(jù)都使用RTP協(xié)議進(jìn)行傳輸,RTCP協(xié)議提供接收方向發(fā)送方反饋信息的功能,它們都是基于UDP的。

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

UDP是一種無連接的數(shù)據(jù)報投遞服務(wù),雖然沒有TCP那么可靠,并且無法保證實(shí)時音視頻傳輸業(yè)務(wù)的QoS(服務(wù)質(zhì)量),需要RTCP實(shí)時監(jiān)控數(shù)據(jù)傳輸和Qos,但是,由于UDP的傳輸延時低于TCP服務(wù)質(zhì)量,能與音頻和視頻流很好地匹配。因此,在實(shí)際應(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é)合實(shí)現(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)擁塞控制算法,實(shí)現(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段獨(dú)立的連接,而TCP源端認(rèn)為它仍與TCP目的端直接連接,然而實(shí)際上是由網(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)點(diǎn)是通過分割端到端的連接,可在衛(wèi)星鏈路上采用最適合于衛(wèi)星條件的協(xié)議,而在地面段繼續(xù)使用TCP。這樣,在對最終用戶保持完全透明的同時,提供了更好的性能??蛻魴C(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實(shí)現(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)用層實(shí)現(xiàn),所以不用修改操作系統(tǒng)的協(xié)議內(nèi)核,因此協(xié)議代碼容易編寫,移植性強(qiáng);應(yīng)答控制、重傳算法和流量控制等功能可以根據(jù)需要,靈活定制。可靠UDP的基本構(gòu)成如圖5所示。

5 視頻傳輸?shù)能浖?shí)現(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實(shí)現(xiàn)都支持流式套接字(stream Socket)和數(shù)據(jù)報套接字(Datagram Socket)。

流式套接字是面向連接的,采用的是TCP,提供了雙向、有序、無重復(fù)并且無報文邊界的數(shù)據(jù)流服務(wù),在這種方式下,兩個相互通信的應(yīng)用程序之間首先需要建立一種虛擬的連接。流式套接字的特點(diǎn)是:通信可靠,對資料有校驗(yàn)和重發(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ù)報套接字的另一個重要特點(diǎn)是它保留了記錄邊界,對于這一特點(diǎn),數(shù)據(jù)報套接字采用了與現(xiàn)在許多包交換網(wǎng)絡(luò)(例如以太網(wǎng)等)非常類似的模型。數(shù)據(jù)報文方式由于取消了校驗(yàn)、重發(fā)機(jī)制,能夠達(dá)到較高的通信速率,可以用做一些對數(shù)據(jù)可靠性要求不高而對數(shù)據(jù)實(shí)時性要求較高的網(wǎng)絡(luò)數(shù)據(jù)通信,如實(shí)時語音和視頻傳送、消息廣播等。

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

6 結(jié)束語

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

關(guān)鍵詞: 于衛(wèi)于衛(wèi)星衛(wèi)星ip網(wǎng)ip網(wǎng)

版權(quán)聲明:
    凡注明來網(wǎng)絡(luò)消費(fèi)網(wǎng)的作品,版權(quán)均屬網(wǎng)絡(luò)消費(fèi)網(wǎng)所有,未經(jīng)授權(quán)不得轉(zhuǎn)載、摘編或利用其它方式使用上述作品。已經(jīng)本網(wǎng)授權(quán)使用作品的,應(yīng)在授權(quán)范圍內(nèi)使用,并注明"來源:網(wǎng)絡(luò)消費(fèi)網(wǎng)"。違反上述聲明者,本網(wǎng)將追究其相關(guān)法律責(zé)任。
    除來源署名為網(wǎng)絡(luò)消費(fèi)網(wǎng)稿件外,其他所轉(zhuǎn)載內(nèi)容之原創(chuàng)性、真實(shí)性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考并自行核實(shí)。
熱文

網(wǎng)站首頁 |網(wǎng)站簡介 | 關(guān)于我們 | 廣告業(yè)務(wù) | 投稿信箱
 

Copyright © 2000-2020 m.netfop.cn All Rights Reserved.
 

中國網(wǎng)絡(luò)消費(fèi)網(wǎng) 版權(quán)所有 未經(jīng)書面授權(quán) 不得復(fù)制或建立鏡像
 

聯(lián)系郵箱:920 891 263@qq.com

備案號:京ICP備2022016840號-15

營業(yè)執(zhí)照公示信息