面向Android客戶端的無(wú)線視頻監(jiān)控系統(tǒng)設(shè)計(jì)

摘 要： 為了滿足智能家居應(yīng)用中隨時(shí)隨地進(jìn)行視頻監(jiān)控的要求，基于ARM嵌入式平臺(tái)，設(shè)計(jì)一種面向Android客戶端的無(wú)線視頻監(jiān)控系統(tǒng)，該系統(tǒng)可實(shí)現(xiàn)無(wú)線中繼傳輸，具備端到端動(dòng)態(tài)地址連接能力，并按需采集傳輸視頻數(shù)據(jù)。系統(tǒng)采用H.264視頻編碼技術(shù)，基于實(shí)時(shí)傳輸協(xié)議和IEEE 802.11g協(xié)議傳輸數(shù)據(jù)，可通過(guò)無(wú)線局域網(wǎng)或互聯(lián)網(wǎng)獲得監(jiān)控視頻。通過(guò)構(gòu)建實(shí)驗(yàn)演示平臺(tái)進(jìn)行了系統(tǒng)測(cè)試和分析，結(jié)果表明該系統(tǒng)部署靈活，獲取的監(jiān)控畫面清晰穩(wěn)定，可以滿足無(wú)線網(wǎng)絡(luò)環(huán)境下家庭視頻監(jiān)控的要求。

關(guān)鍵詞： 視頻監(jiān)控； 中繼傳輸； 無(wú)線網(wǎng)絡(luò)； 端到端連接

中圖分類號(hào)： TN948.64?34； TP399 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2016）12?0006?04

Abstract： Aiming at demand of getting video surveillance whenever and wherever possible in application process of smart home， a wireless video surveillance system for Android client was designed on the basis of ARM embedded platform. The system supports wireless relaying transmission， possesses an ability of peer?to?peer （P2P） connection with dynamic address， acquires and transmits video data as required. The H.264 video coding technology is adopted in the system. The real?time transport protocol （RTP） and IEEE802.11g protocol are used to transfer the encoded data. Surveillance video can be gotten with wireless local area network or Internet. An experimental demonstration platform was built to test and analyze the performance of the system. The results show that the system can be flexibly deployed， the accessed monitoring video is clear and stable， and the wireless video surveillance system can meet the requirements of video monitoring for smart home in the wireless network environment.

Keywords： video surveillance； repeating transmission； wireless network； peer?to?peer （P2P） connection

家庭視頻監(jiān)控是智能家居的重要組成部分，人們希望能隨時(shí)隨地查看家中各個(gè)房間的監(jiān)控視頻，以確保家庭成員和環(huán)境的安全。傳統(tǒng)的監(jiān)控系統(tǒng)裝配體積較大的監(jiān)控設(shè)備和服務(wù)器，采用有線傳輸監(jiān)控畫面，具有布線復(fù)雜、可擴(kuò)展性差、靈活性低的特點(diǎn)。隨著無(wú)線通信網(wǎng)絡(luò)技術(shù)的發(fā)展和網(wǎng)絡(luò)帶寬的提高，視頻監(jiān)控可以通過(guò)更加方便靈活的無(wú)線網(wǎng)絡(luò)傳輸數(shù)據(jù)，而采用802.11單跳網(wǎng)絡(luò)傳輸視頻數(shù)據(jù)存在覆蓋范圍小，邊緣地帶信號(hào)質(zhì)量差的問(wèn)題，不能很好地滿足家庭視頻監(jiān)控的要求[1?3]。同時(shí)，視頻點(diǎn)播以及視頻監(jiān)控普遍采用服務(wù)器轉(zhuǎn)發(fā)模式，并持續(xù)進(jìn)行視頻數(shù)據(jù)采集與傳輸，對(duì)采集端和服務(wù)器處理能力以及網(wǎng)絡(luò)傳輸帶寬要求較高。而在傳輸端和客戶端之間建立直連，按需采集傳輸視頻數(shù)據(jù)，能夠減小資源消耗，并可在一定程度保障家庭視頻監(jiān)控信息的安全。近年來(lái)，Android智能手機(jī)和平板電腦已經(jīng)得到普及，因而，面向Android客戶端的P2P無(wú)線視頻監(jiān)控系統(tǒng)將具有廣泛的應(yīng)用價(jià)值。

