摘 要： 提出了一種基于Android智能手機的視頻監(jiān)控系統(tǒng)視頻上傳客戶端軟件設計方案，介紹了整個系統(tǒng)的框架和客戶端軟件開發(fā)過程?；贏ndroid操作系統(tǒng)平臺，通過擴展會話初始化協(xié)議（SIP）實現(xiàn)信令控制，采用系統(tǒng)多媒體框架實現(xiàn)視頻采集與編碼，使用LocalSocket本地映射獲取編碼視頻數(shù)據(jù)，并以實時傳輸協(xié)議（RTP）實現(xiàn)數(shù)據(jù)傳輸。
關鍵詞： Android；視頻上傳；會話初始化協(xié)議；LocalSocket；實時傳輸協(xié)議
視頻監(jiān)控[1]以其直觀、準確、及時和信息內(nèi)容豐富而廣泛應用于許多場合。國內(nèi)外很多公司都投入了很大的精力在視頻監(jiān)控系統(tǒng)的研究上，如國外的博世、松下，國內(nèi)的?？岛痛笕A等，他們研發(fā)供應監(jiān)控產(chǎn)品，并提供解決方案。近年來Android操作系統(tǒng)[2-3]發(fā)展迅速，擁有廣大的用戶群體。當前市場上基于Android的視頻上傳軟件，通過調(diào)用第三方庫實現(xiàn)視頻數(shù)據(jù)編碼，由CPU實現(xiàn)編碼數(shù)據(jù)算法，資源占用率高。本文設計了一種基于Android智能手機的視頻上傳客戶端軟件，以SIP[4]協(xié)議作為控制信令，采用手機自帶攝像頭錄制視頻，基于系統(tǒng)多媒體框架實現(xiàn)視頻數(shù)據(jù)編碼，并上傳數(shù)據(jù)到服務器。
1 視頻監(jiān)控系統(tǒng)框架
系統(tǒng)由視頻播放客戶端、服務器和視頻上傳設備端3部分組成。視頻播放客戶端包括手機客戶端和PC客戶端，播放設備端上傳的視頻；服務器由一個SIP服務器和一個媒體轉(zhuǎn)發(fā)服務器組成，SIP服務器負責對設備端和播放客戶端的管理，媒體轉(zhuǎn)發(fā)服務器實現(xiàn)媒體數(shù)據(jù)轉(zhuǎn)發(fā)，將設備端的視頻數(shù)據(jù)轉(zhuǎn)發(fā)給播放客戶端；設備端通過WiFi或者3G連接網(wǎng)絡，登錄到SIP服務器，可以接收播放客戶端的視頻邀請并與媒體轉(zhuǎn)發(fā)服務器建立連接，上傳視頻到媒體轉(zhuǎn)發(fā)服務器。系統(tǒng)框架圖如圖1所示，實線為SIP信令流，虛線為RTP媒體流。
2 客戶端軟件設計
客戶端設計包括頂層用戶界面設計和底層的功能模塊設計。用戶界面用于實現(xiàn)人機交互；功能模塊主要有信令控制模塊、視頻采集編碼模塊和視頻上傳模塊，分別實現(xiàn)客戶端與SIP服務器間交互、視頻數(shù)據(jù)采集編碼和將視頻上傳到媒體轉(zhuǎn)發(fā)服務器的功能。
2.1 界面設計
用戶界面主要有登錄界面、等待視頻邀請界面和視頻采集界面，是通過調(diào)用應用程序框架層的API接口和View組件，配合XML布局文件實現(xiàn)的Activity。在登錄界面輸入賬號和密碼，登錄成功后跳轉(zhuǎn)到等待視頻邀請界面；在等待視頻邀請界面，用戶可以選擇登出服務器；若收到視頻邀請消息，可以跳轉(zhuǎn)到視頻采集界面；在視頻采集界面進行視頻采集、編碼與上傳；若收到結(jié)束邀請消息，則斷開與媒體轉(zhuǎn)發(fā)服務器的連接，回到等待視頻邀請界面，等待下一次的視頻邀請。
2.2 信令控制模塊
Android手機客戶端與SIP服務器之間的信息控制采用SIP協(xié)議，采用XML擴展SIP消息體。SIP消息實現(xiàn)的功能有設備注冊、設備?；睢⒀堃曨l和結(jié)束邀請，如圖2所示。
設備注冊時，客戶端向服務器發(fā)送兩次REGISTER消息，第一次客戶端向服務器發(fā)送REGISTER消息，服務器回復帶有密文消息體的200 OK消息；客戶端解析密文，通過REGISTER將解析后的密文發(fā)回服務器，服務器回復200 OK表明注冊成功。注冊成功后，客戶端需要向服務器發(fā)送?；钚畔??？蛻舳税l(fā)送REGISTER消息，消息體中是?；钫埱笮畔?；服務器回復帶有?；铐憫Ⅲw的200 OK消息。視頻邀請時，服務器向客戶端發(fā)送INVITE消息，消息體中有媒體轉(zhuǎn)發(fā)服務器的IP和數(shù)據(jù)接收端口號；客戶端回復200 OK，并在消息體中設置上傳視頻的相關信息；服務器準備就緒后，向客戶端發(fā)送ACK消息；客戶端回復200 OK表示客戶端準備就緒，可以進行視頻上傳。結(jié)束視頻邀請時，服務器向客戶端發(fā)送BYE消息，客戶端回復200 OK消息表示收到結(jié)束視頻請求。
2.3 采集編碼模塊
由于網(wǎng)絡傳輸帶寬的限制，視頻需經(jīng)過編碼發(fā)送，本文采用H.264編碼標準[5]。Android系統(tǒng)MediaRecorder類支持的文件封裝格式有AAC ADTS、AMR NB、AMR WB、MP4、RAW_AMR、3GPP，本文采用MP4封裝格式進行研究。MP4封裝格式[6]基于QuickTime容器格式定義，媒體描述與媒體數(shù)據(jù)分開，目前被廣泛應用于封裝H.264視頻和ACC音頻，是高清視頻的代表。
本文采用MediaRecorder錄制視頻，基于Android系統(tǒng)的多媒體框架進行視頻H.264編碼，將錄制的視頻流映射到本地LocalSocket上，獲取編碼數(shù)據(jù)。為了獲取H.264碼流，通過啟動兩次MediaRecorder實現(xiàn)。第一次啟動，設置視頻錄制相關參數(shù)，并將錄制視頻以MP4格式保存到當前應用目錄下，從MP4文件的尾部找到SPS、 PPS和視頻數(shù)據(jù)存放起始位置；第二次啟動后將錄制的視頻映射到LocalSocket的發(fā)送端，在LocalSocket的接收端獲取視頻流，并通過之前第一次啟動MediaRecorder得到的視頻存放位置從視頻流中截取H.264碼流，每次提取一幀數(shù)據(jù)，由視頻上傳模塊發(fā)送給媒體轉(zhuǎn)發(fā)服務器。H.264碼流獲取流程如圖3所示。
2.4 視頻上傳模塊
為了擁有較好的實時性，視頻數(shù)據(jù)基于RTP協(xié)議傳輸，根據(jù)RFC3984協(xié)議進行操作。手機底層硬件是按照相同速率進行視頻采集的，故每一幀的停留時間是相同的。如果采用編碼后直接打包發(fā)送的策略，數(shù)據(jù)大的幀其分片包多，此期間發(fā)包速率高；數(shù)據(jù)小的幀分片包少，此期間發(fā)包速率低?？梢姶朔N發(fā)包機制的發(fā)包速率不穩(wěn)定，包發(fā)送速率是由幀的大小決定，這樣會出現(xiàn)發(fā)包高峰期，造成網(wǎng)絡阻塞，從而導致丟包率升高，影響了接收端的圖像質(zhì)量。
針對這一情況，本文設計了一種平穩(wěn)發(fā)包策略，通過開辟相應的發(fā)送緩存，以較平穩(wěn)的速率來發(fā)送視頻數(shù)據(jù)包。緩存模仿隊列進行設計，采用先進先出的原則，實現(xiàn)了一個緩存鏈表。開啟兩個線程，一個線程負責將分片后的數(shù)據(jù)包從緩存尾部放入緩存，另一個線程負責從緩存頭部提取數(shù)據(jù)包進行發(fā)送。緩存通過設計兩個類實現(xiàn)：StreamBufNode.java類和StreamBuf.java類。其中StreamBufNode.java類定義了緩存鏈表節(jié)點的數(shù)據(jù)類型和相關操作方法；StreamBuf.java類定義了整個緩存鏈表的數(shù)據(jù)結(jié)構、加入節(jié)點到鏈表和從鏈表取出節(jié)點等操作方法。發(fā)包的緩存示意圖如圖4所示。
本文設計實現(xiàn)了一種基于Android智能手機的視頻監(jiān)控系統(tǒng)視頻上傳客戶端軟件，并介紹了視頻監(jiān)控系統(tǒng)的整體框架和視頻上傳客戶端軟件設計方案。主要介紹了客戶端軟件的用戶界面和功能模塊設計，包括信令控制模塊、采集編碼模塊和視頻上傳模塊。軟件基于日常使用的Android智能手機開發(fā)，移動性強，成本低。未來是移動的世界，基于智能手機設備端視頻監(jiān)控軟件的設計和實現(xiàn)具有一定的現(xiàn)實意義。
參考文獻
[1] 周毅．基于Android系統(tǒng)的視頻監(jiān)控客戶端軟件的設計與實現(xiàn)[D]．浙江：浙江工業(yè)大學，2012．
[2] 楊豐盛．Android應用開發(fā)揭秘[M]．北京：機械工業(yè)出版社，2010．
[3] 金仙力，陳晶晶．Android平臺上的實時圖像采集與遠程存儲系統(tǒng)設計[J]．無線互聯(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的研究與軟件實現(xiàn)[D]．南京：南京郵電學院，2004．
[6] 周瑾，支琤，宋利．流媒體應用中TS和MP4格式分析[J]．信息技術，2007，31（7）：16-19．