• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
    • 軟件測試技術
    • 軟件測試博客
    • 軟件測試視頻
    • 開源軟件測試技術
    • 軟件測試論壇
    • 軟件測試沙龍
    • 軟件測試資料下載
    • 軟件測試雜志
    • 軟件測試人才招聘
      暫時沒有公告

    字號: | 推薦給好友 上一篇 | 下一篇

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

    發布: 2007-6-23 21:39 | 作者:   | 來源:   | 查看: 33次 | 進入軟件測試論壇討論

    領測軟件測試網

       
       2.稀疏模式組播路由協議
       當組播組在網絡中集中分布或者網絡提供足夠大帶寬的情況下,密集模式組播路由協議是一個有效的方法,當組播組成員在廣泛區域內稀疏分布時,就需要另一種方法即稀疏模式組播路由協議將組播流量控制在連接到組播組成員的鏈路路徑上,

    而不會“泄漏”到不相關的鏈路路徑上,這樣既保證了數據傳輸的安全,又能夠有效的控制網絡中的總流量和路由器的負載。
      
       (1)基于核心樹的組播協議 (CBT)
       和DVMRP和MOSPF為每個“發送源、目的組”對構建最短路徑樹不同的是,CBT協議只構建一個樹給組中所有成員共享,這個樹也就被稱為共享樹。整個組播組的組播通信量都在這個共享樹上進行收發而不論發送源有多少或者在什么位置。這種共享樹的使用能夠極大的減少路由器中的組播狀態信息。
      
       CBT共享樹有一個核心路由器用來構建這個樹。要加入的路由器發送加入請求給這個核心路由器。核心路由器接收到加入請求后,沿反路徑返回一個確認,這樣就構成了樹的一個分枝。加入請求數據包在被確認之前不需要一直被傳送到核心路由器。如果加入請求包在到達核心路由器之前先到達樹上的某個路由器,該路由器就接收下這個請求包而不繼續向前發送并確認這個請求包。發送請求的路由器就連接到共享樹上了。 CBT將組播流量集中在最少數量的鏈路而不是在一個基于發送源的共享樹上。集中在核心路由器上的流量可能會引起組播路由的某些問題。某些版本的CBT支持多個組播核心的使用,和單個組播核心相比多核心更能達到負載平衡。
      
       (2)獨立組播稀疏模式協議 (PIM-SM)
       和CBT相似,PIM-SM被設計成將組播限制在需要收發的路由器上。PIM-SM圍繞一個被稱為集中點(RP:Rendezvous Point)的路由器構建組播分布樹。這個集中點扮演著和CBT核心路由器相同的角色,接收者在集中點能查找到新的發送源。但是PIM-SM比CBT更靈活,CBT的樹通常是組播組共享樹,PIM-SM中的獨立的接收者可以選擇是構建組共享樹還是最短路徑樹。
      
       PIM-SM協議最初先為組播組構建一個組共享樹。這個樹由連接到集中點的發送者和接收者共同構建,就像CBT協議圍繞著核心路由器構建的共享樹一樣。這共享樹建立以后,一個接受者(實際上是最接近這個接收者的路由器)可以選擇通過最短路徑樹改變到發送源的連接。這個操作的過程是通過向發送源發送一個PIM加入請求完成的。一旦從發送源到接收者的最短路徑建立了,通過RP的外部分枝就被修剪掉了。
      
       三、IP組播路由中的隧道傳輸機制
       組播中的隧道概念指將組播包再封裝成一個IP數據包在不支持組播的互聯網絡中路由傳輸。最有名的組播隧道的例子就是MBONE(采用DVMRP協議)。在隧道的入口處進行數據包的封裝,在隧道的出口處則進行拆封。在達到本地全IP組播配置傳輸機制上,隧道機制非常有用。
      
       四、網絡多媒體的應用要求
       因為多媒體信號是交互的、互動的,它對網絡提出了以下的應用要求:
       (1) 吞吐(throughtput)的要求:是指對高傳輸帶寬、大存儲緩沖帶寬的要求和對流量的控制。
       (2) 可靠性的要求:在這里對可靠性的要求不是重點。適當的數據丟失不會過多影響視頻 播出的實際效果。
       (3) 網絡延時要求:對網絡延時、抖動要求較高,因為多媒體視頻流對網絡傳輸延時和抖動比較敏感。如傳輸的視頻信號與音頻信號必須同步等。
      
       五、IP視頻應用要求
       因為網上信息的交互性和互動性,使網絡中的信息傳輸量日益劇增,網絡傳輸的瓶頸問題是突出的。在多媒體應用中,視頻傳輸帶來的網絡帶寬問題更突出。當n個IP地址同時接收網絡多媒體視頻流時,設每個視頻流所需傳輸帶寬為1.5 Mbps,按現在網絡結構,所需帶寬為n×1.5 Mbps,同時會帶來無法忍受的網絡延時和抖動,F有的大部分網絡多是使用TCP/IP點到點的協議構置,因此我們研究的重點是如何在現有網絡條件下不作過多的改變來實現視頻的傳輸,即IP組播解決方案要與現有網絡兼容。
      
       多媒體視頻流對數據可靠性要求不高,適當的數據丟失不會過多影響視頻播出的實際效果。雖然多媒體視頻流對網絡傳輸延時和抖動比較敏感,而IP組播在網絡中延時與抖動是很少的。所以用IP組播通信來傳輸IP視頻信號是可行的。
      
       六、利用IP組播實現視頻傳輸的方法
       目前在IP網上提供視頻服務的方式主要有兩種:
       (1)完全利用路由器的Multicast技術,不需另加服務器轉發,但會增加路由器負擔,有“ 廣播風暴”危險,網絡路由協議也需調整。
       (2)利用軟件和服務器,在整個IP寬帶網上疊加一個處理媒體流的疊加網,由疊加網實現點到多點組播、媒體流路由和多點注入等功能。
      
       現在采用視頻服務方式一般為方案(2)。具體地說就是:計算機配合專用軟件組成服務器,實現實時控制?刂频哪康氖牵簩τ诙嗝襟w視頻服務器端,必須具有最大效率的發送機制,也就是說,系統能夠最大限度地在最短時間內響應和滿足從多媒體視頻接收端送來的視頻請求,一次完成指向需求用戶所有地址的數據發送,計算機實時控制系統隨時監控視頻傳輸的質量,同時自動調整帶寬等。當然傳輸方法的實現能與目前的網絡設施兼容。
      
       該方案實施過程中,計算機(服務器)時刻監控著系統,達到盡可能好的廣播質量和高效率,絕不發生如“廣播風暴”等危險。
      
       用IP組播實現視頻傳輸的系統由由4部分組成:即視頻發送、視頻轉發、視頻接收、視頻控制。
      
       視頻發送為預制視頻或者稱為實時視頻,它可以是獨立的計算機,也可以與第一級“視頻轉發”單元共用一臺計算機。具體地說,先將視頻按MPEG-1 編碼技術進行實時視頻壓縮,此格式的數碼率為1.5 Mbit/s,圖像采用SIF格式(352×288),每秒30幀,2路立體聲伴音。之所以按MPEG-1 編碼技術進行實時視頻壓縮,因為通過它壓縮后的視頻信號質量令人滿意,而數碼率帶寬相對比較窄,有利于IP組播(當然也可以用其他編碼技術),然后將壓縮后的信號送到視頻轉發端。信號從視頻發送連接到視頻轉發是點到點的傳輸(此單元屬于IPv4的通信方式)。
      
       視頻轉發主要是將從視頻發送端發送來的視頻信號,通過IP網絡轉發給視頻接收端或下一級的視頻轉發端。它是IP組播傳輸視頻信號的核心,視頻信號用IP組播方式轉發,即對一組特定IP地址(同一類請求的用戶)進行數據傳送。視頻轉發,由轉發計算機(服務器)完成。
      
       視頻接收是用戶的多媒體終端。要求用戶的多媒體終端設備必須能支持IP組播。
      
       視頻控制的主要功能是對轉發站點進行控制,用來建立和管理轉發站點上的IP組播數據組的傳輸?刂葡到y要最大限度地滿足完成指向需求用戶的數據發送,同時密切注意視頻 傳輸的質量。具體地說就是要盡可能多地為同類請求用戶發送數據,但要在允許的帶寬范圍之內。這個帶寬是通過計算機實時控制的,計算機實時控制系統隨時監控視頻傳輸的質量,自動調整帶寬;同時對網絡其他各項參數也實現實時監控?梢,視頻控制實質上也就是計算機的實時控制。計算機實時控制的好壞直接決定了IP組播的效果。
      
       七、IP組播技術在多點視頻數據傳輸方面的優勢
       由于數字視頻在網絡傳輸時有著很大的數據吞吐量,如果使用端對端的IP單播技術進行數字視頻的多點傳送,首先,視頻服務器必須始終保持在偵聽狀態,以了解每一個動態加入的客戶端的服務請求,而套接字的偵聽非常消耗系統的CPU資源,過于頻繁的偵聽容易造成系統的不穩定,同時還會影響視頻傳輸的實時性,造成視頻在網絡中傳輸時出現頻繁抖動,最終影響視頻傳輸的服務質量(QoS);其次,視頻服務器面對不同的客戶端的同一視頻服務請求,需要進行重復發送,N個客戶端需要占用N倍的網絡帶寬資源,極大地浪費了網絡帶寬資源,如果控制不力,還會引起廣播風暴,造成系統全面崩潰。
      
       因此,在網絡帶寬環境能夠無限滿足視頻傳輸需要的前提下,點對點傳送和組播在性能上無本質差異,但是,這種理想狀態基本上不會出現,否則除了研究網絡帶寬以外,其它的網絡技術就失去了研究的基礎和意義。我們設想在10BASE-T的局域網環境下,當只有2個或單個客戶機提出視頻服務請求時,二者無明顯性能差異;當有3個至5個客戶機提出視頻服務請求時,二者之間的差異就比較顯著,采用點對點傳送方式的視頻服務器明顯已經力不從心,網絡丟包和延遲比較嚴重,接收端視頻明顯滯后、不連續;當有5個以上的客戶機提出視頻服務請求時,就造成了廣播風暴,系統處于崩潰的邊緣。
      
       由此可見,IP組播技術在多點視頻數據傳輸方面具有很大的優勢,當某個IP站點向網絡中的多個IP站點發送同一視頻數據時,IP組播技術可以減少不必要的重疊發送,與多次點對點的單播(Unicast)相比,減輕了系統和網絡的負擔,提高了CPU資源和網絡帶寬的利用率,極大地改善了視頻數據傳輸的實時性。參與通信的各主機不論是源站點還是目的站點均使用同一程序,無客戶機和服務器之分,從而具有對等性。
      
       IP組播帶入了許多新的應用并減少了網絡的擁塞和服務器的負擔。目前IP組播的應用范圍還不夠大,但它能夠降低占用帶寬,減輕服務器負荷,并能改善傳送數據的質量,尤其適用于需要大量帶寬的多媒體應用,如音頻、視頻等。這項新技術已成為當前網絡界的熱門話題,并將從根本上改變網絡的體系結構。

    延伸閱讀

    文章來源于領測軟件測試網 http://www.kjueaiud.com/


    關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
    版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
    北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
    技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

    軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>