列車CCTV網(wǎng)絡監(jiān)控系統(tǒng)SDK的設計與應用

張颯漪， 劉全利， 王 偉

(大連理工大學控制科學與工程學院，遼寧大連116024)

閉路電視(Closed Circuit Television，CCTV)網(wǎng)絡監(jiān)控系統(tǒng)，是安全技術(shù)防范體系中的一個重要組成部分［1］，現(xiàn)已應用于社會安防監(jiān)控的各大領域［2］，同時在軌道交通中也發(fā)揮了巨大的作用。列車CCTV監(jiān)控系統(tǒng)可以分為前端、傳輸和終端3個部分［3］。就硬件而言，前端用于獲取被監(jiān)控區(qū)域的圖像，傳輸部分通常由視頻電纜補償器、視頻放大器等組成，終端包括監(jiān)視器和控制設備以及記錄設備等;就軟件而言，前端屬于服務器，傳輸部分屬于網(wǎng)絡通信，終端屬于客戶端。在實際項目應用中，一般CCTV的前端產(chǎn)品供應商都會配套一個SDK(Software Development Kit)，針對自己的產(chǎn)品制定內(nèi)部通信協(xié)議并實現(xiàn)API的封裝，留出功能接口供給客戶端編程使用。客戶端程序開發(fā)人員可以在不了解視頻壓縮、回放和網(wǎng)絡傳輸?shù)燃夹g(shù)的前提下，進行視頻程序開發(fā)。

文中設計實現(xiàn)的CCTVSDK是一個基于某地鐵項目的車載CCTV設備進行的接口封裝，此項目中使用的前端攝像頭編碼卡和DVR(Digital Video Recorder)均集視頻采集、壓縮和網(wǎng)絡傳輸于一體，為CCTVSDK的設計和實現(xiàn)提供了前提。另外，微軟公司的DirectShow編程接口，為在Windows開發(fā)平臺上處理各種格式的媒體文件回放、音視頻采集等高性能要求的多媒體應用提供了完整解決方案。該CCTVSDK實現(xiàn)了取流、播放、存儲、獲取設備狀態(tài)、獲取視頻數(shù)據(jù)等接口功能，以滿足此項目地面監(jiān)控系統(tǒng)的開發(fā)需求，并為本項目列車CCTV系統(tǒng)的地面監(jiān)控開發(fā)提供高效、完整、便捷的開發(fā)和控制手段。

1 監(jiān)控中心對CCTVSDK的需求分析

文中的CCTVSDK是在某城市地鐵項目開發(fā)過程中，針對車載CCTV監(jiān)控系統(tǒng)定制的開發(fā)包。該列車由6節(jié)編組組成，具體如圖1所示。每個編組的監(jiān)控系統(tǒng)由車載攝像機(Camera)、車載DVR、車載監(jiān)控單元(TLCD)以及車載交換機(Switch)組成。

圖1 列車CCTV系統(tǒng)結(jié)構(gòu)示意Fig.1 Structure sketch of the train CCTV system

Camera由攝像頭和編碼卡兩部分組成，分布在客室和司機室，一塊編碼卡引出兩個TNC連接器，通過同軸電纜分別和一個攝像頭相連。攝像頭負責視頻采集，編碼卡采用Linux嵌入式平臺，負責對視頻圖像數(shù)據(jù)按照H.264編碼標準［4］進行編碼壓縮，并作為RTSP［5］服務器等待取流。

TDVR也采用Linux嵌入式平臺，分布在司機室，車頭車尾各一個，負責按照項目需求管理自己所屬范圍內(nèi)的攝像機，上電后根據(jù)RTSP取流協(xié)議將攝像頭實時視頻數(shù)據(jù)按照一定規(guī)則(如時間、通道號等)存儲在硬盤中，方便查詢錄像歷史。

TLCD安裝在司機室，車頭車尾各一個，采用Linux嵌入式平臺，可以通過在觸摸板上進行人工操作，以輪詢或者單獨監(jiān)控的方式對車廂內(nèi)日常和緊急情況進行監(jiān)控，還可以修改車內(nèi)其他IP設備參數(shù)，便于司機在運營時掌握列車狀態(tài)、不同車廂內(nèi)乘客情況以及停車時維護。

