基于DirectX的音頻視頻無(wú)線(xiàn)傳輸系統設計與實(shí)現

　　1引言

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

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

　　2系統概述

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

　　3基于DirectPlay Voice的音頻傳輸

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

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

　　3.1 混音

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

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

　　3.2語(yǔ)音延時(shí)、抖動(dòng)消除

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

　　本系統實(shí)現時(shí)提供了兩種混音方式和多種音頻編碼類(lèi)型可選，因此能夠適應網(wǎng)絡(luò )帶寬較差的環(huán)境，提供的編碼類(lèi)型如下：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的應用系統，COM組件有3種類(lèi)型：進(jìn)程內組件、本地組件和遠程組件。Filter一般是一種進(jìn)程內組件，以動(dòng)態(tài)鏈接庫(Dell)的形式提供服務(wù)。在Dir。ectShow體系結構中，Filter是最基本的模塊。DirectShow對流媒體的處理是分步進(jìn)行的，每項特定的處理由特定的Filter。來(lái)完成。Filter主要有3類(lèi)：SourceFilters，Transform Filters和Render ing Filters。 SourceFilters主要負責取得數據，然后將數據往下傳輸;Trans-form Fitlers主要負責數據的格式轉換、傳輸;RenderingFiltes主要負責數據的最終去向。

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

　　4.1視頻的壓縮與編碼

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

　　4.2 RTP/RTCP協(xié)議

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

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

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

　　4.3 DirectShow框架下RTP實(shí)現

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

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

　　架中的兩個(gè)RTP濾鏡負責數據傳輸，而TCP傳輸的反饋控制在兩端上層的濾鏡圖管理器中實(shí)現。

　　4.4 Filter實(shí)現

　　本系統中視頻流的網(wǎng)絡(luò )發(fā)送與接收通過(guò)自己開(kāi)發(fā)的Filter來(lái)實(shí)現。

　　發(fā)送端Filter類(lèi)：

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

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

　　(1)初始化套接字;

　　(2)設置系統緩沖區，綁定端口;

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

　　(4)調用sendto發(fā)送數據;

　　(6)關(guān)閉套接字。

　　5結語(yǔ)

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

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

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