基于H.323高性能MCU的設計與實現

摘 要:針對基于H.323協議的Openh323開源視頻會議系統中源MCU容納終端有限，圖像質量差等缺陷，在VC++6.0開發平臺上，采用基于幀緩沖映射軟交換技術改進源碼中的MCU，提高其存儲轉發的能力，從而增加參與視頻會議的終端;在占用較少CPU資源的同時，有效提高其傳輸速率，并縮短了傳輸時延，取得了良好的測試結果。

關鍵詞:H.323;OpenH323;MCU;幀緩沖映射;軟交換

中圖分類號:TN919.8;TP393 文獻標識碼:A 文章編號:1004-373X(2010)04-137-04

Design and Realization of High-performance MCU Based on H.323

HUANG Zhi，WANG Ping，QIU Hao，GAO Yujie

(Guangxi Region Meteorological Information Center，Nanning，530022，China)

Abstract:The paper deals with the problem that the limit of MCU accepts less endpoints and the poor quality of images- synthesis in Openh323 open source video conferencing system which basing on H323 protocol.It is available to adopt soft exchange with frame-buffer-mapping to improve its stored-and-forward ability and increase more terminal participating in system.While taking the few CPU resources，raising its transmission speed effectively and reducing the transmission delay by use of VC6.0 platform，and getting batter results.

Keywords:H.323;OpenH323;MCU;frame-buffer-mapping;soft exchange

0 引 言

隨著計算機的硬件，特別是CPU主頻的不斷提升，基于軟件的音、視頻編碼效率也越來越高，因此考慮到成本與各方面的因素，軟件MCU必然成為以后的主流方向。但現今大多的MCU都是軟硬件相結合，純軟件的MCU很少且效率不高。

當前H.323視頻會議系統大都是以Openh323協議庫為基礎開發的視頻和語音傳輸系統軟件。Openh323是由澳大利亞Equivalence Pty Ltd.公司組織開發的，能實現基本的H.323協議框架，在Openh323 V4中，基于視頻緩存池的MCU最多只能處理合成4路終端，不能適應現今市場發展的需要，因此重新設計MCU的架構，便成為研發軟件MCU的關鍵[1-3]。

1 源MCU的缺陷和不足

(1) OpenH323中源MCU只能形成不超過4個終端畫面的圖像。其中，4×1為CIF格式(352×288);1×1為QCIF格式(176×144)，因此視頻混合存在兩種不同方式，包括QCIF格式源圖像混合成CIF格式圖像以及CIF格式源圖像混合成CIF格式圖像，如圖1所示。

圖1 傳統MCU圖像合成

當源圖像為QCIF格式時，源圖像大小正好是混合后圖像大小的1/4，這時可以將源圖像整幅地拷貝到混合圖像的相應位置;當源圖像為CIF格式時，源圖像與混合后圖像的大小一樣，因此源圖像3/4的像素必須被丟掉，采用的方法是:對源圖像在水平方向進行隔點采樣，在垂直方向進行隔行采樣。這樣處理之后，源圖像大小也正好是混合后圖像大小的1/4，雖然圖像的分辨率已經下降，但是保持了源圖像畫面的完整性;如果將MCU變成可容納16個終端的顯示畫面[4]，在將QCIF源圖像轉換為CIF的合成圖像過程中，只能將源圖像的采樣點按倍數減少。也就是將CIF格式等分為16份，相當于用88×72的像素點去存儲176×144 QCIF圖像，合成圖像顯示的像素點只有源圖像的1/4;如果將MCU可容納的終端數目擴大為32，甚至更多時，圖像的清晰度將大打折扣。

(2) 傳統軟件MCU的架構是從硬件MCU繼承過來的，MCU包括MC和MP部分。MC部分對終端進行連接控制以及邏輯通道的管理;MP部分對音頻進行混合，視頻進行合成。傳統MCU的設計如圖2所示，這種架構適用于硬件MCU;但對用軟件實現的MCU并不太適合。用軟件實現的MCU的編解碼都是通過CPU來運算的，這樣必然增加CPU的運算負荷。例如:要編碼一路30 f/s的CIF(352×288)圖像，大概編碼后的字節數為30×352×288×2=6 MB，CPU要處理如此大的視頻數據量，經測試，P4-2.6 G的CPU在這種架構下，最多支持5路終端，如超過5路，CPU運算負荷過大，其資源基本耗盡，圖像合成的效果嚴重下降。