1 系統(tǒng)設(shè)計(jì)

視頻監(jiān)控的目的是幫助人們利用網(wǎng)絡(luò)和終端實(shí)時(shí)訪問(wèn)家庭監(jiān)控視頻，掌握家中的安全狀態(tài)，采集家中的監(jiān)控視頻信息，客戶端通過(guò)采集端IP地址請(qǐng)求訪問(wèn)監(jiān)控視頻。在家庭局域網(wǎng)中，采集傳輸端和客戶端可通過(guò)分配的靜態(tài)局域網(wǎng)絡(luò)IP地址建立端到端（Peer to Peer，P2P）連接。而當(dāng)客戶端通過(guò)移動(dòng)互聯(lián)網(wǎng)（或互聯(lián)網(wǎng)）進(jìn)行遠(yuǎn)程訪問(wèn)時(shí)，由于采集傳輸端和客戶端多沒(méi)有全球惟一的IP地址，需要借助外部服務(wù)器進(jìn)行地址轉(zhuǎn)發(fā)幫助建立連接。所以整個(gè)視頻監(jiān)控系統(tǒng)由視頻采集傳輸端、客戶端和外部服務(wù)器組成。在一個(gè)無(wú)線接入點(diǎn)（Access Point，AP）不能覆蓋家庭范圍的情況下，可使用多個(gè)AP中繼傳輸擴(kuò)大監(jiān)控范圍。系統(tǒng)連接關(guān)系示意圖如圖1所示。

1.1 無(wú)線視頻采集傳輸模塊設(shè)計(jì)

為了適應(yīng)安裝靈活、低成本、高性能的應(yīng)用需求，系統(tǒng)采用ARM處理器作為視頻采集傳輸端的處理核心。在常規(guī)工作模式下，按需采集和傳輸數(shù)據(jù)，沒(méi)有查看請(qǐng)求時(shí)不啟動(dòng)視頻采集傳輸流程，可極大地降低不必要的信息傳輸流量。為了有效保障家庭安全，系統(tǒng)通過(guò)紅外傳感器、接近傳感器、玻璃破碎傳感器檢測(cè)外部接近和意外闖入事件，通過(guò)事件驅(qū)動(dòng)啟動(dòng)視頻采集流程進(jìn)入事件驅(qū)動(dòng)監(jiān)控模式，并實(shí)時(shí)推送告警消息。在事件驅(qū)動(dòng)監(jiān)控模式下，客戶端可遠(yuǎn)程存儲(chǔ)監(jiān)控視頻信息。也可通過(guò)圖像檢測(cè)的方法判斷是否有異常闖入事件。

無(wú)線視頻采集傳輸模塊硬件組成包括ARM處理器、紅外傳感器、接近傳感器、玻璃破碎傳感器、USB攝像頭、SD卡、無(wú)線局域網(wǎng)模塊。傳感器數(shù)據(jù)輸出口與處理器輸入口連接；USB攝像頭采集視頻數(shù)據(jù)可存儲(chǔ)于大容量SD卡；無(wú)線局域網(wǎng)模塊通過(guò)SDIO接口與處理器連接，接入家庭無(wú)線局域網(wǎng)。Android智能終端作為接收客戶端。傳輸模塊硬件組成如圖2所示。

1.2 無(wú)線視頻監(jiān)控系統(tǒng)軟件設(shè)計(jì)

