多媒體客戶端視音頻引擎的設計與實現

摘要：文章基於當前視音頻技術的特點，根據DirectX技術的採集與播放方案，融合H.264和Speex的編解碼技術，設計了一套多媒體視音頻引擎的實現方案。本引擎的實現結合了多媒體客戶端視音頻數據處理過程的每個環節，屏蔽了應用開發人員複雜的視音頻底層概念，提供了引擎開發的清晰接口，並實現了實時、高效和穩定的服務。經實際測試表明，本引擎符合要求。

關鍵詞：視音頻引擎 DirectX H.264 Speex

中圖分類號：TP391.41 文獻標識碼：A 文章編號：1007-9416（2016）01-0000-00

1 引言

當前，大多數網絡視頻會議及實時工作平臺的工作方式都是依託多媒體客戶端開展的，在多媒體客戶端所能提供的服務當中，視音頻服務最爲重要，而且，伴隨着計算機網絡技術的不斷進步，視音頻服務已成爲其重中之重，因此，設計並實現高質量的視音頻引擎服務已成爲當前的熱點。本設計來源於互聯網會議系統的引擎開發項目，其目的是研發一套可以滿足實用功耗小、佔用帶寬低、主觀質量好要求，且可以支持互聯網會議服務的視音頻引擎系統，該引擎可以提供應用開發人員多樣模式的接口，從而使用戶獲得更好的實際體驗，進而降低了互聯網會議系統研製的成本。

2 視音頻引擎的'設計與實現

視音頻引擎所要提供的服務，首先是對視音頻數據的採集。在視音頻編解碼技術中，H.264及Speex以其良好的實用性被用戶廣泛使用，所以，本設計選用H.264及Speex作爲終端編解碼方式。據引擎功能的實現，可將其分爲三個應用模塊：（1）視音頻數據採集模塊；（2）視音頻數據編解碼模塊；（3）視音頻數據播放模塊。文中引擎的設計就是依據上述三個模塊進行研究的。

2.1 視音頻數據採集

引擎提供的視音頻服務，首先是對其數據進行採集，視頻和語音的採集是在攝像頭與麥克風打開的同時進行的。

2.1.1 視音頻設備的獲取

在採集的初始時刻，應用程序先判定系統中視音頻設備的可用性，然後通過DirectSho創建系統設備的明細表，這樣可以便與選擇相應的設備來進行工作。當設備選定後，程序將記錄該設備的ID，並開始數據捕捉。

2.1.2 視音頻數據的捕獲

在獲取設備的ID後，開始捕捉數據，系統通過辨認ID來打開指定設備，同時開始數據採集，並通過回調函數MMGrabber取出視音頻數據。

（1）IcaptureGraphBuilder2接口初始化。對於應用DirectSho實現的視音頻捕捉，在建立應用程序時，DirectSho提供一個名爲Capture Graph Builder的對象，並提供一個IcaptureGraphBuilder2的接口，通過調用該接口可實現Capture Graph的建立與控制。在建立視頻捕捉程序時，應先獲取並初始化IcaptureGraphBuilder2接口，然後選擇視頻捕捉設備。（2）創建Capture filter。在完成接口初始化並選定設備後，應創建對應設備的Capture filter。創建完畢後，通過調用AddiFilter將對應設備的Capture filter添加到Filter Graph中，從而開始視音頻數據的採集。（3）實現視音頻數據捕獲。在完成設備Capture filter的創建及添加後，啓動系統程序並運行，此時DirectSho將實時捕獲的對應視音頻設備的視頻數據，並交送給系統的編解碼模塊，從而進行後續的視音頻壓縮編解碼處理。

2.2 視音頻數據編解碼

爲了減小互聯網傳輸數據量的容量，視音頻數據必須要經過壓縮處理，所以，要選取合適的視音頻編解碼方案纔可實現互聯網終端的快速傳輸。在本設計中，分別以H.264和Speex作爲視音頻的編解碼方式，從而實現數據的壓縮與解壓縮處理。

視音頻數據的編解碼操作分爲：發送端編碼操作和接收端解碼操作。

2.2.1 發送端編碼處理

（1）編碼器創建。圖1所示爲發送端編碼處理的流程圖，由圖1可知，發送端編碼處理的初始環節是要進行編碼器的創建，編碼器的工作是對視音頻幀進行編碼。本設計採用Video_CreateEncoder來創建編碼器，在創建編碼器前，預先定義需要的變量。（2）動態調整參數。在視音頻編碼器創建後，需要啓動運行過程中的動態參數調整許可，即允許動態設置編碼器參數。當參數重設後，編碼器將根據新的參數進行操作。對於重置編碼參數，需要調用數x264_param_parse重置參數，並且需調用x264_encoder_reconfig進行參數更新。（3）視音頻編碼。當編碼器創建完成之後，採用video_EncodeFrame對視音頻數據進行編碼。在編碼處理時，通過相應參數確定編碼器ID，之後，傳入內存中的初始數據信息。四、銷燬編碼器。當完成視音頻數據的編碼操作後，需要銷燬已經建立好的編碼器，此時，需要調用函數 video_ReleaseEncoder來完成。當調用video_release_encoder時，其內部會調用x264_picture_clean清理對應編碼器裏的結構空間，並應用x264_encoder_close銷燬編碼器。

