基于DirectX的音頻視頻無線傳輸系統(tǒng)設計與實現(xiàn)

　　1引言

　　近些年來，多媒體技術，網(wǎng)絡技術和無線通信技術的迅速發(fā)展為相互之間的交叉融合奠定了基礎，也使其成為信息產(chǎn)業(yè)發(fā)展的必然趨勢，傳統(tǒng)的Internet主要提供數(shù)據(jù)業(yè)務，無線通信主要提供語音業(yè)務，而多媒體技術的日新月異，使得文本、語音及視頻綜合加入Internet與無線通信領域的需求日益增長。對于音視頻流的傳輸，如果采用TCP協(xié)議，由于TCP的檢錯和重傳機制會大大增加數(shù)據(jù)包的延時，因此不符合音視頻傳輸?shù)囊?，而如果單純采用UDP協(xié)議，由于UDP不提供任何的QoS保證，因此傳輸質(zhì)量不理想。而IETF制定的實時傳輸協(xié)議/實時傳輸控制協(xié)議(RTP/RTCP)使得在理論上具有提供多媒體實時傳輸?shù)哪芰Α?/P>

　　微軟推出的DirectX提供了與音視頻應用相關的SDK，開發(fā)者以此為跳板則可以較方便地實現(xiàn)語音與視頻的捕捉、網(wǎng)絡傳輸、解壓、回放等功能，并可以根據(jù)需要來訂制和擴充利用。

　　2系統(tǒng)概述

　　本系統(tǒng)設計應用于XXX設備與系統(tǒng)，主要實現(xiàn)前后方音頻與視頻的無線通信，音頻傳輸部分基于DirectPlayVoice實現(xiàn)，視頻傳輸部分基于DirectShow實現(xiàn)。采用典型的客戶端/服務器結構，服務器端主要包括音頻視頻的采集與壓縮以及數(shù)據(jù)發(fā)送，客戶端主要包括數(shù)據(jù)接收以及音頻視頻解壓播放，客戶端與服務器端通過無線網(wǎng)連接。系統(tǒng)結構如圖1所示。

　　3基于DirectPlay Voice的音頻傳輸

　　DireetPlay Voice是DirectX系統(tǒng)的成員之一，圖2顯示了應用DirectPlay Voice開發(fā)時可用的組件。

　　采用客戶端/服務器模式時，使用IdirectPlayVoice-Client和IdireetPlayVoiceServer接口創(chuàng)建并管理一個聲音會話。

　　3.1 混音

　　本系統(tǒng)實際應用中，經(jīng)常需要多人同時語音會話，因此對混音效果有很高要求，DireetPlayVoice提供了多人會話時混音功能，并且C/S模式下提供了客戶端混音，服務器混音兩種混音方式。

　　客戶端混音方式，通過轉發(fā)服務器拓撲結構，選擇會話中的一個客戶端電腦充當轉發(fā)服務器，每一個客戶端把語音數(shù)據(jù)流送到轉發(fā)服務器，轉發(fā)服務器負責把收到的所有客戶聲音數(shù)據(jù)送到每一個客戶端，然后每一個客戶端把接收到的音頻數(shù)據(jù)混音并播放。 服務器混音方式，選擇服務器端電腦作為混音服務器，每一個客戶端的聲音數(shù)據(jù)流到混音服務器上，混音服務器會檢測每個聲音流的目的地，完成解壓縮、混音，再壓縮，把混音的音頻數(shù)據(jù)送到每一個客戶端，每一個客戶端接受單一的預混和的音頻數(shù)據(jù)并播放。

　　3.2語音延時、抖動消除