現(xiàn)行的家庭遠(yuǎn)程視頻監(jiān)控系統(tǒng)多通過(guò)第三方服務(wù)器進(jìn)行視頻的轉(zhuǎn)發(fā)和存儲(chǔ)，家庭內(nèi)部視頻信息存儲(chǔ)于外部服務(wù)器上，將帶來(lái)隱私保護(hù)的安全問(wèn)題，同時(shí)也會(huì)浪費(fèi)不必要的網(wǎng)絡(luò)資源和服務(wù)器資源。P2P點(diǎn)技術(shù)主要特點(diǎn)是整個(gè)網(wǎng)絡(luò)結(jié)構(gòu)中不存在中心節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)能同時(shí)作為信息提供者和信息消費(fèi)者，打破了傳統(tǒng)的服務(wù)器與客戶端的界限。無(wú)線視頻監(jiān)控系統(tǒng)可能受到的隱私安全威脅主要來(lái)自存儲(chǔ)視頻泄露和視頻采集傳輸端非法訪問(wèn)。采用P2P系統(tǒng)架構(gòu)可避免家庭視頻監(jiān)控?cái)?shù)據(jù)通過(guò)外部服務(wù)器進(jìn)行中轉(zhuǎn)和存儲(chǔ)，能有效保護(hù)家庭隱私。針對(duì)視頻采集端非法訪問(wèn)，可通過(guò)身份驗(yàn)證和視頻流加密相結(jié)合的方法，保證視頻會(huì)話連接的可靠和數(shù)據(jù)傳輸?shù)陌踩?，進(jìn)一步提高無(wú)線視頻傳輸系統(tǒng)的保護(hù)隱私能力。

因此，本系統(tǒng)采用P2P架構(gòu)。在無(wú)惟一IP地址的遠(yuǎn)程客戶端互聯(lián)網(wǎng)訪問(wèn)時(shí)，通過(guò)服務(wù)器與采集端交換地址和端口信息，以建立端到端連接。當(dāng)多個(gè)客戶端同時(shí)訪問(wèn)一個(gè)視頻采集傳輸終端時(shí)，在采集傳輸端和客戶端建立一個(gè)用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）多播組廣播監(jiān)控視頻數(shù)據(jù)，實(shí)現(xiàn)同時(shí)訪問(wèn)。系統(tǒng)軟件結(jié)構(gòu)如圖3所示，系統(tǒng)分為采集傳輸端、客戶端和服務(wù)器端軟件。其中采集傳輸端由視頻采集、壓縮編碼、數(shù)據(jù)通信、報(bào)警推送和發(fā)送端控制邏輯5個(gè)模塊組成。發(fā)送端控制邏輯用于檢測(cè)環(huán)境異常和用戶傳輸請(qǐng)求，控制采集傳輸和消息推送模塊的狀態(tài)。客戶端軟件分為數(shù)據(jù)通信、解壓解碼、視頻播放、推送接收、接收端控制邏輯模塊。接收端控制邏輯管理視頻數(shù)據(jù)請(qǐng)求。

2 無(wú)線視頻傳輸系統(tǒng)主要功能模塊設(shè)計(jì)

傳輸系統(tǒng)主要功能模塊包括數(shù)據(jù)采集、視頻編解碼、數(shù)據(jù)傳輸和端到端連接模塊。

2.1 數(shù)據(jù)采集

因?yàn)闊o(wú)線視頻傳輸系統(tǒng)采用按需采集和按需傳輸?shù)哪Ｊ?，需要采集系統(tǒng)在不啟動(dòng)視頻采集傳輸流程的時(shí)候具有發(fā)現(xiàn)家庭異常情況的能力，所以使用傳感器輔助檢測(cè)異常情況。數(shù)據(jù)采集模塊通過(guò)采集視頻數(shù)據(jù)為客戶端提供監(jiān)控畫面，通過(guò)采集傳感器數(shù)據(jù)感應(yīng)意外狀況，從而及時(shí)推送報(bào)警信息。

