基于IOS平臺的移動終端實時監(jiān)控系統(tǒng)*

侯沛德，楊軍平，許存祿

(蘭州大學信息科學與工程學院，甘肅蘭州 730000)

0 引言

隨著無線網(wǎng)絡以及流媒體在技術(shù)基礎(chǔ)、傳輸速率等方面的飛速發(fā)展，智能終端性能的不斷提高，極大的促進了移動流媒體的發(fā)展，進而促進移動多媒體業(yè)務的普及。在國內(nèi)外市場上，主要推出的是數(shù)字控制的模擬視頻監(jiān)控和數(shù)字視頻監(jiān)控兩類產(chǎn)品。前者技術(shù)發(fā)展已經(jīng)非常成熟、性能穩(wěn)定，并在實際工程應用中得到廣泛應用，特別是在大、中型視頻監(jiān)控工程中的應用尤為廣泛;后者是新近崛起的以計算機技術(shù)及圖像視頻壓縮為核心的新型視頻監(jiān)控系統(tǒng)，該系統(tǒng)解決了模擬系統(tǒng)部分弊端而迅速崛起，但仍需進一步完善和發(fā)展。目前，第三代基于網(wǎng)絡攝像機的網(wǎng)絡視頻監(jiān)控系統(tǒng)正興起，以它特有的優(yōu)勢會逐步成為監(jiān)控系統(tǒng)新的潮流。

眾所周知，視頻信息具有直觀性、確切性、高效性、廣泛性等特點，但視頻信息量太大，要視頻得到有效應用，首先需解決視頻壓縮編碼問題，其次解決壓縮后視頻質(zhì)量保證的問題，因此既要有較大的壓縮比，又要保證一定的視頻質(zhì)量。2003年3月，ⅠTU-T/ⅠSO正式公布了H.264視頻壓縮標準，它具有的目前最高壓縮效率使它成為了無線系統(tǒng)的最佳候選標準［1］。

筆者主要針對目前較為流行的ⅠOS平臺，實現(xiàn)了基于ⅠOS平臺下移動流媒體數(shù)據(jù)的接收、解碼、丟包處理、播放、錄制視頻等功能。采用了RTSP協(xié)議對視頻進行封裝發(fā)送，同時采用H.264編碼標準，在保持監(jiān)控系統(tǒng)特點的前提下，盡量將編解碼過程在達到監(jiān)控系統(tǒng)的要求下做到最簡與最優(yōu)，因此對FFmpeg開源框架進行研究，優(yōu)化該框架的解碼部分，最終實現(xiàn)ⅠOS平臺上的實時解碼工作［2］。

1 視頻監(jiān)控系統(tǒng)的總體設(shè)計

本系統(tǒng)的設(shè)計目標是通過iPhone手機客戶端，實現(xiàn)對視頻監(jiān)控系統(tǒng)所獲得的視頻圖像的實時獲取并實時顯示在客戶端屏幕上，從而實現(xiàn)移動終端的實時視頻流監(jiān)控。一般移動流媒體服務器系統(tǒng)包括三個部分:①與流媒體服務器相連接的視頻攝像頭;②流媒體服務器;③移動終端，這樣用戶就可以利用此系統(tǒng)來查看所需要監(jiān)控的地方。圖1所示為文中視頻監(jiān)控系統(tǒng)的基本架構(gòu)，各個子系統(tǒng)的功能如下。

(1)web服務器:該部分負責對系統(tǒng)的管理，主要對視頻列表及相關(guān)信息的管理等。

(2)流媒體服務器:該部分負責將獲取的視頻流信息進行編碼、分流、響應客戶端的請求以及發(fā)送請求的對應流媒體數(shù)據(jù)流等。

(3)移動終端:該部分完成查看實時監(jiān)控視頻畫面以及云臺控制的工作。

視頻監(jiān)控系統(tǒng)中視頻傳輸播放的流程圖如圖2所示，各個模塊功能介紹如下。

(1)攝像頭負責原始視頻數(shù)據(jù)的采集，它不用去考慮傳輸數(shù)據(jù)的格式。

(2)將原始視頻數(shù)據(jù)解析拆包處理，去除冗余信息，并將其轉(zhuǎn)換為解碼過需要的格式，本系統(tǒng)需要標準的H.264編碼格式的數(shù)據(jù)。

(3)在客戶端進行解碼，恢復出所需要的圖像數(shù)據(jù)并緩存在客戶端。

(4)將緩存的圖像數(shù)據(jù)在客戶端以UⅠⅠmage為載體顯示出來。

圖1 視頻監(jiān)控系統(tǒng)的基本架構(gòu)

圖2 視頻傳輸播放的流程圖

2 移動視頻監(jiān)控系統(tǒng)客戶端的實現(xiàn)

2.1 HTTP 協(xié)議

