1、多媒體網絡通信技術大作業1、題目：基于局域網的可視對講系統設計2、系統開發環境與工具：（1）、硬件環境：實驗室局域網（2）、軟件環境：WindowsXP操作系統（3）、開發工具：自己熟悉的面向對象的網絡通信編程工具與平臺，相關音頻、視頻編碼與傳輸協議類庫3、要求與評分標準：（1）要求：在以上硬軟件環境下，利用合適的開發工具，設計一套可視對講軟件，實現局域網內兩臺計算機之間的可視對講功能，要求音視頻信號連續性、實時性較好，滿足正常交流需要。（2）評分標準系統原理分析（20分）1.系統原理概述（10分）2.關鍵技術分析（10分）系統總體方案設計（30分）1.按模塊化設計要求畫系統結構圖（15分）2

2、數據流分析（15分）系統具體設計（30分）呼叫處理模塊流程圖與關鍵代碼（6分）音視頻采集與播放模塊流程圖與關鍵代碼（6分）音視頻處理（編解碼）模塊流程圖與關鍵代碼（6分）音視頻封包與解析模塊流程圖與關鍵代碼（6分）音視頻發送與接收模塊流程圖與關鍵代碼（6分）系統測試與評價（20）實現語音通信（6分）實現視頻通信（6分）實現音視頻同步（8分）1系統原理分析1.1系統原理概述視頻聊天系統應該具備提供便捷、靈活、全面的音頻、視頻信息的傳遞和服務的功能，并且實時傳輸給聊天軟件在線的人。本次方案采用Microsoft Visual C+ 6.0編程開發視頻聊天系統的一套比較常用的解決方案。語音視頻聊天采

3、用UDP模式，在客戶端之間點對點的進行，因為UDP傳輸速度快，TCP是面向連接的，建立連接時雙方需經過三次握手，數據傳輸可靠，FTP、TELNET等就是基于TCP的，UDP是面向非連接的，發出信息不需對方確認，但這樣速度比TCP快，但有可能丟失數據，象SMTP、TFTP等就是基于UDP的。在該方案中，通過函數庫VFW（Video for Windows）來實現視頻捕獲、影像壓縮以及影像播放。微軟公司提供的專門用于視頻捕獲開發的工具包VFW，為在Windows操作系統中實現視頻捕獲提供了標準的接口，從而大大降低了程序的開發難度。在視頻傳輸方面，則通過組建視頻幀，將位圖形式的視頻幀壓縮成幀格式的M

4、PEG4流，傳輸到客戶端后，解壓并顯示影像。同時采用線程來實現語音錄制和語音回放，最終實現了通過服務器中轉的文字聊天、點對點的語音視頻聊天。1.2關鍵技術分析可視對講的關鍵技術之一是音視頻同步問題。解決同步問題的方法有很多種，其中時間戳是最成熟最完美也是最復雜的解決辦法，可以解決任何多媒體領域的音視頻同步問題。其原理是選擇一個參考時間，在生成數據流時依據參考時間上的時間給每個數據塊都打上時間戳；在播放時，讀取數據塊上的時間戳，同時參考當前時鐘上的時間來安排播放，讓快于這個參考時間的包等待，丟棄慢于這個參考時間的包。在基于時間戳的同步機制中，僅僅對不同步的數據進行處理是不完備的，還需要反饋機制，

5、如基于Windows平臺的DirectShow就提供這樣一個反饋機制，它的質量控制(QualityControl)可以將播放的狀態反饋給源，讓源端加快或者放慢數據流的速度。多媒體文件的采集，播放及對同步的要求都非常嚴格，如果從多媒體文件中分離出音視頻數據的數據不同步，音視頻的時間差則會越來越大，這是無法忍受的，所以在多媒體文件中，不但要求有同步機制，還要求有反饋機制。可視對講的關鍵技術之二是數據壓縮技術。多媒體信息數字化后的數據量非常大，尤其是視頻信號，數據量更大，需要占用更大的信道帶寬，成本十分昂貴。為了節省存儲空間充分利用有限的信道容量傳輸更多視頻信息，必須對視頻信息進行壓縮。目前，在視頻

6、圖像信息的壓縮方面已經取得了很大的進展。有關圖像壓縮編碼的國際標準主要有JPEG、H.261、H.263、MPEG-1、MPEG-2、MPEG-4等。有關音頻信號的壓縮編碼技術基本上與圖像壓縮技術相同，不同之處在于圖像信號是二維信號，而音頻信號是一維信號，相比較而言音頻信號數據壓縮難度較低。可視對講的關鍵技術之三是視頻采集。對于視頻的采集，主要采用微軟公司的關于數字視頻的一個軟件包VFW（Video for Windows）。VFW是Microsoft 1992年推出的關于數字視頻的一個軟件包，它能使應用程序通過數字化設備并播放從傳統的模擬視頻源得到數字化的視頻剪輯。為了解決數字視頻數據量大的

