HTML5无法原生播放RTSP流，必须通过服务端转协议（如WebRTC/HLS/WebSocket-FLV），在线人数统计必须在服务端实现：WebRTC查SFU consumer数、HLS查Nginx-RTMP/SRS的clients字段、WebSocket-FLV调SRS API获取clients数组长度，前端统计不可靠。
HTML5 无法原生播放 RTSP 流
直接用 <video> 标签加载 rtsp:// 地址，浏览器会静默失败——因为 HTML5 规范不支持 RTSP 协议，所有主流浏览器（Chrome、Firefox、Edge）均无 RTSP 解析能力。所谓“HTML5 播放 RTSP”，本质是服务端转协议（如转成 WebRTC、HLS 或 MSE 兼容的 WebSocket-FLV），前端再对接。在线人数统计必须落在这个中转环节，而非前端。
在线数统计必须在流媒体服务端做
前端无法可靠感知“谁在看”，video.play() 成功不代表画面真在渲染（可能被静音、切后台、被广告拦截器阻断），也难以区分同一用户多标签打开或刷新重连。真正可信赖的连接数，只能从服务端的活跃会话中获取：
- WebRTC 方案：统计信令服务器或 SFU（如 mediasoup、Janus）中该流对应的
consumer或transport数量 - HLS 方案：统计 Nginx-RTMP 或 SRS 的
/stat接口里该 m3u8 的clients字段（注意：HLS 是无状态 HTTP，需依赖服务端 session 维护或主动心跳） - WebSocket-FLV 方案：SRS 或 Nginx-http-flv-module 中，每个 WebSocket 连接对应一个观看者，查
/api/v1/streams/{app}/{stream}/clients即可
避免用前端轮询 document.visibilityState 做统计
有人尝试在页面监听 visibilitychange 或定时发心跳到后端标记“还活着”，这会导致严重误判：
- 用户开多个标签页看同一监控流 → 后端收到多条“上线”，但实际只算 1 人
- 网络抖动导致心跳丢失 → 后端误判掉线，人数骤降
- 用户关闭标签但未触发
beforeunload（如强制 kill 进程）→ 后端残留僵尸连接
这类逻辑只适合做“用户级活跃度”辅助判断，绝不能替代服务端真实连接数。
立即学习“前端免费学习笔记（深入）”；
SRS 示例：用 API 实时查某路监控的在线数
假设你用 SRS 部署了 RTSP 转 WebRTC，推流地址为 rtsp://192.168.1.100:554/stream，SRS 配置了 WebRTC 服务并开启 HTTP API：
curl "http://srs-server:1985/api/v1/streams/live/stream/clients"
返回 JSON 中的 clients 数组长度就是当前真实观看人数。可由监控后台每 5 秒调一次，存入 Redis 计数器，再供前端展示。注意：SRS 默认不统计 HTTP-FLV/HLS 的客户端数，除非启用 http_hooks 或自定义日志解析。
真正卡点在于流媒体服务的选型和配置粒度——不是前端写几行 JS 就能搞定的事。协议转换层一旦没暴露连接状态接口，或者用了黑盒云服务（如某些厂商 SDK），在线数就根本不可信。
