摘  要： 提出了一種基于Android智能手機(jī)的視頻監(jiān)控系統(tǒng)視頻上傳客戶(hù)端軟件設(shè)計(jì)方案,，介紹了整個(gè)系統(tǒng)的框架和客戶(hù)端軟件開(kāi)發(fā)過(guò)程,。基于Android操作系統(tǒng)平臺(tái),，通過(guò)擴(kuò)展會(huì)話(huà)初始化協(xié)議（SIP）實(shí)現(xiàn)信令控制,，采用系統(tǒng)多媒體框架實(shí)現(xiàn)視頻采集與編碼，使用LocalSocket本地映射獲取編碼視頻數(shù)據(jù),，并以實(shí)時(shí)傳輸協(xié)議（RTP）實(shí)現(xiàn)數(shù)據(jù)傳輸,。
 關(guān)鍵詞： Android；視頻上傳,；會(huì)話(huà)初始化協(xié)議,；LocalSocket；實(shí)時(shí)傳輸協(xié)議

    視頻監(jiān)控[1]以其直觀,、準(zhǔn)確,、及時(shí)和信息內(nèi)容豐富而廣泛應(yīng)用于許多場(chǎng)合,。國(guó)內(nèi)外很多公司都投入了很大的精力在視頻監(jiān)控系統(tǒng)的研究上，如國(guó)外的博世,、松下,，國(guó)內(nèi)的海康和大華等,，他們研發(fā)供應(yīng)監(jiān)控產(chǎn)品,，并提供解決方案。近年來(lái)Android操作系統(tǒng)[2-3]發(fā)展迅速,，擁有廣大的用戶(hù)群體,。當(dāng)前市場(chǎng)上基于Android的視頻上傳軟件，通過(guò)調(diào)用第三方庫(kù)實(shí)現(xiàn)視頻數(shù)據(jù)編碼,，由CPU實(shí)現(xiàn)編碼數(shù)據(jù)算法,，資源占用率高。本文設(shè)計(jì)了一種基于Android智能手機(jī)的視頻上傳客戶(hù)端軟件,，以SIP[4]協(xié)議作為控制信令,，采用手機(jī)自帶攝像頭錄制視頻，基于系統(tǒng)多媒體框架實(shí)現(xiàn)視頻數(shù)據(jù)編碼,，并上傳數(shù)據(jù)到服務(wù)器,。
1 視頻監(jiān)控系統(tǒng)框架
    系統(tǒng)由視頻播放客戶(hù)端、服務(wù)器和視頻上傳設(shè)備端3部分組成,。視頻播放客戶(hù)端包括手機(jī)客戶(hù)端和PC客戶(hù)端,，播放設(shè)備端上傳的視頻；服務(wù)器由一個(gè)SIP服務(wù)器和一個(gè)媒體轉(zhuǎn)發(fā)服務(wù)器組成,，SIP服務(wù)器負(fù)責(zé)對(duì)設(shè)備端和播放客戶(hù)端的管理,，媒體轉(zhuǎn)發(fā)服務(wù)器實(shí)現(xiàn)媒體數(shù)據(jù)轉(zhuǎn)發(fā)，將設(shè)備端的視頻數(shù)據(jù)轉(zhuǎn)發(fā)給播放客戶(hù)端,；設(shè)備端通過(guò)WiFi或者3G連接網(wǎng)絡(luò),，登錄到SIP服務(wù)器，可以接收播放客戶(hù)端的視頻邀請(qǐng)并與媒體轉(zhuǎn)發(fā)服務(wù)器建立連接,，上傳視頻到媒體轉(zhuǎn)發(fā)服務(wù)器,。系統(tǒng)框架圖如圖1所示，實(shí)線(xiàn)為SIP信令流,，虛線(xiàn)為RTP媒體流,。

2 客戶(hù)端軟件設(shè)計(jì)
    客戶(hù)端設(shè)計(jì)包括頂層用戶(hù)界面設(shè)計(jì)和底層的功能模塊設(shè)計(jì)。用戶(hù)界面用于實(shí)現(xiàn)人機(jī)交互,；功能模塊主要有信令控制模塊,、視頻采集編碼模塊和視頻上傳模塊，分別實(shí)現(xiàn)客戶(hù)端與SIP服務(wù)器間交互,、視頻數(shù)據(jù)采集編碼和將視頻上傳到媒體轉(zhuǎn)發(fā)服務(wù)器的功能,。
