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