基于DirectShow架構的無線視頻服務系統設計研究

摘要:視頻實時網絡化已經成為信息傳播的重要途徑，特別是隨著無線技術的不斷發展，以無線網絡承載的視頻業務將進一步推動各類迫切需要通過視頻才能盡情表達的內容和服務。但無線網絡本身固有的種種約束與人們對視頻服務的期望和要求存在距離，通過優化視頻數據的傳輸和控制機制，系統架構設計的層次與方法和圖像處理策略，以不依賴于具體某種視頻壓縮技術為前提，進一步有效的挖掘現有無線網絡的潛力，讓視頻盡早的進入商業服務領域成為可能。

關鍵詞:無線網絡;視頻;系統架構;DirectShow;傳輸機制;控制

中圖分類號:TP37文獻標識碼:A 文章編號:1009-3044(2010)01-80-03

Wireless Video Services System Design Based on DirectShow Architecture

ZHANGQing

(Department of Automation， Shanghai Jiao Tong University， Shanghai 200240， China)

Abstract: Real-time network video technology has become an important means of information dissemination， especially as wireless technology continues to evolve in networks for video services. That will further promote the urgent need for various types of expression by video in order to enjoy the content and services. However， there is distance， inherent in all kinds of wireless network constraints and people's expectations and requirements of video services. With the optimizing the video data transfer mechanism and control mechanism， the system architecture level and method and image processing strategies which never depends on specific types of video compression technology. Effectively exploit the existing potential of wireless networks would make video as soon as possible to enter the field of business services.

Key words:wireless network; video; system architecture; DirectShow; transfer mechanism; control

1 DirectShow 架構介紹

DirectShow 是微軟公司提供的一套在 Windows 平臺上進行流媒體處理的開發包，與 DirectX 開發包一起發布[1]。

DirectShow [2]是基于組件對象模型(COM)的一種架構，該架構的三層關系本質是:Source 是該架構的入口，同時提供數據源;Transform 是該架構的處理核心，要對所有數據進行各種運算加工，凡對數據進行操作的COM模塊，統屬于該層次;Render 是該架構的表現核心，各種媒體類型的數據表現均可在該層完成(參考圖1)。

2 DirectShow 架構分析

2.1 理解Pin

Filter 的連接是通過其上Pin腳連接，方向通常從Upstream Filter 的輸出Pin 腳傳向Downstream Filter 的輸入Pin腳，這個連接的本質是一個協商的過程。Pin間的數據傳送單元sample(Allocate COM組件)通過協商完成 sample的容量大小，數量和創建者，以及連接雙方Pin上使用的媒體類型，至此協商完成。顯然， 網絡視頻流中的每個sample單元與Pin間傳送的sample單元間沒有直接內容的關聯。一個是根據壓縮算法裝包/解包原則實現，另一個是根據網絡傳輸打包原則實現。

2.2 封裝

這里將不討論視頻壓縮的相關技術， 直接引用經H264壓縮過視頻數據做仿真系統分析討論。以下圖示標明分別用UDP(圖2)和TCP(圖3) 封裝封裝的全過程， 可將其分三層理解。

圖2圖3

第一層:圖像壓縮包根據壓縮算法的規范和分界，無論是流模式還是幀模式，視頻中的每一個張圖像都被虛擬化成一個個變長大小的包，每一個邏輯包在經過解碼之后，都是一張完整的圖像表達(解碼前數據包之間的關聯取決于編碼策略和方式)。

第二層:網絡包的尺寸變化范圍是限定的。顯然，一個邏輯圖像包多數情況需要被多個網絡包去承載，對于TCP這種封裝形式，其被稱之為流封裝，包與包間是無縫的，如果需要在每個網絡數據包上運用組合算法，則需要增加分界標識。而用UDP這種封裝形式，其稱之為數據包封裝，包與包間是存在固有邊界，雖然UDP是不可靠的傳輸(可通過多種應用算法和策略優化降低其不可靠，稍后會談及)但其快速響應的優點仍在圖像信息傳輸中扮演重要的角色。

第三層:在每一個網絡包中，為了有效的管理數據，我們不單單加載數據信息，也封裝進各類應用管理協議和標識字段，用來控制，標識，表達其中的內容，如RTCP。

3 視頻在無線網絡中實時傳輸所面臨的若干挑戰和對策

3.1 主要問題點和設計關鍵點