Switch用于各車廂CCTV設備連接，上述設備均通過以太網(wǎng)連接到交換機上，各個車廂內(nèi)交換機再級連，為列車的監(jiān)控系統(tǒng)網(wǎng)絡通信數(shù)據(jù)(包括控制命令數(shù)據(jù)和視頻數(shù)據(jù))提供傳輸通道，同時為構(gòu)成局域網(wǎng)奠定了基礎。

地面監(jiān)控系統(tǒng)通過路由與車載交換機相連，可以通過主動發(fā)起通話，獲取車載設備信息、車輛緊急信息，獲取監(jiān)控畫面之后進行控制中心上墻顯示，或進行控制中心本地存儲等。

通過對系統(tǒng)的分析可以看出，文中的車載CCTV監(jiān)控系統(tǒng)以全數(shù)字IP設備為基礎，對其操作涉及到網(wǎng)絡通信、流媒體等方面的技術(shù)，導致地面監(jiān)控開發(fā)人員開發(fā)過程較為復雜。對于攝像頭實時預覽，地面監(jiān)控開發(fā)人員需要知道RTSP取流協(xié)議，獲取視頻數(shù)據(jù)之后，需要將視頻數(shù)據(jù)進行音視頻解碼并負責顯示，當多路視頻輪詢切換時，要考慮不同顯示窗口的切換問題、CPU的利用率等問題;對于以DVR錄像文件下載和本地回放，地面監(jiān)控開發(fā)人員需要知道DVR內(nèi)部存儲規(guī)則(時間段、通道號、硬盤號等)，文件格式結(jié)構(gòu)和文件轉(zhuǎn)換過程，以及回放時播放器機制等;對于監(jiān)測設備狀態(tài)，地面監(jiān)控開發(fā)人員要想知道設備是否在線、掉線、重連、有無緊急情況發(fā)生等狀態(tài)，需要自己建立網(wǎng)絡通信機制，通過一系列套接字實現(xiàn)狀態(tài)查詢功能。這一切都對地面監(jiān)控系統(tǒng)的開發(fā)形成了不便和困擾。

因此，地面監(jiān)控中心需要集成3大類功能:①網(wǎng)絡視頻流處理;②車載錄像本地下載、存儲和回放;③車載設備狀態(tài)檢測、緊急信息獲取。

以上所有功能在CCTVSDK中都進行了封裝，以Windows API的形式提供給地面監(jiān)控系統(tǒng)的編程人員，最終產(chǎn)品以DLL［6］(動態(tài)鏈接庫)的形式生成。這樣的設計就使用戶不再關(guān)心內(nèi)部通信和操作細節(jié)，極大地提高了二次開發(fā)的效率。

2 CCTVSDK軟件結(jié)構(gòu)

CCTVSDK接口功能主要包含設備操作、本地視頻文件回放和控制操作、車載緊急信息獲取3大模塊。其中設備操作由設備取流、視頻播放、視頻本地存儲、視頻數(shù)據(jù)操作和設備狀態(tài)監(jiān)控這幾部分組成。軟件結(jié)構(gòu)如圖2所示。

圖2 CCTVSDK軟件結(jié)構(gòu)Fig.2 Structure of CCTVSDK

其中網(wǎng)絡視頻流處理模塊基于C/S模型，由設備取流、視頻播放、視頻本地存儲、視頻數(shù)據(jù)操作幾部分組成;本地視頻處理模塊由錄像文件回放和回放控制兩部分組成;OCC報警監(jiān)控模塊同樣基于C/S模型，由車載設備狀態(tài)監(jiān)控和車載緊急信息獲取兩部分組成。

應用程序開始時，無論想要實現(xiàn)何種功能，必須首先調(diào)用相應模塊的初始化操作接口，主要用于開辟SDK內(nèi)部資源，如為網(wǎng)絡通信創(chuàng)建套接字、清空設備隊列以及初始化COM庫等。

