直接回答
將攝影機 RTSP 來源視為攝取協議，並在攝影機網路和瀏覽器用戶端之間放置授權網關。 選擇 WebRTC 實現互動式延遲，或選擇 HLS 實現可擴展的緩衝傳輸。
為什麼會發生這種情況
現代瀏覽器媒體堆疊通常不會公開原始 RTSP 播放器。 網關必須處理攝影機驗證、編解碼器相容性、會話扇出和網路本機傳輸。
瀏覽器通常需要一個網關將攝影機輸入轉換為網路原生傳輸路徑。
受控測試
在選擇軟體之前劃定攝取、網關、瀏覽器和身份驗證邊界。
一次更改一個變數。 記錄相機型號、韌體、終端機、帳號；然後將網路可及性、協定回應、媒體傳輸和解碼作為單獨的層進行測試。
使用專用的僅供查看的帳戶和值得信賴的本地診斷工具。 在共享輸出之前編輯憑證、私人地址和識別資料。
診斷順序
| 查看 | 行動 | 進展的證據 |
|---|---|---|
| 延遲 | 定義最大玻璃到玻璃延遲。 | 目標指向 WebRTC、HLS 或其他交付模式。 |
| 規模 | 估計並發觀看者和攝影機扇出。 | 如果沒有計劃，一台相機不會每個瀏覽器開啟一次。 |
| 編解碼器 | 將相機輸出與瀏覽器解碼支援相符。 | 直通或轉碼是有意選擇的。 |
| 相信 | 將攝影機憑證保存在網關處。 | 瀏覽器接收範圍訪問，而不是相機密碼。 |
保留證據
架構記錄應指明誰終止 RTSP、誰對觀看者進行身份驗證、視訊是否進行轉碼以及緩衝區在何處增加延遲。
邊界和安全說明
切勿將帶有憑證的私人 RTSP URL 放入客戶端 JavaScript 或公共線上播放器中。
對於遠端查看，請使用託管 VPN，而不是將 RTSP 或攝影機管理連接埠直接暴露到公共網際網路。
SmartRTSP
SmartRTSP 是一款以相機為中心的 RTSP 和 ONVIF 檢視器，適用於 Apple 裝置、Windows 和 Android。 適合直接觀看、發現和多機位檢查；當需要連續記錄、證據導出或集中企業控制時，保留專用的 NVR 或 VMS。
常見問題
Chrome或Safari可以直接開啟rtsp://嗎？
不要圍繞直接原始 RTSP 播放進行設計；使用受控網關和網路本機交付路徑。
我什麼時候該選擇WebRTC？
當互動式或操作查看需要低延遲並且添加的會話基礎設施是可接受的。
什麼時候 HLS 比較合適？
當廣泛的 HTTP 交付時，快取和對基於段的延遲的容忍度比互動性更重要。
主要參考文獻
相關 SmartRTSP 指南
開啟相關指南選擇 WebRTC、HLS 或其他 Web 原生輸出，而不是期望瀏覽器直接開啟相機 RTSP URL。