基于H.323 高性能MCU的設(shè)計與實現(xiàn)

0 引 言

隨著計 算機的 硬件, 特別 是 CPU 主 頻的不 斷提 升, 基于軟件的音、視頻編碼效率也越來越高, 因此考慮 到成本與各方面的因素, 軟件 MCU 必然成為以后的主 流方向。但現(xiàn)今大多的 MCU 都是軟硬件相結(jié)合, 純軟件的MCU 很少且效率不高。當前 H.323 視頻會議系統(tǒng)大都是以 Open h323 協(xié)議庫為 基 礎(chǔ) 開 發(fā) 的 視 頻 和 語 音傳輸系統(tǒng) 軟 件。 Openh323 是由澳大利亞 Equivalence PtyLtd。公司組 織開 發(fā) 的, 能 實 現(xiàn) 基 本 的 H.32 3 協(xié)議框 架, 在Openh323V4 中, 基于視頻緩存池的 MCU 最多只能處 理合成 4 路終端, 不能適應(yīng)現(xiàn)今市場發(fā)展的需要, 因此重新設(shè) 計 MCU 的 架 構(gòu), 便成為 研 發(fā) 軟 件 MCU 的關(guān)鍵 。

1 源MCU 的缺陷和不足

( 1) OpenH 3 23 中源 MCU 只能形成不超過 4 個終 端畫面的圖像。其中, 4 *1 為 CIF 格式 ( 35 2 * 28 8) ;1 * 1 為QCIF 格式( 176* 144) , 因此視頻混合存在兩種不同方式, 包括 QCIF 格式源圖像混合成CIF格式圖像以及 CIF格式源圖 像 混 合成 CIF 格 式 圖像, 如 圖 1所示。

圖 1 傳統(tǒng)MCU 圖像合成

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

( 2) 傳統(tǒng)軟件 MCU 的架構(gòu)是從硬件 MCU 繼承過 來的, MCU 包括 MC 和 MP 部分。MC 部分對終端進 行連接控制以及邏輯通道的管理; MP 部分對音頻進行混合, 視頻進行合成。傳統(tǒng) MCU 的設(shè)計如圖 2 所示, 這種架構(gòu)適用于硬件 MCU ; 但對用軟件實現(xiàn)的 MCU 并不太適合。用軟件實現(xiàn)的 MCU 的編解碼都是通過 CPU 來運算 的, 這樣 必然增加 CPU 的運算 負荷。例 如: 要編碼一路 30 f/ s 的 CIF ( 352 * 288 ) 圖像, 大概編 碼后的字節(jié)數(shù)為 30 * 3 52 * 28 8 * 2 = 6 MB, CPU 要處 理如此大的視頻數(shù)據(jù)量, 經(jīng)測試, P4- 2.6 G 的 CPU 在 這種架構(gòu)下, 最多支持 5 路終端, 如超過 5 路, CPU 運 算負 荷過大, 其資源 基本耗盡, 圖像 合成的效 果嚴重 下降。因此, 要實現(xiàn)高性能的 MCU , 必須把 MCU 對多路音、視頻編碼的大數(shù)據(jù)量處理的工作環(huán)節(jié)轉(zhuǎn)移到各個終 端上, 讓終端對相應(yīng)的音、視頻編碼進行處理, 而 MCU 只對各路 的音 視頻 流 進行 存 儲轉(zhuǎn) 發(fā), 這 樣才 能 減輕MCU 的負荷, 從而提高系統(tǒng)的整體效率。

圖 2 傳統(tǒng) M C U 設(shè)計圖

2 幀緩沖映射的軟交換模式的 MCU 的設(shè)計

綜上所述, 在此提出采用基于幀緩沖映射軟交換的 MCU 系統(tǒng)設(shè)計模式, 所謂的軟交換模式就是仿照交換 機的模式, 不對音、視頻流進行編解碼的處理, 只對數(shù)據(jù) 進行轉(zhuǎn)發(fā)與控制。該MCU 也包括 MC 與 MP?；谲浗粨Q的 MP ,通過幀緩沖映射算法, 查找終端對應(yīng)的緩沖區(qū), 然后到把接收到的音、視頻流存放到該緩沖區(qū)里面, 通過 MC控制, 把音、視頻數(shù)據(jù)流轉(zhuǎn)發(fā)到終端。

2. 1 M C 部分總體設(shè)計思想

MC 部分的設(shè)計 主要包括會議組 管理、會 議 RTP流轉(zhuǎn)發(fā)管理。
( 1) 會議管理。該系統(tǒng)只默認一組會議, 且默認的 會議房間為/ r oom1010 。對一組會議來說, 主要管理會 議的成員信息, 處理與會者的加入與退出等。為了實現(xiàn) 這些功能, 建立一個會議 組類、成員信息 類、成員狀 態(tài) 類、成員身份類和成員視頻緩沖類。會議組類主要記錄 終端所選的會議 ID; 成員信息類主要記錄終端的 To- ken , IP 地址等信息; 成員類狀態(tài)主要記錄成員是否在 線; 成員身份類可以確定是主席, 還是聽眾; 成員視頻緩 沖類主要是存放在線各個終端的 RTP 包, 一個緩沖類 里面可以存在多個緩沖區(qū)。MC 首先通過設(shè)定 TCP 特 定的端口, 并在端口上建立一個 TCP 監(jiān)聽線程, 終端通 過這個端 口與 MCU 進 行 TCP 連 接, 并由 MC 建 立 一個H.225 呼叫線程, 用于監(jiān)聽 H.22 5 呼叫信令, 通過 這個 H.225 通道, 終端把自己的會議組 ID, IP, Token 等身份認證注冊到 MC。圖 3 為 MC 的會議管理系統(tǒng)框圖。