超文本傳輸協(xié)議，是Web服務中常用的一種協(xié)議，通過發(fā)送HTML來完成數(shù)據(jù)通信，也支持多媒體數(shù)據(jù)的傳送。

2.2 RTP/RTCP 協(xié)議

RTP(Real-Time Transport Protocol)是一種針對多媒體數(shù)據(jù)流傳輸?shù)膮f(xié)議，該協(xié)議支持一對一和一對多的傳輸情況，同時可提供時間信息和實現(xiàn)數(shù)據(jù)流同步。RTP協(xié)議大多數(shù)情況下通過UDP來傳輸數(shù)據(jù)，當然也支持TCP。當一個應用程序開始一個RTP會話時，會使用兩個端口:一個用來支持RTP，另一個是為RTCP提供服務。RTP本身并不能按順序傳送數(shù)據(jù)包提供可靠的傳輸機制，也不提供流量控制或者擁塞控制，這就需要RTCP來協(xié)助完成。

RTCP(Real-Time Transport Control Protocol)與RTP協(xié)議協(xié)調(diào)工作，共同提供流量控制和擁塞控制的服務。在RTP的會話期間RTCP扮演著質(zhì)量監(jiān)督檢測員的身份。RTP在RTCP的配合下，可以有效的進行反饋而達到減小開銷提高傳輸效率的目的。

2.3 RTSP 協(xié)議

實時流協(xié)議RTSP(Real-Time Streaming Protocol)是有Netscape和RealNetworks提出的。使用該協(xié)議，可以通過ⅠP網(wǎng)絡完成一對多的數(shù)據(jù)通信工作。RTSP協(xié)議可以很好的控制多個數(shù)據(jù)鏈路，并且提供選擇基于RTP上發(fā)送機制的解決方案。從體系結(jié)構(gòu)方面來講，它處于RTP和RTCP協(xié)議的上層，使用了RTP或TCP協(xié)議進行數(shù)據(jù)傳輸，RTSP協(xié)議利用流技術(shù)將數(shù)據(jù)分成數(shù)據(jù)包，而數(shù)據(jù)包的大小可以由網(wǎng)絡的帶寬所決定。用戶不需要下載整個媒體文件就可以實現(xiàn)播放，具體的播放過程為:客戶端下載完成并解碼第一個數(shù)據(jù)包進行播放的同時，對已經(jīng)下載好的第二個數(shù)據(jù)包進行解碼，而同時下載第三個數(shù)據(jù)包。通過RTSP協(xié)議就可以讓服務器端跟蹤流媒體在傳輸過程的時間，地址，方式，并可以實現(xiàn)暫停，快放等交互功能。

2.4 H.264 簡介

H.264和以前的標準一樣，也是DPCM加變換編碼的混合編碼模式。但它采用“回歸基本”的簡潔設(shè)計，加強了對各種信道的適應能力，采用“網(wǎng)絡友好”的結(jié)構(gòu)和語法，有利于對誤碼和丟包的處理;應用目標范圍較寬，以滿足不同速率、不同解析度以及不同傳輸(存儲)場合的需求。

技術(shù)上，H.264在所有碼率下都能持續(xù)提供較高的視頻質(zhì)量。H.264能工作在低延時模式以適應實時通信的應用(如視頻會議)，同時又能很好地工作在沒有延時限制的應用，如視頻存儲和以服務器為基礎(chǔ)的視頻流式應用。H.264提供包傳輸網(wǎng)中處理包丟失所需的工具，以及在易誤碼的無線網(wǎng)中處理比特誤碼的工具。

在系統(tǒng)層面上，H.264在視頻編碼層(Video Coding Layer，VCL)和網(wǎng)絡提取層(Network Abstraction Layer，NAL)之間進行概念性分割，前者是視頻內(nèi)容的核心壓縮內(nèi)容之表述，后者是通過特定類型網(wǎng)絡進行遞送的表述，這樣的結(jié)構(gòu)便于信息的封裝和對信息進行更好的優(yōu)先級控制。

2.5 H.264視頻解碼器的移植

從官方網(wǎng)站上下載FFmpeg的源碼，由于FFmpeg針對不同版本和硬件處理器，在內(nèi)部處理上會有區(qū)別，因此需要區(qū)別于不同的環(huán)境相應改變編譯腳本，才能保證FFmpeg在ios平臺下的正確使用。我們依次編譯對armv7、armv7s以及i386的支持，重新建立bash腳本來合并靜態(tài)庫，，編譯成功之后就會生成六個靜態(tài)庫，分別是 Libavcodec.a、Libavdevice.a、Libavfilter.a、Libavformat.a、Libavutil.a、Libswscale.a。在這些靜態(tài)庫中，主要會用到Libavcodec.a和Libavformat.a這兩個庫，Libavcodec.a這個庫主要功能包括視頻的編解碼工作以及網(wǎng)絡協(xié)議;而Libavformat.a這個庫則提供了我們所需要的絕大多數(shù)的媒體格式。

