多媒體客戶端視音訊引擎的設計與實現
摘要：文章基於當前視音訊技術的特點，根據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 結語
綜上所述，本引擎設計符合要求，且能夠提供實時、高效和穩定的視音訊服務。