網路視頻監(jiān)控關鍵幀提取技術

應用背景
　　由于寬帶網絡近年來在世界各地的高速發(fā)展，高品質的音視頻壓縮技術不斷推陳出新，更高的壓縮比率加上更寬的帶寬，使得互聯網用戶在互聯網上觀看高品質電視節(jié)目的愿望不再是幻想。美國、意大利、法國、加拿大等國網絡視頻市場的日漸成熟，國內哈爾濱、泉州、上海等地的小試牛刀，都證明了以更強的互動性作為賣點、基于互聯網技術和P2P傳輸技術的網絡視頻服務已經漸成氣候。
　　網絡視頻是對基于互聯網技術傳播的所謂寬帶視頻的統(tǒng)稱，可以是用戶自己制作、在線上傳或點播視頻節(jié)目，自主性和自助性強。各種視頻網站和流媒體服務器隨著人們對網絡視頻服務的需求快速增長，民營網絡視頻企業(yè)更是如雨后春筍。
　　2007年是網絡視頻用戶基數迅速成長的一年。據CNNIC今年1月份發(fā)布中國互聯網調查報告，76.9%的網絡用戶使用網絡視頻，成為繼音樂、即時通信之后的第三大互聯網應用。這也是網絡家庭娛樂應用第一次全面超過了網絡商務應用，即郵件、搜索引擎和新聞等傳統(tǒng)資訊應用。
　　但隨著網絡視頻的高速成長，各種黃色、暴力和反動等垃圾信息也摻雜在網絡視頻中在寬帶網絡上肆意泛濫，嚴重影響了人們的正常工作和生活，也對社會精神文明建設和未成年人教育帶來了巨大的隱患。
　　由于寬帶視頻網絡的高速數據包傳送，傳統(tǒng)的信息安全監(jiān)控設備在這方面顯得力不從心，因此，我們提出應用關鍵幀提取技術來抽取網絡視頻中的關鍵幀，從而減小處理的負載和存儲空間，降低設備成本并提高處理效率。建立相應的垃圾視頻關鍵幀匹配庫，通過視頻關鍵幀匹配算法和模式，從高速的視頻流中監(jiān)測出垃圾信息。應用此視頻監(jiān)控系統(tǒng)和其他網絡安全設備，可以為企業(yè)、學校和家庭打造一個高速干凈的網絡視頻環(huán)境，讓人們輕松盡情享受寬帶視頻服務。
　　系統(tǒng)方案
　　1.視頻解碼方案論證
　　方案一：利用Xilinx公司的FPGA產品Spartan 3E實現系統(tǒng)的視頻解碼。在Spartan 3E支持的MicroBlaze微處理器軟核上移植開源視頻解碼器，由于MicroBlaze最高處理頻率為50MHz，遠不能滿足現在的高速視頻數據包的解碼；
　　方案二：通過在最新嵌入式微處理機eBox-4300上移植嵌入式操作系統(tǒng)WinCE來實現開源視頻解碼器。eBox處理器主頻為500MHz，可以滿足10/100MHz網絡的視頻解碼，且在eBox上的WinCE操作系統(tǒng)可移植性較好，便于以后在系統(tǒng)中加入更多的視頻格式解碼器。
　　2.數據包前端處理方案論證
　　方案一：利用Xilinx公司FPGA產品系列Spartan 3E來捕獲網絡中的視頻數據包。高速的邏輯結構和并行特性是FPGA的特性，通過FPGA來識別并捕獲視頻數據包能降低系統(tǒng)的丟包率和漏報率；
　　方案二：利用eBox-4300自帶的以太網接口直接連接到網絡上。由于WinCE操作系統(tǒng)下的以太網操作已封裝好，為了兼顧可移植性，因此其效率沒有直接在FPGA上實現的IP核好。
　　3.關鍵幀匹配方案論證
　　方案一：利用Xilinx公司的FPGA產品系列Spartan 3E來實現視頻關鍵幀標準庫的查找和匹配。由于FPGA特有的存儲單元結構，便于快速查找。
　　方案二：利用ADI公司的Blackfin 535數字信號處理器來實現視頻幀的匹配算法。DSP特有的快速音視頻處理能力能很好滿足系統(tǒng)的性能要求。但Blackfin的片上存儲空間有限，如果增加外部存儲器將降低關鍵幀查找速率，從而成為整個系統(tǒng)的瓶頸。
　　綜合上述：系統(tǒng)采用Xilinx公司的FPGA產品系列Spartan 3E來作為數據包前端處理，識別并捕獲相應格式的網絡視頻數據包，按序列將視頻數據包傳送到eBox-4300處理器上的視頻解碼單元。在eBox-4300處理器上抽取出視頻的關鍵幀后，將視頻關鍵幀傳送到在Spartan 3E上實現的關鍵幀匹配單元中進行匹配模式檢驗。
　　
　　圖 1 系統(tǒng)示意圖
　　實現原理
　　1. 視頻數據包識別捕獲
　　實時流協(xié)議RTSP是一個應用層協(xié)議，用于控制具有實時特性的數據如多媒體流的傳送。為多媒體數據流提供遠程控制功能，如播放、 停止、快進等。該協(xié)議支持以下操作：
　　1. 從媒體服務器上獲取媒體；
　　2. 邀請媒體服務器加入會議；
　　3. 在一個已存在的演示中加入新的媒體流。
　　RTSP協(xié)議一般與RTP/RTCP和RSVP等底層協(xié)議一起協(xié)同工作，提供基于Internet的整套的流服務。它可以選擇發(fā)送通道如UDP、組播UDP和TCP和基于RTP的發(fā)送機制。它可以應用于組播和點播。
　　RTSP協(xié)議負責在服務器和客戶端之間建立并控制一個或多個時間上同步的連續(xù)流媒體，其目標是像HTTP協(xié)議為用戶提供文字和圖形服務那樣為用戶提供連續(xù)媒體服務。因此，RTSP協(xié)議的設計在語法和操作上與HTTP協(xié)議很相似，這樣，對于HTTP的大部分擴展也適用于RTSP。但是RTSP協(xié)議和HTTP協(xié)議在很多方面有著區(qū)別：
　　1. HTTP是一個無狀態(tài)協(xié)議，而RTSP協(xié)議是有狀態(tài)的。
　　2. HTTP本質上是一個非對稱協(xié)議，客戶端提出請求而服務器響應；而RTSP是對稱的，服務器和客戶端都可發(fā)送和響應請求。
　　在RTSP中，每個演示及其所對應的媒體流都由一個RTSP URL標識。整個演示及媒體特性都在一個演示描述文件中定義，該文件可能包括媒體編碼方式、語言、RTSP URLs、目標地址、端口及其它參數。用戶在向服務器請求某個連續(xù)媒體流的服務之前，必須首先從服務器獲得該媒體流的演示描述文件以得到必需的參數，演示描述文件的獲取可采用HTTP、Email或其他方法。