0? 引言

????? 視頻會議的多點控制單元(MCU)是視頻會議系統(tǒng)的核心設備。所有參與會議的終端可與MCU建立一對一的連接，終端負責采集本會場的聲音和圖像，然后經編碼后傳輸?shù)組CU，由MCU根據(jù)當前視頻會議的模式確定對音視頻信號的處理方式和轉發(fā)邏輯，最后將處理后的音視頻數(shù)據(jù)再發(fā)送到每一個與會者。

1? 多點視頻會議的分類

　　基于H.324標準，多點會議實現(xiàn)有各種不同的方法和配置，主要可以為集中式多點會議和分散式多點會議兩種模式。

　　集中式多點會議是由一個多點控制單元來組織，所有終端以點對點方式向多點控制單元發(fā)送視頻流、音頻流和控制流。其結構如圖1所示。圖1中的多點控制器使用H.245控制功能來對會議進行集中式管理。H.245也可用來指定各終端的通信能力。多點處理器可進行混音、數(shù)據(jù)分配以及視頻信號的混合和切換，并將處理結果送回參加會議的終端。一個支持集中式多點會議的典型多點控制單元通常由一個多點處理器和多點控制器組成。
?

　　分散式多點會議是傳統(tǒng)的會議系統(tǒng)(如H.320)所沒有的。在這種管理方式的系統(tǒng)中沒有MCU，也沒有集中控制和集中管理的設備，MCU的功能是以MC和MP功能模塊的方式分別存在于系統(tǒng)的其他設備中。分布式多點控制和管理之所以能在基于分組的通信網(wǎng)中實現(xiàn)，其主要原因是網(wǎng)絡中的通信是在邏輯信道中進行的，而不是以物理信道為單位進行的。分布式多點會議利用多點播送技術來組織，參加會議的終端向別的與會者終端以多點播送方式傳送視頻和音頻信息，而無須在多點處理器集中進行。H.245控制信息仍然以點對點的方式傳送給主多點控制器，圖2所示是分散式MCU的組網(wǎng)結構。

?

　　集中式多點視頻會議中的MCU集多點視頻會議控制器(MC)和多點視頻會議處理器(MP)于一身，它既有組織和管理會議的功能，同時負責所有與會者的聲音和圖像的處理和切換。

2 MCU的系統(tǒng)設計

　　2.1? 集中式多點視頻會議的網(wǎng)絡結構

　　星型組網(wǎng)方案是集中式多點會議的首選方案。星型組網(wǎng)方案是將所有終端通過集線器或交換機連接到MCU，每個終端都只與MCU建立一個基于H.324標準的連接，圖3所示是其星型組網(wǎng)方案。每個終端負責對本會場的聲音、圖像進行采集后，再經過相應的編碼算法進行編碼，然后將編碼得到的音視頻流通過交換機發(fā)送到MCU，由MCU根據(jù)當前的會議模式對音頻和視頻分別進行處理。音視頻的處理主要包括對與會者聲音的混合和多畫面合成，最后將處理后的音視頻數(shù)據(jù)由MCU根據(jù)會議模式轉發(fā)給每個參會者的終端。

?

　　視頻會議模式的設置和參與會議的成員管理可由MCU控制臺來完成。實際應用中，一般會為每個會議配備一個會議管理者，又稱會議管理員。會議管理員可通過MCU控制臺對多點控制單元進行遠程控制，包括設置會議開始和結束的時間、會議采用的音視頻標準、會議模式的設置、與會者列表的管理以及會議模板的裝載和保存等。在會議進行中，會議管理員還可通過MCU控制臺對會議進行調度，包括指定新的主席、指定新的發(fā)言聽眾、取消發(fā)言等。

