《電子技術(shù)應(yīng)用》
您所在的位置:首頁(yè) > 其他 > 設(shè)計(jì)應(yīng)用 > 基于多播的分布式視頻會(huì)議的研究
基于多播的分布式視頻會(huì)議的研究
來(lái)源:微型機(jī)與應(yīng)用2013年第7期
郭 琳1,楊曉軍2
(1.昆明理工大學(xué) 津橋?qū)W院 計(jì)算機(jī)系,云南 昆明 650021; 2.昆明昆船物流信息產(chǎn)業(yè)有限公司
摘要: 基于JMF和多播技術(shù)實(shí)現(xiàn)了一個(gè)沒(méi)有多點(diǎn)控制單元的分布式視頻會(huì)議。視音頻的壓縮由各個(gè)客戶(hù)端來(lái)處理,并引入了視頻會(huì)議的自由模式和主講模式,兩種模式之間的切換由各個(gè)對(duì)等點(diǎn)之間協(xié)調(diào)同步完成。在沒(méi)有多點(diǎn)控制單元的情況下,依然保證視頻會(huì)議的正常進(jìn)行。會(huì)議中的各個(gè)對(duì)等點(diǎn)采用多播技術(shù)傳輸視音頻流,以盡量減少對(duì)帶寬的占用。
關(guān)鍵詞: 多播 分布式 JMF 同步
Abstract:
Key words :

摘  要: 基于JMF多播技術(shù)實(shí)現(xiàn)了一個(gè)沒(méi)有多點(diǎn)控制單元的分布式視頻會(huì)議。視音頻的壓縮由各個(gè)客戶(hù)端來(lái)處理,并引入了視頻會(huì)議的自由模式和主講模式,兩種模式之間的切換由各個(gè)對(duì)等點(diǎn)之間協(xié)調(diào)同步完成。在沒(méi)有多點(diǎn)控制單元的情況下,依然保證視頻會(huì)議的正常進(jìn)行。會(huì)議中的各個(gè)對(duì)等點(diǎn)采用多播技術(shù)傳輸視音頻流,以盡量減少對(duì)帶寬的占用。
關(guān)鍵詞: 多播;分布式;JMF;同步

1 視頻會(huì)議的發(fā)展歷程
    視頻會(huì)議在電信行業(yè)己經(jīng)存在了30多年,但在上世紀(jì)90年代以前,這些系統(tǒng)一直使用專(zhuān)用的編解碼硬件和軟件,視頻會(huì)議都需要昂貴的設(shè)備和專(zhuān)線(xiàn)互連才能實(shí)現(xiàn)。
    而近幾年來(lái),隨著國(guó)內(nèi)外大型網(wǎng)絡(luò)運(yùn)營(yíng)商對(duì)網(wǎng)絡(luò)環(huán)境的建設(shè)和改造,以及ISDN、DDN、VPN、xDSL、ATM等技術(shù)的應(yīng)用和推廣,視音頻編解碼技術(shù)趨于成熟,圖像傳輸質(zhì)量大為提高,視頻會(huì)議系統(tǒng)價(jià)格開(kāi)始下調(diào),視頻會(huì)議系統(tǒng)的使用環(huán)境變得越來(lái)越好,因此無(wú)論是通信行業(yè)還是IT行業(yè),都對(duì)視頻會(huì)議領(lǐng)域重新進(jìn)行關(guān)注。
    目前視頻音頻數(shù)據(jù)的編碼解碼技術(shù)也趨于成熟,計(jì)算機(jī)處理速度和附屬板卡的處理速度也大幅度增強(qiáng),很多以前需要專(zhuān)門(mén)的硬件設(shè)備MCU來(lái)進(jìn)行的音視頻編碼解碼操作,現(xiàn)在都可以在普通的計(jì)算機(jī)上進(jìn)行,寬帶的接入愈來(lái)愈廉價(jià)、普及,成本比硬件系統(tǒng)低很多,為了使視頻會(huì)議“大眾化”,利用其現(xiàn)有的計(jì)算機(jī)和網(wǎng)絡(luò)系統(tǒng),實(shí)現(xiàn)視頻會(huì)議的應(yīng)用,視頻會(huì)議由“硬”到“軟”是必然的趨勢(shì)。就市場(chǎng)來(lái)看,據(jù)國(guó)際著名的通信研究機(jī)構(gòu)Wainhouse Research近期預(yù)測(cè),未來(lái)全球硬件視頻會(huì)議設(shè)備銷(xiāo)售的增長(zhǎng)約為18%,而軟件視頻會(huì)議的增長(zhǎng)則將達(dá)到144%。