　　在語音傳輸過程中，由于網(wǎng)絡等原因會發(fā)生語音延時、抖動，采取抖動緩沖技術，可以較好地解決這一問題。在接收方設定一個緩沖池，語音包到達時首先進入緩沖池暫存，系統(tǒng)以穩(wěn)定平緩的速率將語音包從緩沖池中取出、解壓，然后播放給受話者。如圖3(a)所示，這種緩沖技術可以在一定限度內(nèi)有效處理語音抖動，提高音質(zhì)。 為了確定呼話音包的正確時間間隔，在RTP的包頭上提供了一個時間戳(Time Stamp)，用于記錄這個呼包的產(chǎn)生時間。在發(fā)送端網(wǎng)關產(chǎn)生的呼包①經(jīng)過A，B的時間間隔和B，C的時間間隔均為20ms，如圖3(b)所示;經(jīng)過網(wǎng)絡傳輸，在接收端收到的呼包②的B，C的時間間隔變成了30ms;為了恢復原有的時間間隔，接收端網(wǎng)關根據(jù)每個呼包的RTP時間戳來確定呼包③的正確時間間隔，把他們恢復成原來的20ms向下一級設備發(fā)送。由于消抖動緩存池不是在接收到每一個話音包的情況下就立即轉發(fā)，因此還要確定適當?shù)霓D發(fā)延時的大小。如果延時太長，就會使系統(tǒng)整體的延時變得很長;如果延時太短，話音包在允許的時間范圍內(nèi)沒有到達，話音仍會出現(xiàn)抖動現(xiàn)象，緩存池的作用不很明顯。取兩者平衡點的結果使緩存器的網(wǎng)絡延時保持在40ms左右。

　　本系統(tǒng)實現(xiàn)時提供了兩種混音方式和多種音頻編碼類型可選，因此能夠適應網(wǎng)絡帶寬較差的環(huán)境，提供的編碼類型如下：MS-PCM 64kb/s，MS-ADPCM 32.8kb/s，Microsoft GSM6.10 13kb/s，True Speech(TM)8.6kb/s，Voxware SC03 3.2 kb/s，'Voxware SC06 6.4kb/s。

　　4基于DirectShow的視頻傳輸

　　DirectShow是一套完全基于COM的應用系統(tǒng)，COM組件有3種類型：進程內(nèi)組件、本地組件和遠程組件。Filter一般是一種進程內(nèi)組件，以動態(tài)鏈接庫(Dell)的形式提供服務。在Dir。ectShow體系結構中，F(xiàn)ilter是最基本的模塊。DirectShow對流媒體的處理是分步進行的，每項特定的處理由特定的Filter。來完成。Filter主要有3類：SourceFilters，Transform Filters和Render ing Filters。 SourceFilters主要負責取得數(shù)據(jù)，然后將數(shù)據(jù)往下傳輸;Trans-form Fitlers主要負責數(shù)據(jù)的格式轉換、傳輸;RenderingFiltes主要負責數(shù)據(jù)的最終去向。

　　視頻傳輸結構框圖如圖4所示：在發(fā)送端，采集卡捕獲的視頻數(shù)據(jù)經(jīng)過Divx MPEG-4 LOW-Motion Filter編碼壓縮，然后進行RTP打包，再發(fā)送到網(wǎng)絡上。接收端使用RTP解包，Divx MPEG-4 Receivet Filter接收并緩沖視頻流，然后由Divx Decoder Filter進行解碼，由VideoRenderer Filter播放。同時引入RTCP進行傳輸質(zhì)量控制。

　　4.1視頻的壓縮與編碼

　　在視頻傳輸?shù)倪^程中，服務器和客戶端的視頻壓縮、解壓縮過程至關重要，視頻的流量非常龐大，網(wǎng)絡帶寬的占用隨著用戶的增加大幅增長，這在要求高質(zhì)量視頻的時候最為突出。針對這種情況，選擇MPEG-4視頻壓縮算法，以提供高質(zhì)量的視頻質(zhì)量。與現(xiàn)有的標準相比，在可比擬速率上，MPEG-4標準能提供更好的主觀視覺質(zhì)量的圖像，一般來說MPEG-4的壓縮倍數(shù)高達100倍。MPEG-4具有很強的容錯性，這使得他廣泛應用在各種媒體中，尤其在易發(fā)生嚴重錯誤的低比特率應用中，MPEG-4將提高抗錯誤能力。

　　4.2 RTP/RTCP協(xié)議

　　RTP協(xié)議是IETF在1996年為支持網(wǎng)絡數(shù)據(jù)實時傳輸而制訂的標準。RTP協(xié)議實際上是由實時傳輸協(xié)議RTP(Real Time Transport Protocol)和實時傳輸控制協(xié)議RTCP(Real Time Transport Control Protoeol)兩部分組成。