無線網絡，特別是采用802.11WLAN時[3]，持續負荷大容量數據時容易受外界環境干擾從而出現延遲增大，掉包，連接中斷，無信號等狀況。除了在工程安裝方面的優化改造，加強增益以外。還可從系統設計方面，考慮關鍵幀的超時重傳和非關鍵幀的緩沖重組機制，以及主動丟棄策略[4]。同時心跳保活機制和主動掃描最強信號也可有效的保障無線網絡連接的不間斷。

3.2 與DirectShow 的匹配設計

當使用獨占的網絡資源，并且網絡帶寬充裕，網絡狀況始終保持良好。由于采用DirectShow架構進行視頻處理[5]，數據傳送單元sample的內容既是每次要render的圖像完整內容。如果sample不是完整的一幀圖像內容，則會出現圖像信息丟失(表現為花屏和黑屏) ，而采用H264編碼算法，存在I幀，P幀，B幀大小各異，且即便是同種類型的幀之間的大小也不相同。需要完整的將一幀圖像通過網絡傳出就需要花費數量不等的RTP包，這里可采用Frame-Marker技術，即在圖像采集壓縮打包的一端將每一幀圖像做標記，這樣在網絡的另外一頭進行解包時，在沒有得到當前幀結束標志之前，始終以阻塞狀態對待下一級的連接Pin，暫時不傳送數據給下一級等待接收處理數據的filter，并持續將新接收到的數據堆放在緩沖bucket中。這樣就可保證在Pin間傳遞的sample中裝載的是完整的一個I(或P或B)幀圖像，使得解碼之后，完成一幀圖像的Render表現任務。

3.3 多策略

當存在多個連接終端時(點對點連接)[4，6]，網絡中的帶寬資源的需求會增大，就存在網絡可以提供的帶寬資源小于等于某一時刻實際需要的帶寬總資源的可能性。這時，就會出現網絡資源占用峰和占用谷的現象，而圖像的表現則會可能出現以下兩種狀況:

①如果在碼流控制中輔助有速度匹配，則會出現圖像逐漸延遲，而這種延遲具有累加效果，最終這個延遲的上限時間由網卡中接受RTP (承載在UDP)緩沖的大小而限制，當限制達到門限值，就會出現個體差異的固有圖像延遲。

②如果沒有在接收端的Source Filter進行碼流控制，并且解碼器有能力進行快速解碼，則會出現短暫的快放現象。這是其消費已寫入網絡緩沖的數據行為表現，有時也有時快時慢的現象。

我們在 ①中可以通過建立動態緩沖池鏈表[7-8]，一旦網絡上有數據傳過來，就將數據從網卡上第一時間取出堆放在緩沖池鏈表中，鏈表另外一頭勻速的將緩沖池鏈表數據釋放出，傳給解碼部分。仿真設計源平均3秒產生一個I幀，當鏈表的長度超過設計長度(根據虛擬網卡緩存大小)，將有以下幾種機制對策:

魯棒優化(Robust Optimization):

設定當鏈表的長度超過本機網卡緩存限制或當前套接字緩沖限制或I幀結點個數大于5個，則將鏈表單元上所有幀都丟棄，直到最后一個I幀結點，并將其改為鏈表新頭，這種優化方法在仿真環境可能的最大的完整圖像延遲為(3×5) 15秒。

指數退避優化(Exponent Retreat Optimization):

設定當鏈表的長度超過本機網卡緩存限制或當前套接字緩沖限制或I幀結點個數分別大于 ，則將鏈表單元上所有幀都被銷毀丟棄直到最后一個I幀結點，并改為鏈表新頭。這種優化方法在仿真環境可能的最大的完整圖像延遲為[3×(1+2+4+8)] 45秒。

源流控制優化(Source Streaming Control Optimization):

數據源頭定期會接到接收端發送的反饋狀況報告，相應做出判斷與當前接收方庫存容量和消費速度匹配的發送機制:如果庫存容量超過設計閥值，并且消費速度大于系統設計基準速度，則源頭可以根據系統性能做動態縮減碼流帶寬，推遲關鍵幀出現，以及主動丟棄一個時間片單元的圖像數據，等等，從而降低源頭對后端網絡模塊和處理模塊的壓力;如果庫存超過設計閥值，但消費速度小于基準速度，可以選擇不做源頭的調整， 僅提高前端發送狀況報告的頻率。

P幀I幀調節優化(P Frame I Frame Regulation Optimization):

設定當鏈表的長度超過本機網卡緩存限制或當前套接字緩沖限制或I幀結點個數大于設定閥值的個數時，銷毀這些I幀中間的所有P幀“參考幀”。這種優化方法存在多跳，每一次跳躍跨一個關鍵幀時間段(仿真環境為3秒)，但經過處理依然盡可能的保存圖像信息的完整性。