2 多播技術(shù)的應(yīng)用
    視頻會(huì)議可以采取單播、多播和廣播中任一技術(shù)來(lái)實(shí)現(xiàn)。單播即點(diǎn)對(duì)點(diǎn)的通信,需建立連接,雖然能保證數(shù)據(jù)不丟失,但很占用資源,例如,為了使視頻會(huì)議系統(tǒng)顯現(xiàn)的圖像是動(dòng)態(tài)的、連續(xù)的,一個(gè)視頻信息流就需要占用1.5 Mb/s的帶寬[1],在一個(gè)單播(unicast)環(huán)境里,若有N個(gè)用戶(hù)接收,視頻服務(wù)器依次送出N個(gè)信息流,共需要N×1.5 Mb/s的帶寬;如果服務(wù)器處于10 M的以太網(wǎng)內(nèi),6~7個(gè)信息流就占滿(mǎn)了帶寬;而在一個(gè)多播(multicast)環(huán)境里,不論網(wǎng)絡(luò)中的用戶(hù)數(shù)目有多少,服務(wù)器只發(fā)出的一個(gè)視頻流,僅需1.5 Mb/s的帶寬即可。
    廣播技術(shù)在發(fā)送給參與視頻會(huì)議用戶(hù)的同時(shí)也會(huì)把視頻流發(fā)送給那些對(duì)此不關(guān)心的用戶(hù),尤其視頻音頻的數(shù)據(jù)都比較大,這樣會(huì)導(dǎo)致Internet面臨崩潰,而多播通信的目標(biāo)性更強(qiáng)并且比廣播通信窄[1]。例如,如圖1所示,若采用多播發(fā)送,則發(fā)送端A的視頻流只會(huì)在路由器1復(fù)制一次,并發(fā)送給路由器2,路由器2再?gòu)?fù)制一次發(fā)給接收端B;如用廣播技術(shù),則發(fā)送端A的視頻流到達(dá)路由器1時(shí),路由器1將復(fù)制出三個(gè)視頻流分別發(fā)給與它相連的3個(gè)路由器,這3個(gè)路由器又將收到的視頻流廣播到其他網(wǎng)絡(luò),而不管這些客戶(hù)是否有需要。因此本系統(tǒng)采用多播技術(shù)來(lái)實(shí)現(xiàn)流媒體的傳輸。

3 分布式視頻會(huì)議及JMF
    分布式視頻會(huì)議是傳統(tǒng)的會(huì)議系統(tǒng)(如:H.320視頻會(huì)議系統(tǒng))所沒(méi)有的,又與點(diǎn)對(duì)點(diǎn)網(wǎng)絡(luò)下視頻會(huì)議不同[2]。在這種管理方式中,系統(tǒng)沒(méi)有MCU,也就是沒(méi)有集中控制和集中管理的設(shè)備,MCU的功能分別由終端實(shí)現(xiàn)。這種方式之所以能在基于分組的通信網(wǎng)(如IP網(wǎng))中實(shí)現(xiàn),其主要原因是網(wǎng)絡(luò)中的通信在邏輯信道進(jìn)行而不是以物理信道為單位進(jìn)行的,并且目前視頻編碼技術(shù)和客戶(hù)端計(jì)算機(jī)的處理能力也大幅提高,使得這種分布式視頻會(huì)議模式成為可能。
    Java媒體框架JMF(Java Media Framework)[3]是一個(gè)把音頻、視頻和其他基于時(shí)間(Time-Base)的媒體結(jié)合到Java程序中的應(yīng)用程序接口。它使Java程序具有許多新功能:捕捉音視頻信號(hào)、存儲(chǔ)、播放并處理媒體數(shù)據(jù),并能夠傳輸媒體數(shù)據(jù)和對(duì)多媒體格式進(jìn)行編譯碼。它還支持壓縮的媒體流及存儲(chǔ)媒體的同步、控制、處理和播放。
    JMF包括JMF API和RTP API兩個(gè)部分,前者的主要功能是捕捉、處理、存儲(chǔ)和播放媒體流;后者主要是在網(wǎng)絡(luò)上實(shí)時(shí)地(Real-Time)傳輸和接收媒體流,另外由于它是一種采用Java語(yǔ)言開(kāi)發(fā)媒體應(yīng)用的API,因此保證了媒體應(yīng)用程序的跨平臺(tái)性。