一個(gè)家庭內(nèi)無(wú)線視頻傳輸系統(tǒng)可能配置有多個(gè)采集傳輸端，家庭成員持有多個(gè)客戶端。一個(gè)傳感器采集到異常信息則給所有家庭成員客戶端推送報(bào)警信息。采集端傳感器在家庭成員外出或休息時(shí)可開(kāi)啟，傳感器異常報(bào)警推送流程如圖4所示。玻璃破碎傳感器檢測(cè)狀態(tài)異常，表明窗戶玻璃突然破碎；紅外傳感器和接近傳感器狀況異常，則表明有生物靠近門窗邊并持續(xù)接近。兩種情況下均認(rèn)為家庭安全受到外來(lái)人員威脅，發(fā)送報(bào)警推送請(qǐng)求。

2.2 視頻數(shù)據(jù)編解碼

視頻傳輸對(duì)網(wǎng)絡(luò)環(huán)境的要求非常高，要實(shí)現(xiàn)大容量視頻數(shù)據(jù)和視頻存儲(chǔ)，必須要先對(duì)采集到的視頻數(shù)據(jù)進(jìn)行壓縮處理。視頻編碼領(lǐng)域視頻編碼標(biāo)準(zhǔn)有H.263，H.264，H.265，MPEG?1，MPEG?2，MPEG?4等標(biāo)準(zhǔn)，其中，H.264編碼平均比H.263節(jié)省50%的碼率，能在低碼率情況下提供高質(zhì)量的視頻圖像[4]。并且市場(chǎng)上主流編解碼器對(duì)H.264的支持廣泛，而H.265由于硬件廠商支持不足的原因普及度不高，所以本視頻監(jiān)控系統(tǒng)編碼技術(shù)采用H.264標(biāo)準(zhǔn)。H.264編解碼通過(guò)視頻編碼層（Network Abstraction Layer，VCL）進(jìn)行視頻內(nèi)容的高效壓縮，通過(guò)網(wǎng)絡(luò)提取層（Network Abstraction Layer，NAL）完成數(shù)據(jù)格式的封裝，封裝后視頻數(shù)據(jù)能在Internet上利用傳輸協(xié)議傳輸數(shù)據(jù)[5]。NAL層封裝后的數(shù)據(jù)為網(wǎng)絡(luò)抽象層單元（Network Abstraction Layer Unit，NALU），H.264 的基本數(shù)據(jù)流由一系列NALU組成。

H.264編解碼實(shí)現(xiàn)方式有硬件編解碼和軟件編解碼，硬件編解碼利用支持H.264標(biāo)準(zhǔn)的解碼集成電路或含專用解碼芯片和系統(tǒng)芯片編解碼數(shù)據(jù)；軟件編解碼實(shí)現(xiàn)主要利用支持H.264標(biāo)準(zhǔn)的解碼軟件。硬件編解碼處理速度比較快，延時(shí)小，占用CPU資源少，本系統(tǒng)視頻數(shù)據(jù)的壓縮選用硬件編碼。但由于目前大部分Android設(shè)備不支持硬解碼，所以采用軟件解碼視頻流。

2.3 視頻數(shù)據(jù)傳輸

家庭無(wú)線視頻監(jiān)控系統(tǒng)中原始視頻數(shù)據(jù)經(jīng)過(guò)H.264編碼后，需要通過(guò)傳輸層協(xié)議封裝傳輸。TCP/IP協(xié)議棧傳輸層基本協(xié)議包括傳輸控制協(xié)議（Transmission Control Protocol，TCP）和UDP。其中TCP保證數(shù)據(jù)可靠傳輸，但傳輸時(shí)延較大，直接采用TCP傳輸視頻監(jiān)控?cái)?shù)據(jù)不符合實(shí)時(shí)傳輸?shù)囊?；而UDP傳輸簡(jiǎn)單、實(shí)時(shí)性強(qiáng)，但不保證傳輸數(shù)據(jù)可靠性和順序到達(dá)，客戶端收到的H.264視頻數(shù)據(jù)包可能無(wú)法正確按順序還原。實(shí)時(shí)傳輸協(xié)議（Real?time Transport Protocol，RTP）是建立在TCP，UDP上的傳輸層協(xié)議，為數(shù)據(jù)提供了具有實(shí)時(shí)特征的端對(duì)端傳送服務(wù)。RTP協(xié)議數(shù)據(jù)通過(guò)給數(shù)據(jù)包分配序列號(hào)的方法來(lái)確保視頻數(shù)據(jù)接收后按照順序恢復(fù)。在本系統(tǒng)中采用基于UDP的RTP傳輸實(shí)時(shí)視頻數(shù)據(jù)。

