HTML5不支持RTSP，必须服务端转协议：低延迟选WebRTC（
HTML5 本身不支持 RTSP，硬上会直接失败
浏览器原生的 标签只认 HTTP(S) 协议（如 MP4、WebM、HLS、DASH），rtsp:// 地址一贴进去就静音黑屏，控制台报 DOMException: The element has no supported sources 或直接加载中断。这不是播放器写得不对，是协议层被浏览器主动拦截了——RTSP 没进 HTML5 标准，也没任何主流引擎实现它。
必须转协议：RTSP → WebRTC / HLS / MSE-HTTP
真正可行的路径只有一条：在服务端把 RTSP 流转成浏览器能吃的格式。选哪种取决于延迟和兼容性权衡：
-
低延迟首选 WebRTC：用
ffmpeg+webrtc-streamer或mediasoup转推，客户端用RTCPeerConnection接收，端到端延迟可压到 300ms 内；但需信令服务、NAT 穿透配置，Safari 对 H.265 支持差 -
兼容性首选 HLS：用
ffmpeg -i rtsp://... -c:v libx264 -f hls .../index.m3u8切片，前端用hls.js加载；延迟通常 10–30 秒，iOS Safari 原生支持，但 iOS 17+ 对非 HTTPS 的 HLS 已彻底拒接 -
折中选 MSE + HTTP-FLV：用
nginx-rtmp-module或SRS将 RTSP 转为 FLV over HTTP，前端用flv.js解码喂给MediaSource；延迟约 1–3 秒，Chrome/Firefox 支持好，但需自己处理关键帧对齐和时间戳修复
“限帧”不是前端能干的事，得在转流环节控
所谓“限帧率”，比如把 IPC 的 30fps 强制压到 15fps 来降带宽，这个动作必须发生在服务端转码时，前端 JS 对已编码的视频流没有帧级干预能力。常见错误是试图用 requestVideoFrameCallback 或 Canvas drawImage 截帧来“丢帧”，这只会卡顿、花屏、音画不同步。
正确做法是在 ffmpeg 转流命令里加参数：
立即学习“前端免费学习笔记（深入）”；
ffmpeg -i rtsp://192.168.1.100:554/stream -vf "fps=15" -c:v libx264 -preset fast -b:v 1M -f flv rtmp://localhost/live/stream15
注意：fps=15 是视频滤镜，比 -r 15 更可靠（后者可能被忽略）；若源流 I 帧间隔大，还需加 -g 30 控制 GOP 长度，避免首帧等待过久。
WebRTC 场景下帧率微调靠 SDP 与编码器参数
如果走 WebRTC，帧率约束实际由两端协商决定，不能仅靠前端 JS。关键点：
- 创建
RTCPeerConnection后，在addTransceiver时传sendEncodings: [{maxFramerate: 15}] - 生成 offer 前，用
pc.getSenders()[0].getParameters()拿到当前编码配置，手动改encodings[0].maxFramerate = 15，再sender.setParameters() - 服务端（如 webrtc-streamer）也要配
--video-bitrate=1000 --video-fps=15，否则浏览器发的帧仍会被网关全量转发 - 注意：Chrome 117+ 对
maxFramerate的实际生效依赖底层硬件编码器是否支持动态帧率，USB 摄像头或软编容易失效
真正卡脖子的地方往往不在代码，而在 RTSP 源是否稳定输出关键帧、服务端转流进程是否被 OOM kill、以及 WebSocket 信令是否因 TLS 握手慢导致 candidate 交换超时——这些比“怎么限帧”更常导致播放失败。
