HTML5原生不支持RTSP，因video标签仅支持MP4/WebM等格式及H.264/H.265+AAC编码，而RTSP是传输协议且常承载裸H.264流；可行方案是服务端转WebRTC或HLS。
HTML5 原生不支持 RTSP，硬上 <video> 标签会失败
直接把 RTSP 地址（如 rtsp://192.168.1.100:554/stream）塞进 <video src="...">，浏览器会静默失败或报 DOMException: The element has no supported sources。这是因为 HTML5 的 <video> 仅支持 MP4、WebM、Ogg 等容器，且要求编码为 H.264/H.265 + AAC，而 RTSP 是传输协议，不是媒体格式，底层通常跑的是裸 H.264 流（Annex B），浏览器根本无法识别。
FFmpeg 本身不能直接在浏览器里跑，但可用来转封装或转协议
浏览器里没法直接调用命令行版 ffmpeg，但你可以用它做前置处理：
- 用
ffmpeg -i rtsp://... -c copy -f mp4 -movflags +frag_keyframe+empty_moov -实时转成可流式播放的 fragmented MP4（配合 MSE） - 更常用的是用
ffmpeg搭配ffserver（已弃用）或现代替代方案（如nginx-rtmp-module、gstreamer、mediasoup）把 RTSP 转成 HLS 或 WebRTC 流 - 若坚持“前端处理”，得借助 WebAssembly 版本（如
ffmpeg.wasm），但它不擅长实时解码 RTSP —— 延迟高、CPU 占用大、不支持 TCP 长连接拉流，仅适合离线小文件分析
真正可行的轻量方案：用 WebRTC 中继（推荐）
RTSP 摄像头 → WebRTC 信令服务器（如 janus-gateway、medooze、LiveKit）→ 浏览器 RTCPeerConnection。这类方案本质是服务端完成 RTSP 拉流 + 解复用 + 编码适配（如 H.264 to VP8/AV1），再以 WebRTC 协议推给前端。优势是低延迟（通常
示例关键点：
立即学习“前端免费学习笔记（深入）”；
- 服务端需配置 RTSP 输入源，例如
janus.conf中启用videoroom插件并配置rtsp://...作为媒体源 - 前端用
new RTCPeerConnection()发起 offer，服务端返回 answer 并开始转发视频轨道 - 无需在页面里写
ffmpeg相关逻辑，也不依赖用户装任何东西
别踩坑：HLS 方案看似简单，实则延迟高且 iOS 有兼容陷阱
用 ffmpeg 把 RTSP 转成 HLS（.m3u8 + .ts 分片）后，前端用 hls.js 播放，确实能跑通。但要注意：
- HLS 天然延迟 ≥ 10 秒（取决于分片长度和缓冲策略），不适合监控、对讲等实时场景
- iOS Safari 对自签名证书下的 HLS 支持差，若用 HTTPS 但证书不被信任，会静默失败
-
hls.js不支持纯 Annex B 格式 H.264，ffmpeg转码时必须加-vcodec libx264 -x264opts keyint=30:min-keyint=30强制 IDR 帧对齐，否则花屏
RTSP 到浏览器没有银弹，选方案前先确认延迟容忍度、设备范围、运维能力——WebRTC 中继虽要搭服务端，却是目前最稳的生产级路径。