使用RTP傳輸H.264視頻流的方法是從H.264視頻中剝離出NALU。每個(gè)NALU 前用起始碼0x0001作為一個(gè)NALU的起始標(biāo)識(shí)。RTP在NALU前添加RTP包頭，然后將包含RTP 包頭和NALU 的數(shù)據(jù)包發(fā)送出去。

2.4 網(wǎng)絡(luò)連接建立

在視頻監(jiān)控系統(tǒng)中，傳輸端與客戶端建立連接時(shí)，需兩者處于同一局域網(wǎng)或者一方有合法公網(wǎng)地址。采集端和客戶端所處網(wǎng)絡(luò)和分配IP可能情況見(jiàn)表1。

表1 系統(tǒng)網(wǎng)絡(luò)分配情況

序號(hào)1所示情況可以直接通過(guò)局域網(wǎng)IP發(fā)起連接請(qǐng)求。序號(hào)2、序號(hào)3所示情況則不能直接請(qǐng)求建立連接，需通過(guò)網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）將采集端內(nèi)部地址映射為一個(gè)合法公網(wǎng)地址；802.11單跳網(wǎng)絡(luò)無(wú)法覆蓋整個(gè)家庭范圍，家庭內(nèi)部使用多AP部署無(wú)線網(wǎng)絡(luò)時(shí)，需要保證多AP所在網(wǎng)絡(luò)屬于同一局域網(wǎng)。網(wǎng)絡(luò)運(yùn)營(yíng)商給普通家庭用戶分配的IP一般是動(dòng)態(tài)變化的，沒(méi)有固定的公網(wǎng)IP，所以不能通過(guò)端口映射到公網(wǎng)IP的方式直接建立網(wǎng)絡(luò)連接，局域網(wǎng)內(nèi)的監(jiān)控設(shè)備和局域網(wǎng)外的智能終端需要通信，必須要進(jìn)行內(nèi)網(wǎng)穿透即NAT穿透[6]。

在NAT穿透技術(shù)中，UDP打洞（Hole Punching）技術(shù)通過(guò)聚集服務(wù)器，轉(zhuǎn)發(fā)公有端點(diǎn)地址消息，使兩個(gè)客戶機(jī)建立P2P UDP對(duì)話，不需要服務(wù)器和客戶端支持專有協(xié)議。在視頻監(jiān)控系統(tǒng)廣域網(wǎng)的應(yīng)用場(chǎng)景下，如表1中序號(hào)2、序號(hào)3情況所示，外網(wǎng)訪問(wèn)方案采用UDP打洞技術(shù)能最大程度減少服務(wù)器的開(kāi)銷。UDP打洞技術(shù)原理如圖5所示，A表示采集傳輸端，B表示客戶端。A向服務(wù)器發(fā)送UDP消息告知其設(shè)備標(biāo)識(shí)符和NAT地址，并在局域網(wǎng)地址上監(jiān)聽(tīng)UDP數(shù)據(jù)報(bào)。當(dāng)B希望與A建立P2P連接時(shí)，通過(guò)A的標(biāo)識(shí)符向服務(wù)器發(fā)送UDP請(qǐng)求查詢其NAT地址，服務(wù)器向B轉(zhuǎn)發(fā)A的NAT地址，用戶B向A的NAT地址發(fā)送UDP數(shù)據(jù)包，此時(shí)，用戶B的UDP數(shù)據(jù)包經(jīng)過(guò)NAT A的端口映射，轉(zhuǎn)發(fā)給用戶A監(jiān)聽(tīng)的UDP端口，A與B完成P2P連接建立的工作。

