HTML5不支持RTSP，需服务端转流为HLS或WebRTC；多路并发瓶颈在设备连接限制、服务端CPU/带宽及SFU扩展性，实测16核服务器可稳撑20–25路WebRTC（720p+QSV加速）。
HTML5 本身不支持 RTSP，多路并发无从谈起
浏览器原生的 标签只支持 MP4、WebM、Ogg 等 HTTP-based 媒体格式，rtsp:// 协议根本不会被解析——直接写 src="rtsp://..." 会静默失败，控制台通常只报 MediaError.MEDIA_ERR_SRC_NOT_SUPPORTED 或干脆无提示。
必须靠服务端转流（如 FFmpeg + WebSocket / WebRTC）
要让 HTML5 播放 RTSP，得先在服务端把 RTSP 流拉下来，转成浏览器能吃的格式。常见路径有两条：
- 转 HLS：用
ffmpeg拉流 + 切片生成.m3u8+ 静态文件服务；适合低实时性场景（延迟 ≥ 10s），但多路并发时磁盘 I/O 和切片管理开销大 - 转 WebRTC：用
ffmpeg+janus-gateway/mediasoup/LiveKit等信令+SFU 架构；延迟可压到 500ms 内，CPU 消耗高但更适合多路
注意：WebSocket + MSE（如用 flv.js 播 FLV over WebSocket）也能做，但需服务端支持 FLV 封装且 RTSP→FLV 转发稳定，不如 WebRTC 成熟。
多路并发的关键瓶颈不在前端，而在服务端转流能力
前端开 16 个 标签没问题，但后端能否同时拉 16 路 RTSP 并转出 16 路 WebRTC 流，取决于：
立即学习“前端免费学习笔记（深入）”；
本文档主要讲述的是android rtsp流媒体播放介绍；实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
- CPU：H.264/H.265 解码 + 编码（若需转码）是重负载，建议用硬件加速（
-hwaccel qsv/-c:v h264_qsv） - 网络：每路 WebRTC 至少占用 1–2 Mbps 上行带宽（720p@30fps），16 路需 20+ Mbps 稳定上行
- 信令与 SFU：Janus 默认单进程扛不住 16 路以上，需部署多个实例 + 负载均衡；mediasoup 支持 worker 进程隔离，扩展性更好
实测中，一台 16 核 32G 的服务器，在启用 QSV 加速、仅转发（不转码）、720p 分辨率下，可稳定支撑 20–25 路 WebRTC 输出。
别忽略 RTSP 设备本身的限制
很多 IPC/NVR 厂家对单设备 RTSP 并发连接数做了硬限制（如海康最多 4 路、大华默认 3 路），超出后新连接会被拒绝或老连接断开。这不是你服务端的问题，而是设备侧策略。
解决办法只有两个：
- 查设备文档，看是否支持提高并发数（常需开启“多播”或修改高级参数）
- 用代理方式：起一个中间服务（如
rtsp-simple-server），先连设备拿一路流，再由它分发给多个下游转流进程——绕过设备直连限制
真正卡住多路 RTSP 播放的，往往不是 HTML5 或 JS，而是设备许可、服务端解码资源、以及 WebRTC SFU 的连接管理粒度。这些地方一不留神，页面看着开了 16 个窗口，实际只有一半在动。