2.1 界面設(shè)計(jì)
    用戶(hù)界面主要有登錄界面,、等待視頻邀請(qǐng)界面和視頻采集界面，是通過(guò)調(diào)用應(yīng)用程序框架層的API接口和View組件,，配合XML布局文件實(shí)現(xiàn)的Activity,。在登錄界面輸入賬號(hào)和密碼，登錄成功后跳轉(zhuǎn)到等待視頻邀請(qǐng)界面,；在等待視頻邀請(qǐng)界面,，用戶(hù)可以選擇登出服務(wù)器；若收到視頻邀請(qǐng)消息,，可以跳轉(zhuǎn)到視頻采集界面,；在視頻采集界面進(jìn)行視頻采集、編碼與上傳,；若收到結(jié)束邀請(qǐng)消息,，則斷開(kāi)與媒體轉(zhuǎn)發(fā)服務(wù)器的連接，回到等待視頻邀請(qǐng)界面,，等待下一次的視頻邀請(qǐng),。
2.2 信令控制模塊
    Android手機(jī)客戶(hù)端與SIP服務(wù)器之間的信息控制采用SIP協(xié)議，采用XML擴(kuò)展SIP消息體,。SIP消息實(shí)現(xiàn)的功能有設(shè)備注冊(cè),、設(shè)備保活,、邀請(qǐng)視頻和結(jié)束邀請(qǐng),，如圖2所示。

    設(shè)備注冊(cè)時(shí),，客戶(hù)端向服務(wù)器發(fā)送兩次REGISTER消息，第一次客戶(hù)端向服務(wù)器發(fā)送REGISTER消息,，服務(wù)器回復(fù)帶有密文消息體的200 OK消息,；客戶(hù)端解析密文，通過(guò)REGISTER將解析后的密文發(fā)回服務(wù)器,，服務(wù)器回復(fù)200 OK表明注冊(cè)成功,。注冊(cè)成功后，客戶(hù)端需要向服務(wù)器發(fā)送?；钚畔?。客戶(hù)端發(fā)送REGISTER消息,，消息體中是?；钫?qǐng)求信息；服務(wù)器回復(fù)帶有?；铐憫?yīng)消息體的200 OK消息,。視頻邀請(qǐng)時(shí),，服務(wù)器向客戶(hù)端發(fā)送INVITE消息，消息體中有媒體轉(zhuǎn)發(fā)服務(wù)器的IP和數(shù)據(jù)接收端口號(hào),；客戶(hù)端回復(fù)200 OK,，并在消息體中設(shè)置上傳視頻的相關(guān)信息；服務(wù)器準(zhǔn)備就緒后,，向客戶(hù)端發(fā)送ACK消息,；客戶(hù)端回復(fù)200 OK表示客戶(hù)端準(zhǔn)備就緒，可以進(jìn)行視頻上傳,。結(jié)束視頻邀請(qǐng)時(shí),，服務(wù)器向客戶(hù)端發(fā)送BYE消息，客戶(hù)端回復(fù)200 OK消息表示收到結(jié)束視頻請(qǐng)求,。
2.3 采集編碼模塊
    由于網(wǎng)絡(luò)傳輸帶寬的限制,，視頻需經(jīng)過(guò)編碼發(fā)送，本文采用H.264編碼標(biāo)準(zhǔn)[5],。Android系統(tǒng)MediaRecorder類(lèi)支持的文件封裝格式有AAC ADTS,、AMR NB、AMR WB,、MP4,、RAW_AMR、3GPP,，本文采用MP4封裝格式進(jìn)行研究,。MP4封裝格式[6]基于QuickTime容器格式定義，媒體描述與媒體數(shù)據(jù)分開(kāi),，目前被廣泛應(yīng)用于封裝H.264視頻和ACC音頻,，是高清視頻的代表。
    本文采用MediaRecorder錄制視頻,，基于Android系統(tǒng)的多媒體框架進(jìn)行視頻H.264編碼,，將錄制的視頻流映射到本地LocalSocket上，獲取編碼數(shù)據(jù),。為了獲取H.264碼流,，通過(guò)啟動(dòng)兩次MediaRecorder實(shí)現(xiàn)。第一次啟動(dòng),，設(shè)置視頻錄制相關(guān)參數(shù),，并將錄制視頻以MP4格式保存到當(dāng)前應(yīng)用目錄下，從MP4文件的尾部找到SPS,、 PPS和視頻數(shù)據(jù)存放起始位置,；第二次啟動(dòng)后將錄制的視頻映射到LocalSocket的發(fā)送端，在LocalSocket的接收端獲取視頻流,，并通過(guò)之前第一次啟動(dòng)MediaRecorder得到的視頻存放位置從視頻流中截取H.264碼流,，每次提取一幀數(shù)據(jù),，由視頻上傳模塊發(fā)送給媒體轉(zhuǎn)發(fā)服務(wù)器。H.264碼流獲取流程如圖3所示,。

