浏览器不能直接解决所有摄像头播放
常见 IP 摄像头输出 RTSP，而标准浏览器并不直接播放普通 RTSP 流。现场项目通常需要一个网关先接入摄像头，再向浏览器提供可播放的地址，例如 HTTP-FLV、WS-FLV、HLS 或 WebRTC。
不同输出适合不同场景：WebRTC 更适合低延迟预览，HTTP-FLV / WS-FLV 适合受控网络内的低延迟观看，HLS 兼容性好但延迟通常更高。选择哪种方式应根据网络、浏览器、延迟和运维要求确定。
录像回放要和通道管理结合
录像回放不是简单保存文件。项目还需要录像索引、时间范围检索、通道过滤、播放地址、拖动定位、保留周期和磁盘管理。StreamGate 把通道、预览、录像、回放和日志放在同一套 Web Console 中，便于现场人员排查。
对于正式项目，建议在真实设备上验证长时间预览、录像写入、检索、回放拖动、磁盘占用和异常断流恢复。
浏览器播放和录像回放要一起看
很多项目先从“浏览器能不能看摄像头”开始，但真正上线时还会遇到录像计划、录像检索、回放拖动、权限和历史数据保留。实时播放和录像回放如果分散在不同工具里，现场值守、管理端和业务系统会很难统一使用。
StreamGate 的浏览器播放适合 Web Console、值守大屏、第三方业务页面和远程查看。输出协议可按项目选择 HTTP-FLV、WS-FLV、HLS 或 WebRTC。录像能力则需要同时确认录像目录、切片、索引、磁盘空间、保留策略、通道过滤和回放播放地址。
录像回放验收建议
验收时建议准备一段真实摄像头录像，覆盖跨小时、跨天、断线恢复后的索引连续性，以及拖动定位后的首帧时间。若需要业务系统对接，还应验证通过接口获取录像索引和播放地址的流程，而不是只在本地页面手工点击。
哪些指标决定体验
实时预览重点看首帧时间、多画面切换、长时间播放、断线恢复和浏览器 CPU 占用。录像回放重点看检索速度、时间轴定位、拖动后的恢复时间、跨天查询和无录像时的提示。两类体验都需要在真实摄像头、真实码率和目标浏览器上确认，单独使用测试流只能覆盖一部分场景。
如果业务系统只需要嵌入播放地址，可以先验证单通道播放和鉴权；如果需要做值守大屏、录像检索或事件联动，就应同时验证通道列表、录像索引、状态接口和告警通知，避免上线后再补接口。
从项目负责人角度看，这类能力的价值不只是“能在浏览器看”。更重要的是减少客户端安装、降低值守端维护成本、让录像回放和业务系统共用同一套通道数据。评估产品时，应关注浏览器兼容范围、部署端口、并发观看方式、录像保留成本和后续接入业务系统的工作量。