簡介這是一款面向視頻監(jiān)控與GB28181平臺開發(fā)測試人員的公共測試軟件。SkeyeVSS-3.2.0以中心信令管理服務(wù)為核心支持設(shè)備注冊、心跳檢測、視頻流調(diào)度、事件通知與會話控制等關(guān)鍵功能適配Windows系統(tǒng)部署可幫助技術(shù)人員在本地快速搭建GB28181平臺環(huán)境驗(yàn)證設(shè)備接入與視頻流分發(fā)流程。資源包共458個(gè)文件壓縮后約160.62MB主要包含exe、dll、so等程序與運(yùn)行庫js、css、html及map文件為配套Web管理界面bat腳本用于安裝維護(hù)服務(wù)ttf、woff等為前端資源整體結(jié)構(gòu)清晰。目前已有246人學(xué)習(xí)使用適合正在研究GB28181協(xié)議、視頻融合云平臺信令管理或需要搭建測試環(huán)境的安防開發(fā)與運(yùn)維人員下載參考。1. 為什么我在項(xiàng)目中盯上了 SkeyeVSS做視頻接入和安防平臺這一行的人應(yīng)該都有體會項(xiàng)目里最耗人的往往不是攝像機(jī)本身而是各種接入?yún)f(xié)議、設(shè)備型號、流格式之間的“互相打架”。?？档淖邍鴺?biāo)、大華的走私有 SDK、老項(xiàng)目里還混著 RTSP 拉流、ONVIF 探測甚至還有幾路古老的 RTMP 推流。過去每個(gè)項(xiàng)目都要單獨(dú)搭一套流媒體服務(wù)再寫一堆適配層簡直是重復(fù)造輪子。SkeyeVSS 這個(gè)名字業(yè)內(nèi)做視頻監(jiān)控綜合管理的人應(yīng)該不陌生。VSS 在視頻領(lǐng)域一般對應(yīng) Video Surveillance System也就是視頻監(jiān)控系統(tǒng)。它不像單純的流媒體服務(wù)器那樣只管轉(zhuǎn)碼和分發(fā)而是把設(shè)備接入、國標(biāo)信令、流媒體網(wǎng)關(guān)、錄像存儲、告警聯(lián)動(dòng)這些都收到一個(gè)平臺里統(tǒng)一管理。3.2.0 這個(gè)版本我實(shí)際部署了一段時(shí)間正好項(xiàng)目里有一個(gè)存量監(jiān)控平臺要升級替換所以把整個(gè)接入、配置、調(diào)優(yōu)的過程都過了一遍。這篇文章就圍繞 SkeyeVSS 3.2.0 的實(shí)際使用體驗(yàn)來寫適合正在做視頻監(jiān)控平臺集成、國標(biāo)設(shè)備接入、或者想替換老舊監(jiān)控管理系統(tǒng)的朋友參考。先說結(jié)論這個(gè)版本適合的場景很明確——以 GB/T 28181 國標(biāo)設(shè)備為主、同時(shí)要兼容 RTSP/ONVIF/RTMP 等異構(gòu)源的安防項(xiàng)目。它幫你把“接入、轉(zhuǎn)流、存儲、分發(fā)”這條鏈路打通你不用再同時(shí)維護(hù)四五個(gè)開源組件來拼一套系統(tǒng)。2. 平臺整體設(shè)計(jì)拆解它到底解決了什么問題2.1 從單點(diǎn)接入到統(tǒng)一接入網(wǎng)關(guān)早期做視頻平臺最常見的方式是設(shè)備廠商的 SDK 直接嵌到業(yè)務(wù)系統(tǒng)里。聽起來直接但坑很深?？档?SDK 和大華的 SDK 接口風(fēng)格完全不一樣今天接一個(gè)廠商明天接另一個(gè)廠商代碼里全是 if-else。而且 SDK 版本升級還會導(dǎo)致舊代碼失效維護(hù)成本極高。SkeyeVSS 的邏輯是把所有設(shè)備通過統(tǒng)一接入層納管對外提供的是標(biāo)準(zhǔn)化的設(shè)備列表、實(shí)時(shí)預(yù)覽、云臺控制、錄像查詢接口。它內(nèi)部支持 GB/T 28181、RTSP、RTMP、ONVIF、?？?大華私有 SDK 等協(xié)議。3.2.0 版本對國標(biāo)設(shè)備的接入做了不少優(yōu)化特別是 SIP 注冊的兼容性我實(shí)測下來比之前的版本穩(wěn)定很多。為什么統(tǒng)一接入層這么重要因?yàn)樯蠈拥臉I(yè)務(wù)系統(tǒng)不需要關(guān)心攝像機(jī)是什么品牌、什么協(xié)議只需要面向 SkeyeVSS 的 API 做開發(fā)。設(shè)備被抽象成統(tǒng)一的數(shù)據(jù)模型業(yè)務(wù)側(cè)只需要拿到設(shè)備 ID就能拉流、控制、回放。這個(gè)思路和微服務(wù)架構(gòu)里的 API 網(wǎng)關(guān)是一個(gè)道理——把復(fù)雜性擋在網(wǎng)關(guān)后面業(yè)務(wù)層保持干凈。2.2 信令與媒體分離SIP 網(wǎng)關(guān)和流媒體網(wǎng)關(guān)的分工SkeyeVSS 內(nèi)部把“信令”和“媒體流”分開處理。國標(biāo)設(shè)備接入走 SIP 信令通道設(shè)備注冊、心跳、實(shí)時(shí)預(yù)覽的 INVITE 請求都走 SIP 服務(wù)器。而實(shí)際的 RTP 媒體流通過流媒體網(wǎng)關(guān)來接收和分發(fā)。這種分工在國標(biāo)平臺里非常關(guān)鍵。信令通道要求穩(wěn)定、低延遲但流量很小媒體通道相反流量大、并發(fā)高需要專門優(yōu)化。如果混在一起處理并發(fā)一高信令就容易被媒體流擠垮。3.2.0 版本里流媒體網(wǎng)關(guān)支持多節(jié)點(diǎn)部署信令服務(wù)器可以獨(dú)立擴(kuò)展這也意味著在大型項(xiàng)目里可以把信令節(jié)點(diǎn)和媒體節(jié)點(diǎn)分開部署各自擴(kuò)容。我在部署時(shí)發(fā)現(xiàn)官方默認(rèn)配置里信令服務(wù)和媒體服務(wù)其實(shí)是啟動(dòng)在同一臺機(jī)器上的但通過配置項(xiàng)可以拆分。這里建議項(xiàng)目規(guī)模超過 500 路攝像頭時(shí)就直接考慮拆開部署否則媒體轉(zhuǎn)發(fā)壓力上來后SIP 注冊也會跟著超時(shí)。2.3 數(shù)據(jù)模型設(shè)備、通道、流三位一體SkeyeVSS 的數(shù)據(jù)模型我梳理下來核心是三層設(shè)備Device、通道Channel、流Stream。設(shè)備是物理接入單元比如一臺 NVR 或一個(gè)攝像頭通道是設(shè)備下面的視頻源比如一個(gè) NVR 下掛了 16 路攝像頭對應(yīng) 16 個(gè)通道流則是通道對應(yīng)的具體碼流比如主碼流、子碼流。這種模型的優(yōu)勢在于它天然適配國標(biāo)的結(jié)構(gòu)。GB/T 28181 里就是設(shè)備 ID 通道 ID 的組合SkeyeVSS 只是在此基礎(chǔ)上擴(kuò)展了 Onvif 和私有 SDK 的接入把不同協(xié)議都映射成同一套設(shè)備/通道結(jié)構(gòu)。業(yè)務(wù)系統(tǒng)對接時(shí)只需要理解這一個(gè)模型即可。獲取設(shè)備列表就會返回設(shè)備和通道的層級關(guān)系選擇通道后就能拿到播放地址。我在對接一個(gè)第三方平臺時(shí)就是先拉一次設(shè)備列表、再選擇通道、然后調(diào)播放接口半小時(shí)內(nèi)就通了基本沒有理解成本。3. 3.2.0 版本核心功能拆解與實(shí)操要點(diǎn)3.1 設(shè)備接入國標(biāo)、RTSP、ONVIF 三條路怎么選3.2.0 版本我實(shí)際用下來設(shè)備接入主要是三條路徑GB/T 28181 接入是最推薦的路徑。只要攝像頭或 NVR 支持國標(biāo)協(xié)議填寫平臺 SIP 服務(wù)器地址、端口和設(shè)備編號后就能注冊上來。不需要 SDK不依賴廠商私有協(xié)議全標(biāo)準(zhǔn)實(shí)現(xiàn)。3.2.0 對國標(biāo)的心跳超時(shí)處理做了優(yōu)化設(shè)備網(wǎng)絡(luò)波動(dòng)后能更快自動(dòng)重新注冊實(shí)測網(wǎng)絡(luò)斷開 30 秒再恢復(fù)大約 20 秒內(nèi)設(shè)備狀態(tài)就能回到在線。RTSP 接入適合那些不支持國標(biāo)的舊攝像頭。直接填 RTSP URL平臺會主動(dòng)拉流。這種方式簡單粗暴但注意它不是“接入管理”只是“拉流轉(zhuǎn)發(fā)”設(shè)備狀態(tài)、云臺控制這些國標(biāo)能力是缺失的。我建議只在存量舊設(shè)備過渡階段用新項(xiàng)目盡量全部走國標(biāo)。ONVIF 接入主要解決設(shè)備發(fā)現(xiàn)和參數(shù)獲取的問題。ONVIF 本身不傳視頻流它管的是設(shè)備發(fā)現(xiàn)、媒體參數(shù)協(xié)商等。SkeyeVSS 里 ONVIF 通常和 RTSP 配合使用——先用 ONVIF 探測到設(shè)備支持的媒體參數(shù)再通過 RTSP 拉流。補(bǔ)充一個(gè)實(shí)操細(xì)節(jié)國標(biāo)設(shè)備的 SIP 認(rèn)證3.2.0 支持 ID 認(rèn)證和密碼認(rèn)證兩種方式。絕大多數(shù)攝像頭默認(rèn)開啟 ID 認(rèn)證。如果設(shè)備注冊失敗先確認(rèn) SIP 服務(wù)器 ID 和設(shè)備的國標(biāo)編號是否對得上這是最常見的坑。3.2 流媒體分發(fā)從 HLS、HTTP-FLV 到 WebRTC視頻流進(jìn)來之后最終要分發(fā)給用戶端觀看。SkeyeVSS 3.2.0 的分發(fā)協(xié)議支持得比較全RTSP、RTMP、HLS、HTTP-FLV、WebRTC。這里我實(shí)際測試了幾個(gè)關(guān)鍵場景Web 端低延遲播放首選 HTTP-FLV?；?HTTP 協(xié)議瀏覽器端用 flv.js 播放延遲能做到 1 到 3 秒。3.2.0 版本對 HTTP-FLV 的并發(fā)連接做了優(yōu)化我測試單臺流媒體服務(wù)承載 200 路并發(fā)觀看壓力不大。移動(dòng)端 H5 頁面播放HLS 兼容性最好。iOS 的 Safari 原生支持 HLS但延遲通常在 5 到 10 秒。如果項(xiàng)目對延遲要求不高只是大屏展示或回放HLS 最省事。超低延遲場景比如指揮調(diào)度、視頻對講直接上 WebRTC。3.2.0 的 WebRTC 是基于 UDP 傳輸?shù)亩说蕉搜舆t可以控制在 500 毫秒左右。我在一個(gè)遠(yuǎn)程調(diào)度項(xiàng)目里測過畫面基本是實(shí)時(shí)的說話和口型對得上。選擇分發(fā)協(xié)議時(shí)建議優(yōu)先考慮播放端的場景而不是單純追求低延遲。如果只是監(jiān)控墻展示HLS 就夠了沒必要上 WebRTC復(fù)雜度會高不少。3.3 錄像存儲與回放計(jì)劃模板和存儲策略錄像功能是安防平臺的剛需。SkeyeVSS 3.2.0 的錄像存儲設(shè)計(jì)得比較合理——它基于通道配置錄像計(jì)劃支持全天錄像和自定義時(shí)間段錄像。存儲方面平臺支持本地磁盤存儲和云存儲比如對象存儲 S3、MinIO。我項(xiàng)目里用的是 MinIO 集群配置上只需要在存儲配置里填對象存儲的地址和訪問密鑰就行。這里有個(gè)容易踩坑的地方錄像存儲的“切片時(shí)長”參數(shù)。SkeyeVSS 默認(rèn)錄像切片是 5 分鐘一個(gè)文件也就是每路通道每 5 分鐘生成一個(gè)錄像文件。如果項(xiàng)目需要經(jīng)常回放某個(gè)片段切片短一點(diǎn)比如 3 分鐘更靈活但會產(chǎn)生更多的小文件對存儲系統(tǒng)的性能有壓力。反之如果存儲空間吃緊切片可以拉到 10 到 15 分鐘。我的建議是默認(rèn) 5 分鐘就好除非你有特殊的檢索需求?；胤沤涌谠O(shè)計(jì)上平臺支持按時(shí)間段檢索錄像然后以 HLS 或 HTTP-FLV 的方式播放。HLS 的回放體驗(yàn)最好可以在播放器里直接拖動(dòng)時(shí)間軸Web 端播放器用 video.js 或 hls.js 都能順利播放。3.4 告警與事件聯(lián)動(dòng)3.2.0 的告警模塊支持設(shè)備離線告警、移動(dòng)偵測告警和視頻遮擋告警。告警消息可以通過 HTTP 回調(diào)推送到業(yè)務(wù)平臺也可以直接在控制臺查看。我實(shí)際用下來告警推送這里建議用 HTTP 回調(diào)的方式對接自己的業(yè)務(wù)系統(tǒng)。平臺支持自定義回調(diào)地址當(dāng)告警產(chǎn)生時(shí)會向指定 URL 發(fā)送 POST 請求內(nèi)容包含設(shè)備 ID、通道 ID、告警類型和截圖地址。一個(gè)容易被忽略的配置告警回調(diào)的超時(shí)時(shí)間。如果業(yè)務(wù)系統(tǒng)的回調(diào)接口響應(yīng)慢超過默認(rèn)超時(shí)時(shí)間后平臺會認(rèn)為推送失敗然后重試。我在對接一個(gè)老業(yè)務(wù)系統(tǒng)時(shí)出現(xiàn)過重復(fù)告警推送的問題后來排查發(fā)現(xiàn)是對方接口響應(yīng)時(shí)間到了 8 秒超過了平臺默認(rèn)的 5 秒超時(shí)。調(diào)整超時(shí)配置后就好了。4. 部署與配置實(shí)操記錄3.2.0 版4.1 部署環(huán)境準(zhǔn)備和安裝步驟我這次部署的環(huán)境是 CentOS 7.98 核 16G 內(nèi)存系統(tǒng)盤 100G數(shù)據(jù)盤 2T專門掛錄像存儲。SkeyeVSS 3.2.0 基于 Java 開發(fā)依賴 JDK 1.8 以上和 MySQL 5.7 以上也可以用 PostgreSQL。實(shí)際安裝步驟大致是準(zhǔn)備好 JDK 環(huán)境后解壓服務(wù)端安裝包執(zhí)行初始化腳本創(chuàng)建數(shù)據(jù)庫和導(dǎo)入初始數(shù)據(jù)然后通過啟動(dòng)腳本拉起服務(wù)。我這里整理一個(gè)標(biāo)準(zhǔn)步驟供參考安裝 JDK 1.8配置 JAVA_HOME 環(huán)境變量解壓 SkeyeVSS 服務(wù)端包到指定目錄比如/opt/skeyevss在 MySQL 里創(chuàng)建數(shù)據(jù)庫skeyevss導(dǎo)入初始化 SQL 腳本修改主配置文件application.yml重點(diǎn)確認(rèn)數(shù)據(jù)庫連接信息和服務(wù)端口執(zhí)行start.sh啟動(dòng)服務(wù)觀察啟動(dòng)日志確認(rèn)服務(wù)正常注冊這里特別注意默認(rèn)的數(shù)據(jù)庫配置里如果密碼含有特殊字符比如、#一定要做 URL 編碼否則數(shù)據(jù)庫連接會失敗。我第一次部署時(shí)就因?yàn)槊艽a里帶了個(gè)糾結(jié)了半天一直報(bào)連接超時(shí)最后發(fā)現(xiàn)是配置文件里的數(shù)據(jù)庫密碼沒轉(zhuǎn)義。4.2 關(guān)鍵配置項(xiàng)解析端口、數(shù)據(jù)庫、存儲路徑SkeyeVSS 的配置集中在兩個(gè)部分核心服務(wù)配置和流媒體網(wǎng)關(guān)配置。核心配置里這些端口要留意配置項(xiàng)默認(rèn)值說明HTTP 服務(wù)端口8080Web 管理端和 API 訪問端口HTTPS 服務(wù)端口8443可選有 HTTPS 需求時(shí)開啟SIP 服務(wù)端口5060國標(biāo)設(shè)備 SIP 注冊端口RTSP 服務(wù)端口554RTSP 拉流和播放端口RTMP 服務(wù)端口1935RTMP 推拉流端口一個(gè)端口規(guī)劃的教訓(xùn)如果平臺部署在云端安全組一定要放通 5060 的 UDP 和 TCP 端口國標(biāo)設(shè)備的 SIP 注冊要同時(shí)用到 UDP 和 TCP。之前有次設(shè)備死活注冊不上排查了一下午最后發(fā)現(xiàn)是云安全組只放通了 TCP 5060UDP 被擋了。存儲配置主要關(guān)注錄像文件的落盤路徑。如果系統(tǒng)盤和數(shù)據(jù)盤是分開的記得把錄像存儲路徑指到數(shù)據(jù)盤否則時(shí)間長了系統(tǒng)盤會被寫滿導(dǎo)致平臺服務(wù)異常。4.3 Web 管理端操作流程添加設(shè)備和配置通道SkeyeVSS 的 Web 管理端交互設(shè)計(jì)比較直觀。添加設(shè)備的主要流程是在“設(shè)備管理”菜單里點(diǎn)擊添加設(shè)備選擇接入?yún)f(xié)議國標(biāo)/RTSP/ONVIF填寫設(shè)備信息保存后等待設(shè)備注冊或拉流。國標(biāo)設(shè)備的添加比較有意思——你填寫的“設(shè)備國標(biāo)編號”要和攝像頭里的設(shè)備編號完全一致。很多工程師在這里犯錯(cuò)攝像頭里編號是 34020000001320000001平臺里填寫時(shí)少了一位設(shè)備就永遠(yuǎn)注冊不上。添加完設(shè)備后平臺會自動(dòng)獲取設(shè)備下的通道列表。國標(biāo)設(shè)備通常會自動(dòng)上報(bào)通道信息而 RTSP 接入需要手動(dòng)填通道名稱和 RTSP 播放地址。這里分享一個(gè)通道配置技巧在平臺里給通道設(shè)置“名稱”時(shí)盡量和物理位置對應(yīng)比如“3 號樓東門入口”。這樣后續(xù)在業(yè)務(wù)系統(tǒng)里做地圖聯(lián)動(dòng)或告警展示時(shí)直接調(diào)通道名稱就能定位位置不用二次維護(hù)映射表。5. 常見問題與排查技巧實(shí)錄5.1 設(shè)備頻繁離線、注冊超時(shí)怎么排查設(shè)備離線是安防平臺最常遇到的問題沒有之一。3.2.0 版本里我遇到的最多的是心跳超時(shí)導(dǎo)致離線。國標(biāo)協(xié)議里設(shè)備需要定時(shí)向 SIP 服務(wù)器發(fā)送心跳包平臺在設(shè)置的超時(shí)時(shí)間內(nèi)沒收到心跳就會把設(shè)備標(biāo)記為離線。排查思路可以按下面的路徑走查看平臺日志里有沒有設(shè)備的 SIP 注冊包和心跳包。如果沒有收到用抓包工具抓一下 5060 端口的報(bào)文看設(shè)備是否真的發(fā)出了請求檢查網(wǎng)絡(luò)鏈路設(shè)備到平臺服務(wù)器之間的 UDP 5060 是否有丟包。用 ping 和 mtr 連續(xù)測幾分鐘確認(rèn)網(wǎng)絡(luò)質(zhì)量確認(rèn)設(shè)備側(cè)的心跳間隔配置。有些設(shè)備默認(rèn)心跳間隔是 60 秒如果平臺心跳超時(shí)設(shè)置成了 30 秒設(shè)備就很容易被判定離線3.2.0 的 SIP 日志里可以用關(guān)鍵字REGISTER和MESSAGE做過濾很快能定位設(shè)備是否在正常發(fā)送心跳。我在排查一臺離線設(shè)備時(shí)抓包發(fā)現(xiàn)它的 SIP 注冊請求已經(jīng)發(fā)出去了但服務(wù)器的響應(yīng)沒有回來最后定位是安全組沒有放通 UDP 5060 端口。5.2 播放黑屏或卡頓的排查路徑播放黑屏重點(diǎn)排查兩處一是拉流是否成功二是播放協(xié)議是否匹配。如果 Web 播放器黑屏先用 VLC 直接拉 RTSP 流測試確認(rèn)源流本身沒有問題。如果 VLC 能放那么問題大概率在播放器兼容性上比如瀏覽器不支持對應(yīng)的編解碼格式。SkeyeVSS 對 H.264 的兼容性最好H.265 的視頻在部分瀏覽器里是黑屏的因?yàn)闉g覽器不原生支持 H.265 解碼。3.2.0 版本提供了轉(zhuǎn)碼能力可以把 H.265 轉(zhuǎn)成 H.264。但要注意轉(zhuǎn)碼非常消耗 CPU 資源。我在測試時(shí)開了一路 4K H.265 轉(zhuǎn) H.264CPU 直接吃掉了兩個(gè)核。所以生產(chǎn)環(huán)境如果涉及大量 H.265 設(shè)備建議買支持硬轉(zhuǎn)碼的服務(wù)器或者直接用 GPU 轉(zhuǎn)碼方案別讓 CPU 硬扛。畫面卡頓則優(yōu)先排查網(wǎng)絡(luò)帶寬。一路 1080P 主碼流的帶寬大約需要 3 到 5 Mbps。如果入口帶寬只有 50 Mbps卻同時(shí)看 20 路 1080P卡頓是必然的。這里可以調(diào)低碼率或改用子碼流預(yù)覽——子碼流一般只有主碼流的三分之一帶寬用來做巡檢預(yù)覽非常合適。5.3 錄像文件缺失或無法回放的處理建議錄像文件缺失通常是存儲配置或錄像計(jì)劃的問題。第一步先檢查通道的錄像計(jì)劃是否已經(jīng)啟用很多時(shí)候是添加通道后忘了配置錄像計(jì)劃導(dǎo)致沒有錄像文件生成。第二步看存儲狀態(tài)。平臺管理端里一般能看到存儲總?cè)萘亢鸵咽褂萌萘咳绻鎯M了錄像文件會被清理或停止寫入。我在項(xiàng)目里遇到過磁盤空間滿導(dǎo)致錄像大面積缺失的情況后來設(shè)置了存儲清理策略保留最近 30 天的錄像才把問題解決。如果是部分時(shí)間段的錄像缺失可以考慮是不是該時(shí)段的網(wǎng)絡(luò)出現(xiàn)了波動(dòng)導(dǎo)致流中斷后平臺沒有自動(dòng)重連錄像。3.2.0 支持?jǐn)嗔髯詣?dòng)重連但重連過程會有幾秒的空白這是正常的。要減少這種情況需要從網(wǎng)絡(luò)層面改善設(shè)備到平臺的鏈路質(zhì)量。按實(shí)際項(xiàng)目經(jīng)驗(yàn)做幾點(diǎn)補(bǔ)充這套平臺用下來整體的設(shè)計(jì)思路和穩(wěn)定性在同類系統(tǒng)里屬于比較扎實(shí)的。信令和媒體分離的架構(gòu)讓它在面對大規(guī)模設(shè)備接入時(shí)不會輕易出現(xiàn)信令風(fēng)暴多協(xié)議分發(fā)則讓 Web、App、大屏都能找到合適的播放方式。最后再分享一個(gè)小技巧SkeyeVSS 3.2.0 的日志體系比較完整配置里支持按模塊獨(dú)立開啟日志級別。遇到問題時(shí)先打開對應(yīng)模塊的 DEBUG 日志很多問題能直接通過日志定位根本不需要抓包。如果你也在規(guī)劃視頻監(jiān)控平臺的選型或升級建議先在測試環(huán)境把小規(guī)模設(shè)備比如 10 路左右完整跑一遍把國標(biāo)注冊、實(shí)時(shí)預(yù)覽、錄像回放這幾個(gè)核心鏈條摸熟再上生產(chǎn)。這樣踩坑成本最低生產(chǎn)交付時(shí)的信心也最足。本文還有配套的精品資源點(diǎn)擊獲取