HTML5原生不支持RTSP，video标签无法直接播放rtsp://地址，因RTSP是控制协议且浏览器无内置解析器；帧率问题根源在后端转流参数、HLS切片设置或WebRTC SDP协商等环节。
HTML5 原生不支持 RTSP，所谓“HTML5 播放 RTSP”实际是靠后端转流（如 FFmpeg + WebSocket / HTTP-FLV / HLS / WebRTC）再由前端播放，帧率低根本不在 HTML5 侧，而在转流链路或协议选型上。
为什么 video 标签直接 src="rtsp://..." 一定失败
RTSP 是控制协议，不是媒体传输格式； 只接受 HTTP(S) 下的 MP4、WebM、HLS（.m3u8）、MPEG-DASH 或 WebRTC 数据流。浏览器没内置 RTSP 解析器，也无权限直连设备 RTSP 端口（跨域 + 协议限制）。
常见误操作：
- 用
video.src = "rtsp://192.168.1.100:554/stream"—— 控制台报DOMException: The element has no supported sources - 引入第三方 JS 库（如
rtsp-relay、hls.js直接喂 RTSP）—— 实际没生效，只是掩盖了转流缺失的事实
真正影响帧率的三个关键环节
帧率卡在 5–10fps？大概率卡在这三处，而非前端渲染：
立即学习“前端免费学习笔记（深入）”；
-
后端转流命令参数不合理：FFmpeg 默认不设
-r或设错，或用了-vsync vfr导致输出帧率抖动；建议固定输出帧率：ffmpeg -i rtsp://... -c:v libx264 -r 25 -g 50 -f flv rtmp://127.0.0.1/live/stream -
选用 HLS 协议时切片太长：默认
-hls_time 10会导致延迟高、首帧慢、浏览器缓存多段导致帧率感知下降；改用-hls_time 1 -hls_list_size 3并启用#EXT-X-PROGRAM-DATE-TIME对齐 PTS -
WebRTC 转流未启用硬件加速或 VP8/VP9 编码：纯软编（libx264）在高分辨率下 CPU 溢出，丢帧严重；用
ffmpeg -hwaccel qsv -c:v h264_qsv（Intel）或h264_nvenc（NVIDIA）可稳定 25–30fps
hls.js 播放时卡顿/掉帧的典型配置修正
hls.js 不是万能胶，对低延迟 RTSP 转 HLS 场景需针对性调参：
- 禁用自动码率切换：
enableStreamingMode: true+abrElevation: 0，避免因网络抖动反复切档位造成帧率跳变 - 缩短缓冲区：
maxMaxBufferLength: 1（单位秒），防止浏览器攒太多 GOP 导致解码压力大、丢帧 - 强制使用
renderingMode: 'performance'，关闭 canvas 渲染路径，走原生解码 - 检查服务端是否返回正确
Content-Type: application/vnd.apple.mpegurl，否则hls.js会静默降级为 MSE 模式并出错
WebRTC 方案中容易被忽略的帧率陷阱
用 janus-gateway 或 mediasoup 接 RTSP 后推 WebRTC，仍卡在 15fps？注意：
- SDP 中未声明接收帧率能力：
offer里要带a=framerate:30，否则远端按默认 15fps 发送 - 编码器未设置 keyframe interval：WebRTC 需求 I 帧间隔 ≤ 2 秒（即
-g 60@30fps），否则弱网下无法快速恢复 - 前端
RTCPeerConnection创建时未指定codecPreferences，导致协商出低效的 H.264 baseline 而非 high profile，解码耗时翻倍 - Chrome 浏览器对
MediaStreamTrack.getSettings()返回的frameRate是只读提示，不能反向控制源，必须从服务端源头约束
帧率问题从来不是改个 video.playbackRate 或加个 CSS 就能解决的；最常被绕开的其实是 FFmpeg 的 -vsync 模式和 WebRTC 的 SDP 帧率协商字段——这两处一错，其他优化全白搭。
