RTSP 和 ONVIF 不是同一类能力
RTSP 是媒体取流协议，摄像头或 NVR 通过 RTSP 输出音视频码流。ONVIF 更像设备管理协议，用于发现设备、读取 Profile、获取 RTSP 地址、识别设备信息和执行部分 PTZ 控制。很多项目说“支持 ONVIF 播放”，实际落地仍然是 ONVIF 找到设备和地址，再用 RTSP 拉流。
理解这个分工后，接入问题会清楚很多：发现不到设备，通常查网络、账号、ONVIF 服务和端口；有地址但不能播放，通常查 RTSP URL、认证、码流编码、网络和权限。
接入前需要准备的信息
| 信息 | 用途 |
|---|---|
| 摄像头 IP、端口、账号和密码 | 设备发现、RTSP 拉流和云台（PTZ）控制 |
| 主码流 / 子码流 | 决定清晰度、码率和服务器压力 |
| 编码格式 | 确认 H.264 / H.265、音频编码和浏览器播放链路 |
| ONVIF Profile | 用于获取 RTSP URL 和能力信息 |
| NVR 通道号 | 多通道设备需要确认真实通道映射 |
| 网络位置 | 判断是否需要端口开放、VPN、专线或 SRT 回传 |
浏览器为什么不能直接播放 RTSP
标准浏览器不能直接播放普通 RTSP 摄像头流。工程项目通常采用网关方案：网关在服务器侧拉取 RTSP / ONVIF 设备流，再输出 WebRTC、HLS、FLV 或播放地址给浏览器和业务系统。
这种方式的好处是浏览器端不用装插件，摄像头账号不暴露给每个用户，播放链路和权限可以集中管理，也便于统一录像、回放和日志。
用 StreamGate 做现场接入
StreamGate 适合把现场摄像头、NVR、RTSP URL 和 ONVIF 设备集中接入，再通过 Web Console 管理通道、预览画面、配置录像和查看日志。业务系统可以通过接口获取通道状态、播放地址和录像索引。
评估时建议至少准备三类设备：一台常规 IP 摄像头、一台 NVR 或多通道设备、一条已有 RTSP URL。这样可以同时验证设备发现、账号权限、通道映射和播放稳定性。
排障顺序
- 先用厂商工具确认摄像头本身可登录。
- 再确认 ONVIF 服务是否启用、账号是否有 ONVIF 权限。
- 用 RTSP URL 验证主码流和子码流是否可拉取。
- 在 StreamGate 中添加设备，查看在线状态和错误日志。
- 验证浏览器预览、录像任务、录像检索和回放。
- 正式部署前确认端口、防火墙、存储和授权通道数。
RTSP 和 ONVIF 的分工
RTSP 解决媒体流获取，ONVIF 解决设备发现、能力读取和部分控制。工程上通常先通过 ONVIF 找到设备和 Profile，再取得 RTSP 地址进行拉流。不要把 ONVIF 当成播放协议，也不要假设所有摄像头的 ONVIF 实现都完全一致。
现场排障顺序
当摄像头无法接入时，建议按网络连通、账号密码、ONVIF 发现、Profile、RTSP URL、主码流/子码流、编码格式、防火墙和时间同步逐项检查。很多问题不是网关本身失败，而是设备权限、子码流关闭或地址不可达。
网关接入的价值
网关可以把不同厂商、不同配置方式的摄像头整理成统一通道列表，再向浏览器、业务系统和录像模块输出稳定接口。这样业务系统不必直接处理每台摄像头的差异。
RTSP 与 ONVIF 的关系
RTSP 通常承载实际媒体流，ONVIF 更多用于发现设备、读取媒体配置、获取流地址、云台（PTZ）控制和设备信息。很多项目误以为“支持 ONVIF 就等于能播放”，实际落地时还要确认 ONVIF 返回的 Profile、RTSP URL、认证方式、码流编码和网络可达性。
StreamGate 适合把这些差异收敛到 Web Console 和通道管理中，减少业务系统直接适配不同摄像头的成本。StreamCore SDK 则适合客户端或服务端软件直接完成播放、采集和推流。两种方式都应先用 Demo、运行包或试用授权验证真实设备链路，再进入正式授权。