4 設(shè)計(jì)和核心技術(shù)實(shí)現(xiàn)
    模擬現(xiàn)實(shí)中的會(huì)議,會(huì)議模式包括自由模式和主講模式兩種。自由模式下,各個(gè)用戶(hù)間可以自由交流,通過(guò)本地終端能看到和聽(tīng)到其他所有參與會(huì)議的人的動(dòng)態(tài)畫(huà)面和聲音;主講模式下,由一個(gè)終端用戶(hù)主講,其他用戶(hù)每個(gè)終端只接收主講的視頻和音頻流,并關(guān)閉自己的視頻音頻流的網(wǎng)絡(luò)傳輸。各個(gè)終端既作為服務(wù)器也作為客戶(hù)端,即每個(gè)用戶(hù)從攝像頭和麥克風(fēng)捕獲視頻流和音頻流并向其他3人傳送,同時(shí)也分別接收其他3人傳送來(lái)的視頻音頻流并分別同步播放,無(wú)需其他專(zhuān)門(mén)的硬件設(shè)備比如MCU來(lái)控制會(huì)議的進(jìn)行,會(huì)議的管理控制由各個(gè)終端共同協(xié)作完成。流程圖如圖2所示。

4.1 流媒體的采集和壓縮
    利用JMF中的類(lèi)CaptureDevice獲取本地捕獲音頻流的設(shè)備信息對(duì)象CaptureDeviceInfo,利用獲取的設(shè)備信息創(chuàng)建媒體流的URL,并封裝到數(shù)據(jù)源DataSource(JMF中處理多媒體數(shù)據(jù)的數(shù)據(jù)模型)。
    發(fā)送前對(duì)捕獲的視頻音頻流進(jìn)行壓縮。由于直接從捕獲的視頻中得到的音頻或視頻原始數(shù)據(jù)很大,無(wú)法直接在網(wǎng)絡(luò)上傳輸,例如,10 s內(nèi)捕獲的原始音頻流1.70 M,而進(jìn)行G723.1壓縮后10 s內(nèi)的數(shù)據(jù)量?jī)H為151 KB,因此需要進(jìn)行壓縮編碼然后再由網(wǎng)絡(luò)傳輸。
4.2 流媒體的傳輸
    JMF提供的RTPConnector接口實(shí)現(xiàn)了與底層網(wǎng)絡(luò)的獨(dú)立性,RTP管理器使用RTPConnector接口可以實(shí)現(xiàn)基于底層UDP/TCP網(wǎng)絡(luò)的媒體流應(yīng)用。但JMF沒(méi)有提供RTPConnector的缺省實(shí)現(xiàn),為了實(shí)現(xiàn)UTP和RTP的通信,需要設(shè)計(jì)一個(gè)類(lèi)RTPUTPHandle來(lái)實(shí)現(xiàn)RTPConnector接口中的主要的兩個(gè)方法:getDataInputStream()和getDataOutputStream(),這兩個(gè)方法分別實(shí)現(xiàn)將接收到的數(shù)據(jù)源和要發(fā)送的數(shù)據(jù)源的處理給RTP管理器。但在實(shí)現(xiàn)這個(gè)RTPConnector接口前,還需要實(shí)現(xiàn)javax.media.protocol包中PushsourceStream和OutputDataStream接口中的方法。PushSoureStream中主要實(shí)現(xiàn)read()方法,用于將底層網(wǎng)絡(luò)中的UDP數(shù)據(jù)包中的數(shù)據(jù)傳輸給RTP管理器,OutputDataStream中主要需要實(shí)現(xiàn)write()方法,用于將RTP管理的所要發(fā)送的數(shù)據(jù)輸出到底層網(wǎng)絡(luò)。用UML表示如圖3所示。

4.3 同步處理
    由于處理器的狀態(tài)要經(jīng)歷如圖4所示幾個(gè)階段,首先獲取要播放的流,再獲得計(jì)算機(jī)資源,之后才能播放。當(dāng)接收到來(lái)自同一個(gè)源的視頻音頻對(duì)時(shí),若直接創(chuàng)建兩個(gè)處理器并直接播放,則兩個(gè)處理器都互相不考慮各自從初始狀態(tài)(Unrealized)到播放狀態(tài)(Started)所用的時(shí)間,則必定造成畫(huà)面和聲音的不同步。因此當(dāng)其中一個(gè)處理器到達(dá)就緒狀態(tài)時(shí)(Prefetched),如果另一個(gè)處理器還未就緒,則等待,直到另一個(gè)處理器到達(dá)就緒狀態(tài)再播放。由于從Prefetched到Started狀態(tài)的時(shí)間很短可忽略不計(jì),便于實(shí)現(xiàn)音頻視頻的同步播放。若從Prefetched到Started狀態(tài)還是造成了不同步,比如其中一個(gè)處理器從Prefetched到Started狀態(tài)用時(shí)0.1 s,而另一個(gè)處理器用時(shí)0.2 s,造成0.1 s的不同步,則需要設(shè)置播放延時(shí),即當(dāng)兩處理器都處于Prefetched狀態(tài)時(shí),設(shè)置延時(shí)為0.2 s,這樣即使先進(jìn)入Started也需要等0.1 s才能播放,依次實(shí)現(xiàn)播放的同步。