應用程序調(diào)用過程中，可能有多種調(diào)用方法實現(xiàn)同一種功能，編程人員可根據(jù)自己需求選取不同分支方法。

應用程序結(jié)束時，需要調(diào)用相應模塊的清除操作接口進行清理資源操作，主要目的是用來回收內(nèi)部資源，避免內(nèi)存泄露。

3 CCTVSDK軟件的內(nèi)部功能實現(xiàn)

3.1 設備取流功能的實現(xiàn)

CCTVSDK實現(xiàn)的取流功能是基于標準RTSP協(xié)議，從開始申請網(wǎng)絡取流到成功獲取視頻數(shù)據(jù)的過程就是一個RTSP協(xié)議的實現(xiàn)過程。

RTSP協(xié)議全稱為實時流媒體協(xié)議(Real Time Streaming Protocol)，是由Real Network和Netscape以及哥倫比亞大學共同提出的如何有效在IP網(wǎng)絡上傳輸流媒體數(shù)據(jù)的應用層協(xié)議。這個協(xié)議位于RTP和RTCP之上，本身并不傳輸數(shù)據(jù)，而是使用TCP或RTP完成數(shù)據(jù)的傳送。它只是相當于流媒體服務器的遠程控制。

車載攝像頭編碼卡和車載DVR均為RTSP服務器，文中涉及到的控制過程中包含以下幾個命令，具體見表1。各個步驟之后的狀態(tài)流程如圖3所示。CCTVSDK作為客戶端進行相關(guān)取流操作，當一個RTSP的申請過程在Play命令成功之后就可以收到服務器發(fā)出的視頻數(shù)據(jù)。

表1 RTSP請求流程Tab.1 Request process of RTSP

圖3 RTSP狀態(tài)轉(zhuǎn)換Fig.3 State transition diagram of RTSP

C++的開源項目Live555為RTSP每個過程的實現(xiàn)提供了良好的開發(fā)基礎。它實現(xiàn)了對標準流媒體傳輸協(xié)議(如RTP/RTCP、RTSP、SIP等)的支持，并實現(xiàn)對多種音視頻編碼格式的音視頻數(shù)據(jù)接收和處理的支持。由于結(jié)構(gòu)設計良好，Live555已被用于多款開源播放器的流媒體播放功能的實現(xiàn)，如VLC，MPlayer。Live555的整體框架包括 4 個庫:UsageEnvironment模塊是對系統(tǒng)環(huán)境的抽象，包括抽 象 類 UsageEnvironment，TaskScheduler 和HashTable，實現(xiàn)對事件的異步讀取、對事件句柄的設置以及對錯誤信息的輸出等;BasicUsageEnvironment模塊中的類主要是對UsageEnvironment中對應類的實現(xiàn);Groupsock模塊用于數(shù)據(jù)包的接收和發(fā)送等網(wǎng)絡通信，支持單播和多播;LiveMedia模塊非常重要，包含了實現(xiàn)RTSP Server的類，還有針對不同流媒體類型(TS流或PS流)編碼的類，其中Medium是基類。

運用這一開源代碼，CCTVSDK將RTSP的實現(xiàn)過程加以提煉并抽象提取出來，封裝成名為CstreamMedia的類，并將主要過程以Public成員函數(shù)的形式表現(xiàn)出來。這些接口依次為:

int rtspClientOpenStream(const char* url，int flag)，負責PLAY命令之前的所有過程操作;

int rtspClientPlayStream(void)，負責發(fā)送PLAY命令和解析應答;

int rtspClientReadFrame(FrameInfo*＆ frame)，負責取流之后視頻數(shù)據(jù)獲取;

intrtspClinetGetMediaInfo(enum CodecType codectype，MediaInfo＆ mediainfo)，負責視頻流的類型判斷;

int rtspClientPauseStream(void)，負責發(fā)送PAUSE命令和解析應答;