圖 3 MC 會議管理系統(tǒng)框圖

( 2) 會議 RTP 流轉(zhuǎn)發(fā)管理。MCU 對登陸終端進 行注冊后, MC 建立一個 H. 245 控制信令線程, 并與該終 端進行連接控制, 通過 H.245 控制信令與 MC 進行呼叫、 信令處理與能力協(xié)商、主從決定; 然后建立音、視頻的接 收邏輯通道, 通過 RTP 接收類開始接收終端發(fā)送的 RTP 幀, 把 RT P 幀保存到分配給該終端緩存區(qū)里。MC 為已 經(jīng)進行了呼叫連接的終端分配了一一對應(yīng)的視頻緩沖接 收區(qū), 該緩沖區(qū)是一個分配在堆里面的數(shù)據(jù)結(jié)構(gòu), 例如: 在終端 A 的在線人員列表上, 可以看到登陸注冊到 MCU 的人員名單; 通過對終端的人員名單的選擇, 例如選擇 B, 那么終端 A 可以要求 MC 轉(zhuǎn)發(fā)終端 B 的音、視頻, 當MC 收到終端 A 提交的要求轉(zhuǎn)發(fā)終端 B 的信 息后, 在MC 的 A 終端緩沖池里面, 為終端 B 新建一個緩沖區(qū), 通 過 MP 對終端 B 的 Token 的幀緩沖映射查找到終端 B 的 音視頻緩沖池, 并在終端 A 與終端 B 之間建立一條邏輯 通道, 用于向終端 A 傳輸終端 B 的 RTP 包, 當 MC 的終 端 A 緩沖類接收到終端 B 的 RTP 包后, 把 RTP 包拷貝 到原來的接收緩沖區(qū)里; 然后同樣把終端 B 的惟一 Token 通過哈希函數(shù)映射到這個緩沖區(qū)上。
圖 4 為 MC 的 RTP 管理系統(tǒng)框圖。MC 的軟交換模式如圖 5 所示。

圖 4 MC 的RTP 管理系統(tǒng)框圖

圖 5 基于軟交換的 MCU

2. 2 MP 部分總體設(shè)計思想

基于軟交換的 MP, 通過幀緩沖映射算法查找終端 對應(yīng)的緩沖區(qū), 然后把接收到的音、視頻流存放到該緩沖 區(qū)里面, 通過 M C 的控制, 把音、視頻數(shù)據(jù)流轉(zhuǎn)發(fā)到終端。 由于 MCU 需要處理大量的實時 RTP 包, 效率成為了最 主要的問題。因此如何從緩沖區(qū)里面快速搜索相應(yīng)的數(shù) 據(jù)包是 M P 能否快速處理數(shù)據(jù)的關(guān)鍵。考慮到 M P 要處 理不同的終端, 不同的終端對應(yīng)不同的緩沖區(qū), 所以采用 哈希函數(shù)映射法, 它將任意長度的二進制值映射為固定 長度的較小二進制值, 并把這個哈希表存放到相應(yīng)的內(nèi) 存區(qū), 以便多次的查找, 這樣通過這個較小的二進制值就 可以以非?？斓乃俣日业奖容^大的數(shù)值。因此把視頻緩 沖區(qū)的首地址存放到一個哈希表里面, 并通過這個哈希 表把終端的Token 映射于這個緩沖區(qū), 這樣通過終端的 惟一Token 便可以迅速找到其對應(yīng)的緩沖區(qū)。
實現(xiàn) MP 部分幀緩沖映射算法的具體設(shè)計步驟是: 首先 MCU 把登陸的在線終端 Token ( 終端的惟一標識) 與會議 ID 默認為 room101, 通過哈希函數(shù), 映射到一個 緩沖區(qū), 通過終端的 Tok en 和會議 ID, 就可以直接找到 本終端 的緩沖區(qū), 當 MP 收到 終端的 RTP 包后, 通 過 RTP 包的邊界分析, 把多個 RTP 合成一個數(shù)據(jù)幀, 然后 把數(shù)據(jù)幀放到相應(yīng)的終端緩沖區(qū)里面。幀緩沖映射的查 找如圖 6 所示。假設(shè)當終端 A 要求轉(zhuǎn)發(fā)終端 B 的音、視 頻數(shù)據(jù)流時, M P 通過哈希函數(shù)找到相應(yīng)終端 B 的緩沖區(qū)域, 然后把該緩沖區(qū)的數(shù)據(jù)讀出到數(shù)據(jù)幀里面, 最后通 過 RTP 包進行發(fā)送到終端 A , 而終端 A 在接收到 MCU 發(fā)送的終端 B 的音視頻數(shù)據(jù)壓縮包后, 再對其進行音視 頻進行解碼。

圖 6 幀緩沖映射查找圖

2. 3 MCU 系統(tǒng)實現(xiàn)

根據(jù)以上的設(shè)計思想, 得出如圖 7 所示的 MCU 系統(tǒng)流程圖。

圖 7 MCU 系統(tǒng)流程圖

2. 4 測試結(jié)果與結(jié)論

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

表1 MCU 改進前與改進后的對比數(shù)據(jù)

傳統(tǒng)的 架構(gòu) 基于軟交換 的 MCU 架構(gòu)占用的 CPU 資源 約 60% 約 20% 支持的終端數(shù)量 小于 5 路 大于 9 路 音、視頻的延時 大于 2 s 小于 1 s視頻的幀數(shù) 小于 15 f / s 達到 30 f/ s傳輸速率 60 K b/ s 125 K b/ s終端的 6 分界面如圖 8 所示。

圖8 終端6 分屏界面

3 結(jié) 語

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