7、問題，需要對數據進行壓縮，它引進了一種叫AVI的文件標準，該標準未規定如何對視頻進行捕獲、壓縮及播放，僅規定視頻和音頻該如何存儲在硬盤上，以及在AVI文件中交替存儲視頻幀和與之相匹配的音頻數據。VFW給程序員提供VBX和AVICap窗口類的高級編程工具，使程序員能通過發送消息或設置屬性來捕獲、播放和編輯視頻剪輯。用戶不必專門安裝VFW，在安裝Windows時，安裝程序會自動地安裝配置視頻所需的組件，如設備驅動程序、視頻壓縮程序等。2系統總體方案設計2.1系統模塊分析2.1.1視頻捕獲VFW軟件包主要由以下六個模塊組成：（1）AVICAP.DLL：包含執行視頻捕獲的函數，它給AVI文件、I/O和

8、視頻、音頻設備驅動程序提供一個高級接口；（2）MSVIDEO.DLL：包含一套特殊的DrawDib函數，用來處理屏幕上的視頻操作；（3）MCIAVI.DRV：包括對VFW的MCI命令解釋器的驅動程序；（4）AVIFILE.DLL：包含由標準多媒體I/O（mmio）函數提供的更高的命令，用來訪問AVI文件；（5）壓縮管理器（ICM）：用于管理的視頻壓縮/解壓縮的編譯碼器（Codec）；（6）音頻壓縮管理器（ACM）：提供與ICM相似的服務，適用于波形音頻。AVICap支持實時的視頻流捕獲和單幀捕獲，并提供對視頻源的控制。雖然MCI也提供數字視頻服務，比如，它為顯示AVI文件的視頻提供了AVIVi

9、deo命令集，為視頻疊加提供了overlay命令集，但這些命令主要是基于文件的操作，不能滿足實時地直接從視頻緩存中獲取數據的要求。對于使用沒有視頻疊加能力的捕獲卡的PC機來說，用MCI提供的命令集是無法捕獲視頻流的。而AVICap在捕獲視頻方面具有一定的優勢，它能直接訪問視頻緩沖區，不需要生成中間文件，實時性很強，效率很高。同時，它也可將數字視頻捕獲到文件。在視頻捕獲之前需要創建一個捕獲窗，所有的捕獲操作及其設置都以它為基礎。用AVICap窗口類創建的窗口（通過capCreateCaptureWindow函數創建）被稱為“捕獲窗”，其窗口風格一般為WS_CHILD和WS_VISIBLE。實際上

10、，捕獲窗類似于標準控制（如按鈕、列表框等）。捕獲窗具有下列功能：（1）將視頻流和音頻流捕獲到一個AVI文件中；（2）動態地同視頻和音頻輸入器件連接或斷開；（3）以Overlay或Preview模式對輸入的視頻流進行實時顯示；（4）在捕獲時可指定所用的文件名并能將捕獲文件的內容拷貝到另一個文件；（5）設置捕獲速率；（6）顯示控制視頻源、視頻格式、視頻壓縮的對話框；（7）創建、保存或載入調色板；（8）將圖像和相關的調色板拷貝到剪貼板；（9）將捕獲的一個單幀圖像保存為DIB格式的文件。視頻捕獲編程涉及視頻捕獲的結構、宏、消息和函數。發送AVICap窗口消息所能完成的功能都能調用相應的宏來完成。如，S

11、endMessage與capDriverConnect的作用相同，都是將創建的捕獲窗同視頻輸入器件連接起來。靈活編寫AVICap提供的回調函數可滿足一些特殊需求。將宏capCaptureSequenceNoFile和用capSetCallbackOnVideoStream登記的回調函數一起使用，可使應用程序直接使用視頻和音頻數據。在視頻聊天的應用程序中可利用這一點來獲得視頻幀，回調函數將捕獲的圖像傳到遠端的計算機。應用程序可用捕獲窗來登記回調函數（由用戶編寫，而由系統調用），以便在發生下列情況時，它能通知應用程序，作出相應的反應,捕獲窗狀態改變，出錯；視頻幀和音頻緩存可以使用；在捕獲過程中，其

12、它應用程序處于讓步（Yield）地位。2.1.2視頻壓縮解壓縮視頻壓縮(視頻編碼)是把數字視頻流用更少的數據位進行存放的方法。未經壓縮的視頻數據量非常大，所以壓縮對于數字視頻的存儲和傳輸來說都是必須的。圖像壓縮包括一對互補系統，一個編碼器(encoder)和一個解碼器(decoder)。編碼器利用圖像數據之間的相關性。在保證圖像質暈的情況下使用較少的數據以傳播或存儲該圖像；而解碼器則把壓縮后的圖像還原出原始的視頻數據。視頻壓縮解壓縮采用MPEG-4標準。MPEG-4是為在國際互聯網絡上或移動通信設備（例如移動電話）上實時傳輸音/視頻訊號而制定的最新MPEG標準，MPEG4采用Object Ba

