摘  要： 基于JMF和多播技術(shù)實(shí)現(xiàn)了一個(gè)沒有多點(diǎn)控制單元的分布式視頻會(huì)議。視音頻的壓縮由各個(gè)客戶端來處理,，并引入了視頻會(huì)議的自由模式和主講模式,，兩種模式之間的切換由各個(gè)對(duì)等點(diǎn)之間協(xié)調(diào)同步完成。在沒有多點(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)一直使用專用的編解碼硬件和軟件,，視頻會(huì)議都需要昂貴的設(shè)備和專線互連才能實(shí)現(xiàn),。
    而近幾年來，隨著國(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à)格開始下調(diào)，視頻會(huì)議系統(tǒng)的使用環(huán)境變得越來越好,，因此無論是通信行業(yè)還是IT行業(yè),，都對(duì)視頻會(huì)議領(lǐng)域重新進(jìn)行關(guān)注,。
    目前視頻音頻數(shù)據(jù)的編碼解碼技術(shù)也趨于成熟，計(jì)算機(jī)處理速度和附屬板卡的處理速度也大幅度增強(qiáng),，很多以前需要專門的硬件設(shè)備MCU來進(jìn)行的音視頻編碼解碼操作,，現(xiàn)在都可以在普通的計(jì)算機(jī)上進(jìn)行，寬帶的接入愈來愈廉價(jià),、普及,，成本比硬件系統(tǒng)低很多，為了使視頻會(huì)議“大眾化”,，利用其現(xiàn)有的計(jì)算機(jī)和網(wǎng)絡(luò)系統(tǒng),，實(shí)現(xiàn)視頻會(huì)議的應(yīng)用，視頻會(huì)議由“硬”到“軟”是必然的趨勢(shì),。就市場(chǎng)來看,，據(jù)國(guó)際著名的通信研究機(jī)構(gòu)Wainhouse Research近期預(yù)測(cè)，未來全球硬件視頻會(huì)議設(shè)備銷售的增長(zhǎng)約為18%,，而軟件視頻會(huì)議的增長(zhǎng)則將達(dá)到144%,。
2 多播技術(shù)的應(yīng)用
    視頻會(huì)議可以采取單播、多播和廣播中任一技術(shù)來實(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è)用戶接收，視頻服務(wù)器依次送出N個(gè)信息流,，共需要N×1.5 Mb/s的帶寬,；如果服務(wù)器處于10 M的以太網(wǎng)內(nèi)，6~7個(gè)信息流就占滿了帶寬,；而在一個(gè)多播（multicast）環(huán)境里,，不論網(wǎng)絡(luò)中的用戶數(shù)目有多少，服務(wù)器只發(fā)出的一個(gè)視頻流,，僅需1.5 Mb/s的帶寬即可,。
    廣播技術(shù)在發(fā)送給參與視頻會(huì)議用戶的同時(shí)也會(huì)把視頻流發(fā)送給那些對(duì)此不關(guān)心的用戶，尤其視頻音頻的數(shù)據(jù)都比較大,，這樣會(huì)導(dǎo)致Internet面臨崩潰,，而多播通信的目標(biāo)性更強(qiáng)并且比廣播通信窄[1]。例如，如圖1所示,，若采用多播發(fā)送,，則發(fā)送端A的視頻流只會(huì)在路由器1復(fù)制一次，并發(fā)送給路由器2,，路由器2再復(fù)制一次發(fā)給接收端B,；如用廣播技術(shù)，則發(fā)送端A的視頻流到達(dá)路由器1時(shí),，路由器1將復(fù)制出三個(gè)視頻流分別發(fā)給與它相連的3個(gè)路由器,，這3個(gè)路由器又將收到的視頻流廣播到其他網(wǎng)絡(luò)，而不管這些客戶是否有需要,。因此本系統(tǒng)采用多播技術(shù)來實(shí)現(xiàn)流媒體的傳輸,。

