侯沛德，楊軍平，許存祿

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 HTTP 協(xié)議

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

2.2 RTP/RTCP 協(xié)議

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

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

2.3 RTSP 協(xié)議

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

2.4 H.264 簡介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 總結(jié)

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

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

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

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