當(dāng)前位置:首頁 > 嵌入式培訓(xùn) > 嵌入式學(xué)習(xí) > 講師博文 > Android視頻監(jiān)控實(shí)現(xiàn)(一)
第一章 系統(tǒng)簡介
近年來,視頻監(jiān)控市場的發(fā)展已經(jīng)進(jìn)入高速時期,與此同時,隨著各大運(yùn)營商對基礎(chǔ)網(wǎng)絡(luò)建設(shè)的巨大投入,快速地推動了網(wǎng)絡(luò)攝像機(jī)在各個領(lǐng)域的快速發(fā)展應(yīng)用。安卓在Google的推進(jìn)以及本身的開放性作用下,已經(jīng)延生到生活的各個方面,從安卓智能手機(jī)、平板,到可穿戴的Android Ware、眼鏡、手表、再到Android汽車、智能家居、電視,甚至日本出的幾款機(jī)器人都是Android系統(tǒng)的,傳統(tǒng)監(jiān)控中的移動終端設(shè)備,例如:單兵設(shè)備、手持設(shè)備、車載終端設(shè)備,包括家庭監(jiān)控中用到的智能設(shè)備,都可以用Android系統(tǒng)替代了,不僅開發(fā)容易,而且易擴(kuò)展,設(shè)備也更加智能了。在此思路下我們實(shí)現(xiàn)了Android手機(jī)的音視頻采集與上傳、流媒體服務(wù)器轉(zhuǎn)發(fā)、多平臺播放器播放的實(shí)時監(jiān)控系統(tǒng)。
1.1 視頻采集安卓端(spydroid)
Google Code上有一個開源項(xiàng)目:spydroid-ipcamera,spydroid能在Android手機(jī)中建立一個精簡的HTTP Server和RTSP Server,功能類似于一般的IpCamera,既能夠通過網(wǎng)頁訪問攝像機(jī)并修改監(jiān)控配置,還能通過http或者rtsp協(xié)議,獲取監(jiān)控的實(shí)時音視頻。具體原理是,通過android手機(jī)對mediaRecorder錄制視頻,把localsocket傳輸?shù)奖镜氐牧鹘?jīng)過硬編碼,添加RTP頭,分離NALU包,根據(jù)RTSP協(xié)議交互過程把數(shù)據(jù)發(fā)送到對方。而且從其代碼結(jié)構(gòu)中,spydroid已經(jīng)實(shí)現(xiàn)了RTSPServer、RTSPClient、RTP、RTCP、H264、AAC...等等功能,總之,音視頻采集與上傳需要的Utility都已經(jīng)具備了,我們將這些功能組合到一塊實(shí)現(xiàn)了直播需求。
1.2 流媒體服務(wù)器(Darwin Streaming Server)
Darwin Streaming Server簡稱DSS。DSS是Apple公司提供的開源實(shí)時流媒體播放服務(wù)器程序。整個程序使用C++編寫,在設(shè)計(jì)上遵循高性能,簡單,模塊化等程序設(shè)計(jì)原則,務(wù)求做到程序高效,可擴(kuò)充性好。并且DSS是一個開放源代碼的,基于標(biāo)準(zhǔn)的流媒體服務(wù)器,可以運(yùn)行在Windows NT和Windows 2000,以及幾個UNIX實(shí)現(xiàn)上,包括Mac OS X,Linux,F(xiàn)reeBSD,和Solaris操作系統(tǒng)上的。
1.2.1 主體框架
DSS的核心服務(wù)器部分是由一個父進(jìn)程所fork出的一個子進(jìn)程構(gòu)成,該父進(jìn)程就構(gòu)成了整合流媒體服務(wù)器。父進(jìn)程會等待子進(jìn)程的退出,如果在運(yùn)行的時候子進(jìn)程產(chǎn)生了錯誤從而退出,那么父進(jìn)程就會fork出一個新的子進(jìn)程?梢钥闯,網(wǎng)絡(luò)客戶和服務(wù)器直接的對接是由核心服務(wù)器來完成的。網(wǎng)絡(luò)客戶RTSPoverRTP來發(fā)送或者接受請求。服務(wù)器就通過模塊來處理相應(yīng)的請求并向客戶端發(fā)送數(shù)據(jù)包。
核心流媒體服務(wù)通過創(chuàng)建四種類型的線程來完成自己的工作,具體如下:
服務(wù)器自己擁有的主線程。當(dāng)服務(wù)器需要關(guān)閉檢查,以及在關(guān)閉之前記錄相關(guān)狀態(tài)打印相關(guān)統(tǒng)計(jì)信息等任務(wù)處理時,一般都是通過這個線程來完成的。
空閑任務(wù)線程。這個任務(wù)線程是用來對一個周期任務(wù)隊(duì)列的管理,主要管理兩種任務(wù),超時任務(wù)和Socket任務(wù)。
事件線程。套接口相關(guān)事件由事件線程負(fù)責(zé)監(jiān)聽,當(dāng)有RTSP請求或者收到RTP數(shù)據(jù)包時,事件線程就會把這些實(shí)踐交給任務(wù)線程來處理。
任務(wù)線程。任務(wù)線程會把事件從事件線程中取出,并把處理請求傳遞到對應(yīng)的服務(wù)器模塊進(jìn)行處理,比如把數(shù)據(jù)包發(fā)送給客戶端的模塊,在默認(rèn)情況下,核心服務(wù)器會為每個處理器核創(chuàng)建一個任務(wù)線程。
1.2.2 相關(guān)協(xié)議
如果要使用QuickTime流媒體服務(wù)器的編程接口,您應(yīng)該熟悉該服務(wù)器實(shí)現(xiàn)的互聯(lián)網(wǎng)工程組織(Internet Engineering Task Force,簡稱IETF)協(xié)議,列舉如下:
實(shí)時流媒體協(xié)議(Real Time Streaming Protocol,簡稱RTSP)
實(shí)時傳輸協(xié)議(Real Time Transport Protocol,簡稱RTP)
實(shí)時傳輸控制協(xié)議(Real Time Transport Control Protocol,簡稱RTCP)
對話描述協(xié)議(Session Description Protocol,簡稱SDP)
1. 實(shí)時流媒體協(xié)議
當(dāng)我們需要創(chuàng)建并且對一個或多個時間的同步且連續(xù)的音視頻的媒體數(shù)據(jù)流控制的時候,我們需要用到RTSP協(xié)議,也就是實(shí)時流協(xié)議。RTSP并不是通過連續(xù)的數(shù)據(jù)流來創(chuàng)建并控制媒體流數(shù)據(jù)的,所以不會產(chǎn)生媒體流與控制流的交叉。用另外一種說法就是,RTSP本身是對流媒體服務(wù)器的遠(yuǎn)程控制。為了時間實(shí)時音視頻數(shù)據(jù)的受控(快進(jìn),暫停)以及按需分配流,這個協(xié)議為我們提供了可實(shí)現(xiàn)的框架。實(shí)時流控制協(xié)議可以用在對多個數(shù)據(jù)發(fā)送的會話,通過UDP或者TCP方式,以及基于RTP發(fā)送方式來實(shí)現(xiàn)。
2. 實(shí)時傳輸協(xié)議
RTP協(xié)議是互聯(lián)網(wǎng)上進(jìn)行媒體數(shù)據(jù)的一種傳輸協(xié)議,為了實(shí)現(xiàn)一對一或者一對多的同步傳輸和提供時間信息,我們就會采用RTP協(xié)議。由于其典型應(yīng)用建立在UDP傳輸之上,但也能在TCP或者ATM等其他協(xié)議上使用這個協(xié)議。實(shí)時傳輸協(xié)議本身只能對確保數(shù)據(jù)的實(shí)時性以及完整性,但并不對傳輸?shù)捻樞蛞约皞鬏斂煽啃蕴峁┍U。由于是建立在UDP協(xié)議之上,所以RTP協(xié)議本身并沒有提供流量控制或者阻塞控制,所以在一般情況下我們需要使用RTCP來進(jìn)行這些幫助。由于DSS本身默認(rèn)的傳輸協(xié)議就是RTP協(xié)議,而RTP協(xié)議需要通過RTCP協(xié)議進(jìn)行流量控制,這樣很大程度上增加了機(jī)頂盒也就是解碼端的CPU處理壓力,因此本設(shè)計(jì)采用UDP協(xié)議直接對TS包進(jìn)行發(fā)送,不使用RTP協(xié)議進(jìn)行數(shù)據(jù)封裝,由于UDP協(xié)議也缺少流量控制機(jī)制,我們使用PCR值來對發(fā)送流量進(jìn)行控制以防止接收端出現(xiàn)緩存溢出影響播放質(zhì)量。
3. 實(shí)時傳輸控制協(xié)議
實(shí)時傳輸控制協(xié)議的作用是管理傳輸?shù)馁|(zhì)量,也就是在進(jìn)程間傳輸?shù)耐瑫r相互交換信息。在建立RTP會話的時候,參與傳輸?shù)碾p方周期性的傳輸RTCP包,這個數(shù)據(jù)包中包含了所有相關(guān)傳輸?shù)男畔,比如?shù)據(jù)包大小,丟失的數(shù)據(jù)包數(shù)量等等。因此通常我們利用RTCP來對傳輸流量或有效載荷進(jìn)行動態(tài)調(diào)整,同時與RTP配合有效的控制傳輸速率,所以特別適合傳送實(shí)時數(shù)據(jù)。
4. 對話描述協(xié)議
對話描述協(xié)議(SDP)就是用來描述多媒體會話通告,多媒體會話邀請和其他形式的多媒體會話初始化的協(xié)議。SDP協(xié)議對流媒體描述的具體信息如下:會話名和會話目的,會話發(fā)起時間,會話中相關(guān)的網(wǎng)絡(luò)信息,會話發(fā)起者的相關(guān)信息,媒體類型,傳輸所使用的協(xié)議,流媒體編碼格式,傳輸時所使用的端口號,IP網(wǎng)絡(luò)地址。因此我們可以通過解析SDP協(xié)議來獲取我們所需要的一些必要的相關(guān)信息。
其中RTSP是非常重要的協(xié)議,因此后面會結(jié)合原代碼做一個詳細(xì)的分析,這個結(jié)果對設(shè)計(jì)模塊有著非常重要的影響,也可以說是本設(shè)計(jì)的關(guān)鍵。
1.2.3 模塊
流媒體服務(wù)器使用模塊來響應(yīng)各種請求及完成任務(wù)。有三種類型的模塊:
1. 內(nèi)容管理模塊
媒體源相關(guān)的RTSP請求與響應(yīng),我們通過內(nèi)容管理模塊來管理,每個模塊都用來對客戶的需求進(jìn)行解釋并做相應(yīng)處理,例如讀取和解析模塊支持的文件,或者請求的網(wǎng)絡(luò)源信息,并通過RTP等方式響應(yīng)。
內(nèi)容管理模塊有以下幾個:
QTSSFileModule,
QTSSReflectorModule,
QTSSRelayModule,
QTSSMP3StreamingModule。
2. 服務(wù)器支持模塊
服務(wù)器支持模塊執(zhí)行服務(wù)器數(shù)據(jù)的收集和記錄功能。
服務(wù)器模塊包括:
QTSSErrorLogModule,
QTSSAccessLogModule,
QTSSWebStatsModule,
QTSSWebDebugModule,
QTSSAdminModule,
QTSSPOSIXFileSystemModule。
3. 訪問控制模塊
訪問控制模塊提供鑒權(quán)和授權(quán)功能,以及操作URL路徑提供支持。
訪問控制模塊包括:
QTSSAccessModule,
QTSSHomeDirectoryModule,
QTSSHttpFileModule,
QTSSSpamDefenseModule。
1.2.4 工作流程
在DSS中的模塊分為動態(tài)模塊和靜態(tài)模塊,動態(tài)模塊在服務(wù)器啟動時會首先裝載動態(tài)模塊,之后才會裝載一部分靜態(tài)模塊。我們一般建議將我們自己書寫的功能模塊編譯為動態(tài)模塊來替換或擴(kuò)展現(xiàn)有的服務(wù)器模塊,因?yàn)樗鼤粌?yōu)先裝載。在QTSS的模塊中必須包含Register這個角色,這也是每個模塊所必須支持的角色。在模塊被裝載之后服務(wù)器會調(diào)用每個模塊的Register角色。在這個角色當(dāng)中,模塊會調(diào)用QTSS_AddRole函數(shù)來記錄這個模塊所支持的其他角色。然后服務(wù)器就將初始化角色來調(diào)用每一個擁有這個角色的模塊。這個角色主要是做一些初始化的任務(wù),比如說內(nèi)存的分配或者對數(shù)據(jù)結(jié)構(gòu)的初始化等等。在關(guān)閉服務(wù)器的時候,所有模塊的Shutdown角色將被調(diào)用,這個角色主要是為了結(jié)束工作后處理現(xiàn)場,比如釋放內(nèi)存等等。流媒體服務(wù)器主要就是通過這種角色來完成相應(yīng)任務(wù)的。
1.3 視頻播放器(VLC)
VLC多媒體播放器(初命名為VideoLAN客戶端)是VideoLAN計(jì)劃的多媒體播放器。它支持眾多音頻與視頻解碼器及文件格式,并支持DVD影音光盤,VCD影音光盤及各類流式協(xié)議。它也能作為unicast或 multicast的流式服務(wù)器在IPv4或 IPv6的高速網(wǎng)絡(luò)連接下使用。它融合了FFmpeg計(jì)劃的解碼器與libdvdcss程序庫使其有播放多媒體文件及加密DVD影碟的功能。
優(yōu)秀的開源播放器可以播放MPEG-1、MPEG-2、MPEG-4、DivX、DVD/VCD、數(shù)字衛(wèi)星頻道、數(shù)字地球電視頻道(digital terrestial television channels)、在許多作業(yè)平臺底下透過寬頻 IPv4、IPv6網(wǎng)絡(luò)播放線上影片;此軟件開發(fā)項(xiàng)目是由法國學(xué)生所發(fā)起的,參與者來自于世界各地,設(shè)計(jì)了多平臺的支持,可以用于播放網(wǎng)絡(luò)串流及本機(jī)多媒體檔案之播放。