int rtspClientCloseStream(void)，負責發(fā)送TEARDOWN命令和解析應答。

當創(chuàng)建一個CstreamMedia類的對象時，通過調(diào)用以上不同接口，便可實現(xiàn)RTSP的整個流程，完成取流過程并在成功取流過程后加以過程控制。

3.2 設備視頻播放功能的實現(xiàn)

設備視頻播放功能基于微軟的DirectShow SDK開發(fā)完成。DirectShow是經(jīng)過DirectX 6.0中的Direct Media發(fā)展而來，集成了DirectX家族中其他成員(如 DirectDraw、DirectSound 等)的技術(shù)［7］。Dshow設計初衷就是要讓應用程序開發(fā)人員從負責的數(shù)據(jù)傳輸、硬件差異、同步性等工作中解脫出來，使得多媒體應用變得簡單。

DirectShow使用Filter Graph模型管理整個數(shù)據(jù)流的處理過程，參與數(shù)據(jù)處理的各個功能模塊是Filter。各個Filter按照一定的順序連接成一條“流水線”協(xié)同工作。Filter按照功能可以分為3類:Source Filters，Transform Filters和 Rendering Filters。

Source Filters主要負責獲取數(shù)據(jù)(數(shù)據(jù)源可以是文件、計算機里的采集卡、數(shù)字攝像機等)，然后將數(shù)據(jù)往下傳輸。數(shù)據(jù)傳送可以分為推模式和拉模式，推模式最典型的情況發(fā)生在實時源中;拉模式典型發(fā)生在文件源中。Transform Filters主要負責數(shù)據(jù)的格式轉(zhuǎn)換，例如數(shù)據(jù)流分離 /合成、解碼 /編碼等，然后將數(shù)據(jù)繼續(xù)往下傳輸;Rendering Filters主要負責將數(shù)據(jù)送給顯卡、聲卡進行多媒體的演示播放，或者輸出到文件進行存儲。CCTVSDK中視頻播放功能實現(xiàn)嚴格按照Source Filter-Transform Filter-Rendering Filter的結(jié)構(gòu)設計完成。

Source Filter采用推模式，被封裝為CRTSPStreamFilter類，由CBaseFilter和CAMThread派生出來。Source Filter可以使用專門的線程將經(jīng)過RTSP談判獲取的網(wǎng)絡數(shù)據(jù)流推送下去。因此，在CRtspStream的構(gòu)造函數(shù)中開啟了RTSP的請求過程，如果成功，在循環(huán)推送的線程中將會把車載監(jiān)控設備發(fā)出的H.264視頻數(shù)據(jù)流推送到下一級Filter，在類的具體實現(xiàn)代碼中，以上闡述的過程體現(xiàn) 在 CRTSPStreamFilter::DoBufferProcessing-Loop()和CRTSPStreamFilter::FillBuffer()中。每次傳遞的過程都可以獲取到此次傳遞buffer大小。

CH264Decoder是CTransformFilter的子類，當這一Filter對象被添加到Graph中并收到上級傳來的數(shù)據(jù)時，會進入CH264Decoder::Transform()的階段，將視頻數(shù)據(jù)根據(jù)buffer類型和大小進行標準H.264解碼。解碼的過程運用了ffmpeg［8］開源解決方案。解碼之后的YUV數(shù)據(jù)，繼續(xù)傳送到下一級Filter。

Rendering Filter運用了DirectShow新一代的Video Render即 VMR7(Video Mixing Render)。VMR有很多新特性，其中典型的特性是實現(xiàn)了真正的無窗口模式(Windowsless)。普通Render在顯示視頻時，總是需要創(chuàng)建窗口，將此窗口作為應用程序創(chuàng)建窗口的子窗口;而VMR無需如此，應用程序使用時，只需要傳入窗口句柄，畫面就可以在傳入的窗口中顯示，沒有父子關(guān)系。

當用戶準備啟動視頻播放時，運用IGraphBuilder::Connect()方法將以上3個Filter連接，形成一條播放鏈路，具體如圖4所示。再運用IMediaControl::Run()這一方法，數(shù)據(jù)流就會在Filter中自動傳遞，畫面顯示流暢，實現(xiàn)預覽功能。