4.4 會(huì)議模式之間的切換
    系統(tǒng)在自由模式和主講模式之間切換時(shí),由于沒(méi)有獨(dú)立出來(lái)的控制器,如多點(diǎn)控制單元MCU,因此使用阻塞機(jī)制及Java的線(xiàn)程同步技術(shù)保證各終端之間能相互協(xié)作以完成會(huì)議模式的同步轉(zhuǎn)換,避免出現(xiàn)某些終端處于自由模式而某些終端處于主講模式。當(dāng)自由模式向主講模式轉(zhuǎn)換時(shí),由主講向各個(gè)終端發(fā)送主講控制信息,各個(gè)終端關(guān)閉本地視頻音頻流的發(fā)送,并進(jìn)入阻塞狀態(tài),只接收主講的視頻音頻流;當(dāng)主講模式向自由模式轉(zhuǎn)換時(shí),由主講向各個(gè)終端發(fā)送結(jié)束主講控制信息,各個(gè)終端解除阻塞狀態(tài),打開(kāi)本地視頻音頻流的發(fā)送。
    軟件化的分布式視頻會(huì)議由于在客戶(hù)端進(jìn)行視音頻的編碼壓縮操作,增加了一定的處理負(fù)擔(dān),采用軟件編碼也比硬件編碼速度上有劣勢(shì),但可擴(kuò)展性卻是硬件視頻會(huì)議無(wú)法比擬的,MCU的端口數(shù)直接限制了可接入的用戶(hù)數(shù),且可接入數(shù)越多,MCU的價(jià)格越昂貴,很難被廣泛使用;在帶寬足夠大的情況下,分布式視頻會(huì)議卻不受這個(gè)限制。
