摘 要: 基于JMF和多播技術(shù)實現(xiàn)了一個沒有多點控制單元的分布式視頻會議。視音頻的壓縮由各個客戶端來處理,,并引入了視頻會議的自由模式和主講模式,,兩種模式之間的切換由各個對等點之間協(xié)調(diào)同步完成。在沒有多點控制單元的情況下,,依然保證視頻會議的正常進行,。會議中的各個對等點采用多播技術(shù)傳輸視音頻流,以盡量減少對帶寬的占用,。
關(guān)鍵詞: 多播,;分布式;JMF,;同步
1 視頻會議的發(fā)展歷程
視頻會議在電信行業(yè)己經(jīng)存在了30多年,,但在上世紀90年代以前,這些系統(tǒng)一直使用專用的編解碼硬件和軟件,,視頻會議都需要昂貴的設備和專線互連才能實現(xiàn),。
而近幾年來,,隨著國內(nèi)外大型網(wǎng)絡運營商對網(wǎng)絡環(huán)境的建設和改造,以及ISDN,、DDN,、VPN、xDSL,、ATM等技術(shù)的應用和推廣,,視音頻編解碼技術(shù)趨于成熟,圖像傳輸質(zhì)量大為提高,,視頻會議系統(tǒng)價格開始下調(diào),,視頻會議系統(tǒng)的使用環(huán)境變得越來越好,因此無論是通信行業(yè)還是IT行業(yè),,都對視頻會議領域重新進行關(guān)注,。
目前視頻音頻數(shù)據(jù)的編碼解碼技術(shù)也趨于成熟,計算機處理速度和附屬板卡的處理速度也大幅度增強,,很多以前需要專門的硬件設備MCU來進行的音視頻編碼解碼操作,,現(xiàn)在都可以在普通的計算機上進行,寬帶的接入愈來愈廉價,、普及,,成本比硬件系統(tǒng)低很多,為了使視頻會議“大眾化”,,利用其現(xiàn)有的計算機和網(wǎng)絡系統(tǒng),,實現(xiàn)視頻會議的應用,視頻會議由“硬”到“軟”是必然的趨勢,。就市場來看,,據(jù)國際著名的通信研究機構(gòu)Wainhouse Research近期預測,未來全球硬件視頻會議設備銷售的增長約為18%,,而軟件視頻會議的增長則將達到144%,。
2 多播技術(shù)的應用
視頻會議可以采取單播、多播和廣播中任一技術(shù)來實現(xiàn),。單播即點對點的通信,,需建立連接,雖然能保證數(shù)據(jù)不丟失,,但很占用資源,,例如,為了使視頻會議系統(tǒng)顯現(xiàn)的圖像是動態(tài)的,、連續(xù)的,,一個視頻信息流就需要占用1.5 Mb/s的帶寬[1],在一個單播(unicast)環(huán)境里,若有N個用戶接收,,視頻服務器依次送出N個信息流,,共需要N×1.5 Mb/s的帶寬;如果服務器處于10 M的以太網(wǎng)內(nèi),,6~7個信息流就占滿了帶寬,;而在一個多播(multicast)環(huán)境里,不論網(wǎng)絡中的用戶數(shù)目有多少,,服務器只發(fā)出的一個視頻流,,僅需1.5 Mb/s的帶寬即可。
廣播技術(shù)在發(fā)送給參與視頻會議用戶的同時也會把視頻流發(fā)送給那些對此不關(guān)心的用戶,,尤其視頻音頻的數(shù)據(jù)都比較大,,這樣會導致Internet面臨崩潰,而多播通信的目標性更強并且比廣播通信窄[1],。例如,,如圖1所示,若采用多播發(fā)送,,則發(fā)送端A的視頻流只會在路由器1復制一次,,并發(fā)送給路由器2,路由器2再復制一次發(fā)給接收端B,;如用廣播技術(shù),,則發(fā)送端A的視頻流到達路由器1時,路由器1將復制出三個視頻流分別發(fā)給與它相連的3個路由器,,這3個路由器又將收到的視頻流廣播到其他網(wǎng)絡,而不管這些客戶是否有需要,。因此本系統(tǒng)采用多播技術(shù)來實現(xiàn)流媒體的傳輸,。
3 分布式視頻會議及JMF
分布式視頻會議是傳統(tǒng)的會議系統(tǒng)(如:H.320視頻會議系統(tǒng))所沒有的,又與點對點網(wǎng)絡下視頻會議不同[2],。在這種管理方式中,,系統(tǒng)沒有MCU,也就是沒有集中控制和集中管理的設備,,MCU的功能分別由終端實現(xiàn),。這種方式之所以能在基于分組的通信網(wǎng)(如IP網(wǎng))中實現(xiàn),其主要原因是網(wǎng)絡中的通信在邏輯信道進行而不是以物理信道為單位進行的,,并且目前視頻編碼技術(shù)和客戶端計算機的處理能力也大幅提高,,使得這種分布式視頻會議模式成為可能。
Java媒體框架JMF(Java Media Framework)[3]是一個把音頻,、視頻和其他基于時間(Time-Base)的媒體結(jié)合到Java程序中的應用程序接口,。它使Java程序具有許多新功能:捕捉音視頻信號、存儲、播放并處理媒體數(shù)據(jù),,并能夠傳輸媒體數(shù)據(jù)和對多媒體格式進行編譯碼,。它還支持壓縮的媒體流及存儲媒體的同步、控制,、處理和播放,。
JMF包括JMF API和RTP API兩個部分,前者的主要功能是捕捉,、處理,、存儲和播放媒體流;后者主要是在網(wǎng)絡上實時地(Real-Time)傳輸和接收媒體流,,另外由于它是一種采用Java語言開發(fā)媒體應用的API,,因此保證了媒體應用程序的跨平臺性。
4 設計和核心技術(shù)實現(xiàn)
模擬現(xiàn)實中的會議,,會議模式包括自由模式和主講模式兩種,。自由模式下,各個用戶間可以自由交流,,通過本地終端能看到和聽到其他所有參與會議的人的動態(tài)畫面和聲音,;主講模式下,由一個終端用戶主講,,其他用戶每個終端只接收主講的視頻和音頻流,,并關(guān)閉自己的視頻音頻流的網(wǎng)絡傳輸。各個終端既作為服務器也作為客戶端,,即每個用戶從攝像頭和麥克風捕獲視頻流和音頻流并向其他3人傳送,,同時也分別接收其他3人傳送來的視頻音頻流并分別同步播放,無需其他專門的硬件設備比如MCU來控制會議的進行,,會議的管理控制由各個終端共同協(xié)作完成,。流程圖如圖2所示。
4.1 流媒體的采集和壓縮
利用JMF中的類CaptureDevice獲取本地捕獲音頻流的設備信息對象CaptureDeviceInfo,,利用獲取的設備信息創(chuàng)建媒體流的URL,,并封裝到數(shù)據(jù)源DataSource(JMF中處理多媒體數(shù)據(jù)的數(shù)據(jù)模型)。
發(fā)送前對捕獲的視頻音頻流進行壓縮,。由于直接從捕獲的視頻中得到的音頻或視頻原始數(shù)據(jù)很大,,無法直接在網(wǎng)絡上傳輸,例如,,10 s內(nèi)捕獲的原始音頻流1.70 M,,而進行G723.1壓縮后10 s內(nèi)的數(shù)據(jù)量僅為151 KB,因此需要進行壓縮編碼然后再由網(wǎng)絡傳輸,。
4.2 流媒體的傳輸
JMF提供的RTPConnector接口實現(xiàn)了與底層網(wǎng)絡的獨立性,,RTP管理器使用RTPConnector接口可以實現(xiàn)基于底層UDP/TCP網(wǎng)絡的媒體流應用,。但JMF沒有提供RTPConnector的缺省實現(xiàn),為了實現(xiàn)UTP和RTP的通信,,需要設計一個類RTPUTPHandle來實現(xiàn)RTPConnector接口中的主要的兩個方法:getDataInputStream()和getDataOutputStream(),,這兩個方法分別實現(xiàn)將接收到的數(shù)據(jù)源和要發(fā)送的數(shù)據(jù)源的處理給RTP管理器。但在實現(xiàn)這個RTPConnector接口前,,還需要實現(xiàn)javax.media.protocol包中PushsourceStream和OutputDataStream接口中的方法,。PushSoureStream中主要實現(xiàn)read()方法,用于將底層網(wǎng)絡中的UDP數(shù)據(jù)包中的數(shù)據(jù)傳輸給RTP管理器,,OutputDataStream中主要需要實現(xiàn)write()方法,,用于將RTP管理的所要發(fā)送的數(shù)據(jù)輸出到底層網(wǎng)絡。用UML表示如圖3所示,。
4.3 同步處理
由于處理器的狀態(tài)要經(jīng)歷如圖4所示幾個階段,,首先獲取要播放的流,再獲得計算機資源,,之后才能播放,。當接收到來自同一個源的視頻音頻對時,若直接創(chuàng)建兩個處理器并直接播放,,則兩個處理器都互相不考慮各自從初始狀態(tài)(Unrealized)到播放狀態(tài)(Started)所用的時間,,則必定造成畫面和聲音的不同步。因此當其中一個處理器到達就緒狀態(tài)時(Prefetched),,如果另一個處理器還未就緒,,則等待,直到另一個處理器到達就緒狀態(tài)再播放,。由于從Prefetched到Started狀態(tài)的時間很短可忽略不計,,便于實現(xiàn)音頻視頻的同步播放。若從Prefetched到Started狀態(tài)還是造成了不同步,,比如其中一個處理器從Prefetched到Started狀態(tài)用時0.1 s,,而另一個處理器用時0.2 s,造成0.1 s的不同步,,則需要設置播放延時,即當兩處理器都處于Prefetched狀態(tài)時,,設置延時為0.2 s,,這樣即使先進入Started也需要等0.1 s才能播放,依次實現(xiàn)播放的同步,。
4.4 會議模式之間的切換
系統(tǒng)在自由模式和主講模式之間切換時,,由于沒有獨立出來的控制器,如多點控制單元MCU,,因此使用阻塞機制及Java的線程同步技術(shù)保證各終端之間能相互協(xié)作以完成會議模式的同步轉(zhuǎn)換,,避免出現(xiàn)某些終端處于自由模式而某些終端處于主講模式。當自由模式向主講模式轉(zhuǎn)換時,由主講向各個終端發(fā)送主講控制信息,,各個終端關(guān)閉本地視頻音頻流的發(fā)送,,并進入阻塞狀態(tài),只接收主講的視頻音頻流,;當主講模式向自由模式轉(zhuǎn)換時,,由主講向各個終端發(fā)送結(jié)束主講控制信息,各個終端解除阻塞狀態(tài),,打開本地視頻音頻流的發(fā)送,。
軟件化的分布式視頻會議由于在客戶端進行視音頻的編碼壓縮操作,增加了一定的處理負擔,,采用軟件編碼也比硬件編碼速度上有劣勢,,但可擴展性卻是硬件視頻會議無法比擬的,MCU的端口數(shù)直接限制了可接入的用戶數(shù),,且可接入數(shù)越多,,MCU的價格越昂貴,很難被廣泛使用,;在帶寬足夠大的情況下,,分布式視頻會議卻不受這個限制。
參考文獻
[1] 朱濤江,,林劍.Java網(wǎng)絡編程[M].北京:中國電力出版社,,2005:478-500.
[2] 郭琳,楊曉軍,,王云澤.P2P網(wǎng)絡下多媒體實時共享系統(tǒng)[J].計算機工程,,2010,36(17):245-248.
[3] 孫一林,,彭波.Java網(wǎng)絡編程實例[M].北京:清華大學出版社,,2003.219-277.