視頻監(jiān)控平臺軟件的發(fā)展現(xiàn)狀
視頻監(jiān)控行業(yè)至今走過了二十多年的發(fā)展，到今天已經(jīng)是一個比較完備和發(fā)達的產業(yè)。隨著視頻編解碼技術的發(fā)展，從模擬時代到數(shù)字時代，在經(jīng)歷了H.263、MPEG4、H.264技術的激蕩后，我們終于迎來了H.265的大時代，盡管目前大行其道的還是H.264。在這個過程中，視頻監(jiān)控平臺軟件一直扮演著不可或缺而且居功至偉的角色，在促進自身發(fā)展的同時，也直接或間接地促進了編解碼技術、傳輸技術、負載均衡技術、應用技術的提升，同時更滿足了廣大受眾對于監(jiān)控共享類功能的需要。
當前，在信息技術和應用領域結合非常緊密的大背景下，視頻監(jiān)控平臺軟件的角色定位一般有兩個：一個是視頻的匯聚和設備的管理，另一個是資源的共享與數(shù)據(jù)的應用。在監(jiān)控領域發(fā)展的早期，第一個角色占據(jù)主導地位。這是一個筑城的時代，也是一個閉環(huán)的時代。各個視頻監(jiān)控廠家在低競爭、大擴張的大氣候下攻城略地，構筑自己的市場壁壘。在這個階段，大多數(shù)視頻監(jiān)控類廠家都想玩出自己的特色，在本源的視頻編解碼和封裝技術上構筑自己的領地。而對于共享的考量（例如標準的統(tǒng)一）則退而求其次了。
在經(jīng)歷了這樣的“戰(zhàn)國happy時代”以后，我們迎來了一個“帝國時代”。在這個時代，恐怕大多數(shù)傳統(tǒng)的視頻監(jiān)控類廠家就不那么happy了。首先，廣大的人民，確切地說是廣大的網(wǎng)民進步了。在那個happy的時代，視頻監(jiān)控的使用者大多都是不怎么懂得操作，更不懂得領域訴求和特色的“局外人”。他們當中，有鼠標都拿得顫顫巍巍的老大爺，也有剛剛進入這個領域懵懵懂懂的愣頭小伙，還有將視頻監(jiān)控作為展示平臺或者配角的使用單位。他們對于監(jiān)控平臺的要求，可能僅僅是能看看視頻，能在電視墻上投投影而已。
但是技術在進步，行業(yè)在發(fā)展，在經(jīng)歷了一段朦朧的“不懂”歲月以后，廣大的使用者迅速對監(jiān)控類軟件熟悉起來，從而誕生了一大批“領域專家”。他們對于監(jiān)控類軟件有了更高層的要求，視頻清不清晰、傳輸占用多大的帶寬、分辨率是多少、存儲多久，諸如此類不勝枚舉，并且這樣的需求越來越強烈。另一方面，每個廠家都不能獨霸天下占領全部市場全部領域，在不同的領域，不同的市場區(qū)域之間會產生資源共享和互通的要求，更會有軟件定制化開發(fā)的要求。尤其是平安城市建設較為發(fā)達的城市和省份，這種要求非常迫切。能不能與其他廠家的異構系統(tǒng)實現(xiàn)視頻相互共享、能不能對使用單位和領域的一些特色功能定制性開發(fā)成為了這個時代的必然課題。
ZNV中興力維視頻監(jiān)控平臺軟件發(fā)展現(xiàn)狀
ZNV中興力維自從1995年成立以來，一直將視頻監(jiān)控類軟件作為自己的支柱產品之一。在經(jīng)歷了視頻匯聚和設備管理的功能性階段以后，也必然地走上了領域需求定制化和與其他廠家的異構系統(tǒng)資源共享的道路。
但是ZNV中興力維的客戶群體一直比較寬泛，其中除了滿足運營商和鐵塔的需要之外，公安、交通、電力、教育、鐵路、廣電等多個行業(yè)都有涉足。當然，這些行業(yè)對于視頻監(jiān)控軟件平臺的定位和理解是不一樣的，對于軟件功能的取舍和利用也是不同的。有些使用方把視頻監(jiān)控功能作為主業(yè)，例如公安領域，圖偵已經(jīng)成為了四大偵緝手段之一，并且由于行業(yè)內的涉密機制，共享性需求會偏低，更進一步地說，別人給資源可以，資源給別人比較難。有的行業(yè)用戶將領域應用作為主業(yè)，視頻監(jiān)控只是輔業(yè)，對于領域內的特色需求比較看重。還有的用戶，例如運營商，更偏重于交換傳輸，他們不生產視頻，他們只是視頻的搬運工。另外例如廣電用戶，他們對于視頻的要求就是匯聚和共享，為機頂盒提供頻道素材。
多年以來，ZNV中興力維一直在集成上發(fā)力，集成能力比較強，因而業(yè)務形式也比較多樣，滿足了不同客戶群體的功能需求、體驗需求和購買需求。當然，隨著onvif協(xié)議被國內視頻監(jiān)控領域的普遍認可和各種國家標準的普及，類似ZNV中興力維這樣的集成性監(jiān)控平臺軟件可以卸載一部分接入壓力，但是仍有大量的非標準的監(jiān)控設備、存儲設備需要被接入。例如云存儲設備、CMR設備、NVR設備、乃至監(jiān)控軟件平臺等。這些軟硬件各自有各自的特色，被集成后，使用方都希望發(fā)揮集成后各個子系統(tǒng)的最大價值。由于各個廠家的軟硬件產品功能、配置和使用方式不同，必然造成了集成軟件定制性的復雜化。
另外，作為行業(yè)領域內的標準，國家標準是最有權威的，是一道準入的門檻，其制訂的意義就在于讓視頻監(jiān)控或領域內的使用者、建設者們以最小的代價實現(xiàn)資源的共享和互通，最大程度地消除語義間的歧義。
定制化軟件的市場發(fā)展和關鍵問題
定制化軟件固然滿足了大多數(shù)用戶對于領域的需求，但也造成了一些問題。從開發(fā)者的角度來說，軟件間耦合過大、穩(wěn)定性和兼容性較差、需求無法收斂等。而從使用者的角度來說，風格不統(tǒng)一、軟件不穩(wěn)定不好用、期望與實現(xiàn)有差距等問題也始終存在。
但是，針對廣大用戶和領域的個性化需求，軟件定制化又是不可避免和勢在必行的。目前市面上各種定制化的視頻監(jiān)控平臺軟件的大量出現(xiàn)就是明證。例如在公安行業(yè)，對于刑偵案件的管理，在各個單位就是不一樣的，各個軟件開發(fā)廠家的理解也是百家爭鳴的。為了滿足各單位的便捷使用就不得不定制開發(fā)。如果開發(fā)的模式模型設計得不好，很可能會存在一套版本一套代碼的尷尬局面。另外還有以下一些問題亟待解決：
1. 穩(wěn)定性問題
由于定制化軟件往往增加了很多異構子系統(tǒng)，各個系統(tǒng)之間要交聯(lián)，要相互配合。但是各個廠家的產品水平參差不齊，被集成起來以后，其穩(wěn)定性大打折扣。例如SDK的接入方式就是把第三方廠商的開發(fā)包集成進來，使得第三方的模塊直接運行在自己的進程中，一旦SDK產生非法問題，很可能會導致SDK的調用進程是非法的。
2. 維護問題
軟件的定制化開發(fā)與維護是一個自始至終存在的問題。定制開發(fā)的程度越大，維護的代價也就越大，成本也就越高。同時，滿足不同用戶的業(yè)務需求，需要開發(fā)人員對相關領域有較深的知識積累，這在一定程度上也提高了定制化軟件的開發(fā)門檻和成本。很難想象對于領域不熟悉的人能夠開發(fā)出滿足領域內使用的優(yōu)秀應用軟件。
3. 需求的收斂問題
定制化軟件的開發(fā)往往是一個需求與開發(fā)并駕齊驅的過程。在軟件研發(fā)的初始階段，無論是用戶還是需求的采集者往往沒有辦法細化需求到最小粒度，這造成了一個顯而易見的問題：開發(fā)的軟件與用戶的需求不符，甚至大相徑庭，導致需求無法收斂。這在定制性軟件中太家常便飯了。
4. 軟件的安全性問題
其實這不是定制性軟件才有的問題，而是所有軟件都存在的問題。軟件的安全性主要包含兩方面，網(wǎng)絡安全和系統(tǒng)安全。通俗來講，就是怎樣“御敵于國門之外”和怎樣“本土作戰(zhàn)”。前段時間出現(xiàn)的某省公安廳的監(jiān)控設備被入侵和控制，其實就屬于第一種情況。而廠家的應對策略也主要是加強登錄密碼強度等等，這種方式針對高強度的入侵顯得非常單薄。
圖3.1 定制性軟件面臨的其他主要問題
應需而變，搶占市場發(fā)展高地
當前，定制化軟件在視頻監(jiān)控軟件領域大行其道，針對日益發(fā)展的各個行業(yè)，誰想清高地摒棄軟件定制化反而顯得不合時宜。一味地追求軟件的產品化，企圖以產品的需求滿足眾口難調的受眾，多少顯得力不從心了。定制化軟件有這樣那樣的問題，但急切之間又無法摒棄它，非但不能摒棄反而還有愈發(fā)依賴的勢頭，現(xiàn)今買套視頻監(jiān)控平臺軟件，如果里面不加點定制化的需求買主自己都過意不去。
那么視頻監(jiān)控平臺軟件廠家怎么樣才能在產品化和定制化之間找到平衡點？如何才能提升定制化安防類軟件尤其是管理平臺類軟件的含金量？如何才能在問題與代價面前不再脆弱？除了傳統(tǒng)的需求管控、迭代式開發(fā)等管理方式的革新外，我認為有以下幾點需要遵從和探索：
1. 視頻與會話協(xié)議的輸出多樣性：
在視頻編解碼領域，當前大都遵循MPEG4標準，采用的是H.264的壓縮方式，而H.265也方興未艾。但是各個廠家的視頻流的封裝卻包羅萬象。有的廠家是私有的封裝方式，有的是RTP封裝，也有的是PS(節(jié)目流)封裝，個別的是TS(傳輸流)封裝。更有甚者，壓縮方式也有變化，給解碼端和共享端造成了很大的障礙。同時，各個領域對于視頻流的封裝又有不同的規(guī)定。例如公安領域，由于GB28181等標準的出臺，PS流成為輸出的標準；在廣電領域，機頂盒一般要求輸入TS流才能正常解碼。而還有一些行業(yè)標準，例如鐵路行業(yè)，其視頻流的封裝更為靈活，可以采用RTP的方式，并且RTP可以進行擴展，視頻流的壓縮方式也不拘泥于H.264。
為了適配各個領域對視頻流的訴求，一個優(yōu)秀的視頻監(jiān)控平臺類軟件，應該能對這種情況應付自如，至少不會窘迫。那么就要求我們可以輸出多種多樣的會話規(guī)范和視頻流，包括基于SIP的方式(GB28181，GB28059、DB41等)，基于http的方式，基于rtsp的方式，基于RTMP的方式，基于SNMP的方式、基于定制化規(guī)范的方式等等，而視頻流則需要兼容PS流和TS流，乃至各種封裝的視頻流。做到了視頻與會話協(xié)議的輸出多樣性，在應對資源共享的訴求時，定制性開發(fā)的成本會降低到最少。
規(guī)范名稱會話協(xié)議類型視頻輸出標準應用
ONVIFHTTP+RTSPRTP+H.264國際標準，各行業(yè)通用
GB28181SIPPS+H.264國家標準，公安領域
鐵路綜合視頻監(jiān)控系統(tǒng)技術規(guī)范非標準協(xié)議靈活行業(yè)標準，鐵路領域
GB28059非標準協(xié)議+RTSPPS+H.264國家標準，高速公路領域
JY/T-KS-JS-2007-1國家教育考試網(wǎng)上巡查系統(tǒng)技術規(guī)范標準SIPPS+H.264行業(yè)標準，教育領域
DB33SIPPS+H.264浙江地方標準，公安領域
DB41SIPPS+H.264河南地方標準，公安領域
中國移動千里眼視頻監(jiān)控業(yè)務規(guī)范標準/非標準協(xié)議靈活運營商
中國聯(lián)通寬視界視頻監(jiān)控業(yè)務規(guī)范標準/非標準協(xié)議靈活運營商
電網(wǎng)視頻監(jiān)控系統(tǒng)及接口SIP+HTTP+RTSPH.264電力
規(guī)范名稱 會話協(xié)議類型 視頻輸出標準 應用
ONVIF HTTP+RTSP RTP+H.264 國際標準，各行業(yè)通用
GB28181 SIP PS+H.264 國家標準，公安領域
鐵路綜合視頻監(jiān)控系統(tǒng)技術規(guī)范 非標準協(xié)議 靈活 行業(yè)標準，鐵路領域
GB28059 非標準協(xié)議+RTSP PS+H.264 國家標準，高速公路領域
JY/T-KS-JS-2007-1國家教育考試網(wǎng)上巡查系統(tǒng)技術規(guī)范標準 SIP PS+H.264 行業(yè)標準，教育領域
DB33 SIP PS+H.264 浙江地方標準，公安領域
DB41 SIP PS+H.264 河南地方標準，公安領域
中國移動千里眼視頻監(jiān)控業(yè)務規(guī)范 標準/非標準協(xié)議 靈活 運營商
中國聯(lián)通寬視界視頻監(jiān)控業(yè)務規(guī)范 標準/非標準協(xié)議 靈活 運營商
電網(wǎng)視頻監(jiān)控系統(tǒng)及接口 SIP+HTTP+RTSP H.264 電力
表4.1 現(xiàn)有主流的視頻監(jiān)控領域互聯(lián)互通規(guī)范
2. 視頻監(jiān)控平臺軟件與大數(shù)據(jù)
視頻監(jiān)控軟件對接了那么多設備和系統(tǒng)資源，每時每刻都有大量的數(shù)據(jù)流入流出，除了視頻流，監(jiān)控點位的告警信息、運維數(shù)據(jù)、異構平臺的領域知識形成了規(guī)模龐大的數(shù)據(jù)集團軍。如何采集這些數(shù)據(jù)，各家都有各家的高招，但是如何保存和利用這些數(shù)據(jù)，則是傳統(tǒng)安防領域面臨的新課題。
時下流行的Hadoop框架、數(shù)據(jù)倉庫為我們完成上述工作提供了很好的引擎。數(shù)據(jù)通過數(shù)據(jù)倉庫保存，通過Hadoop系統(tǒng)進行深度挖掘和預測，結合人工智能領域的算法和模型，例如貝葉斯分類、聚類、粗糙集、序列模式等，可以從中學習到很多知識，并且利用機器學習算法，能夠建立一定的挖掘規(guī)則，從而遞歸地完善挖掘規(guī)則，提高挖掘的精度和質量。這么多種類的大數(shù)據(jù)量無疑又是定制性監(jiān)控類軟件新的功能增長動力，，為定制性軟件功能的擴展提供了豐富空間。
3. 視頻監(jiān)控平臺軟件與互聯(lián)網(wǎng)
傳統(tǒng)視頻監(jiān)控系統(tǒng)基本上是在專網(wǎng)運行的，也就是在局域網(wǎng)中運行，視頻數(shù)據(jù)的流出和流入形成了一個相對封閉的環(huán)。但是在資源共享的今天，我們除了要把自己的資源送給別的系統(tǒng)外，也要讓廣大民眾享受到近年來平安城市建設的紅利，最便捷的途徑就是互聯(lián)網(wǎng)。
而當今互聯(lián)網(wǎng)產業(yè)中，優(yōu)酷、騰訊、土豆等大型互聯(lián)網(wǎng)視頻網(wǎng)站對于監(jiān)控資源的整合并不多見，其資源大多數(shù)都是娛樂類的。當我們開車遠行時，如何趨通避堵選擇一條最佳線路就成為了對車主最暖心的服務，通過手機或者PC瀏覽器完成這些操作是最簡單的。而這項服務能否在優(yōu)酷或者騰訊的視頻服務類菜單中體現(xiàn)呢？除了體現(xiàn)，怎樣加強豐富多彩的互動和增加選擇的多樣性呢？這種仁者見仁智者見智的需求，恐怕也只有深度定制化和多種會話協(xié)議輸出的軟件平臺才能完成。
4. 視頻監(jiān)控平臺軟件與安全軟件
上文說過，軟件的安全性不是定制化軟件才有的問題，而是所有軟件產品都面臨的問題。尤其是定制化視頻監(jiān)控平臺軟件怎樣加強網(wǎng)絡安全和系統(tǒng)安全？我認為可以采取以下策略：
網(wǎng)絡安全：傳統(tǒng)廠商在應對網(wǎng)絡安全時一般會采用增加防火墻、安全接入網(wǎng)關、加強登陸驗證等策略。另外可以采用增加過濾型驅動程序的辦法來應對網(wǎng)絡安全問題，完全可以在網(wǎng)絡協(xié)議棧驅動程序中對網(wǎng)絡流量進行監(jiān)控和導流。TCPIP驅動程序作為TDI（傳輸驅動接口）服務的提供者，上層是AFD（輔助功能驅動），它們中間就是TDI。AFD以上正是用戶空間的socket庫?？梢栽谟脩艨臻g（即AFD）以上增加驅動，亦可以在TCPIP驅動以上增加過濾型驅動。
圖4.1 以總線驅動為例，增加過濾型驅動示意圖
系統(tǒng)安全：系統(tǒng)安全主要是指系統(tǒng)的入侵與反入侵，病毒的檢測等等。一般可以通過rootkit技術來檢測和應對。例如掛鉤系統(tǒng)調用描述符表（SSDT）、中斷描述符表（IDT）、IPR處理函數(shù)表、特定進程的IAT（導入地址表）等技術來實現(xiàn)。另外對調用過程打補丁也是比較常用的做法。通過這些手段，可以有效地掛鉤調用的系統(tǒng)功能或一般的過程調用，實現(xiàn)對過程調用的登記，再結合數(shù)據(jù)分析和機器學習的手段可以偵知系統(tǒng)中異常的行為和非法進程，這在視頻監(jiān)控領域也很有意義。
掛鉤對象/方式用途說明
IDT用于中斷處理例程掛鉤，可以登記和監(jiān)控中斷服務
SSDT用于系統(tǒng)調用例程掛鉤，可以登記和監(jiān)控系統(tǒng)調用
IRP Handler用于驅動程序特定IRP處理例程掛鉤，可以登記和監(jiān)控驅動服務，例如tcpip驅動
IAT導入地址表掛鉤，可以登記和監(jiān)控靜態(tài)方式導入的用戶空間模塊
GDT這種方式可以替換操作系統(tǒng)全局描述符表
MSR register登記和監(jiān)控快速系統(tǒng)調用的專用寄存器
APC采用異步過程調用的方法可以在被監(jiān)控進程中引入新的模塊或者創(chuàng)建新的線程
二進制補丁更改磁盤上被監(jiān)控進程的相關模塊，即原位補丁
運行時補丁更改內存上被監(jiān)控進程的相關模塊，可以通過迂回補丁實現(xiàn)
掛鉤對象/方式 用途說明
IDT 用于中斷處理例程掛鉤，可以登記和監(jiān)控中斷服務
SSDT 用于系統(tǒng)調用例程掛鉤，可以登記和監(jiān)控系統(tǒng)調用
IRP Handler 用于驅動程序特定IRP處理例程掛鉤，可以登記和監(jiān)控驅動服務，例如tcpip驅動
IAT 導入地址表掛鉤，可以登記和監(jiān)控靜態(tài)方式導入的用戶空間模塊
GDT 這種方式可以替換操作系統(tǒng)全局描述符表
MSR register 登記和監(jiān)控快速系統(tǒng)調用的專用寄存器
APC 采用異步過程調用的方法可以在被監(jiān)控進程中引入新的模塊或者創(chuàng)建新的線程
二進制補丁 更改磁盤上被監(jiān)控進程的相關模塊，即原位補丁
運行時補丁 更改內存上被監(jiān)控進程的相關模塊，可以通過迂回補丁實現(xiàn)
表4.2 X86架構處理器下系統(tǒng)安全登記和監(jiān)控的主要手段
軟件定制化未來發(fā)展趨勢
軟件定制化在視頻監(jiān)控管理平臺的發(fā)展過程中處于重要地位，現(xiàn)在存在，將來很長時間內也會存在。它的興衰是與監(jiān)控行業(yè)各種技術的發(fā)展、監(jiān)控手段的進步密切相關的。機遇很大，問題也不少。在軟件定制化發(fā)展過程中，接入接出標準化、輸出的靈活化和多樣性可以有效降低定制化的成本。除了傳統(tǒng)的應用程序，還可以通過接管系統(tǒng)服務或增加過濾型驅動的方式構筑操作系統(tǒng)與應用程序一體的軟件防護體系和安全登記體系，對于提高定制化軟件的安全性、魯棒性有著非常的意義。當然，這也需要跨越更高的技術門檻。
作者：深圳中興力維技術有限公司研發(fā)體系視頻技術總工程師 譚喆