QoS application:

通過指定服務類型RTSP 和RTP/RTCP來改善在傳輸信道中和實時圖像傳輸有關的數據傳輸優先級，從而盡可能的將傳輸信道資源用于圖像信息負載 (屬于數據通訊中的實現范圍，這里不進行詳細闡述)。

3.4 多用戶

當存在連接用戶非常多(上百)[6]，前端的無線網絡肯定是無法承受一對多的點對點模式，需要通過多處分流的無線接入，同時根據系統容量，設計多個可以級聯的視頻轉發服務器[5]。但如果是在純粹的局域網中，也可采用組播方式建立通訊共享視頻數據[4]，這樣能有效的控制總體延遲和個體間時間差，也能把對視頻服務器的一部分壓力轉移給網絡設備去承擔。

3.5 無線局域網傳輸方式的多樣化討論

①如果要實現的系統需要實時性強，但圖像內容精細度要求不高，且整體結構簡約，可考慮采用UDP進行音視頻數據的封裝，因為傳輸時可以通過RTP應用層協議確保數據的有序性和同步性。當數據量大時(并發數據量超越網絡中交換機的轉發能力)或無線網絡信號時強時弱，甚至中途無線接入設備斷電或被移除。在網絡自恢復后，圖像實時傳輸也可快速自恢復，特別是采用默認的非阻塞方式傳送音視頻數據，可以大大減少個別接收端故障對整個系統造成的負面壓力影響。

該模型的優化空間依然很大，這里做幾個簡單的優化模型例子[8]:一個是為了減少二次數據協議封裝帶來的帶寬浪費，可以在先建立一條面向連接的連接通路，這條通路好比是高速公路，然后將所有數據通過這個TRUNK發送。另一個是建立分布式的樹形轉發機制，盡可能讓每個點的負荷和通訊效率趨近于更優化組合(通過壓力測試和計量統計取得平衡點數據)，同時也可實現對數據冗余備份，提高視頻傳播的可靠性。

②如果目標系統需要圖像質量好，盡可能減少圖象信息丟失，且需要數據流局域網透傳，特別是無線網絡的信號強弱變化劇烈時，單從應用協議上排列和同步數據，數據的錯誤率依然會較高，此時建議采用TCP 進行封裝為好，RTP/RTCP確保數據的雙重有序性和同步性。不過，Connect數量的遞增對系統的負荷會呈指數型遞增，并且，一旦網絡被切斷，需要重新建立連接來恢復視頻通道，都需要增加輪訓守護機制確保自動重連的實現。另外，如果目標是個別接收端的故障不會對整個系統造成不穩定影響，需要結合多線程和傳輸組織策略來進一步改善。

4 結論

網絡傳輸視頻，如果所有傳輸媒介都是無線局域網，那么系統容易受到外界環境的影響，特別是距離和隔斷物。如果無線只是作為接入方式，而點間傳輸最終要流經廣域網，除了帶寬資源非常有限外，而且由于中間路由時常變化。這樣，實現一個有限網絡資源的實時穩定無線視頻瀏覽系統就具有較高的商業價值。而今，無線網絡的長足發展，更離不開對有限資源的優化運用。

參考文獻:

[1] Microsoft DirectX9.0 SDK . http:// www.microsoft.corn，2006-12-11.

[2] 陸其明.DirectShow開發指南[M].北京:清華大學出版社，2003.

[3] 802.11 Wireless Networks: The Definitive Guide， 2/e.Matthew S. Gast. O'Reilly，2006-4-1.

[4] 熊利祥.基于SIP的視頻會議系統設計與實現[J].武漢理工大學學報.2009-08-05.

[5] 鐘禮秋，馬爭.基于DirectShow的MPEG-4監控系統的設計與實現[J]. 電子科技大學學報，2007(1).

[6] 楊格蘭，曹理宇.多路視頻遠程傳輸系統的設計與實現[J].湖南工程學院學報(自然科學版)，2006(1).

[7] Advanced Programming in the UNIX Environment. W.Richard Stevens， Stephen A.Rago . Addison-Wesley.2005-6-27.

[8] Unix Network Programming， Vol.1:The Sockets Networking API，Third Edition. W.Richard Stevens，Bill Fenner， Andrew M. Rudoff，Richard W.Stevens . Addison Wesley/Pearson.2003-12-24.