13、sed方式解壓縮，壓縮比指標遠遠優于以上幾種，壓縮倍數為450倍(靜態圖像可達800倍)，分辨率輸入可從320 ×240到1280 ×1024，這是同質量的MPEG1和MJEPG的十倍多。MPEG-4使用圖層(layer)方式，能夠智能化選擇影像的不同之處，是可根據圖像內容，將其中的對象（人物、物體、背景）分離出來分別進行壓縮，使圖文件容量大幅縮減，而加速音/視頻的傳輸，這不僅僅大大提高了壓縮比，也使圖像探測的功能和準確性更充分的體現出來。在網絡傳輸中可以設定MPEG-4的碼流速率，清晰度也可在一定的范圍內作相應的變化，這樣便于用戶根據自己對錄像時間、傳輸路數和清晰度的不同

14、要求進行不同的設置，大大提高了系統使用時的適應性和靈活性。也可采用動態幀測技術，動態時快錄，靜態時慢錄，從而減少平均數據量，節省存儲空間。而且當在傳輸有誤碼或丟包現象時，MPEG-4受到的影響很小，并且能迅速恢復。MPEG-4與MPEG-1、MPEG-2以及H.264相比，更注重多媒體系統的交互性和靈活性。最顯著的差別在于它采用基于對象的編碼理念；即在編碼時將一幅景物分成若干個在時間和空間上相互聯系的視頻音頻對象，分別編碼后經過復用傳輸到接收端，在接收端再對不同對象分別解碼。最后合成所需的視頻和音頻。這樣便于對不同對象進行不同的編碼和操作，也有利于不同數據類型間的融合。MPEG-4的應用前景將

15、是非常廣闊的。它的出現將對以下各方面產生較大的推動作用：數字電視、動態圖像、萬維網（WWW）、實時多媒體監控、低比特率下的移動多媒體通信、于內容存儲和檢索多媒系統、Internet/Intranet上的視頻流與可視游戲、基于面部表情模擬的虛擬會議、DVD上的交互多媒體應用、基于計算機網絡的可視化合作實驗室場景應用、演播電視等。2.1.3語音的錄制、回放我們主要利用線程來處理語音部分的錄制、回放。線程是一個獨立的執行流，是進程內部的一個獨立的執行單元，相當于一個子程序，它對應于Visual C+中的CWinThread類對象。單獨一個執行程序運行時，缺省地包含了一個主線程，主線程以函數地址的形式

16、出現，提供程序的啟動點，當主線程終止時，進程也隨之終止。根據實際需要，應用程序可以分解成許多獨立執行的線程，每個線程并行的運行在同一進程中。一個進程中的所有線程都在該進程的虛擬地址空間中，使用該進程的全局變量和系統資源。操作系統給每個線程分配不同的CPU時間片，在某一個時刻，CPU只執行一個時間片內的線程，多個時間片中的相應線程在CPU內輪流執行，由于每個時間片時間很短，所以對用戶來說，仿佛各個線程在計算機中是并行處理的。操作系統是根據線程的優先級來安排CPU的時間，優先級高的線程優先運行，優先級低的線程則繼續等待。Windows提供了兩種線程：用戶界面線程和工作線程（又稱為后臺線程）。這里主

17、要介紹用戶界面線程的運用。用戶界面線程通常用來處理用戶的輸入并響應各種事件和消息，其實，應用程序的主執行線程CWinApp對象就是一個用戶界面線程，當應用程序啟動時自動創建和啟動，同樣它的終止也意味著該程序的結束，進程終止。（1）線程的啟動創建一個用戶界面線程，首先要從類CwinThread產生一個派生類，同時必須使DECLARE_DYNCREATE和IMPLEMENT_DYNCREATE來聲明和實現這個CwinThread派生類。第二步是根據需要重載該派生類的一些成員函數如：ExitInstance（）、InitInstance（）、OnIdle（）、PreTranslateMessage（

18、）等函數。最后調用AfxBeginThread()函數的一個版本：CWinThread*AfxBeginThread(CRuntimeClass* pThreadClass,int nPriority = THREAD_PRIORITY_NORMAL, UINT nStackSize = 0, DWORD dwCreateFlags = 0, LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL)啟動該用戶界面線程，其中第一個參數為指向定義的用戶界面線程類指針變量，第二個參數為線程的優先級，第三個參數為線程所對應的堆棧大小，第四個參數為線程創建時的附加標志，