3 分布式視頻會(huì)議及JMF
    分布式視頻會(huì)議是傳統(tǒng)的會(huì)議系統(tǒng)（如：H.320視頻會(huì)議系統(tǒng)）所沒有的，又與點(diǎn)對(duì)點(diǎn)網(wǎng)絡(luò)下視頻會(huì)議不同[2],。在這種管理方式中,，系統(tǒng)沒有MCU，也就是沒有集中控制和集中管理的設(shè)備,，MCU的功能分別由終端實(shí)現(xiàn),。這種方式之所以能在基于分組的通信網(wǎng)（如IP網(wǎng)）中實(shí)現(xiàn)，其主要原因是網(wǎng)絡(luò)中的通信在邏輯信道進(jìn)行而不是以物理信道為單位進(jìn)行的,，并且目前視頻編碼技術(shù)和客戶端計(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語言開發(fā)媒體應(yīng)用的API，因此保證了媒體應(yīng)用程序的跨平臺(tái)性,。
4 設(shè)計(jì)和核心技術(shù)實(shí)現(xiàn)
    模擬現(xiàn)實(shí)中的會(huì)議,，會(huì)議模式包括自由模式和主講模式兩種,。自由模式下，各個(gè)用戶間可以自由交流,，通過本地終端能看到和聽到其他所有參與會(huì)議的人的動(dòng)態(tài)畫面和聲音,；主講模式下，由一個(gè)終端用戶主講,，其他用戶每個(gè)終端只接收主講的視頻和音頻流,，并關(guān)閉自己的視頻音頻流的網(wǎng)絡(luò)傳輸。各個(gè)終端既作為服務(wù)器也作為客戶端,，即每個(gè)用戶從攝像頭和麥克風(fēng)捕獲視頻流和音頻流并向其他3人傳送,，同時(shí)也分別接收其他3人傳送來的視頻音頻流并分別同步播放，無需其他專門的硬件設(shè)備比如MCU來控制會(huì)議的進(jìn)行,，會(huì)議的管理控制由各個(gè)終端共同協(xié)作完成,。流程圖如圖2所示。

4.1 流媒體的采集和壓縮
    利用JMF中的類CaptureDevice獲取本地捕獲音頻流的設(shè)備信息對(duì)象CaptureDeviceInfo,，利用獲取的設(shè)備信息創(chuàng)建媒體流的URL,，并封裝到數(shù)據(jù)源DataSource（JMF中處理多媒體數(shù)據(jù)的數(shù)據(jù)模型）。
    發(fā)送前對(duì)捕獲的視頻音頻流進(jìn)行壓縮,。由于直接從捕獲的視頻中得到的音頻或視頻原始數(shù)據(jù)很大,，無法直接在網(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沒有提供RTPConnector的缺省實(shí)現(xiàn),，為了實(shí)現(xiàn)UTP和RTP的通信，需要設(shè)計(jì)一個(gè)類RTPUTPHandle來實(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)接收到來自同一個(gè)源的視頻音頻對(duì)時(shí),，若直接創(chuàng)建兩個(gè)處理器并直接播放,，則兩個(gè)處理器都互相不考慮各自從初始狀態(tài)（Unrealized）到播放狀態(tài)（Started）所用的時(shí)間，則必定造成畫面和聲音的不同步,。因此當(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í),，由于沒有獨(dú)立出來的控制器，如多點(diǎn)控制單元MCU,，因此使用阻塞機(jī)制及Java的線程同步技術(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),，打開本地視頻音頻流的發(fā)送。
    軟件化的分布式視頻會(huì)議由于在客戶端進(jìn)行視音頻的編碼壓縮操作,，增加了一定的處理負(fù)擔(dān),，采用軟件編碼也比硬件編碼速度上有劣勢(shì)，但可擴(kuò)展性卻是硬件視頻會(huì)議無法比擬的,，MCU的端口數(shù)直接限制了可接入的用戶數(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.