為了擴(kuò)大AP信號(hào)覆蓋范圍，無(wú)線網(wǎng)絡(luò)通過(guò)多個(gè)AP通過(guò)橋接或中繼器的方式連接形成分布式無(wú)線（Wireless Distribution System，WDS）網(wǎng)絡(luò)。中繼模式下從某一接入點(diǎn)接收的信息包通過(guò)分布式無(wú)線系統(tǒng)連接轉(zhuǎn)發(fā)到另一個(gè)接入點(diǎn)；橋接模式接收的信息包只能被轉(zhuǎn)發(fā)到有線網(wǎng)絡(luò)或無(wú)線主機(jī)。由于只有中繼模式可以進(jìn)行WDS到WDS信息包的轉(zhuǎn)發(fā)，所以系統(tǒng)中AP在中繼模式下建立連接，實(shí)現(xiàn)信號(hào)中繼和無(wú)縫切換，從而使接入不同AP的采集端和客戶端處于同一局域網(wǎng)網(wǎng)段。

3 實(shí)驗(yàn)及結(jié)果分析

為了檢驗(yàn)所設(shè)計(jì)視頻監(jiān)控系統(tǒng)的可行性以及性能，通過(guò)搭建實(shí)驗(yàn)開(kāi)發(fā)平臺(tái)進(jìn)行實(shí)驗(yàn)驗(yàn)證，并對(duì)視頻傳輸系統(tǒng)的性能進(jìn)行了分析。

3.1 系統(tǒng)實(shí)驗(yàn)平臺(tái)

系統(tǒng)的測(cè)試實(shí)驗(yàn)中硬件平臺(tái)的搭建處理器采用ARM11處理器，Linux 2.6.28系統(tǒng)內(nèi)核版本，處理器自帶MFC（Multi Format Codec）編碼器，支持H.264格式的編解碼；USB攝像頭采集視頻幀大小為320×240；接收端Android手機(jī)屏幕大小為480×800。

3.2 測(cè)試結(jié)果

本系統(tǒng)客戶端監(jiān)控畫面如圖6所示，屏幕顯示播放畫面大小為480×320，幀率為25 f/s。

為了測(cè)試數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性，進(jìn)行了數(shù)據(jù)包時(shí)延實(shí)驗(yàn)。采集傳輸端與AP間距離小時(shí)，使用單個(gè)AP傳輸無(wú)線信號(hào)；間距離大、網(wǎng)絡(luò)信號(hào)弱時(shí)，采用兩個(gè)AP中繼傳輸。采集傳輸端和客戶端位于不同局域網(wǎng)，數(shù)據(jù)包發(fā)送時(shí)間和接收后還原時(shí)間差值為接收時(shí)延。測(cè)試的網(wǎng)絡(luò)帶寬為2 Mb/s，兩種情況下分別進(jìn)行了50次實(shí)驗(yàn)，每次發(fā)送100個(gè)數(shù)據(jù)包，數(shù)據(jù)包發(fā)送時(shí)間到完全接收的延時(shí)均小于0.5 s，說(shuō)明網(wǎng)絡(luò)正常情況下，數(shù)據(jù)傳輸實(shí)時(shí)性強(qiáng)。

為了獲取視頻數(shù)據(jù)正常傳輸所需的最小帶寬，在單跳無(wú)線網(wǎng)絡(luò)和AP中繼無(wú)線網(wǎng)絡(luò)中分別進(jìn)行了接收成功率實(shí)驗(yàn)。限制采集端IP地址最大上行帶寬從0 Kb/s依次增加25 Kb/s直至300 Kb/s，記錄不同帶寬下成功收到的視頻幀數(shù)，計(jì)算平均接收成功率，結(jié)果如圖7所示。