參考文獻(xiàn)
[1] 朱濤江,林劍.Java網(wǎng)絡(luò)編程[M].北京:中國(guó)電力出版社,2005:478-500.
[2] 郭琳,楊曉軍,王云澤.P2P網(wǎng)絡(luò)下多媒體實(shí)時(shí)共享系統(tǒng)[J].計(jì)算機(jī)工程,2010,36(17):245-248.
[3] 孫一林,彭波.Java網(wǎng)絡(luò)編程實(shí)例[M].北京:清華大學(xué)出版社,2003.219-277.

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載。
亚洲一区二区欧美_亚洲丝袜一区_99re亚洲国产精品_日韩亚洲一区二区
国产亚洲制服色| 亚洲精品在线观看免费| 欧美乱大交xxxxx| 你懂的国产精品| 毛片一区二区三区| 久久中文精品| 美国成人直播| 免费在线观看日韩欧美| 欧美不卡视频| 欧美激情va永久在线播放| 欧美精品国产一区| 欧美日本一区二区三区| 欧美日韩91| 欧美三日本三级三级在线播放| 欧美日韩亚洲一区二区| 欧美色欧美亚洲另类二区| 欧美性猛交视频| 国产精品网曝门| 国产美女精品一区二区三区| 国产噜噜噜噜噜久久久久久久久| 国产精品视频大全| 国产性色一区二区| 狠狠综合久久| 亚洲高清久久久| 亚洲精品在线视频观看| 99精品欧美一区二区三区| 一本色道久久综合亚洲精品按摩 | 欧美在线日韩| 亚洲缚视频在线观看| 亚洲日本欧美在线| 亚洲午夜精品久久久久久浪潮 | 国产精品久久久久久久久免费桃花 | 国外精品视频| 激情综合网址| 亚洲精品中文字幕在线| 亚洲视频在线二区| 欧美一级片久久久久久久| 欧美在线视频不卡| 亚洲区在线播放| 亚洲一二三区在线观看| 欧美有码视频| 欧美国产精品中文字幕| 欧美四级在线| 好看的日韩av电影| 亚洲黄一区二区三区| 亚洲图片欧美一区| 久久精品91| 正在播放日韩| 久久一日本道色综合久久| 欧美伦理a级免费电影| 国产精品一区免费视频| 在线看一区二区| 中文av一区二区| 久久国内精品自在自线400部| 9久re热视频在线精品| 欧美在线黄色| 欧美精品精品一区| 国产精品久久久久久妇女6080| 狠狠操狠狠色综合网| 日韩一级大片| 久久精品一区二区| 亚洲一级在线| 欧美成人激情在线| 国产精品试看| 亚洲黄色高清| 欧美一区二区三区精品| 亚洲视频香蕉人妖| 久久综合婷婷| 国产精品入口| 亚洲人体影院| 欧美一区二区三区在线视频| 一二三区精品福利视频| 久久久之久亚州精品露出| 国产精品wwwwww| 在线观看国产精品淫| 亚洲一二区在线| 亚洲精品国精品久久99热一| 欧美在线免费观看亚洲| 欧美日韩一区在线观看视频| 一区在线视频观看| 亚洲欧美日韩久久精品| 一个色综合av| 免费观看成人| 国产三级欧美三级| 亚洲最新视频在线播放| 亚洲精华国产欧美| 久久国产精品一区二区三区| 欧美日韩在线不卡| 久久精品一区二区三区四区| 国产精品高清一区二区三区| 影音先锋国产精品| 性感少妇一区| 欧美亚洲视频| 欧美午夜免费电影| 亚洲精品在线观| 亚洲精品一区久久久久久| 久久久综合精品| 国产欧美日本| 亚洲一区三区视频在线观看| 亚洲一二三区视频在线观看| 欧美日韩精品在线观看| 亚洲国内高清视频| 亚洲日本中文字幕| 美女图片一区二区| 韩国成人福利片在线播放| 欧美一级片在线播放| 久久av红桃一区二区小说| 国产精品久久中文| 在线中文字幕一区| 亚洲伊人伊色伊影伊综合网| 欧美日韩在线电影| 亚洲免费久久| 亚洲午夜日本在线观看| 欧美日韩亚洲三区| 一本色道久久综合亚洲精品不卡| 在线亚洲自拍| 欧美视频专区一二在线观看| 日韩一级在线观看| 亚洲一区二区三区精品视频 | 伊伊综合在线| 亚洲二区三区四区| 久热国产精品| 在线看欧美视频| 亚洲黄色大片| 欧美激情中文字幕乱码免费| 最新国产成人av网站网址麻豆| 亚洲精品欧美在线| 欧美乱人伦中文字幕在线| 亚洲美女视频在线观看| 亚洲午夜羞羞片| 国产精品理论片| 亚洲欧美伊人| 久久久亚洲影院你懂的| 伊人久久综合| 99热这里只有成人精品国产| 欧美日韩裸体免费视频| 一区二区欧美视频| 欧美亚洲午夜视频在线观看| 国产日韩欧美另类| 久久精品国产一区二区三| 女同性一区二区三区人了人一 | 久久综合狠狠综合久久综合88 | 久久综合五月天婷婷伊人| 亚洲第一毛片| 久久精品国产精品亚洲综合| 美女主播视频一区| 亚洲人成网站777色婷婷| 在线亚洲高清视频| 国产精品久久久久影院色老大 | 欧美视频在线看| 亚洲欧美999| 久久夜色精品国产欧美乱极品| 亚洲第一福利社区| 亚洲午夜精品久久久久久浪潮| 国产精品自拍三区| 亚洲国内高清视频| 欧美日韩亚洲精品内裤| 校园激情久久| 欧美xxx成人| 亚洲一区二区三区欧美| 久久日韩粉嫩一区二区三区| 91久久精品网| 欧美亚洲尤物久久| 亚洲国产91| 亚洲欧美日韩国产精品| 狠狠色丁香久久综合频道| 夜夜嗨av一区二区三区四区| 国产欧美精品日韩| 日韩午夜电影av| 国产精品一区二区在线观看不卡 | 欧美亚洲一区在线| 亚洲高清免费在线| 午夜视频久久久| 亚洲国产精品久久91精品| 亚洲欧美第一页| 在线观看一区视频| 亚洲欧美日韩国产成人| 亚洲高清一区二区三区| 性欧美办公室18xxxxhd| 亚洲国产第一| 久久aⅴ国产欧美74aaa| 91久久线看在观草草青青| 香蕉精品999视频一区二区| 亚洲丰满在线| 欧美在线你懂的| 日韩亚洲欧美综合| 久热这里只精品99re8久| 在线一区日本视频| 欧美福利一区二区三区| 午夜性色一区二区三区免费视频| 欧美激情久久久久久| 欧美在现视频| 国产精品高潮视频| 制服丝袜亚洲播放| 欧美成人免费小视频| 亚洲欧美综合国产精品一区| 欧美日韩国产成人在线免费| 久久国内精品自在自线400部| 国产精品久在线观看| 一区二区三区四区五区精品视频 |