　　在分布式會議方案中，各個終端均完成一定的控制與交換功能，因而靈活性強，與會端加入／退出會議功能易于實現(xiàn)，但其通信協(xié)議比較復雜?？刂菩畔⒁詮V播方式發(fā)送，因而通信效率比較低，所以通常采用集中式實現(xiàn)方案。有時候，主席端也可與MCU合并形成一個超級服務端。這種方式可以演化為人們所熟悉的客戶／服務器體系。在主席端的機動性要求不高時，這種方式具有非常突出的優(yōu)點，如易于實現(xiàn)，控制簡便等。圖4所示是客戶／服務器方式MCU的方案結構。為了保證通用性和機動性，本設計采用集中式MCU方案。

?

?

　　2.2 MCU的通信接口設計

　　通信接口的主要功能是數(shù)據(jù)串／并變換與緩存，其作用類似于較大輸入輸出緩沖區(qū)的串口擴展。從調制解調器(Modem)輸入的串行數(shù)據(jù)格式為2-8-1-N，即2 bit起始位，8 bit數(shù)據(jù)，1bit停止位，無奇偶校驗。接口卡分離出8 bit數(shù)據(jù)位并對之進行串／并變換后存入輸入緩沖區(qū)，緩沖區(qū)是8 kbit的FIFO(先入先出)堆棧，接口卡提供指定的地址以便微機從中讀取數(shù)據(jù)。微機輸出的數(shù)據(jù)可寫入接口卡的輸出緩沖區(qū)。它也是8 kbit的FIFO堆棧，然后接口卡執(zhí)行相反的操作并將之輸出到Modem[17]。接口卡的原理如圖5所示。
?

2.3? 視頻會議系統(tǒng)協(xié)議的簡化模型

　　MCU的設計可參考ITU的H.324系列建議。該建議擬訂了低比特多媒體通信終端的基本框架。它包括四個主要部分：G.723.1音頻編碼標準、H.263視頻編碼標準、H.245通信控制協(xié)議和H.223復接分接協(xié)議，該建議同時也描述了一個在PSTN中采用V.34標準的Modem。V.34標準規(guī)定了輸入／輸出Modem的數(shù)據(jù)格式、比特率等要求。本系統(tǒng)由于MCU連接了多個端口，若各端口Modem的速率不一致，則可能會造成MCU的數(shù)據(jù)擁塞，故本系統(tǒng)中禁止Modem速率的自動調整。一般在會議開始之前，即按各端口中最低速率建立連接，以保證較小的誤碼率。在MCU中，主要是對H.223幀的幀頭進行處理。H.223幀結構中的幀起始標志為3個連續(xù)的FAS碼，每個FAS碼長為4個字節(jié)，試驗系統(tǒng)中可取為0XEC。該標志也可用于實現(xiàn)對H.223幀的定界。由于幀長度是不定的，因此，幀起始標志的正確傳輸與檢測直接影響到幀定位?？刂菩盘栆舱?個字節(jié)，其中前兩個字節(jié)為BAS碼，主要攜帶會議控制信息。因本會議系統(tǒng)的可能狀態(tài)較少，所用到的控制命令也少，故只用一個字節(jié)傳送命令，另一個字節(jié)作為BAS碼的糾錯字節(jié)，以保證命令的正確傳輸。

　　在視頻會議系統(tǒng)的命令交互中，MCU及各個與會站點在會議中都要維護一張狀態(tài)設置表，表中記錄了各與會站點所對應的邏輯端口、電話號碼、地理位置、在會議中的身份(主席、發(fā)言方及普通會員)等，此后MCU進一步將邏輯端口映射成相應的物理地址，以便MCU從該地址讀寫信息。狀態(tài)設置表的初始設置是在會前通過勤務電話確定的。預定的開會時間由MCU負責通過Modem呼通各與會站點，以建立起數(shù)據(jù)鏈路。當某個站點呼通后，該站點即在其H.223幀中插入終端就緒命令，而MCU則將該幀環(huán)回，并將BAS碼替換為就緒確認命令。當所有站點均就緒后，MCU即向各站點發(fā)會議就緒命令。同時將主席端的數(shù)據(jù)切換到各個站點，此時主席便可以發(fā)言，也可以命令其它會員發(fā)言。如果主席沒有發(fā)命令給MCU，則向MCU發(fā)會議進行中狀態(tài)指示，MCU則維持當前狀態(tài)；若主席命令A站點發(fā)言，則其在H.223幀中插入令A發(fā)言的命令。MCU接到命令后，即將A站點的數(shù)據(jù)切換到除A外的所有其它站點，同時將主席的數(shù)據(jù)發(fā)往A站點。當主席命令會議結束時，MCU即向各站點發(fā)送會議結束確認命令，并停止工作，由各站點自行掛斷Modem。圖6為上述過程的命令交互示意圖。
?