19、缺省為正常狀態，如為CREATE_SUSPENDED則線程啟動后為掛起狀態。（2）線程的優先級CwinThread類的成員函數用于線程優先級的操作：int GetThreadPriority（）；BOOL SetThradPriority（）(int nPriority)。（3）線程的掛起和恢復CWinThread類中包含了應用程序掛起和恢復它所創建的線程的函數，其中SuspendThread（）用來掛起線程，暫停線程的執行；ResumeThread（）用來恢復線程的執行。如果你對一個線程連續若干次執行SuspendThread（），則需要連續執行相應次的ResumeThread（）來恢復線程

20、的運行。（4）結束線程終止線程有三種途徑，線程可以在自身內部調用AfxEndThread()來終止自身的運行；可以在線程的外部調用BOOL TerminateThread(HANDLE hThread, DWORD dwExitCode)來強行終止一個線程的運行，然后調用CloseHandle（）函數釋放線程所占用的堆棧；第三種方法是改變全局變量，使線程的執行函數返回，則該線程終止。2.1.4視頻傳輸語音視頻聊天采用用戶數據報協議（User Datagram Protocol）傳輸協議。UDP是無連接的網絡協議，無連接服務是郵政系統服務的抽象，每個分組都攜帶有完整的目的地址

21、，各分組在系統中獨立傳送。無連接服務不能保證分組的先后順序，不進行分組出錯的恢復與重傳，不保證傳輸的可靠性。UDP協議提供無連接的數據報服務。而TCP/IP協議已經很難適應視音頻通信，特別是連續的媒體流（如視頻流）通信的要求。TCP協議是面向連接的協議，被用于各種網絡上提供有序可靠數據傳輸的虛電路服務。它的重傳機制和擁塞控制機制（Congestion Control Mechanism）都是不適合用于實時視音頻傳輸的。因為IP協議只提供無連接、無QOS保證的服務，并且只是盡最大努力地傳送數據報。當網絡帶寬不足而造成較長的時延和較多的丟包時，IP協議并不提供QOS反饋2。因此

22、，需要利用IP層之上的協議來滿足網絡視頻實時傳輸的時延和丟包率的要求。UDP協議是面向非連接的網絡數據協議，在正式通信前不必與對方先建立連接，直接向接收方發送數據，是一種不可靠的通信協議。正是由于UDP協議不關心網絡數據傳輸的一系列狀態，使得UDP協議在數據傳輸過程中節省了大量的網絡狀態確認和數據確認的系統資源消耗，大大提高了UDP協議的傳輸速度，且UDP無需連接管理，可以支持海量并發連接。但是，視頻傳輸的特點要求傳輸協議能夠處理傳輸中的延遲和抖動現象，能夠處理突發的視頻傳送，并且能夠根據接收端的接收質量判斷網絡狀況，做出相應的反饋3。UDP協議本身并不能很好地處理這些情況。由于UDP 協議不

23、能可靠傳輸視頻圖像，為此在應用層添加如下機制實現視頻圖像的可靠傳輸。在發送端和接收端各開一個視頻緩沖區，暫存待發送和已接收的數據幀。通過流量控制，可以避免因網絡擁塞導致包丟失率增加。通過確認技術，可以實現圖像可靠傳輸。而超時處理可以避免發送端和接收端長時間等待，根據網絡當前狀況作出相應的反饋。2.2軟硬件環境兩臺以上電腦，分別配有攝像頭、麥克風、音箱或耳機等外部設備；Windows XP系統，Microsoft Visual Studio 6.0編程開發系統等。2.3技術要求語音視頻聊天作為一種廣泛的網絡應用對其基礎的承載網絡環境有著較高的網絡要求。其中應重點考慮的是網絡的帶寬情況、端到端的時

24、延、丟包率、時延抖動等問題。（1）網絡帶寬需求，視頻聊天對網絡的帶寬需求為“視頻帶寬+IP包頭開銷”，計算方法為：網絡帶寬 = 視頻帶寬× 1.2。（2）端到端的時延，網絡傳輸不可避免的會發生傳輸時延，通常建議視頻聊天的通用時延小于150ms。（3）丟包率，網絡數據傳輸經常會出現丟包現象，視頻傳輸過程中數據丟包嚴重的話會影響在線視頻聊天質量。因此，在設計上應將網絡上的丟包率控制在1%以內。（4）時延抖動，由于音頻/視頻的傳輸為實時的交互，因此網絡的時延抖動更為重要，一般，視頻聊天的時延抖動控制在50ms內。2.4系統結構圖2.4.1硬件結構系統該系統采用的是Client/Client

25、結構，客戶端是兩臺PC機和一個數字攝像頭、耳機和麥克風。進行語音視頻聊天是客戶端與客戶端之間直接進行的點對點的連接，它們之間的網絡拓撲結構如圖1。在圖中，為了簡便，沒有畫出麥克風、音箱或耳機等外部設備。圖1 網絡拓撲結構圖2.4.2系統功能模塊圖語音視頻聊天是對整個在線客戶端兩兩之間進行點對點的視頻聊天。語音視頻聊天包括了視頻捕獲、視頻壓縮、解壓縮、語音錄制、語音回放以及視頻傳輸等。整個系統的功能模塊圖如圖2所示。圖2 系統功能模塊圖系統各模塊流程圖語音視頻聊天流程圖如下圖3所示。在有兩個客戶在線的情況下，才能進行語音視頻聊天。兩個用戶要進行語音視頻聊天時，一個用戶選中另一個用戶的用戶名，根據

