HTML5的标签不支持RTSP协议，因RTSP是控制协议且浏览器未实现其客户端逻辑；需通过服务端转封装为fMP4/WebM并结合MSE实现播放。
HTML5 的
不能。所有主流浏览器（Chrome、Firefox、Safari、Edge）的原生 元素都不解析 RTSP URL，比如 rtsp://192.168.1.100:554/stream 会直接报错或静默失败。
根本原因在于：RTSP 是一个**控制协议**（类似遥控器），它本身不传输音视频数据，而是协商用 RTP/UDP 传输流；而 HTML5 媒体栈只内置了对 HTTP(S) + MP4/WebM/MP3 等**文件式或分块流式（如 MSE 支持的 fragmented MP4）** 的解码与加载能力，没有实现 RTSP 客户端逻辑，也不支持原生解析 RTP 包或处理 SDP 描述。
为什么不能靠改 src 或加 MIME 类型绕过
常见误区是尝试给 设置 src="rtsp://..." 并手动指定 type="video/mp4" 或其他类型——这完全无效。浏览器在解析 src 时首先检查协议头，一旦识别为 rtsp:，就直接拒绝加载，根本不进入后续 MIME 判断流程。
你可能会看到类似这样的错误：
立即学习“前端免费学习笔记（深入）”；
DOMException: The element has no supported sources.
或者控制台显示：
Failed to load resource: net::ERR_UNKNOWN_URL_SCHEME
这些都说明协议层已被拦截，不是格式或编码问题。
可行替代方案：服务端转封装 + MSE
真正落地的方案是把 RTSP 流在服务端转成浏览器能吃的格式，再通过 JavaScript 用 Media Source Extensions（MSE）喂给 。关键点：
- 用
ffmpeg或gstreamer拉取 RTSP 流，实时转成fragmented MP4 (fMP4)或WebM，并通过 HTTP 分块输出（如用 Node.js +express提供/stream?camera=1接口） -
前端用
MediaSource+SourceBuffer接收二进制 chunk，append 到；注意必须严格按 fMP4 的 moof+mdat 结构切片，否则解码失败 - 延迟通常比原生 RTSP 高 1–3 秒，取决于转码缓冲和网络分块策略
示例片段（前端关键逻辑）：
const mediaSource = new MediaSource();
video.src = URL.createObjectURL(mediaSource);
mediaSource.addEventListener('sourceopen', () => {
const sourceBuffer = mediaSource.addSourceBuffer('video/mp4; codecs="avc1.640029"');
fetch('/api/rtsp-to-fmp4?stream=cam1')
.then(r => r.body.getReader())
.then(reader => {
function read() {
reader.read().then(({done, value}) => {
if (!done) {
sourceBuffer.appendBuffer(value); // 注意 value 必须是 fMP4 片段
read();
}
});
}
read();
});
});别踩坑：WebRTC 不等于 RTSP 替代
有人听说 WebRTC 支持低延迟视频，就想直接喂 RTSP 进去——不行。WebRTC 的 RTCPeerConnection 只接受 MediaStream（来自 getUserMedia 或 createMediaStreamSource），不能直接塞 RTSP URL。若真要用 WebRTC，仍需服务端将 RTSP 解复用 → 解码 → 编码为 VP8/VP9/H.264 → 封装为 RTP → 推给信令服务器，整套链路复杂度远超 MSE 方案。
真正省事的方案极少：某些定制浏览器（如基于 Chromium 的工业版）或 Electron 封装应用，可能通过插件或本地 C++ 模块注入 RTSP 支持，但这脱离标准 HTML5 范畴，不可移植、难维护。
最常被忽略的一点：RTSP 流往往带鉴权（rtsp://user:pass@...），而服务端代理转发时，如果没正确透传或重写 Authorization 头，会导致 ffmpeg 拉流失败，前端却只看到“黑屏无报错”。调试时务必先在服务端 curl -v 或 ffplay 验证拉流是否成功。
