HTML5原生不支持RTSP，video标签无法直接播放；必须通过服务端转流（如HLS/WebRTC）或客户端SDK（MSE+WebSocket）实现，无纯前端方案。
HTML5 原生不支持 RTSP 流，直接用 <video></video> 标签是播不了的，所有“HTML5 播 RTSP”的方案本质都是绕过浏览器限制，靠服务端转协议或客户端插件/SDK 中转。
为什么 <video src="rtsp://..."></video> 一定失败
RTSP 是控制协议，依赖 RTP/UDP 传输视频帧，而 HTML5 <video></video> 只支持 HTTP(S) 下载的 MP4/WebM（mp4, webm）或 HLS（m3u8）、DASH（mpd）这类基于 HTTP 的自适应流。浏览器根本不解析 RTSP URL，会直接报 DOMException: The element has no supported sources 或静默失败。
常见错误现象：
- 控制台无报错但画面黑屏、加载图标一直转
-
video.readyState === 0且video.networkState === 0（EMPTY） - 抓包发现浏览器根本没发 RTSP 请求，只尝试了 OPTIONS 或 404
可行路径只有两条：服务端转封装 or 客户端解码
真正落地的方案就两类，没有第三种“纯前端 HTML5 解决方案”：
立即学习“前端免费学习笔记（深入）”；
-
服务端转流（推荐）：用
ffmpeg或GStreamer把 RTSP 拉流，实时转成 HLS（.m3u8+.ts）或 WebRTC（offer/answer）；前端用标准<video></video>或RTCPeerConnection播放 -
客户端 SDK 渲染：引入如
h264bsd、libjitsi、WebRTC adapter等 JS 解码库，配合 WebSocket 接收裸 H.264 Annex-B 帧 + AAC 音频，再用MediaSource Extensions (MSE)合成播放 —— 但延迟高、兼容性差、移动端基本不可用
注意：vlc.js、ffmpeg.wasm 在浏览器里软解 RTSP 是理论可行，实际因 UDP 不可用、性能卡顿、无音频同步，几乎没人用于生产预览。
最简可运行方案：FFmpeg + Nginx-RTMP + HLS
适合小规模内网预览，延迟约 3–8 秒，无需额外 SDK：
- 拉流命令示例：
ffmpeg -i "rtsp://admin:pass@192.168.1.100:554/stream1" -c:v libx264 -c:a aac -f flv rtmp://127.0.0.1:1935/hls/stream1 - Nginx 配置启用
hls on，生成/hls/stream1.m3u8 - 前端直接：
<video src="/hls/stream1.m3u8" controls autoplay></video>
关键点：
- 确保 FFmpeg 编译时含
--enable-libx264和--enable-gpl - HLS 的
hls_time设为 2–3 秒，太小增加请求压力，太大延迟飙升 - Chrome 对 HLS 支持依赖 MSE，需 HTTPS 或 localhost；Safari 原生支持但不支持跨域
m3u8
低延迟选 WebRTC，但必须走信令服务
若要求 500ms 内延迟（如安防云台控制），必须用 WebRTC，但不能“直连 RTSP”：
- 服务端（如
mediasoup、Janus、EasyDarwin）作为 SFU，从 RTSP 拉流后转成 VP8/H.264 + Opus，通过 WebSocket 与前端交换 SDP - 前端调用
RTCPeerConnection，设置offerToReceiveVideo: true，用addTrack或createDataChannel接收流 - 切勿尝试在前端用
WebSocket直收 RTP 包——浏览器没有 API 暴露 RTP 层
容易被忽略的一点：RTSP 流的时间戳（PTS/DTS）和服务端 WebRTC 推流的时间戳不同步，会导致音画不同步或卡顿，必须在服务端做 PTS 重映射或启用 NTP 同步。