　　RTP協(xié)議用來提供端到端的實時數(shù)據(jù)傳輸服務，包括有效載荷類型鑒定、數(shù)據(jù)序號、時間戳、傳送監(jiān)測。但是RTP本身并不能為按序傳輸數(shù)據(jù)包提供保證，他依賴于底層服務去實現(xiàn)這一過程，也不能提供流量控制和擁塞控制，這些都由實時傳輸控制協(xié)議RTCP來負責完成。

　　RTCP用來控制服務質(zhì)量，并在正在進行的會話里傳遞各個參與站點的信息。在RTP會話期間，各站點周期性地傳遞RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包數(shù)量和丟失的數(shù)據(jù)包數(shù)量等統(tǒng)計資料。因此站點可以利用這些信息動態(tài)改變傳輸速率，調(diào)整緩沖區(qū)大小和個數(shù)，甚至改變有效載荷類型。RTP和RTCP配合使用，可以有效地反饋和以最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。

　　4.3 DirectShow框架下RTP實現(xiàn)

　　在DirectShow框架下，多媒體數(shù)據(jù)以媒體樣本為單位在濾鏡之間流動。一個特定應用程序的濾鏡圖中，相鄰濾鏡的引腳之間流動的媒體樣本類型一般不同。因此，傳輸兩端需要選用合理濾鏡圖，確保服務器端傳出的媒體樣本能被客戶端正確播放。

　　程序實現(xiàn)中，傳輸兩端的濾鏡圖如圖5所示。服務器采用攝像頭濾鏡捕獲視頻數(shù)據(jù)，向后傳送，經(jīng)過編碼器濾鏡壓縮，傳到MyRTPRenderer濾鏡，并由他負責網(wǎng)絡發(fā)送;在客戶端，MyRTPSource濾鏡收到MyRTPRenderer發(fā)來的數(shù)據(jù)，經(jīng)過解碼器濾鏡解壓縮后顯示到屏幕渲染濾鏡。服務器的編碼器和客戶端的解碼器是配套的，保證服務器傳輸?shù)拿襟w樣本能被客戶端正確解壓播放。從客戶端來看，網(wǎng)絡對于用戶透明，就相當于是一個遠程攝像頭捕捉、壓縮、解壓、播放的過程。

　　架中的兩個RTP濾鏡負責數(shù)據(jù)傳輸，而TCP傳輸?shù)姆答伩刂圃趦啥松蠈拥臑V鏡圖管理器中實現(xiàn)。

　　4.4 Filter實現(xiàn)

　　本系統(tǒng)中視頻流的網(wǎng)絡發(fā)送與接收通過自己開發(fā)的Filter來實現(xiàn)。

　　發(fā)送端Filter類：

　　CbaseInputPin是一個用于實現(xiàn)輸人Pin的抽象類，該類支持IMereInput Pin接口。由于IMemInputPin接口是一個支持推模式(Push Model)的接口，因此，CnetworkSendFilter支持推模式(Push Model)應用。

　　發(fā)送Filter關鍵過程：

　　(1)初始化套接字;

　　(2)設置系統(tǒng)緩沖區(qū)，綁定端口;

　　(3)創(chuàng)建默認的接口;

　　(4)調(diào)用sendto發(fā)送數(shù)據(jù);

　　(6)關閉套接字。

　　5結語

　　圖6為本系統(tǒng)客戶端界面，有4路視頻顯示，在正常條件下，達到了較好的效果。

　　本文結合實際項目需要，詳細論述了音視頻傳輸系統(tǒng)的設計方法和具體實現(xiàn)框架，利用DirectPlay Voice實現(xiàn)音頻混音功能，并且對音頻傳輸過程中的延時抖動進行了去除，利用RTP/RTCP傳輸MPEG-4視頻流，討論了在DirectShow框架下用RTP/RTCP協(xié)議傳輸MPEG-4視頻數(shù)據(jù)的實現(xiàn)方案。

　　實驗表明，該系統(tǒng)音頻混音效果良好，利用RTP/RTCP傳輸MPEG-4視頻，能夠適應復雜的網(wǎng)絡狀況，提供更好的傳輸質(zhì)量。