HTML5不支持RTSP协议，必须通过服务端转流为HLS或WebRTC等浏览器兼容格式；HLS延迟高（10–30秒）但兼容性好，WebRTC延迟低但部署复杂。
HTML5 本身不支持 RTSP，必须靠服务端转流
浏览器原生 标签根本不认识 rtsp:// 协议，这不是前端能“加个库”绕过去的限制，而是协议层彻底不兼容。RTSP 是控制协议（带 SETUP/PLAY），而 HTML5 只接受基于 HTTP 的流（如 HLS、MPEG-DASH）或 WebRTC 的信令+数据通道。所以所有“HTML5 播放 RTSP”的方案，本质都是：先用服务端把 RTSP 流转成浏览器能吃的格式，再让前端加载。
选 HLS 还是 WebRTC？看延迟和兼容性需求
HLS 延迟高（通常 10–30 秒），但兼容性极好（Safari、Chrome、Android WebView 全支持），部署简单；WebRTC 延迟低（RTCPeerConnection 的 H.264 支持不稳定，Android 旧版 WebView 也不一定支持。
- 监控大屏、非实时回看 → 优先选
HLS，用ffmpeg+nginx-http-flv-module或gstreamer推 HLS - 对讲、远程操控、需要音视频同步交互 → 必须上
WebRTC，推荐用Janus Gateway或Mediasoup接入 RTSP 源 - 别信“纯前端 JS 解码 RTSP”的方案——
rtsp-relay、hls.js加ffmpeg.wasm都扛不住持续视频帧，CPU 爆表且卡顿严重
用 FFmpeg 转 RTSP 到 HLS 的最小可行命令
这是最轻量、调试最快的起步方式，适合测试和小规模部署：
ffmpeg -i "rtsp://admin:password@192.168.1.100:554/stream1" \ -c:v libx264 -c:a aac \ -f hls \ -hls_time 2 \ -hls_list_size 3 \ -hls_flags delete_segments \ /var/www/html/live/stream.m3u8
注意几个关键点：
立即学习“前端免费学习笔记（深入）”；
-
-hls_time 2：每个 ts 片段 2 秒，太小会增加 HTTP 请求压力，太大延迟更高 - 输出路径必须是 Web 服务器可读的静态目录（如 Nginx 的
root），前端用 - 如果 RTSP 源有鉴权，确保 URL 中的用户名密码正确，否则
ffmpeg日志会卡在Authentication failed - 某些 IPC 摄像头只支持 TCP 回传 RTSP，需加
-rtsp_transport tcp参数
WebRTC 方案里最容易被忽略的三件事
用 Janus 或 Mediasoup 接 RTSP 后，前端看似只是调 new RTCPeerConnection()，但实际卡点都在服务端和网络配置上：
- RTSP 源必须是 H.264 baseline 或 main profile —— 很多海康/大华默认用 high profile，WebRTC 解码器不认，会黑屏无报错
- Janus 的
videoroom插件默认不拉流 RTSP，要启用rtsp插件并配rtsp_url和rtsp_user/rtsp_pwd - 内网部署时，
ice_servers如果只写stun:stun.l.google.com:19302，公网用户可能无法连通，必须配好自己的 TURN 服务，或至少 fallback 到iceTransportPolicy: "relay"
真正跑通前，先用 ffplay rtsp://... 和 curl http://your-hls-domain/live/stream.m3u8 确认源和转流都活，再动 WebRTC。一步跨太多，问题根本分不清是推流断了、信令没通，还是 SDP 交换失败。