因此，要實現高性能的MCU，必須把MCU對多路音、視頻編碼的大數據量處理的工作環節轉移到各個終端上，讓終端對相應的音、視頻編碼進行處理，而MCU只對各路的音視頻流進行存儲轉發，這樣才能減輕MCU的負荷，從而提高系統的整體效率。

圖2 傳統MCU設計圖

2 幀緩沖映射的軟交換模式的MCU的設計

綜上所述，在此提出采用基于幀緩沖映射軟交換的MCU系統設計模式，所謂的軟交換模式就是仿照交換機的模式，不對音、視頻流進行編解碼的處理，只對數據進行轉發與控制。

該MCU也包括MC與MP。基于軟交換的MP，通過幀緩沖映射算法，查找終端對應的緩沖區，然后到把接收到的音、視頻流存放到該緩沖區里面，通過MC控制，把音、視頻數據流轉發到終端。

2.1 MC部分總體設計思想

MC部分的設計主要包括會議組管理、會議RTP流轉發管理。

(1) 會議管理。

該系統只默認一組會議，且默認的會議房間為“room101”。對一組會議來說，主要管理會議的成員信息，處理與會者的加入與退出等。為了實現這些功能，建立一個會議組類、成員信息類、成員狀態類、成員身份類和成員視頻緩沖類。會議組類主要記錄終端所選的會議ID;成員信息類主要記錄終端的Token，IP地址等信息;成員類狀態主要記錄成員是否在線;成員身份類可以確定是主席，還是聽眾;成員視頻緩沖類主要是存放在線各個終端的RTP包，一個緩沖類里面可以存在多個緩沖區。MC首先通過設定TCP特定的端口，并在端口上建立一個TCP監聽線程，終端通過這個端口與MCU進行TCP連接，并由MC建立一個H.225呼叫線程，用于監聽H.225呼叫信令，通過這個H.225通道，終端把自己的會議組ID，IP，Token等身份認證注冊到MC。

圖3為MC的會議管理系統框圖。

圖3 MC會議管理系統框圖

(2) 會議RTP流轉發管理。

MCU對登陸終端進行注冊后，MC建立一個H.245控制信令線程，并與該終端進行連接控制，通過H.245控制信令與MC進行呼叫、信令處理與能力協商、主從決定;然后建立音、視頻的接收邏輯通道，通過RTP接收類開始接收終端發送的RTP幀，把RTP幀保存到分配給該終端緩存區里。MC為已經進行了呼叫連接的終端分配了一一對應的視頻緩沖接收區，該緩沖區是一個分配在堆里面的數據結構，例如:在終端A的在線人員列表上，可以看到登陸注冊到MCU的人員名單;通過對終端的人員名單的選擇，例如選擇B，那么終端A可以要求MC轉發終端B的音、視頻，當MC收到終端A提交的要求轉發終端B的信息后，在 MC的A終端緩沖池里面，為終端B新建一個緩沖區，通過MP對終端B的Token的幀緩沖映射查找到終端B的音視頻緩沖池，并在終端A與終端B之間建立一條邏輯通道，用于向終端A傳輸終端B的RTP包，當MC的終端A緩沖類接收到終端B的RTP包后，把RTP包拷貝到原來的接收緩沖區里;然后同樣把終端B的惟一Token通過哈希函數映射到這個緩沖區上。

圖4為MC的RTP管理系統框圖。MC的軟交換模式如圖5所示。

圖4 MC的RTP管理系統框圖

圖5 基于軟交換的MCU

2.2 MP部分總體設計思想

基于軟交換的MP，通過幀緩沖映射算法查找終端對應的緩沖區，然后把接收到的音、視頻流存放到該緩沖區里面，通過MC的控制，把音、視頻數據流轉發到終端。由于MCU需要處理大量的實時RTP包，效率成為了最主要的問題。因此如何從緩沖區里面快速搜索相應的數據包是 MP能否快速處理數據的關鍵。考慮到MP要處理不同的終端，不同的終端對應不同的緩沖區，所以采用哈希函數映射法，它將任意長度的二進制值映射為固定長度的較小二進制值，并把這個哈希表存放到相應的內存區，以便多次的查找，這樣通過這個較小的二進制值就可以以非常快的速度找到比較大的數值。因此把視頻緩沖區的首地址存放到一個哈希表里面，并通過這個哈希表把終端的Token映射于這個緩沖區，這樣通過終端的惟一Token便可以迅速找到其對應的緩沖區。