圖4 Dshow數(shù)據(jù)傳輸流程Fig.4 Data transform chart of Dshow

3.3 視頻本地存儲功能的實現(xiàn)

視頻本地存儲功能是在取流成功的基礎上，在Source Filter內(nèi)部加入接口，將網(wǎng)絡原始視頻數(shù)據(jù)存儲成標準AVI文件，存儲文件名稱以“CAM_當前時間_設備IP_端口號.avi”和“DVR_當前時間_設備IP_通道號_錄像起始時間_錄像結(jié)束時間.avi”規(guī)則進行命名，以避免錄像文件名稱重復。

AVI(AudioVideoInterleaved)是微軟推出的一種音視頻交互格式［9］。它采用了一種有損壓縮方式，分為文件頭、數(shù)據(jù)塊、索引塊3部分(見圖5)。

圖5 AVI數(shù)據(jù)存儲格式Fig.5 Data storage layout of AVI

AVI文件采用的是RIFF文件結(jié)構(gòu)方式，存儲過程簡單易操作，且滿足列車監(jiān)控單元對視頻文件的存儲需求。RIFF(Resource Interchange File Format，資源互換文件格式)是微軟公司定義的一種用于管理Windows環(huán)境中多媒體數(shù)據(jù)的文件格式。構(gòu)造RIFF文件的基本單元為數(shù)據(jù)塊(Chunk)。整個AVI文件是一個以ID為RIFF的塊，其中包含3種塊(此種結(jié)構(gòu)中只有視頻信息，沒有音頻信息):

1)ID 為 LIST，數(shù)據(jù)類型為“hdrl”:包含 AVI文件一般信息，如文件頭、數(shù)據(jù)流頭、數(shù)據(jù)流格式。

2)ID為 LIST，數(shù)據(jù)類型為“movi”:以幀為單位，記錄視頻數(shù)據(jù)信息。

00dc:表示該幀數(shù)據(jù)的類型和流編號，dc-壓縮視頻幀;db-非壓縮視頻幀。

3)ID為idx1，記錄數(shù)據(jù)幀索引信息，包括:

數(shù)據(jù)塊標記(如00dc)，數(shù)據(jù)塊屬性，數(shù)據(jù)塊相對位置，數(shù)據(jù)塊大小。

在SDK中，將AVI文件的存儲操作封裝成CGenerateAVI類，留出公共操作接口。

3.4 設備狀態(tài)監(jiān)控功能的實現(xiàn)

設備狀態(tài)監(jiān)控功能是地面監(jiān)控系統(tǒng)的又一功能需求。在監(jiān)控過程中可實時獲取不同列車的各個CCTV設備的在線狀態(tài)，以便應用程序根據(jù)掉線情況作出冗余處理或者告知維護人員及時處理故障。

CCTVSDK實現(xiàn)流程如下:①設備狀態(tài)通過客戶端發(fā)送消息、服務器給與應答的方式進行判斷。以UDP的方式逐一發(fā)送檢測設備狀態(tài)協(xié)議的網(wǎng)絡通信數(shù)據(jù)包，設備接收后會根據(jù)協(xié)議給與應答。②CCTVSDK初始化時，經(jīng)用戶指定后開啟一個內(nèi)部循環(huán)檢測線程，用戶每注冊一個設備，會得到一個設備ID號，CCTVSDK內(nèi)部記錄該設備IP，并將這一ID號與此IP地址相互關(guān)聯(lián)，同時此設備信息則被添加到設備隊列中，該檢測線程在此設備隊列中不斷檢測每個設備的在線狀態(tài)。③如果在一定的超時時間內(nèi)(文中實現(xiàn)代碼中默認設置為2 s)沒有檢測到正確的回復包，則認為設備掉線;假如在斷線一段時間后的某次檢測過程中，又收到該設備正確的回復包，則認為此設備恢復正常。④設備斷線、在線的變化狀態(tài)，CCTVSDK都會以回調(diào)函數(shù)的方式通知用戶。