2.2.2 接收端解碼處理

（1）解碼器創建。圖2所示爲接收端解碼處理的基本流程圖。在程序初始化時，程序首先會創建一個解碼器。同創建編碼器相比，程序將採用函數video_create_decoder創建一個解碼器。程序首先繪製遍歷鏈表，並查找H.264和Speex解碼器，之後初始化參數，同時，解碼器的創建操作也相應完成。（2）數據幀解碼。在解碼器創建完成後，開始進行解碼操作。當已壓縮好的視頻數據被轉入接收端時，創建的解碼器將進行視音頻幀數據解碼。在解壓操作完成後，將會轉入播放接口進行視音頻播放。爲了便於操作，設置視音頻數據解碼操作函數video_decode_frame爲雙輸入型，除了需制定解碼器的ID外，就是定製兩段存儲空間，其中一段存儲解碼前信息，另一段存儲解碼後信息。（3）銷燬解碼器。解碼器與編碼器的創建於銷燬都是相對應的，均是資源的分配與回收。當程序結束時，爲了釋放所佔用的資源，爲後續操作留下足夠空間，需要銷燬解碼器。當應用程序結束時，會按照流程銷燬解碼器，通過調用函數video_ReleaseDecoder和x264_encoder_close來釋放解碼器所佔資源和銷燬編碼器。 2.3 視音頻數據播放

2.3.1 視頻播放

在解碼處理後，需要在窗口中顯示圖像，這時應使用顯示窗口函數進行處理。

（1）視頻顯示窗口創建。視頻顯示仍需要DirectSho支持，首先，應創建一個視頻顯示窗口。由於程序的運行環境是在indos系統下進行的，所以，在視頻顯示窗口創建時，應將indos句柄作爲參數輸入。在結束視頻窗口操作時，同樣，會釋放視頻窗口資源。在窗口創建後，需要顯示緩衝區的數據，此時，應輸入一些窗口的對應參數以完成視頻顯示準備。（2）視頻顯示。無論針對本地圖像或是遠端圖像，都將使用顯示功能函數來獲取支持。本系統設計了Render系列函數來支持這些功能，render_CreateRender、render_DraBuffer和render_ReleaseRender，分別實現創建一個視頻顯示窗口、顯示緩衝區中數據和釋放一個視頻顯示窗口。在視頻圖像顯示時，仍需要使用DirectDra接口來輔助完成。

2.3.2 音頻播放

對於音頻播放，應首先創建DirectSound對象，然後填充DSBUFFERDESC結構（該結構體保存了緩衝區的重要信息）。DirectSound播放聲音的難點是對緩衝存儲區處理，其中關鍵環節就是對緩衝存儲區的加鎖操作，由於要保證聲音的連續播放，就需不斷的循環緩衝區內存數據。在聲音播放時，負責讀取數據的讀指針伴隨着讀取的進行而不斷向前，當移動到存儲空間的結束位置時，將跳到緩衝存儲區的開始位置繼續進行讀操作。添加數據的寫指針必須滯後於播放數據的讀指針，只有這樣才能保證播放的連貫。在實際操作時，設置通知點是較易出錯的地方。在DirectSound中，LPDIRECTSOUNDNOTIFY結構體SetNotificationPositions函數負責設置通知點。在定義通知點時，需要設定好DSBPOSITIONNOTIFY結構（保存着通知點距離內存起始位置的偏移量以及系統時間通知句柄）。當負責播放的遊標到達通知所在的偏移位置時，程序就會產生一個事件，此時調用Lock函數鎖住寫遊標的位置，然後開始執行寫操作，寫入數據的長度爲兩個通知點的實際聚類。在寫入數據完成後，需要解鎖緩衝區。在實現聲音混音和回放時，需創建IDirectSound對象，同時，DirectSound自動創建主緩衝區，但是，輔助緩衝區需自主創建。在調用輔助緩衝區時，也要使用加鎖和解鎖、機制和通知機制來輔助完成。

2.4 視音頻引擎的測試

局域網視音頻測試對比分析了本視音頻引擎與一款商業視頻引擎的測試程序。在圖像方面，測試項目包括圖像質量、帶寬、CPU佔用率。在語音方面，測試項目只爲其主觀收聽效果。圖像測試效果分析：在局域網測試中，網絡帶寬可以保證的情況下，圖像質量較優，且清晰度較好；網絡狀況擁堵時，圖像偶爾會產生局部信息匱乏，但不影響視覺效果。語音測試效果分析：在局域網測試中，網絡帶寬可以保證的情況下，聲音質量較優，聲音也很流暢；在網絡狀況擁堵時，聲音偶爾會產生中斷，但不影響收聽效果。對於回聲的消除，當網絡延遲較小時，本引擎的回聲消除效果比較明顯。

3 結語

綜上所述，本引擎設計符合要求，且能夠提供實時、高效和穩定的視音頻服務。