利用IP組播技術(shù)傳輸視頻信息（2）

2019-11-03 09:07:42

字體：大中小

供稿：網(wǎng)友

湖南邵陽電視臺鄧永紅

2．稀疏模式組播路由協(xié)議

　　當(dāng)組播組在網(wǎng)絡(luò)中集中分布或者網(wǎng)絡(luò)提供足夠大帶寬的情況下，密集模式組播路由協(xié)議是一個有效的方法，當(dāng)組播組成員在廣泛區(qū)域內(nèi)稀疏分布時，就需要另一種方法即稀疏模式組播路由協(xié)議將組播流量控制在連接到組播組成員的鏈路路徑上，而不會“泄漏”到不相關(guān)的鏈路路徑上，這樣既保證了數(shù)據(jù)傳輸?shù)陌踩帜軌蛴行У目刂凭W(wǎng)絡(luò)中的總流量和路由器的負(fù)載。

（1）基于核心樹的組播協(xié)議（CBT）

　　和DVMRP和MOSPF為每個“發(fā)送源、目的組”對構(gòu)建最短路徑樹不同的是，CBT協(xié)議只構(gòu)建一個樹給組中所有成員共享，這個樹也就被稱為共享樹。整個組播組的組播通信量都在這個共享樹上進(jìn)行收發(fā)而不論發(fā)送源有多少或者在什么位置。這種共享樹的使用能夠極大的減少路由器中的組播狀態(tài)信息。

　　CBT共享樹有一個核心路由器用來構(gòu)建這個樹。要加入的路由器發(fā)送加入請求給這個核心路由器。核心路由器接收到加入請求后，沿反路徑返回一個確認(rèn)，這樣就構(gòu)成了樹的一個分枝。加入請求數(shù)據(jù)包在被確認(rèn)之前不需要一直被傳送到核心路由器。如果加入請求包在到達(dá)核心路由器之前先到達(dá)樹上的某個路由器，該路由器就接收下這個請求包而不繼續(xù)向前發(fā)送并確認(rèn)這個請求包。發(fā)送請求的路由器就連接到共享樹上了。 CBT將組播流量集中在最少數(shù)量的鏈路而不是在一個基于發(fā)送源的共享樹上。集中在核心路由器上的流量可能會引起組播路由的某些問題。某些版本的CBT支持多個組播核心的使用，和單個組播核心相比多核心更能達(dá)到負(fù)載平衡。

（2）獨立組播稀疏模式協(xié)議（PIM-SM）

　　和CBT相似，PIM-SM被設(shè)計成將組播限制在需要收發(fā)的路由器上。PIM-SM圍繞一個被稱為集中點（RP：Rendezvous Point）的路由器構(gòu)建組播分布樹。這個集中點扮演著和CBT核心路由器相同的角色，接收者在集中點能查找到新的發(fā)送源。但是PIM-SM比CBT更靈活，CBT的樹通常是組播組共享樹，PIM-SM中的獨立的接收者可以選擇是構(gòu)建組共享樹還是最短路徑樹。

　　PIM-SM協(xié)議最初先為組播組構(gòu)建一個組共享樹。這個樹由連接到集中點的發(fā)送者和接收者共同構(gòu)建，就像CBT協(xié)議圍繞著核心路由器構(gòu)建的共享樹一樣。這共享樹建立以后，一個接受者（實際上是最接近這個接收者的路由器）可以選擇通過最短路徑樹改變到發(fā)送源的連接。這個操作的過程是通過向發(fā)送源發(fā)送一個PIM加入請求完成的。一旦從發(fā)送源到接收者的最短路徑建立了，通過RP的外部分枝就被修剪掉了。

三、ip組播路由中的隧道傳輸機(jī)制