26、該用戶名在后臺鏈表中的對應IP地址查找用戶并請求視頻連接。當雙方確認視頻連接后就進行視頻傳輸，并顯示在客戶端，同時用線程實現語音錄制和回放。這樣，兩個用戶就實現了點對點的語音視頻聊天。在進行語音視頻聊天的過程中，不能再與其它用戶進行語音視頻聊天，但能夠與其它用戶進行文字聊天。圖3 語音視頻聊天流程圖2.5數據流在發送端和接收端各開一個視頻緩沖區，暫存待發送和已接收的數據幀。由于無線傳輸帶寬和單片機軟硬件資源的限制，壓縮后的JPG 圖像(320 ×240)仍然必須在發送端分割成若干幀，到達接受端時重組。在LINUX 中，JPG 圖像就相當于一個普通文件，可通過open () 函數打開進

27、行讀寫。2.5.1數據幀結構對每幀加上幀頭結構,幀頭結構定義了序列號,視頻壓縮格式,時戳。序列號是數據包發送的順序標記,檢測傳輸中是否有數據丟失,并用在接收端來重新排序。視頻壓縮格式標記用于接收端采用相應的解碼流程。時間戳控制視頻回放的時間。幀結構描述如圖4所示。圖4 數據幀結構圖像在傳輸過程中還涉及到緩沖區、流量控制、確認技術及超時處理等問題。（1）緩沖區。由于發送端存在重發數據幀的可能，接收端有可能收到亂序的數據幀，故發送端和接收端確定一個視頻傳輸緩沖區，大小為65 536 (可根據要傳送的圖像大小適當調整) 字節。發送端首先把一幅jpg 圖像數據一次性寫入緩沖區，將其分解為若干數據幀，各

28、幀按照序號遞增的順序從1 依次編號，使得每一幀的大小不超過2 048 字節，稱為一個數據幀。接收端收到完整的一幅JPG 圖像數據后再一次性寫入圖像文件中。（2）流量控制。UDP借鑒TCP 協議流量控制機制：慢啟動和線性增長成倍減少過程。在連接建立后的慢啟動過程中，先將發送方窗口置為最小值，每當成功傳送完窗口中的數據后，就成倍地增大窗口，直到某個閾值。這就保證了網絡流量不會突然增大，為其他連接留有余地。（3）確認技術。在可靠數據傳遞協議中保證數據可靠傳遞的基本就是要使用確認技術。為了更好地控制流量，達到最大限度地利用網絡資源的目的,可采用捎帶確認、累計確認和超時確認以及擴展確認這幾種方式結合來實

29、現確認。其中前3 種確認方式和TCP 中的用法一致。在接收方收到失序數據包時，為了最大限度地減少重傳，并不是簡單將其丟棄，而是將其存儲在本地的失序緩沖隊列中，并設置失序包計數器。接收方在計數器超過閾值或者確認定時器超時后向發送方發送擴展確認數據包。該數據包中攜帶本端已經收到的最大按序包序號和收到的所有失序包的序號信息。發送端收到由接收端傳來的擴展確認數據包后，將根據最大確認序號和對端收到的失序包的序號計算出應該重傳的數據包序號,并從重傳隊列中取出相應的數據包進行快速重傳。（4）超時處理。處理超時和重傳的方法之一就是發送一個請求后等待n 秒,如果沒有收到應答,則重傳并再等待另外N 秒。這是一種線

30、性重傳的定時器,并且在重傳一定次數后就放棄重傳。這種辦法的問題是,數據報在一個互聯網上往返的時間( RTT) 會從LAN 上的遠遠小到1 s 變成WAN 上的許多秒。影響往返時間(RTT) 的因素是距離、網絡速度和擁塞,當網絡條件變化時,客戶和服務器之間的RTT 會隨著時間很快地變化。因此,必須設計一個將實際測得的RTT 以及RTT 隨時間變化考慮在內的超時和重傳算法。計算發送每個數據報的重傳超時( RTO) 的公式為：delta = RTT - srt tsrt t srtt + g ×deltart tvar rt tvar + h ×(| delta| - rt tv

31、ar)RTO = srtt + 4 ×rt tvar其中，RTT 為數據報的實際往返時間； srtt 為平滑了的RTT 估計因子；rttvar 為平滑了的平均偏差估計因子；delta 為測得的RTT 和當前平滑了的RTT 估計因子(srtt) 之間的差；g 為施加在RTT 估計因子上的增益因子，值為1/ 8；h 為施加在平均偏差估計因子上的增益因子，值為1/ 4。當重傳定時器超時的時候，對下一個RTO要用一個指數退回。例如，如果RTO 是2 s ，這段時間內應答沒有收到，則下一個RTO 是4 s ；如果仍沒有收到，下一個RT0 是8 s ，接著是16 s ，依此類推。2.5.2視頻圖

