Berry AI 的得來速計時系統,一間門市的車道上會裝 5 到 15 支 IP camera (後面簡稱 IP cam),Vision AI 判斷車輛的位置與動線,靠的全是它們拍回來的畫面。
這些相機由當地的施工廠商裝上、接進 PoE switch,我們的工程師遠在台灣。網段裡有幾支相機、各是什麼型號、串流要去哪裡拿,全都得由 edge server 自己問出來 (Day 04 提過這件事)。
那就寫個程式逐台問過去吧,聽起來不難。麻煩的是,該問什麼、怎麼問,得先看是哪一家的相機…
RTSP 是標準協定這點沒問題,但是串流的 URL 路徑長什麼樣子,完全由各家廠商自己決定,/Streaming/Channels/101、/cam/realmonitor?channel=1&subtype=0 之類的寫法五花八門;想改解析度、想關掉自動對焦,更是各家有各家的 HTTP API 與參數名稱。每支援一個新品牌就寫一套 adapter,同品牌的型號不同還得再分一次,這樣下去工程師都不用做別的事了。
ONVIF 是監控設備廠商在 2008 年共同組成的組織,替網路攝影機、NVR 這類設備定義了一套通用介面 (縮寫原本代表 Open Network Video Interface Forum,後來標準的範圍不只影像,全名就停用了)。它用 WSDL 描述服務、以 SOAP over HTTP 交換訊息,都是那個年代的技術選擇,但也因為夠老,市面上絕大多數的 IP cam 都支援。
ONVIF 把功能切成幾個 profile,設備登錄成某個 profile 的符合產品 (conformant product),就代表它實作了對應的必要功能:
| Profile | 內容 |
|---|---|
| S | 基本的影像串流與設定;PTZ、音訊輸入、multicast 等是設備有支援才涵蓋的條件項 |
| T | S 的功能幾乎都有,再加上 H.265、影像參數、移動偵測與遮蔽破壞事件,認證也多了更安全的 digest |
| G | 錄影與回放 |
| M | metadata 與事件分析 |
Profile S 正在淘汰,接手的是 Profile T,原因不在功能而在資安 — Profile S 規定一定要支援 WS-UsernameToken,以現在的標準來看已經不夠安全了。2027 年 3 月 31 日之後就不能再申請 Profile S 認證,不過已經裝在現場的設備照常運作,採購新機時確認有 Profile T 就好。

三個步驟對任何廠牌都是同一套呼叫,差別只在回傳的內容;而每一步都得拿到上一步的回應才發得出去。
239.255.255.250:3702 送一個 Probe,網段內的相機就會各自回一個帶著服務位址的 ProbeMatch,事先不必知道任何一支相機的 IP。GetDeviceInformation 拿到型號、序號、韌體版本,再用 GetServices 問出這台相機提供哪些服務。序號尤其重要,Day 09 會用到它。GetProfiles 列出相機上設定好的媒體 profile (解析度、codec、bitrate 的組合),挑定一個之後用它的 token 呼叫 GetStreamUri,回傳的就是我們要的那條 RTSP 位址啦!到這裡,edge server 已經可以在一間全新的門市裡,不靠任何人工整理的相機清單,自己把每一支相機的型號與串流位址問出來。
GetCapabilities,官方 WSDL 已標明被 GetServices 取代,但舊設備只認得 GetCapabilities。建議先試 GetServices,不支援再改用舊的GetStreamUri 回傳的位址不能照抄。有些相機填的是自己的內部 hostname,也可能是 DHCP 換發前的舊 IP。最保險的做法是只取路徑與 port,host 一律換成我們實際連上去的那個 IPmainstream、substream,名字撞在一起,內容卻完全是兩回事不管網段裡裝的是哪一家的相機,問法都是同一套:找出設備、問出能力、要一條串流位址。不必逐台登入 Web UI,也不必為了新品牌從頭寫一次。
至於答案回來長什麼樣子,那就是另一回事了 — 上面那些坑就是這麼來的。
本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格。