　　組播中的隧道概念指將組播包再封裝成一個IP數(shù)據(jù)包在不支持組播的互聯(lián)網(wǎng)絡(luò)中路由傳輸。最有名的組播隧道的例子就是MBONE（采用DVMRP協(xié)議）。在隧道的入口處進(jìn)行數(shù)據(jù)包的封裝，在隧道的出口處則進(jìn)行拆封。在達(dá)到本地全I(xiàn)P組播配置傳輸機(jī)制上，隧道機(jī)制非常有用。

四、網(wǎng)絡(luò)多媒體的應(yīng)用要求

　　因為多媒體信號是交互的、互動的，它對網(wǎng)絡(luò)提出了以下的應(yīng)用要求：

（1）吞吐(throughtput)的要求：是指對高傳輸帶寬、大存儲緩沖帶寬的要求和對流量的控制。

（2）可靠性的要求：在這里對可靠性的要求不是重點。適當(dāng)?shù)臄?shù)據(jù)丟失不會過多影響視頻播出的實際效果。

（3）網(wǎng)絡(luò)延時要求：對網(wǎng)絡(luò)延時、抖動要求較高，因為多媒體視頻流對網(wǎng)絡(luò)傳輸延時和抖動比較敏感。如傳輸?shù)囊曨l信號與音頻信號必須同步等。

五、IP視頻應(yīng)用要求

　　因為網(wǎng)上信息的交互性和互動性，使網(wǎng)絡(luò)中的信息傳輸量日益劇增，網(wǎng)絡(luò)傳輸?shù)钠款i問題是突出的。在多媒體應(yīng)用中，視頻傳輸帶來的網(wǎng)絡(luò)帶寬問題更突出。當(dāng)n個IP地址同時接收網(wǎng)絡(luò)多媒體視頻流時，設(shè)每個視頻流所需傳輸帶寬為1.5 Mbps，按現(xiàn)在網(wǎng)絡(luò)結(jié)構(gòu)，所需帶寬為n×1.5 Mbps，同時會帶來無法忍受的網(wǎng)絡(luò)延時和抖動。現(xiàn)有的大部分網(wǎng)絡(luò)多是使用TCP／IP點到點的協(xié)議構(gòu)置，因此我們研究的重點是如何在現(xiàn)有網(wǎng)絡(luò)條件下不作過多的改變來實現(xiàn)視頻的傳輸，即IP組播解決方案要與現(xiàn)有網(wǎng)絡(luò)兼容。

　　多媒體視頻流對數(shù)據(jù)可靠性要求不高，適當(dāng)?shù)臄?shù)據(jù)丟失不會過多影響視頻播出的實際效果。雖然多媒體視頻流對網(wǎng)絡(luò)傳輸延時和抖動比較敏感，而IP組播在網(wǎng)絡(luò)中延時與抖動是很少的。所以用IP組播通信來傳輸IP視頻信號是可行的。

六、利用IP組播實現(xiàn)視頻傳輸?shù)姆椒?

　　目前在IP網(wǎng)上提供視頻服務(wù)的方式主要有兩種：

　　(1)完全利用路由器的Multicast技術(shù)，不需另加服務(wù)器轉(zhuǎn)發(fā)，但會增加路由器負(fù)擔(dān)，有“ 廣播風(fēng)暴”危險，網(wǎng)絡(luò)路由協(xié)議也需調(diào)整。

　　(2)利用軟件和服務(wù)器，在整個IP寬帶網(wǎng)上疊加一個處理媒體流的疊加網(wǎng)，由疊加網(wǎng)實現(xiàn)點到多點組播、媒體流路由和多點注入等功能。

　　現(xiàn)在采用視頻服務(wù)方式一般為方案(2)。具體地說就是：計算機(jī)配合專用軟件組成服務(wù)器，實現(xiàn)實時控制?？刂频哪康氖牵簩τ诙嗝襟w視頻服務(wù)器端，必須具有最大效率的發(fā)送機(jī)制，也就是說，系統(tǒng)能夠最大限度地在最短時間內(nèi)響應(yīng)和滿足從多媒體視頻接收端送來的視頻請求，一次完成指向需求用戶所有地址的數(shù)據(jù)發(fā)送，計算機(jī)實時控制系統(tǒng)隨時監(jiān)控視頻傳輸?shù)馁|(zhì)量，同時自動調(diào)整帶寬等。當(dāng)然傳輸方法的實現(xiàn)能與目前的網(wǎng)絡(luò)設(shè)施兼容。