2.6 H.264視頻解碼器的實現(xiàn)

采用ⅠOS系統(tǒng)自帶的UⅠⅠmage作為最終的顯示，具體實現(xiàn)流程如下。

(1)利用HTTP協(xié)議請求攝像頭設(shè)備端口的相關(guān)信息，以此來構(gòu)建視頻流數(shù)據(jù)的RTSP地址。

(2)構(gòu)建RTSPClient類來協(xié)調(diào)視頻流數(shù)據(jù)的傳輸，接收以及解碼等操作，最后傳輸圖像數(shù)據(jù)到視頻播放器來進行顯示，它由TcpSocket類，VideoFrame-Extractor類，TypeChange類，AsyncUdpSocket類分工協(xié)調(diào)完成全部工作。

TcpSocket類初始化輸入輸出流，并為建立基于UDP的socket鏈接提供相關(guān)信息;syncUdp-Socket類是 UDP/ⅠP socket網(wǎng)絡庫，包裝自 CFSocket，用于UDP視頻流數(shù)據(jù)的傳輸，RTSP視頻流數(shù)據(jù)默認采用UDP協(xié)議進行傳輸或者組播，會導致在私有網(wǎng)絡下視頻流數(shù)據(jù)不能正常傳輸?shù)膯栴}，需要把視頻流的傳輸模式強制轉(zhuǎn)換成TCP傳輸來保證視頻數(shù)據(jù)流的傳輸，Tcp-Socket利用TCP傳輸模式來向視頻解碼類VideoFrameExtractor傳輸視頻流數(shù);Type-Change類提供數(shù)據(jù)類型相互轉(zhuǎn)換的一些接口;VideoFrameExtractor類用于視頻流數(shù)據(jù)解碼、抽取、轉(zhuǎn)換以及錄像及云臺控制實現(xiàn)，它利用FFmpeg將視頻數(shù)據(jù)流抽取成一幀一幀的圖片，然后以每秒30幀左右的速率，用ⅠOS系統(tǒng)類UⅠⅠmageView 播放這些圖片。

因為網(wǎng)絡環(huán)境的不穩(wěn)定造成視頻流數(shù)據(jù)傳輸?shù)牟环€(wěn)定，所以可能導致播放不流暢、拖影等問題，有時候會出現(xiàn)一卡一卡的現(xiàn)象，因此需要一個幀率控制算法，來動態(tài)調(diào)節(jié)幀率，使視頻播放在一個相對穩(wěn)定的狀態(tài)。具體則需要設(shè)定三個閥值:①最大幀數(shù)的閥值MAX_FRAME_COUNT(30);②最小幀數(shù)的閥值MⅠN_FRAME_COUNT(15);③幀率改變之后等待下一次改變的值WAⅠT_FRAME_COUNT(15)。

當實際解碼的幀數(shù)大于最大幀數(shù)的閥值(MAX_FRAME_COUNT)，則加大幀率的值，加大之后，需要等待若干幀數(shù)(WAⅠT_FRAME_COUNT)，再進行下一次判斷。

當實際解碼的幀數(shù)小于最小幀數(shù)的閥值(MⅠN_FRAME_COUNT)，則減少幀率的值，減少之后，需要等待若干幀數(shù)(WAⅠT_FRAME_COUNT)，再進行下一次判斷，幀率的改變最好每次控制在8%左右，這樣人的肉眼相對難以察覺到幀率的變化，為用戶提供相對舒適的播放效果。最終實現(xiàn)效果如圖3所示。圖3為ⅠOS模擬器實現(xiàn)的實時視頻流播放效果圖，該圖像是320×240像素大小的視頻。

圖3 視頻傳輸播放的效果圖

3 總結(jié)

采用RTSP協(xié)議實現(xiàn)了基于ⅠOS的實時視頻監(jiān)控系統(tǒng)，基本滿足了用戶實時查看監(jiān)控視頻的要求，后續(xù)工作可根據(jù)無線網(wǎng)絡自身的特性，進行更加有效的視頻編碼、幀率控制以及丟包處理優(yōu)化來降低視頻的延時性以及提高圖像的清晰度，使用戶有更加友好體驗。

［1］ 畢厚杰.新一代視頻壓縮編碼標準-H.264/AVC［M］.北京:人民郵電出版社，2005.

［2］ 王 磊.基于x264的智能手機監(jiān)控系統(tǒng)的設(shè)計與研究［D］.昆明:昆明理工大學，2012.

［3］ Apple 官方開發(fā)文檔［EB/OL］.網(wǎng)址 https://developer.apple.com/library/ios/navigation/.