智慧交通即時影像串流架構：從監控中心到民眾 App
智慧交通即時影像串流架構：從監控中心到民眾 App
交通局的智慧交通標案裡，攝影機影像通常要同時服務兩種完全不同的對象。監控中心的操作員要盯著路況牆判斷事故、調度資源，畫面延遲一拖長，反應就慢半拍；另一邊，民眾打開路況 App 或縣市政府網站查詢即時路況，在乎的是能不能順利打開畫面，即使晚個幾秒也無妨。同一支攝影機來源，兩種需求擺在一起，架構如果設計錯了，往往就是其中一邊要遷就另一邊。
系統整合商在規劃智慧交通標案時，這道「一份影像、兩種服務」的架構題，其實比想像中常被忽略。這篇說明 Wowza Streaming Engine 怎麼用「擷取層」加「分送層」的兩層架構，把兩種需求分開處理，也分享美國一個實際部署上千支攝影機的案例，作為規劃架構規模時的參考。
為什麼交通影像要分成擷取層與分送層來想
多數交通單位的攝影機不是同一批時間採購的，規格、廠牌、輸出協定往往混雜在一起，有些是老舊路口監視器輸出 RTSP，有些是新裝的執法攝影機支援 RTMP 或 SRT，甚至還有走 MPEG-TS 的類比轉換設備。如果串流平台只認一種協定，交通單位就得為了系統整合，逐步汰換還能用的攝影機硬體，這對編列預算、走標案流程的政府機關來說，成本壓力不小。
擷取層要解決的就是這個問題：把來源端的協定差異，統一收進同一個平台。分送層則是另一件事 - 同一份影像收進來之後，要怎麼分別送到監控中心的操作員螢幕，跟送到手機 App 或政府網站，這兩條路徑的技術需求完全不同，值得拆開來看。
擷取層：讓既有攝影機硬體不用整批換掉
Wowza Streaming Engine 在擷取層支援 RTSP、RTSPS、RTMP、SRT、MPEG-TS 等多種協定同時攝取，交通單位既有的攝影機不管是哪個年份採購、哪個廠牌，大多都能直接接進來，不需要為了串流平台重新採購前端設備。這對標案規劃很實際：汰換硬體的預算跟採購流程都比軟體升級慢得多，能沿用既有攝影機、只在後端疊加串流平台，是壓低導入門檻的關鍵。
收進來之後，平台會做轉碼跟封裝，同時產生近即時的縮圖畫面，這些縮圖除了給操作員快速瀏覽整片攝影機牆之外，也是後面 AI 影像分析的重要輸入。平台開放 REST API 作為控制平面，方便交通單位既有的 ATMS（先進交通管理系統）或 VMS（影像管理系統）直接串接控制指令；有客製化需求的整合商，也能透過 Java 模組擴充功能，把平台跟自己開發的 AI 辨識或告警系統整合在一起。
分送層：內部給操作員，公眾端交給 CDN
擷取層統一收進來的影像，分送層要分兩條路徑送出去。內部路徑走低延遲串流，直接送到監控中心的工作站、VMS、ATMS 平台，讓操作員能即時掌握路況、操作攝影機、確認事件；公眾路徑則是把畫面打包成 HLS，透過 CDN（例如 AWS CloudFront、Akamai、Fastly 這類服務）大規模分送出去，提供給市民朋友的 APP、縣市政府路況網站，或旅遊資訊平台這類會有大量併發使用者的通路。
CDN 分送有兩種常見做法：推送型是由 Wowza Streaming Engine 主動把串流推向 CDN 邊緣節點，拉取型則是讓 CDN 在使用者要求時，主動回頭向 Wowza 的來源拉取畫面。哪一種比較合適，通常要看交通單位既有 CDN 合約的計費模式跟流量特性，兩種模式都支援，代表規劃架構時不用被綁死在單一做法上。
負載平衡跟 Kubernetes 容器編排讓這套架構可以水平擴展，一開始從幾十支攝影機起步的標案，日後追加到三百支甚至三千支，架構本身不用重新設計，只是加機器的問題，這點對於分期擴充、後續還有維運標案的交通局來說，是規劃時值得提前確認的擴充性條件。
一個實際案例：1,300 支攝影機怎麼管
美國密西西比州交通部（MDOT）用這套架構管理約 1,300 支 RTSP 攝影機，這個規模對台灣不少縣市的智慧交通標案來說是有參考價值的量級。平台每分鐘掃描全部 1,300 支攝影機的畫面，把異常偵測結果送進團隊的告警系統，過去人工巡查攝影機健康狀態（畫面是否正常、有沒有斷線）大約要佔團隊近五成的工時，導入這套自動掃描機制之後，降到不到 1%。
省下來的人力，代表操作團隊能把心力放回真正需要人判斷的事件處理上，而不是耗在逐支確認攝影機還活著。這也是為什麼平台端產生的縮圖跟元資料，會被拿來直接支援碰撞偵測、逆向行駛偵測、停等車輛偵測這類 AI 辨識應用 - 擷取層已經把畫面跟基礎資料準備好，AI 模組要做的是在這之上加值，不用重新處理一次影像來源。
對台灣智慧交通標案的規劃提醒
台灣的智慧交通標案，案子談成要花不少時間，從縣市交通單位提出需求、走標案流程到決標，往往是以季甚至跨年度計算，但一旦得標，合約規模跟後續維運委外的價值通常不小。這代表在規劃階段把架構想清楚特別重要 - 擷取層要能吃下交通局既有的攝影機規格，分送層要能同時滿足操作端跟公眾端這兩種完全不同的服務對象，日後追加攝影機或串接 AI 辨識模組時，也不需要動到底層架構。
系統整合商在準備標案技術規劃書時，這套「擷取層＋分送層」的分法，也提供了一個清楚的方式，向交通單位說明為什麼同一份影像來源可以同時服務兩種需求，而不是各自建置兩套系統。
常見問題
交通單位既有的攝影機需要換掉才能接入 Wowza Streaming Engine 嗎？
通常不需要。Wowza Streaming Engine 在擷取層支援 RTSP、RTSPS、RTMP、SRT、MPEG-TS 等多種協定，交通單位既有攝影機大多能直接接入，不用為了串流平台重新採購前端設備。
監控中心操作員跟公眾端民眾看到的畫面，延遲會不一樣嗎？
會，這是刻意的架構設計。內部路徑走低延遲串流送到操作員工作站，公眾路徑則打包成 HLS 透過 CDN 分送，兩種對象的延遲需求本來就不同，公眾端多等幾秒不影響使用體驗，操作端則需要盡量即時。
這套架構可以擴展到幾支攝影機？
架構本身支援水平擴展，透過負載平衡與 Kubernetes 容器編排，從幾十支攝影機起步到三百支、三千支都可以只靠增加運算資源達成，不需要重新設計架構，這對分期擴充的標案規劃來說是重要的評估條件。
擷取進來的影像可以直接串接 AI 影像辨識嗎？
可以。平台在擷取層產生的近即時縮圖與元資料，可以直接作為碰撞偵測、逆向行駛偵測、停等車輛偵測等 AI 應用的輸入，不需要另外重新處理一次影像來源。
CDN 分送一定要用推送的方式嗎？
不一定。Wowza Streaming Engine 同時支援推送型（平台主動推向 CDN）與拉取型（CDN 依需求向平台拉取）兩種模式，實際採用哪一種，可以依交通單位既有的 CDN 合約與流量特性決定。
免費下載試用
想了解這套架構在自己的攝影機環境裡怎麼跑，可以先到愛上雲eSHOP下載 Wowza Streaming Engine 免費試用，實際測試多協定攝取跟 CDN 分送的設定流程。