　　該方案實施過程中，計算機(jī)（服務(wù)器）時刻監(jiān)控著系統(tǒng)，達(dá)到盡可能好的廣播質(zhì)量和高效率，絕不發(fā)生如“廣播風(fēng)暴”等危險。

　　用IP組播實現(xiàn)視頻傳輸?shù)南到y(tǒng)由由4部分組成：即視頻發(fā)送、視頻轉(zhuǎn)發(fā)、視頻接收、視頻控制。

　　視頻發(fā)送為預(yù)制視頻或者稱為實時視頻，它可以是獨立的計算機(jī)，也可以與第一級“視頻轉(zhuǎn)發(fā)”單元共用一臺計算機(jī)。具體地說，先將視頻按MPEG－1 編碼技術(shù)進(jìn)行實時視頻壓縮，此格式的數(shù)碼率為1.5 Mbit/s，圖像采用SIF格式（352×288），每秒30幀，2路立體聲伴音。之所以按MPEG－1 編碼技術(shù)進(jìn)行實時視頻壓縮，因為通過它壓縮后的視頻信號質(zhì)量令人滿意，而數(shù)碼率帶寬相對比較窄，有利于IP組播（當(dāng)然也可以用其他編碼技術(shù)），然后將壓縮后的信號送到視頻轉(zhuǎn)發(fā)端。信號從視頻發(fā)送連接到視頻轉(zhuǎn)發(fā)是點到點的傳輸（此單元屬于IPv4的通信方式）。

　　視頻轉(zhuǎn)發(fā)主要是將從視頻發(fā)送端發(fā)送來的視頻信號，通過IP網(wǎng)絡(luò)轉(zhuǎn)發(fā)給視頻接收端或下一級的視頻轉(zhuǎn)發(fā)端。它是IP組播傳輸視頻信號的核心，視頻信號用IP組播方式轉(zhuǎn)發(fā)，即對一組特定IP地址（同一類請求的用戶）進(jìn)行數(shù)據(jù)傳送。視頻轉(zhuǎn)發(fā)，由轉(zhuǎn)發(fā)計算機(jī)（服務(wù)器）完成。

　　視頻接收是用戶的多媒體終端。要求用戶的多媒體終端設(shè)備必須能支持IP組播。

　　視頻控制的主要功能是對轉(zhuǎn)發(fā)站點進(jìn)行控制，用來建立和管理轉(zhuǎn)發(fā)站點上的IP組播數(shù)據(jù)組的傳輸。控制系統(tǒng)要最大限度地滿足完成指向需求用戶的數(shù)據(jù)發(fā)送，同時密切注意視頻傳輸?shù)馁|(zhì)量。具體地說就是要盡可能多地為同類請求用戶發(fā)送數(shù)據(jù)，但要在允許的帶寬范圍之內(nèi)。這個帶寬是通過計算機(jī)實時控制的，計算機(jī)實時控制系統(tǒng)隨時監(jiān)控視頻傳輸?shù)馁|(zhì)量，自動調(diào)整帶寬；同時對網(wǎng)絡(luò)其他各項參數(shù)也實現(xiàn)實時監(jiān)控。可見，視頻控制實質(zhì)上也就是計算機(jī)的實時控制。計算機(jī)實時控制的好壞直接決定了IP組播的效果。

七、IP組播技術(shù)在多點視頻數(shù)據(jù)傳輸方面的優(yōu)勢