32、像數據傳輸過程以一幅圖像傳送為例。如一幅圖像共可拆分打包成n 個數據幀。某次發送編號為i ，j ， k ， m 共4 幀( i < j < k < m) ，接收方成功收到i ， m 兩幀。接收方將已收到的所有幀序號打包成確認幀發送出去,而不只是僅打包本次收到的i ， m 兩幀。發送方收到確認幀后,依據確認幀里各幀序號將表明接收方是否成功收到數據幀的數組相應位置1 。此時發送方依據流量控制原理選取序號大于m 的幀發送,而不是發送上次的序號為j， k 的幀。當幀號等于n 時再從幀號1 開始依據序號遞增的方法選取還未收到確認幀的各幀。實驗表明，這樣大大減少了數據幀和確認幀的重發。因

33、為發送方未收到確認幀并不表明確認幀由于受到線路噪聲干擾或路由器緩沖區已滿而被拋棄，也有可能還在尋找路由。TCP 的順序傳送以幀為單位，而本文方法卻是以一幅圖像為單位。發送流程如圖5所示，接收流程如圖6所示。圖5 圖像數據幀發送流程圖圖6 圖像數據幀接收流程圖音頻信號是一維信號，音頻數據的收發更為簡單，在這里就不作具體分析。3系統具體設計3.1呼叫處理3.1.1呼叫處理模塊在實現語音視頻聊天時，采用的是基于UDP套接字的點對點模式，而UDP面向的是無連接的數據服務，其套接字的使用如圖7所示。圖7 UDP套接字的使用3.1.2呼叫處理關鍵代碼客戶端請求連接線程（呼叫處理）關鍵代碼如下：DWORD

