關鍵詞 視頻; 採集; 壓縮; DirectShow; MPEG-4,RTP
1 引言
近年來，隨着國民經濟的發展，社會各個部門對於視頻監視系統的需求越來越多。但目前的很多監視系統都跟具體的硬件相關，必須要具體的採集卡的支持才能實現。所以有必要開發一種具有通用性的視頻監視系統，用普通的攝像頭就能實現視頻的採集。
基於DirectShow的開發能很靈活地控制音視頻的效果，所以選擇DirectShow這種可擴展性好的技術做開發對以後的應用升級很有幫助。此外， 爲了實現流媒體傳輸控制的策略，流媒體的傳輸和回放也是應解決的問題之一。由Microsoft提供的DirectShow技術基於組件對象模型技術，支 持寬鬆的格式變化，提供高品質的多媒體流回放。利用它可以在普通微機中實現流媒體的客戶端處理，並可以提高系統的通用性和可擴展性。
對於視頻數據的傳輸，壓縮率是一個必須考慮到的因素。MPEG-4是由ISO和IEC的MPEG組制定的一個關於活動圖像和聲音的編碼國際標準。它在基於 內容的交互性、壓縮率、通用訪問能力等方面提供了一系列新的或改進的功能。MPEG-4視頻在提供較好的圖像質量的同時擁有較高的壓縮率，適合於作爲傳輸 的圖像壓縮標準。
2 相關技術
2.1 DirectShow技術簡介
DirectShow是Microsoft爲開發高性能多媒體應用而開發的底層應用程序接口（API）,它是DirectX家族的核心成員之一。 DirectShow自身是通過一種系統內置的或程序員開發的過濾器（Filter）來控制和處理多媒體數據的體系結構。該體系結構定義瞭如何處理和控制 過濾器內部及相互之間的多媒體數據流。每個過濾器都有輸入或輸出針（Pin）, 或兩者都有。
過濾器（Filter）是DirectShow的基本組成部分，是Filter Graph(過濾器圖)中最小的功能模塊，DirectShow將多媒體數據的處理分離成不同的步驟，這些不同的步驟由相應的Filter去處理。這樣我 們可以把不同的過濾器搭配在一起達到我們要求的來處理多媒體數據。過濾器根據實現功能的不同大致可分爲3類：
（1） 源過濾器（Source Filters）。源過濾器負責得到原始媒體數據。這些媒體數據的來源包括本地硬盤或網絡上的媒體文件、各種採集卡等。
（2） 轉換過濾器（Transform Filters）。轉換過濾器的任務是處理從其他過濾器中接收的數據，經過一定的處理後再傳遞給下一個過濾器。編解碼器就是典型的轉換過濾器。
（3） 表現過濾器（Rendering Filters）。表現過濾器對接收到的數據進行最後的處理。它做的工作有：把媒體數據保存爲文件、將數據發送到網絡、顯示視頻、回放音頻等[1]。
在DirectShow 系統之上是應用程序(Application) 。應用程序要按照程序所要實現的功能建立起相應的Filter Graph ,然後藉助於Filter Graph Manager 來控制整個數據的處理過程。DirectShow 能在Filter Graph 運行的時候接收到各種事件,並通過消息的方式發送到應用程序。這樣就實現了應用程序與DirectShow 系統之間的交互。
2.2 RTP/RTCP協議介紹
實時傳輸協議RTP(Realtime Transport Protocol)是針對Internet 上多媒體數據流的一個傳輸協議，1996 年由IETF( Internet 工程任務組) 的AVT小組作爲RFC1889 發佈AVT小組後來對該文檔進行了不斷改進，於2003年7月提出了代替RFC1889的RFC3550。RTP充分體現了應用層分幀這一現代通信協議的 設計思想，允許其用戶瞭解、調整甚至制定連續媒體的打包方案，該協議被廣泛用於VoIP、視頻等實時媒體的傳送。RTP 協議包括RTP 和RTCP(RTP 控制協議) 兩個關係十分密切的子協議：
(1) RTP協議－傳輸具有實時特性的數據；
（2）RTCP協議-監測QoS 和傳送參與傳輸者的信息。
RTP(實時傳輸協議) 通常工作在UDP的上層，從上層接收多媒體信息碼流(如MPEG-4視頻) ，組裝成RTP 數據包,然後發送給下層UDP ，相當於OSI 的會話層，提供同步和排序服務。故RTP 協議適用於傳送連續性強的數據，如視頻、音頻等，並對網絡引起的時延差錯有一定的自適應能力。RTCP 爲實時控制協議，用於管理控制信息，如監視網絡的延時和帶寬，一旦所傳輸的多媒體信息的帶寬發生變化，接收端則通知發送端，廣播符號化識別碼和編碼參數， 達到控制傳輸質量的目的。此外,如果底層網絡支持多點傳播的話，RTP 還支持使用多點傳播向多個目的端點發送數據。
RTP協議具有如下特點[5]：
（1）靈活性
RTP協議的數據報文和控制報文使用不同的端口，數據流和控制流分離，這樣大大地提高了協議的靈活性，處理也簡單。
（2）支持多播
如果下層網路支持，可以支持多播。
（3）可擴展性
RTP協議通常爲一個具體的應用提供服務，通過一個具體的應用進程實現，而不作爲OSI體系結構中單獨的一層來實現，RTP只提供協議框架，開發者可以根據應用的具體要求對協議進行充分的擴展。
3 關鍵技術的實現
該系統的發送端實現思路如下：用USB攝像頭採集數據，用Divx 5.1.1 Codec 對採集到的數據進行MPEG-4的編碼，然後連到一個發送Filter把編碼後的數據發送出去。其Filter Graph如圖1所示 ：
圖1 發送端的Filter Graph
接收端的實現思路如下:通過一個接收Filter接收發送端發送的數據，然後再用Divx Decoder Filter對接收到的數據進行解碼。最後用Video Renderer把解碼後的數據播放出來。其Filter Graph如圖2所示：
圖2 接收端的Filter Graph
3.1 數據採集及編碼的實現
3.1.1 採集Filter Graph的實現
採集應用的Filter Graph一般比較複雜，而直接使用Filter Graph Manager上的IGraphBuilder接口構建這種Filter Graph,有時候難度又很大。爲此，DirectShow特別提供了一個輔助組件Capture Graph Builder,來簡化這種Filter Graph的創建。
首先是創建Filter Graph Manager 組件，核心代碼如下：
3.1.2 加入採集Filter
3.1.3加入MPEG-4編碼器Filter
這裏我們採用Divx 提供的開源編碼Filter。安裝DivX.Pro.v5.1.1後會自動安裝Divx的編碼器Filter和解碼器Filter（注：解碼器 Filter在接收端要用到）。在程序中加入Divx的編碼器Filter，實現思想是在Video Compressors目錄下枚舉到名稱爲"DivX Pro(tm) 5.1.1 Codec"的Filter項後，把它加入到Filter Graph中即可。
3.2 數據的發送和接收
3.2.1 數據的發送Filter的實現
數據的發送要開發一個發送Filter，爲了編程上的方便，這裏採用程序內Filter的形式來實現。即用類的形式而不是編寫一個成一個後綴爲ax的組件 註冊後再使用。這裏我們定義一個繼承自CBaseFilter的類CFilterMpeg4Sender。這個類必須實現以下功能[3]：
(1) 在類中定義CFilterMpeg4Sender上的Pin的實例mInputPin。
(2) 實現繼承自CBaseFilter::GetPin,用於返回Filter上各個Pin的對象指針。
(3) 實現繼承自CBaseFilter::GetPin,用於返回Filter上各個Pin的數量。
定義一個繼承自CRenderedInputPin的類CMpeg4InputPin，用於實現CFilterMpeg4Sender上的輸入pin，發送Filter通過該輸入pin接收編碼Filter輸出的數據，然後按一定的規則發送。
這個類必須實現以下功能[2]：
(1) 重寫方法EndOfStream。
(2) 實現IPin::BeginFlush和IPin::EndFlush兩個函數。
(3) 重寫方法CBasePin::CheckMediaType進行連接時媒體類型的檢查。
(4) 重寫方法CBasePin:: Receive(),接收Sample併發送
3.2.2 數據的接收Filter的實現
數 據的接收其實是要編寫一個Source Filter, 這個Source Filter名稱爲CFilterMpeg4Receiver，也繼承自CBaseFilter。這跟發送Filter的實現有些類似，有一點需要注意的 是該Filter輸出的MediaType的設置。
Char MediaType[]=//媒體數據類型,通過在發送端把媒體類型寫到一個文件中而得到然後通過語句：CFilterMpeg4Receiver:: SetupMediaType((char *)MediaType,88)設置輸出數據的MediaType。
CFilterMpeg4Receiver::SetupMediaType再調用CMpeg4OutPin::SetupMediaType（）設置、接收到的媒體數據的格式，
3.2.3 數據的網絡傳輸的實現
數據的發送我們採用開源代碼JRTPLIB【6】提供的RTP協議棧。最新的JRTPLIB對RFC3550的實現進行了封裝，開發人員只要初步瞭解 RTP協議就可以開發出高質量的音視頻傳輸程序。使用JRTPLIB時，只需要通過繼承RTPSession類，再重新以下幾個函數就可以實現視頻數據的 接收。
在網絡帶寬比較低的情況下（如十幾KBps），數據丟幀現象比較嚴重，這對於圖像質量有很大的影響。我們採用拆幀（拆成1400個字節）以後再發送的方法，來降低丟幀率。接收端收到數據後，再把屬於同一視頻幀的數據再組起來。
網絡發送接收程序流程圖如圖3所示：
圖3 網絡發送接收程序流程圖
對程序流程圖的說明如下：
（1）發送端拆幀的算法如下：
然後把屬於同一視頻幀的數據組好，發送到解碼Filter。
經過測試（在CDMA1.X網絡下），採用拆幀方法傳輸視頻數據比直接發送丟包率更低，傳輸質量有了很大的提高。
3.3 數據解碼及回放的實現
解碼Filter使用的是Divx提供的開源解碼器，在接收Filter的後面接上該解碼Filter即可，最後接上Renderer Filter就可以把接收到的數據回放出來。
3.4 實現幀率控制功能
通過在採集設備和編碼Filter（DivX Pro(tm) 5.1.1 Codec）之間加入一個幀率控制Filter來實現幀率的控制，該Filter相當於一個視頻幀數計數器，每接收到一幀，並不立即把該幀發給下游的編碼 Filter，而是把計數器的值加1，當計數器的值達到最大值時才把當前收到的幀發出去。在接收端發控制幀率命令給採集端可以很方便的實現幀率的遠端控 制。
程序片斷如下：
加了幀率控制Filter的發送端 Filter Graph 如圖4所示：
圖4 實現了幀率控制的Filter Graph
4 總結
該系統採用了DirectShow技術實現了MPEG-4視頻數據的傳輸，視頻數據的傳輸採用了RTP協議。而且還實現了遠端幀率的控制，該系統可以很方 便的移植到未來3G網絡的圖像傳輸系統中。對編解碼器進行研究，採用H.264技術實現編解碼Filter是下一步要完成的工作，當然在傳輸質量 （QoS）方面也要深入進行研究。
參考文獻
1 邵林,曹漢強.基於DiectShow的視頻廣播系統設計與實現[J].微型機與應用,2004, 4 :58-602 Microsoft DirectX C++ SDK Document [EB/OL],2003
3 陸其明.DiectShow開發指南[M].北京.清華大學出版社,2004
4 陸其明.DiectShow實務精選[M].北京:科學出版社,2004
5 張明華.《基於RTP的視頻傳輸控制方法的研究》[D].鄭州市：鄭州大學, 2004.3
6 Jori Liesenborgs JRTPLIB 3.1.0 [EB/OL]