從圖7中可以看出，在單跳網(wǎng)絡(luò)中，帶寬較小時(shí)有大量丟包，帶寬增加后成功接收率隨之增大，帶寬增大到200 Kb/s時(shí)視頻幀基本均能成功接收；兩個(gè)AP中繼傳輸時(shí)，視頻幀平均接收成功率與單跳傳輸接近，帶寬增大到250 Kb/s時(shí)視頻幀基本均能成功接收，傳輸?shù)姆€(wěn)定性也只略有下降。說(shuō)明兩種情況下監(jiān)控視頻傳輸需要的帶寬均較小，在網(wǎng)絡(luò)帶寬正常情況下丟包率很小，傳輸穩(wěn)定，家庭無(wú)線網(wǎng)絡(luò)帶寬能夠滿足監(jiān)控要求。

4 結(jié) 語(yǔ)

本文設(shè)計(jì)了一種基于ARM處理器、存儲(chǔ)設(shè)備、USB攝像頭、傳感器、無(wú)線網(wǎng)絡(luò)模塊和Android客戶端的無(wú)線視頻傳輸系統(tǒng)，按需采集傳輸視頻數(shù)據(jù)。設(shè)計(jì)了系統(tǒng)的硬件組成架構(gòu)和軟件功能模塊，實(shí)現(xiàn)了無(wú)線網(wǎng)絡(luò)下監(jiān)控視頻遠(yuǎn)程中繼傳輸，并通過(guò)實(shí)驗(yàn)測(cè)試了系統(tǒng)數(shù)據(jù)傳輸性能。本文設(shè)計(jì)的系統(tǒng)部署靈活，能適應(yīng)家庭視頻監(jiān)控不同使用場(chǎng)景的需要，獲取的監(jiān)控畫面清晰穩(wěn)定，可以滿足無(wú)線網(wǎng)絡(luò)環(huán)境下家庭視頻監(jiān)控的要求。下一步將重點(diǎn)解決身份驗(yàn)證、視頻流加密和圖像異常檢測(cè)等技術(shù)問(wèn)題，進(jìn)一步提高視頻傳輸系統(tǒng)的保護(hù)隱私能力。

參考文獻(xiàn)

[1] 林飛龍.基于ARM的遠(yuǎn)程監(jiān)控報(bào)警系統(tǒng)的研究與設(shè)計(jì)[D].長(zhǎng)沙：湖南大學(xué)，2014.

[2] 張超.基于嵌入式Linux的交通視頻采集傳輸系統(tǒng)[D].西安：長(zhǎng)安大學(xué)，2013.

[3] 謝慧芝.基于移動(dòng)終端的嵌入式視頻監(jiān)控系統(tǒng)的研究與應(yīng)用[D].南昌：南昌大學(xué)，2013.

[4] 孫克輝，堯平，洪娟娟，等.基于JRTPLIB庫(kù)的H.264視頻傳輸系統(tǒng)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2011，20（12）：21?24.

[5] 單俊麗.基于Android的流媒體客戶端的研究與設(shè)計(jì)[D].西安：西安電子科技大學(xué)，2013.

[6] 梁坤.一種面向安全虛擬網(wǎng)絡(luò)的NAT雙向穿透方法[D].長(zhǎng)沙：湖南大學(xué)，2010.

[7] Rosenberg J， Mahy R， Matthews P. Traversal using relays around Nat （TURN）： relay extensions to session traversal utilities for Nat （STUN）： RFC 5766 [S]. [S.l.]： FRC， 2010.

[8] 黃春文.中繼信道相位響應(yīng)模型及其估計(jì)算法研究[J].現(xiàn)代電子技術(shù)，2014，37（4）：13?16.