17370845950

HTML5原生不支持RTSP，因video标签仅支持MP4/WebM等格式及H.264/H.265+AAC编码，而RTSP是传输协议且常承载裸H.264流；可行方案是服务端转WebRTC或HLS。

HTML5 原生不支持 RTSP，硬上 标签会失败

直接把 RTSP 地址（如 rtsp://192.168.1.100:554/stream）塞进 ，浏览器会静默失败或报 DOMException: The element has no supported sources。这是因为 HTML5 的 仅支持 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 中继虽要搭服务端，却是目前最