基于DirectX的音頻視頻無線傳輸系統(tǒng)設(shè)計與實現(xiàn)-設(shè)計應(yīng)用

精品文檔-下載后可編輯基于DirectX的音頻視頻無線傳輸系統(tǒng)設(shè)計與實現(xiàn)-設(shè)計應(yīng)用1引言

近些年來，多媒體技術(shù)，網(wǎng)絡(luò)技術(shù)和無線通信技術(shù)的迅速發(fā)展為相互之間的交叉融合奠定了基礎(chǔ)，也使其成為信息產(chǎn)業(yè)發(fā)展的必然趨勢，傳統(tǒng)的Internet主要提供數(shù)據(jù)業(yè)務(wù)，無線通信主要提供語音業(yè)務(wù)，而多媒體技術(shù)的日新月異，使得文本、語音及視頻綜合加入Internet與無線通信領(lǐng)域的需求日益增長。對于音視頻流的傳輸，如果采用TCP協(xié)議，由于TCP的檢錯和重傳機制會大大增加數(shù)據(jù)包的延時，因此不符合音視頻傳輸?shù)囊?，而如果單純采用UDP協(xié)議，由于UDP不提供任何的QoS保證，因此傳輸質(zhì)量不理想。而IETF制定的實時傳輸協(xié)議／實時傳輸控制協(xié)議(RTP／RTCP)使得在理論上具有提供多媒體實時傳輸?shù)哪芰?。微軟推出的DirectX提供了與音視頻應(yīng)用相關(guān)的SDK，開發(fā)者以此為跳板則可以較方便地實現(xiàn)語音與視頻的捕捉、網(wǎng)絡(luò)傳輸、解壓、回放等功能，并可以根據(jù)需要來訂制和擴充利用。

2系統(tǒng)概述

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

3基于DirectPlayVoice的音頻傳輸

DireetPlayVoice是DirectX系統(tǒng)的成員之一，應(yīng)用DirectPlayVoice開發(fā)時可用的組件。

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

3.1混音

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

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

3．2語音延時、抖動消除

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

本系統(tǒng)實現(xiàn)時提供了兩種混音方式和多種音頻編碼類型可選，因此能夠適應(yīng)網(wǎng)絡(luò)帶寬較差的環(huán)境，提供的編碼類型如下：MS－PCM64kb／s，MS－ADPCM32.8kb／s，MicrosoftGSM6.1013kb／s，TrueSpeech(TM)8.6kb／s，VoxwareSC033.2kb／s，'VoxwareSC066.4kb／s。

4基于DirectShow的視頻傳輸

DirectShow是一套完全基于COM的應(yīng)用系統(tǒng)，COM組件有3種類型：進程內(nèi)組件、本地組件和遠程組件。Filter一般是一種進程內(nèi)組件，以動態(tài)鏈接庫(Dell)的形式提供服務(wù)。在Dir。ectShow體系結(jié)構(gòu)中，F(xiàn)ilter是基本的模塊。

DirectShow對流媒體的處理是分步進行的，每項特定的處理由特定的Filter。來完成。Filter主要有3類：SourceFilters，TransformFilters和RenderingFilters。SourceFilters主要負責(zé)取得數(shù)據(jù)，然后將數(shù)據(jù)往下傳輸；Trans-formFitlers主要負責(zé)數(shù)據(jù)的格式轉(zhuǎn)換、傳輸；RenderingFiltes主要負責(zé)數(shù)據(jù)的終去向。

在發(fā)送端，采集卡捕獲的視頻數(shù)據(jù)經(jīng)過DiMPEG－4LOW－MotionFilter編碼壓縮，然后進行RTP打包，再發(fā)送到網(wǎng)絡(luò)上。接收端使用RTP解包，DiMPEG－4ReceivetFilter接收并緩沖視頻流，然后由DiDecoderFilter進行解碼，由VideoRendererFilter播放。同時引入RTCP進行傳輸質(zhì)量控制。

4.1視頻的壓縮與編碼

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

4.2RTP／RTCP協(xié)議

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

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

RTCP用來控制服務(wù)質(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.3DirectShow框架下RTP實現(xiàn)

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

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

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

4.4Filter實現(xiàn)

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

發(fā)送端Filter類：

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

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

(1)初始化套接字；(2)設(shè)置系統(tǒng)緩沖區(qū)，綁定端口；(3)創(chuàng)建默認的接口；(4)調(diào)用sendto發(fā)送數(shù)據(jù)；(6)關(guān)閉套接字。

5結(jié)語

本文結(jié)合實際項目需要，詳細論述了音視頻傳輸系統(tǒng)的設(shè)計方法和具體實現(xiàn)框架，利用DirectPlayVoice實現(xiàn)音頻混音功能，并且對音頻傳輸過程中的延時抖動進行了