檢測設備狀態(tài)的通信協(xié)議中的數(shù)據(jù)包采用“報文頭 +報文內(nèi)容”的格式(見表2)。

表2 報文格式Tab.2 Message layout

表2中COMM_HEAD包含此數(shù)據(jù)包的一般信息，如包長度、校驗和等;INTER_HEAD用于區(qū)分數(shù)據(jù)包功能，記錄此數(shù)據(jù)包消息編號等信息;消息數(shù)據(jù)根據(jù)不同的功能進行不同的特殊定義，用不同消息ID號區(qū)分，包含了所有需求功能的信息。

設計這種數(shù)據(jù)包格式基于現(xiàn)有網(wǎng)絡通信協(xié)議數(shù)據(jù)包格式定義。在網(wǎng)絡通信協(xié)議中，以UDP協(xié)議為例，用戶數(shù)據(jù)報被分為報頭和數(shù)據(jù)兩部分。報頭包括源端口、目的端口、報文長度及校驗和。傳輸過程中，通過檢查報頭信息就可以獲取此數(shù)據(jù)包的源地址和目的地址，校驗和可以保證數(shù)據(jù)的安全性［10］。同理，通過COMM_HEAD可對數(shù)據(jù)包進行校驗，一旦發(fā)現(xiàn)數(shù)據(jù)有錯誤，則不再對余下數(shù)據(jù)進行判斷;如果校驗正確，則再通過INTER_HEAD中的消息ID號確定報文的具體功能，作出不同的處理。可以看出，以這種格式安排數(shù)據(jù)包不僅整齊而且便于擴展，添加功能時只需添加不同的消息ID號即可，為編程過程中整包數(shù)據(jù)的解析和解析后的處理流程都提供了很大便捷。

基于以上實現(xiàn)過程，用戶在使用CCTVSDK時，只需在初始化時注冊一個有關(guān)設備狀態(tài)的回調(diào)函數(shù)，在此函數(shù)實現(xiàn)中作出自己應有的動作即可。這一設計方法極大地簡化了用戶調(diào)用流程。

3.5 本地視頻文件回放和控制功能的實現(xiàn)

本地視頻文件回放和控制功能同樣是基于微軟的DirectShow開發(fā)平臺。

Dshow的播放操作都是基于Filter的COM組件完成的，根據(jù)不同視頻編碼選取不同的Filter，通過Pin之間的連接就能串聯(lián)起來，從而構(gòu)建一個完整的Filter Graph。對于一些具體的已知文件格式，Dshow為開發(fā)人員準備了一種非常方便的“智能連接”方法，不用開發(fā)人員手動添加不同的Filter，而是自動加入必要的Filter完成文件回放Filter Graph的構(gòu)建。

Dshow實現(xiàn)多種智能連接方法，其中一種是通過IGraphBuilder::RenderFile()實現(xiàn)的。該方法給出一個文件名稱之后，會首先查找注冊表，根據(jù)一些算法尋找并創(chuàng)建正確的Source Filter，然后從該Source Filter的各個輸出pin開始，進行智能連接。這是一個“遞歸”過程，直到所有分支都連接到一個Rendering Filter上為止。對于編程人員而言，如果想實現(xiàn)智能連接過程，只需要在初始化COM之后調(diào)用IGraphBuilder::RenderFile()這一接口，用已知的文件名作為參數(shù)，即可成功播放。

對于播放控制方面，Dshow也已經(jīng)方便地提供了各種屬性接口:開始、停止、暫停、恢復、快進、慢進、單幀播放、獲取播放文件大小和幀數(shù)、獲取當前播放速度和幀數(shù)、改變播放進度、幀定位、調(diào)整窗口等等。這些屬性接口都是通過Graph的屬性方法實現(xiàn)的。在智能連接過程中的初始化階段，只要再添加IMediaControl和IMediaPosition屬性操作接口，即可方便地完成以上功能操作。