　　由于數(shù)字視頻在網(wǎng)絡(luò)傳輸時有著很大的數(shù)據(jù)吞吐量，如果使用端對端的IP單播技術(shù)進(jìn)行數(shù)字視頻的多點傳送，首先，視頻服務(wù)器必須始終保持在偵聽狀態(tài)，以了解每一個動態(tài)加入的客戶端的服務(wù)請求，而套接字的偵聽非常消耗系統(tǒng)的CPU資源，過于頻繁的偵聽容易造成系統(tǒng)的不穩(wěn)定，同時還會影響視頻傳輸?shù)膶崟r性，造成視頻在網(wǎng)絡(luò)中傳輸時出現(xiàn)頻繁抖動，最終影響視頻傳輸?shù)姆?wù)質(zhì)量（QoS）；其次，視頻服務(wù)器面對不同的客戶端的同一視頻服務(wù)請求，需要進(jìn)行重復(fù)發(fā)送，N個客戶端需要占用N倍的網(wǎng)絡(luò)帶寬資源，極大地浪費了網(wǎng)絡(luò)帶寬資源，如果控制不力，還會引起廣播風(fēng)暴，造成系統(tǒng)全面崩潰。

　　因此，在網(wǎng)絡(luò)帶寬環(huán)境能夠無限滿足視頻傳輸需要的前提下，點對點傳送和組播在性能上無本質(zhì)差異，但是，這種理想狀態(tài)基本上不會出現(xiàn)，否則除了研究網(wǎng)絡(luò)帶寬以外，其它的網(wǎng)絡(luò)技術(shù)就失去了研究的基礎(chǔ)和意義。我們設(shè)想在10BASE-T的局域網(wǎng)環(huán)境下，當(dāng)只有2個或單個客戶機(jī)提出視頻服務(wù)請求時，二者無明顯性能差異；當(dāng)有3個至5個客戶機(jī)提出視頻服務(wù)請求時，二者之間的差異就比較顯著，采用點對點傳送方式的視頻服務(wù)器明顯已經(jīng)力不從心，網(wǎng)絡(luò)丟包和延遲比較嚴(yán)重，接收端視頻明顯滯后、不連續(xù)；當(dāng)有5個以上的客戶機(jī)提出視頻服務(wù)請求時，就造成了廣播風(fēng)暴，系統(tǒng)處于崩潰的邊緣。

　　由此可見，IP組播技術(shù)在多點視頻數(shù)據(jù)傳輸方面具有很大的優(yōu)勢，當(dāng)某個IP站點向網(wǎng)絡(luò)中的多個IP站點發(fā)送同一視頻數(shù)據(jù)時，IP組播技術(shù)可以減少不必要的重疊發(fā)送，與多次點對點的單播（Unicast）相比，減輕了系統(tǒng)和網(wǎng)絡(luò)的負(fù)擔(dān)，提高了CPU資源和網(wǎng)絡(luò)帶寬的利用率，極大地改善了視頻數(shù)據(jù)傳輸?shù)膶崟r性。參與通信的各主機(jī)不論是源站點還是目的站點均使用同一程序，無客戶機(jī)和服務(wù)器之分，從而具有對等性。

　　IP組播帶入了許多新的應(yīng)用并減少了網(wǎng)絡(luò)的擁塞和服務(wù)器的負(fù)擔(dān)。目前IP組播的應(yīng)用范圍還不夠大，但它能夠降低占用帶寬，減輕服務(wù)器負(fù)荷，并能改善傳送數(shù)據(jù)的質(zhì)量，尤其適用于需要大量帶寬的多媒體應(yīng)用，如音頻、視頻等。這項新技術(shù)已成為當(dāng)前網(wǎng)絡(luò)界的熱門話題，并將從根本上改變網(wǎng)絡(luò)的體系結(jié)構(gòu)。

摘自　賽迪網(wǎng)

上一篇：ＩＰ電話的系統(tǒng)應(yīng)用

下一篇：利用IP組播技術(shù)傳輸視頻信息（1）