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

0 引 言

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

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 傳統MCU 圖像合成

當源圖像為QCIF格式時, 源圖像大小正好是混合 后圖像大小的1/4, 這時可以將源圖像整幅地拷貝到混 合圖像的相應位置; 當源圖像為 CIF 格式時, 源圖像與 混合后圖像的大小一樣, 因此源圖像 3/ 4 的像素必須被 丟掉, 采用的方法是: 對源圖像在水平方向進行隔點采 樣, 在垂直方向進行隔行采樣。這樣處理之后, 源圖像 大小也正好是混合后圖像大小的 1/ 4 , 雖然圖像的分辨 率已經下降, 但是保持了源圖像畫面的完整性; 如果將MCU 變成可容納 16 個終端的顯示畫面, 在將 QCIF 源圖像轉換為 CIF 的合成圖像 過程中, 只能將源圖像 的采 樣點按倍數減少。也 就是將 CIF 格 式 等 分 為16 份, 相 當 于 用 88 * 7 2 的 像 素 點 去 存 儲 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 * 3 52 * 28 8 * 2 = 6 MB, CPU 要處 理如此大的視頻數據量, 經測試, P4- 2.6 G 的 CPU 在 這種架構下, 最多支持 5 路終端, 如超過 5 路, CPU 運 算負 荷過大, 其資源 基本耗盡, 圖像 合成的效 果嚴重 下降。因此, 要實現高性能的 MCU , 必須把 MCU 對多路音、視頻編碼的大數據量處理的工作環節轉移到各個終 端上, 讓終端對相應的音、視頻編碼進行處理, 而 MCU 只對各路 的音 視頻 流 進行 存 儲轉 發, 這 樣才 能 減輕MCU 的負荷, 從而提高系統的整體效率。

圖 2 傳統 M C U 設計圖

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

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

2. 1 M C 部分總體設計思想

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

圖 3 MC 會議管理系統框圖

( 2) 會議 RTP 流轉發管理。MCU 對登陸終端進 行注冊后, MC 建立一個 H. 245 控制信令線程, 并與該終 端進行連接控制, 通過 H.245 控制信令與 MC 進行呼叫、 信令處理與能力協商、主從決定; 然后建立音、視頻的接 收邏輯通道, 通過 RTP 接收類開始接收終端發送的 RTP 幀, 把 RT P 幀保存到分配給該終端緩存區里。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, 通過幀緩沖映射算法查找終端 對應的緩沖區, 然后把接收到的音、視頻流存放到該緩沖 區里面, 通過 M C 的控制, 把音、視頻數據流轉發到終端。 由于 MCU 需要處理大量的實時 RTP 包, 效率成為了最 主要的問題。因此如何從緩沖區里面快速搜索相應的數 據包是 M P 能否快速處理數據的關鍵。考慮到 M P 要處 理不同的終端, 不同的終端對應不同的緩沖區, 所以采用 哈希函數映射法, 它將任意長度的二進制值映射為固定 長度的較小二進制值, 并把這個哈希表存放到相應的內 存區, 以便多次的查找, 這樣通過這個較小的二進制值就 可以以非?？斓乃俣日业奖容^大的數值。因此把視頻緩 沖區的首地址存放到一個哈希表里面, 并通過這個哈希 表把終端的Token 映射于這個緩沖區, 這樣通過終端的 惟一Token 便可以迅速找到其對應的緩沖區。
實現 MP 部分幀緩沖映射算法的具體設計步驟是: 首先 MCU 把登陸的在線終端 Token ( 終端的惟一標識) 與會議 ID 默認為 room101, 通過哈希函數, 映射到一個 緩沖區, 通過終端的 Tok en 和會議 ID, 就可以直接找到 本終端 的緩沖區, 當 MP 收到 終端的 RTP 包后, 通 過 RTP 包的邊界分析, 把多個 RTP 合成一個數據幀, 然后 把數據幀放到相應的終端緩沖區里面。幀緩沖映射的查 找如圖 6 所示。假設當終端 A 要求轉發終端 B 的音、視 頻數據流時, M P 通過哈希函數找到相應終端 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 路編解碼, 返回到終端的數據包 延遲比較大, 而修改過的 M CU 沒有進行到編解碼, 因 此數據包的延時很小。傳統的 MCU 在 MC 里面進行 圖像的混合, 圖像的分辨率變為原來的 1/ 4, 因此圖像 質量有較大的下降, 而基于軟交換的 MCU 保持了原來 圖像的分辨率, 因此圖像質量較好。從視頻的幀數來比 較, 傳統的 M CU 架構不能達到15 f/ s, 而基于軟交換的 MCU 能達到 30 f / s 。由于基于軟交換的 MCU 的視頻 傳輸的是 原來 圖像 的 分辨 率, 因 此 傳輸 率比 傳 統的 MCU 要高, 但可以通過在終端采用傳輸率較低的編碼 器來降低 傳輸 率。 表 1 為 M CU 改進 前與 改進 后的 對比。

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

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

圖8 終端6 分屏界面

3 結 語

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