3.6 車載緊急信息獲取功能的實現(xiàn)

車載緊急信息的獲取功能是通過用戶調(diào)用CCTVSDK的相應接口從車載監(jiān)控單元(TLCD)處獲取。這一獲取過程是通過基于UDP傳輸協(xié)議的網(wǎng)絡通信方式實現(xiàn)。

以上涉及的網(wǎng)絡通信消息包和應答包協(xié)議屬于內(nèi)部協(xié)議，格式見表3。

表3 消息格式Tab.3 Message layout

用戶在使用CCTVSDK功能時，需要通過IP地址獲取某個車載TLCD的訪問權(quán)限后，再發(fā)送獲取緊急信息的數(shù)據(jù)包。TLCD在一定超時時間內(nèi)給予回復，回復包中包含本車所有緊急信息的內(nèi)容，CCTVSDK負責按字節(jié)解析之后，將緊急信息類型、優(yōu)先級以及對應車廂號等有用信息返回給用戶，用戶負責進行下一步處理操作。

4 結(jié)語

在城市軌道交通實際項目開發(fā)中，基于車載監(jiān)控系統(tǒng)的SDK開發(fā)包應用非常廣泛，文中基于CCTV監(jiān)控網(wǎng)絡的SDK開發(fā)包針對車載設備內(nèi)部通信協(xié)議和標準取流協(xié)議等，提供了滿足地面監(jiān)控中心開發(fā)需求的各功能接口。

1)具備設備取流、實時預覽、實時回放、存儲視頻文件、文件回放等視頻功能，為了方便用戶不同調(diào)用習慣，還將這些功能接口以不同的接口形式給予開放。具有極大的靈活性和可操作性。

2)具備檢測車載設備狀態(tài)和獲取車載設備緊急信息功能，此項設計優(yōu)于傳統(tǒng)SDK。用戶可以運用此項報警聯(lián)動功能，使得整個監(jiān)控體系變得更加完善。

［1］王唯.遠距離多路電視監(jiān)控系統(tǒng)的設計［J］.科技信息，2009(35):889-890.

WANG Wei.The design of long-range multi-channel TV monitoring system［J］.Science and Technology Information，2009(35):889-890.(in Chinese)

［2］袁文鳳.論視頻技術(shù)的使用與發(fā)展［J］.科技信息，2009(18):199-201.

YUAN Wen-feng.Discussing on using and development of video technology［J］.Science and Technology Information，2009(18):199-201.(in Chinese)

［3］姜濤.淺談閉路監(jiān)控(CCTV)系統(tǒng)［J］.哈爾濱職業(yè)技術(shù)學院學報，2009(1):126-127.

JIANG Tao.Discussing on closed circuit television(CCTV)system［J］.Journal of Harbin Institute of Vocational Technology，2009(1):126-127.(in Chinese)

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

［5］孟懷軍，朱義勝.實時流協(xié)議RTSP的淺析［J］.鹽城工學院學報:自然科學版，2003，16(3):29-31.

MENG Huai-jun，ZHU Yi-sheng.Study on real time streaming protocol［J］.Journal of Yancheng Institute of Technology:Nature Science Edition，2003，16(3):29-31.(in Chinese)

［6］Johnson M H.Windows System Programming［M］.3rd.MA，Boston:Addison-Wesley Professional，2005.

［7］陸其明.Dshow開發(fā)指南［M］.北京:清華大學出版社，2003.

［8］FFmpeg.About FFmpeg.［EB/OL］.(2007-03-09)［2013-04-19］.http://www.ffmpeg.org/about.html.

［9］徐敏，陸達，趙洪志，等.廉價冗余盤陣列(RAID)發(fā)展綜述［J］.計算機工程與應用，1999，35(6):27-29.

XU Min，LU Da，ZHAO Hong-zhi，et al.Review of RAID technology［J］.Computer Engineering and Applications，1999，35(6):27-29.(in Chinese)

［10］姜楠，王健.常用多媒體文件格式壓縮標準解析［M］.北京:電子工業(yè)出版社，2005.