?

　　在會議中，MCU接主席命令后，應根據(jù)該命令所產生的狀態(tài)轉移來修改狀態(tài)設置表。通過低速MCU伺服軟件可使MCU同時控制8個與會站點的數(shù)據(jù)讀入寫出操作，同時進行命令解釋執(zhí)行工作。由于幀交換又要占用大量的內存資源，同時還要保證系統(tǒng)的實時性，因此，MCU伺服軟件的設計不僅要求執(zhí)行效率高，還要求程序本身要占用較少的系統(tǒng)資源。

3 MCU的軟件設計

　　該軟件的設計可采用快速原型方法來完成。首先可建立簡化的快速原型，然后在此基礎上逐步完善以達到設計要求?？焖僭屯瑯涌刹捎媚K化的方法將整個MCU軟件劃分為若干松耦合的功能模塊，并對各模塊分別進行設計與測試，在保證各模塊正確后，再對整個軟件進行綜合調試，以發(fā)現(xiàn)各模塊間接口設計可能存在的失誤，再反過來通過修正各模塊程序來完成整個軟件的設計。具體開發(fā)流程如圖7所示?，F(xiàn)將各步的工作描述如下：
?

?

　　(1)利用電話線在兩臺計算機間通過Modem進行數(shù)據(jù)通信時，可將其作為功能最簡單的快速原型。該步的主要工作是建立DOS平臺上Modem的控制功能。其關鍵是對鍵入的命令進行解釋后傳送給Modem，同時接收Modem的反饋信號，以確定Modem的狀態(tài)，并以此進行進一步的控制；

　　(2)建立遠地自環(huán)模型，以測試快速原型的正確性，同時測試接口卡的工作特性；

　　(3)編寫幀讀入模塊和幀寫出模塊程序，以連續(xù)測試幀環(huán)回及單一測試幀。驗證傳送來的測試幀讀摸塊以及幀寫出模塊的正確性；

　　(4)編寫命令提取與解釋模塊和狀態(tài)修改模塊程序，通過改變測試幀的BAS碼并讀取狀態(tài)修改結果來驗證上述模塊的正確性；

　　(5)編寫幀切換／BAS碼替換模塊程序，構造三臺計算機間的測試平臺，并使其一充當MCU，然后通過另兩端的測試幀切換來驗證上述模塊的正確性；

　　(6)根據(jù)實際條件建立多臺計算機間的測試平臺，并適當改變測試幀的長度(128～512 byte)，進行連續(xù)的測試并計時，以檢驗各模塊的工作時延。然后按照系統(tǒng)的實時性要求對產生時延較大的模塊進行改進。

4? 結束語

　　由于MCU對運動程度不同的視頻圖像的處理能力有所不同，所以，傳送運動程度不同的視頻圖像時，在終端B接收到的視頻質量良好的情況下，MCU的最大接入終端數(shù)(MCU的容量)是不同的。測試發(fā)現(xiàn)，本文設計的MCU在運動量比較大(n=16的時候)時，音視頻圖像良好；n=20的時候，音視頻效果基本可以接收，但是偶爾圖像有失真；而在n=32時，圖像色彩嚴重失真，聲音斷斷續(xù)續(xù)。同時再考慮圖像時延和延遲抖動(話音和圖像的同步)等視頻會議的規(guī)定值(點對點的圖像時延不超過150 ms，延遲抖動約為400ms)?？梢缘贸觯涸趫D像質量良好，圖像時延和延遲抖動均能達到規(guī)定要求的情況下，本MCU的單臺容量應為16。