直接回答
将摄像机 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。