2.4 視頻上傳模塊
    為了擁有較好的實(shí)時(shí)性,，視頻數(shù)據(jù)基于RTP協(xié)議傳輸，根據(jù)RFC3984協(xié)議進(jìn)行操作,。手機(jī)底層硬件是按照相同速率進(jìn)行視頻采集的,，故每一幀的停留時(shí)間是相同的。如果采用編碼后直接打包發(fā)送的策略,，數(shù)據(jù)大的幀其分片包多,，此期間發(fā)包速率高；數(shù)據(jù)小的幀分片包少,，此期間發(fā)包速率低,。可見(jiàn)此種發(fā)包機(jī)制的發(fā)包速率不穩(wěn)定,，包發(fā)送速率是由幀的大小決定,，這樣會(huì)出現(xiàn)發(fā)包高峰期，造成網(wǎng)絡(luò)阻塞,，從而導(dǎo)致丟包率升高,，影響了接收端的圖像質(zhì)量。
    針對(duì)這一情況,，本文設(shè)計(jì)了一種平穩(wěn)發(fā)包策略,，通過(guò)開(kāi)辟相應(yīng)的發(fā)送緩存，以較平穩(wěn)的速率來(lái)發(fā)送視頻數(shù)據(jù)包,。緩存模仿隊(duì)列進(jìn)行設(shè)計(jì),，采用先進(jìn)先出的原則，實(shí)現(xiàn)了一個(gè)緩存鏈表,。開(kāi)啟兩個(gè)線(xiàn)程,，一個(gè)線(xiàn)程負(fù)責(zé)將分片后的數(shù)據(jù)包從緩存尾部放入緩存，另一個(gè)線(xiàn)程負(fù)責(zé)從緩存頭部提取數(shù)據(jù)包進(jìn)行發(fā)送,。緩存通過(guò)設(shè)計(jì)兩個(gè)類(lèi)實(shí)現(xiàn)：StreamBufNode.java類(lèi)和StreamBuf.java類(lèi)。其中StreamBufNode.java類(lèi)定義了緩存鏈表節(jié)點(diǎn)的數(shù)據(jù)類(lèi)型和相關(guān)操作方法,；StreamBuf.java類(lèi)定義了整個(gè)緩存鏈表的數(shù)據(jù)結(jié)構(gòu),、加入節(jié)點(diǎn)到鏈表和從鏈表取出節(jié)點(diǎn)等操作方法。發(fā)包的緩存示意圖如圖4所示,。

    本文設(shè)計(jì)實(shí)現(xiàn)了一種基于Android智能手機(jī)的視頻監(jiān)控系統(tǒng)視頻上傳客戶(hù)端軟件,，并介紹了視頻監(jiān)控系統(tǒng)的整體框架和視頻上傳客戶(hù)端軟件設(shè)計(jì)方案。主要介紹了客戶(hù)端軟件的用戶(hù)界面和功能模塊設(shè)計(jì),，包括信令控制模塊,、采集編碼模塊和視頻上傳模塊,。軟件基于日常使用的Android智能手機(jī)開(kāi)發(fā)，移動(dòng)性強(qiáng),，成本低,。未來(lái)是移動(dòng)的世界，基于智能手機(jī)設(shè)備端視頻監(jiān)控軟件的設(shè)計(jì)和實(shí)現(xiàn)具有一定的現(xiàn)實(shí)意義,。
參考文獻(xiàn)
[1] 周毅．基于Android系統(tǒng)的視頻監(jiān)控客戶(hù)端軟件的設(shè)計(jì)與實(shí)現(xiàn)[D]．浙江：浙江工業(yè)大學(xué),，2012．
[2] 楊豐盛．Android應(yīng)用開(kāi)發(fā)揭秘[M]．北京：機(jī)械工業(yè)出版社，2010．
[3] 金仙力,，陳晶晶．Android平臺(tái)上的實(shí)時(shí)圖像采集與遠(yuǎn)程存儲(chǔ)系統(tǒng)設(shè)計(jì)[J]．無(wú)線(xiàn)互聯(lián)科技,，2012（10）：64-65．
[4] IETF.RFC 3261 SIP: Session initiation protocol[EB/OL].[2002-07-19].http://www.ietf.org/rfc/rfc3261.txt.
[5] 周恒．H.264的研究與軟件實(shí)現(xiàn)[D]．南京：南京郵電學(xué)院，2004．
[6] 周瑾,，支琤,，宋利．流媒體應(yīng)用中TS和MP4格式分析[J]．信息技術(shù)，2007,，31（7）：16-19．