HTML5播RTSP必须用FFmpeg吗？

HTML5原生不支持RTSP协议，因其video标签仅能解析MP4、WebM等特定容器格式及H.264/H.265+AAC编码，而RTSP是传输协议且常承载浏览器无法识别的裸H.264流，直接嵌入会导致静默失败；FFmpeg虽不能在浏览器中直接运行，但可作为服务端转封装或转协议的关键工具（如转为fragmented MP4、HLS或WebRTC），不过前端用ffmpeg.wasm实时处理RTSP存在高延迟、高CPU占用和连接限制等严重缺陷；目前最轻量、低延迟且生产可用的方案是通过WebRTC中继——由服务端拉取RTSP流并适配编码后，以WebRTC协议推送给浏览器，兼顾性能、兼容性与实时性。

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 中继虽要搭服务端，却是目前最稳的生产级路径。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《HTML5播RTSP必须用FFmpeg吗？》文章吧，也可关注golang学习网公众号了解相关技术文章。