为什么需要 RTSP 转换
大多数 IP 摄像机和 NVR 都能提供 RTSP 地址，但浏览器本身通常不能直接播放普通 RTSP 流。项目里如果需要在 Web 页面、值守大屏、业务系统或移动浏览器中观看摄像头画面，就需要在摄像头和浏览器之间放置网关，把 RTSP 统一转换成浏览器可播放的协议。
常见输出包括 WebRTC、HTTP-FLV、WS-FLV 和 HLS。WebRTC 更适合低延迟预览和调度场景；HTTP-FLV / WS-FLV 适合内网或受控网络里的低延迟观看；HLS 兼容性好，适合对延迟要求不高的页面和回放场景。实际选择时，应同时看浏览器兼容、延迟要求、网络环境、HTTPS 证书、并发观看人数和现场运维方式。
转换链路验收要点
RTSP 转浏览器播放不能只验收“能出画面”。还要看首帧时间、断线恢复、H.264 / H.265、音频、码流变化、浏览器切换、全屏显示、长时间预览和多画面同时播放。若需要录像回放，还要验证实时预览和录像检索是否使用同一套通道信息，避免现场人员在多个系统之间来回切换。
StreamGate 的定位是先统一接入 RTSP、ONVIF、GB28181、SRT 回传和已有视频流，再向浏览器和业务系统输出可用的播放地址。对只需要在自有软件中嵌入播放器的项目，StreamCore SDK 则更适合直接集成到桌面端、移动端或服务端程序。
选型建议
如果项目目标是浏览器预览摄像头，优先确认 RTSP 源是否稳定、是否需要 ONVIF 自动发现、是否有 H.265、是否需要低延迟和录像回放。小规模本地观看可先用标准版网关验证；需要更多协议、开放接口、转码或厂商 SDK 适配时，再评估专业版或企业项目范围。
四种浏览器播放输出怎么选
WebRTC、HTTP-FLV、WS-FLV 和 HLS 都能服务于浏览器观看，但它们适合的项目重点不同。WebRTC 更适合低延迟预览、值守大屏和调度类场景；HTTP-FLV / WS-FLV 更适合内网 Web 预览、简单播放器集成和低延迟要求明确的页面；HLS 更适合兼容性优先、对延迟不敏感、需要移动浏览器或回放入口的场景。
如果项目里同时存在值守端、管理端和外部业务系统，不一定只选择一种输出。常见做法是实时预览使用 WebRTC 或 FLV，录像回放或低频查看使用 HLS 或专用回放地址。这样可以在延迟、兼容性和服务器负载之间取得更稳定的平衡。
影响实际延迟的因素
RTSP 转浏览器播放的延迟不只由协议决定，还受摄像头 GOP、码率、编码格式、网络抖动、网关缓冲、转码策略、播放器缓冲和浏览器实现影响。若摄像头本身输出较长 GOP，即使网关侧很快，首帧时间和拖动恢复也会受到影响。若输入是 H.265，浏览器端是否能够直接播放也会影响最终输出路径。
项目验收时建议分别记录三类时间：接入侧首包时间、浏览器首帧时间、长时间播放中的端到端延迟。对于多画面预览，还应观察 4/9/16 分屏下的 CPU、内存、网络吞吐和页面响应。这样能区分是摄像头、网关、浏览器还是网络造成的瓶颈。
网关部署时需要确认的配置
部署 RTSP 转浏览器播放网关时，应提前确认摄像头账号、RTSP 主码流和子码流、是否需要音频、是否需要 HTTPS、浏览器访问域名或 IP、跨网段访问方式、端口开放范围和录像策略。内网项目也建议使用明确的访问地址和证书规划，避免后续业务系统嵌入时才发现播放地址、跨域或安全策略不匹配。
对于需要对外访问的项目，还要确认反向代理、NAT、TLS 证书、WebRTC 端口和防火墙策略。对只在局域网内使用的项目，则应优先保证局域网路径稳定、摄像头与服务器互通、播放地址可被业务终端访问。
与 StreamGate 和 StreamCore SDK 的关系
如果目标是把一批摄像头统一接入、管理并给浏览器或业务系统提供播放地址，StreamGate 更适合做现场网关。如果目标是把播放器、采集、推流或低延迟参数集成到自有桌面端、移动端或服务端程序里，StreamCore SDK 更适合直接嵌入。
同一个项目也可以两者配合：StreamGate 负责现场摄像头接入、录像和开放接口，StreamCore SDK 负责业务客户端里的播放、采集或推流能力。这样可以把现场设备差异和客户端体验分开处理。