實現MP部分幀緩沖映射算法的具體設計步驟是:首先MCU把登陸的在線終端Token(終端的惟一標識)與會議ID默認為room101，通過哈希函數，映射到一個緩沖區，通過終端的Token和會議ID，就可以直接找到本終端的緩沖區，當MP收到終端的RTP包后，通過RTP包的邊界分析，把多個RTP合成一個數據幀，然后把數據幀放到相應的終端緩沖區里面。幀緩沖映射的查找如圖6所示。假設當終端A要求轉發終端B的音、視頻數據流時，MP通過哈希函數找到相應終端B的緩沖區域，然后把該緩沖區的數據讀出到數據幀里面，最后通過RTP包進行發送到終端A，而終端A在接收到MCU發送的終端B的音視頻數據壓縮包后，再對其進行音視頻進行解碼。

圖6 幀緩沖映射查找圖

2.3 MCU系統實現

根據以上的設計思想，得出如圖7所示的MCU系統流程圖。

圖7 MCU系統流程圖

2.4 測試結果與結論

通過重新設計MCU的MC和MP后，MCU的性能有了較大的提高。從性能方面進行測試，由于傳統的MCU在MC上進行編解碼，只能容納4路音、視頻終端，而通過修改的MCU，MC沒有進行編解碼，只對音、視頻進行存儲轉發，因此在9路音、視頻的情況下，系統的CPU只占有5%。從效率、質量方面進行比較，由于傳統的MCU進行了4路編解碼，返回到終端的數據包延遲比較大，而修改過的MCU沒有進行到編解碼，因此數據包的延時很小。傳統的MCU在MC里面進行圖像的混合，圖像的分辨率變為原來的1/4，因此圖像質量有較大的下降，而基于軟交換的MCU保持了原來圖像的分辨率，因此圖像質量較好。從視頻的幀數來比較，傳統的MCU架構不能達到15 f/s，而基于軟交換的MCU能達到30 f/s。由于基于軟交換的MCU的視頻傳輸的是原來圖像的分辨率，因此傳輸率比傳統的MCU要高，但可以通過在終端采用傳輸率較低的編碼器來降低傳輸率。表1為MCU改進前與改進后的對比。

表1 MCU改進前與改進后的對比數據

傳統的MCU架構基于軟交換的MCU架構

占用的CPU資源約60%約20%

支持的終端數量小于5路大于9路

音、視頻的延時大于2 s小于1 s

視頻的幀數小于15 f/s達到30 f/s

傳輸速率60 Kb/s125 Kb/s

終端的6分界面如圖8所示。

3 結 語

從以上的測試證明，基于軟交換的MCU架構，使MCU的性能有了很大的提高。本文同時也說明了只要系統程序設計合理，基于軟件的MCU是切實可行的。隨著硬件水平的不斷提高，純軟件的MCU將以其低成本、簡易操作而普及到低端用戶。

圖8 終端6分屏界面

參考文獻

[1]齊小謙.如何運用Openh323協議棧來開發VoIP軟件[J].無線電通信技術，2004，30(6):55-57.

[2]黃志，覃團發.基于OpenH323視頻會議系統控件ActiVeX的實現[A].第十二屆全國青年通信學術會議論文集[C].2007.

[3]畢敏娜，王清陽，胥布工.基于H.323的視頻會議系統及應用[J].微計算機信息，2006，22(15):156-158.

[4]Equivalence Pry Ltd.OpenH323和PWLib類庫[EB/OL].http://www.openh323.org，2002.

[5]劉袆瑋.Visual C++視頻/音頻開發實用工程案例精選[M].北京:人民郵電出版社，2004.

[6]張益貞，劉滔.Visual C++實現MPEG/JPEG編解碼技術[M].北京:人民郵電出版社，2002.

[7]曹寧，閆朝敏.H.263壓縮協議在H.323會議系統中的嵌入[J].計算機工程， 2004，30(14):143-145.

[8]萬俊青，王興國.基于H.264標準的桌面視頻會議系統設計[J].電視技術，2005(2):73-76.

[9]ITU-T Recommendation.H.323 Version.Packet-based Multimedia Communication Systems，1998.

[10]林瑞仲，吳越.Visual C++.NET 類庫應用實例[M].北京:電子工業出版社，2003.