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