34、WINAPI ConnectThreadFunc(LPVOID pParam)CChatRoomDlg *pChatRoom = (CChatRoomDlg *)pParam;ASSERT(pChatRoom ! = NULL);pChatRoom ->m_ConnectSock = socket (AF_INET ,SOCK_STREAM , IPPROTO_TCP);if ( pChatRoom->m_ConnectSock = INVALID_SOCKET) AfxMessageBox(_T("新建Socket 失敗！");return FALSE;CSt

35、ring strServIp;pChatRoom->GetDlgItemText(IDC_IP_ADDR, strServIp);int iPort = pChatRoom ->GetDlgItemInt (IDC_CONNECT_PORT);if( iPort <= 0 | iPort > 65535 ) AfxMessageBox(_T("請輸入合適的端口：1 - 65535");goto _Error_End;char szIpAddr16 = 0;USES_CONVERSION;strcpy_s(szIpAddr, 16, T2A(strSe

36、rvIp);sockaddr_in server;server.sin_family = AF_INET;server.sin_port = htons(iPort);server.sin_addr.s_addr = inet_addr(szIpAddr);if(connect(pChatRoom->m_ConnectSock,(struct sockaddr*)&server, sizeof(struct sockaddr) = SOCKET_ERROR )AfxMessageBox(_T("連接失敗，請重試！");goto _Error_End;pChat

37、Room->ShowMsg(_T(" 系統信息：連接服務器成功！");while( TRUE ) if ( SOCKET_Select(pChatRoom->m_ConnectSock) ) TCHAR szBufMAX_BUF_SIZE = 0;int iRet = recv (pChatRoom->m_ConnectSock, (char*)szBuf, MAX_BUF_SIZE, 0);if ( iRet > 0 ) pChatRoom->ShowMsg(szBuf);elsepChatRoom->ShowMsg(_T("

38、聊天服務器已停止，請重新進行連接！");break;Sleep(500);_Error_End:closesocket(pChatRoom->m_ConnectSock);return TRUE;3.2音視頻采集與播放利用VFW接口，視頻捕獲可以分為以下幾個步驟：（1）建立視頻采集窗口：該窗口用來接收視頻捕捉驅動程序傳來的數據和消息。（2）連接視頻驅動程序：將建立的視頻捕捉窗口與視頻設備驅動程序相連。（3）視頻捕獲初始化。（4）視頻捕捉設置：VFW下視頻捕捉參數的設置可以通過調用函數或彈出對話框的形式來實現。一般視頻驅動程序允許設置的參數包括視頻源選擇、視頻格式、視頻顯示格式等

39、。（5）設置回調函數：通過回調函數來通知程序視頻事件的發生，比如捕捉一幀圖像成功的消息，捕捉出錯的消息等。（6）結束捕捉：結束捕捉是應該有一些清除工作。如釋放分配的內存，斷開捕捉窗口與視頻捕捉驅動程序的連接，清除視頻捕捉窗口等。3.2.1捕獲窗口在捕獲前必須創建一個捕獲窗口（Capture Widnow），下面介紹有關捕獲窗口的情況：創建一個AVICap捕獲窗口，用capCreateCaptureWindow函數并返回一個句柄。將捕獲窗口連接至捕獲設備，用capDriverConnect函數來使一個捕獲窗口與一個捕獲設備連接或關聯連接上后，就可以通過捕獲窗口向捕獲設備發送各種消息，可以使用函數

40、capGetDriverDescription來獲得已安裝的捕獲設備名稱及版本，將其列舉在實現程序過程中。再利用capDriverGetName函數來得到捕獲設備的名稱將獲得的版本發送到capDriverGetVersion。如果斷開捕獲窗口與捕獲設備的連接用capDriverDisconnect。捕獲窗口的狀態，用capGetStatus函數來獲得當前捕獲窗口的狀態，得到一個CAPSTATUS結構的拷貝。該結構的內容包含了圖片的尺寸、卷軸的當前位置、overlay和preview是否已設置。由于其信息是動態的，每當捕獲的視頻流的尺寸發生改變，程序應該在獲取捕獲設備的視頻格式以后及時進行刷新。

41、而捕獲窗口尺寸的改變并不影響實際的捕獲視頻流的尺寸。該尺寸由視頻捕獲設備的格式和視頻對話框決定。代碼如下：/捕獲窗口BOOL VideoCapture:Initialize() char devname128=0,devversion128=0;int index=0; BOOL ret = TRUE, ret1 = TRUE, ret2 = TRUE, ret3 = TRUE;TRACE("VideoCapture:Initializen"); /創建一個AVICap捕獲窗口m_capwnd = capCreateCaptureWindow("Capture&q

42、uot;,WS_POPUP,0,0,1,1,0,0);if(!m_capwnd)return FALSE;/connect callback functionsret = capSetUserData(m_capwnd,this);/Change destroy functions also. ret1 = capSetCallbackOnVideoStream(m_capwnd,OnCaptureVideo); /得到已安裝的捕獲設備的名稱及版本 ret2 = capGetDriverDescription(index,devname,100,devversion,100);/ Connec

43、t to webcam driver/使一個捕獲窗口與一個捕獲設備連接或關聯ret3 = capDriverConnect(m_capwnd,index);if(!(ret && ret1 && ret2 && ret3)/ Device may be open already or it may not have been/ closed properly last time.AfxMessageBox("Unable to open Video Capture Device");/log.WriteString("

44、;n Unable to connect driver to the window");m_capwnd=NULL;return FALSE;/ Set the capture parametersif(SetCapturePara()=FALSE)/ log.WriteString("n Setting capture parameters failed");capDriverDisconnect(m_capwnd); /使捕獲窗口與一個捕獲設備斷開return FALSE;return TRUE;3.2.2設置CAPTUREPARAMS結構VC+采用VFW技術

45、，客戶端通過capSetCallbackOnFrame()注冊回調函數，當采集卡采集到一幅圖像后，系統就會自動調用回調函數，在其中使用ICSeqCompressFrame()函數進行壓縮。然后再通過Winsock將壓縮后的數據發送到另一客戶端。該客戶端接收完一幀以后，交給ICDecompress()解壓，最后用SetDIBitsToDevice()將圖像顯示出來。基本的捕獲設置包括設置捕獲速度（每秒捕獲多少幀）、是否同時捕獲聲頻、捕獲緩沖、允許最大丟失多少幀和是否使用DOS內存，以及使用鍵盤的哪個鍵或鼠標的哪個鍵來終止捕獲等內容，這些設置使用CAPTUREPARAMS結構描述，capCaptu

46、reGetSetup宏來得到當前的設置，然后改變此結構的成員變量，再使用capCaptureSetSetup宏設置新的設置。設置捕獲速度，通過使用capCaptureGetSetup宏來得到當前的捕捉速度，將當前的捕捉速度保存在CAPTUREPARAMS結構的dwRequestMicroSecPerFrame成員變量中，也可以通過設置此變量來改變當前設置值。設置終止捕獲，也通過使用capCaptureGetSetup宏來得到當前的設置，當前按鍵設置保存在CAPTUREPARAMS結構的vKeyAbort成員中，鼠標設置保存在fAbortLeftMouse和fAbortRightMouse成員中

47、，通過修改可以設置新的熱健或者鼠標左右鍵，修改完成后，使用capCaptureSetSetup宏來進行更新。捕獲的時間限制，用CAPTUREPARAMS結構中的fLimitEnabled表示捕獲是否有時間的限制，wTimeLimit用來設置指示捕獲最大的持續時間，其單位為秒。使用capCaptureGetSetup宏來得到當前的設置值。下面程序為設置CAPTUREPARAMS結構的實現代碼：BOOL VideoCapture:SetCapturePara()CAPTUREPARMS CapParms=0;capCaptureGetSetup(m_capwnd,&CapParms,siz

48、eof(CapParms);/得到當前的捕獲速度CapParms.fAbortLeftMouse = FALSE;CapParms.fAbortRightMouse = FALSE;CapParms.fYield = TRUE;CapParms.fCaptureAudio = FALSE;CapParms.wPercentDropForError = 80;if(!capCaptureSetSetup(m_capwnd,&CapParms,sizeof(CapParms)/log.WriteString("n Failed to set the capture paramet

49、ers ");return FALSE;/ Set Video Format capGetVideoFormat(m_capwnd,&m_bmpinfo,sizeof(m_bmpinfo);m_bmpinfo.bmiHeader.biWidth=IMAGE_WIDTH;m_bmpinfo.bmiHeader.biHeight=IMAGE_HEIGHT;BOOL ret=capSetVideoFormat(m_capwnd,&m_bmpinfo,sizeof(m_bmpinfo);/log.WriteString("n Video parameters set

50、 properly");return ret;/終止一個捕獲任務BOOL VideoCapture:StopCapture()capCaptureStop(m_capwnd);capCaptureAbort(m_capwnd);Sleep(500);return TRUE;3.3音視頻處理（編解碼）音視頻編碼處理就是對音視頻進行壓縮。MPEG-4編碼算法的完整源代碼如下：class CVideoEncoderX264 :public: CVideoEncoderX264(void); CVideoEncoderX264(void); virtual bo

51、ol Connect(CVideoEnDecodeNotify* pNotify, const CVideoEnDecodeItem& Item); virtual void Release(void); virtual void Encode(BYTE* pInData, int nLen, BYTE* pOutBuf, int& nOutLen, int& nKeyFrame);private: x264_picture_t m_Pic; x264_t *h; x264_param_t param; void Flush(void);文

52、件：VideoEncoderX264.cppbool CVideoEncoderX264:Connect(CVideoEnDecodeNotify* pNotify, const CVideoEnDecodeItem& Item) CBase:Connect(pNotify, Item); ParseSize(Item.m_stSize); x264_param_default( &param ); param.i_threads = 1; param.i_frame_total = 0; param.i_width&

53、#160; = m_nWidth; param.i_height = m_nHeight; param.i_keyint_min = Item.m_nKeyInterval; param.i_keyint_max = Item.m_nKeyInterval * 10; param.i_fps_num = Item.m_nFps;*/ param.i_log_level = X264_LOG_NONE;if( ( h = x264_encoder_open( &param ) ) = NULL ) return false; 

54、/* Create a new pic */x264_picture_alloc( &m_Pic, X264_CSP_I420, param.i_width, param.i_height ); return true;void CVideoEncoderX264:Release(void) Flush(); x264_picture_clean( &m_Pic ); x264_encoder_close( h ); CBase:Release();void CVideoEncoderX264:Encode(BYTE* pInD

55、ata, int nLen, BYTE* pOutBuf, int& nOutLen, int& nKeyFrame) if(nLen != param.i_width * param.i_height * 3) return; param.i_frame_total +;memcpy(m_Pic.img.plane0, pInData, param.i_width * param.i_height);memcpy(m_Pic.img.plane1, pInData + param.i_width * param.i_height, param.i

56、_width * param.i_height / 4);memcpy(m_Pic.img.plane2, pInData + param.i_width * param.i_height * 5 / 4, param.i_width * param.i_height / 4); m_Pic.i_pts = (int64_t)param.i_frame_total * param.i_fps_den;static x264_picture_t pic_out;x264_nal_t *nal = NULL;int i_nal, i;if( &m_Pic )m_Pic.i_typ

57、e = X264_TYPE_AUTO;m_Pic.i_qpplus1 = 0; /TraceTime("x264_encoder_encode begin");if( x264_encoder_encode( h, &nal, &i_nal, &m_Pic, &pic_out ) < 0 )  return;/TraceTime("x264_encoder_encode   end");int nOutCanUse = nOutLen;nOutLen = 0;for( i =

58、0; i < i_nal; i+ )int i_size = 0;if( ( i_size = x264_nal_encode( pOutBuf + nOutLen, &nOutCanUse, 1, &nali ) ) > 0 )nOutLen += i_size;nOutCanUse -= i_size;nKeyFrame = pic_out.i_type=X264_TYPE_IDR;/ | (pic_out.i_type=X264_TYPE_I && coCfg->x264_max_ref_frames=1)void CVideoEncoderX264:Flush(void)x264_picture_t pic_out;x264_nal_t *nal;int i_nal, i;int i_file = 0;if( x264_encoder_encode( h, &nal, &i_nal, NULL, &pic_out ) < 0 )解碼代碼不做詳細分析。3.4.語音處理3.4.1語