HTML5原生不支持RTSP协议，因RTSP是控制协议且依赖UDP传输，而浏览器禁止JavaScript直接收发UDP包；必须通过服务端转协议为HLS或WebRTC等浏览器支持的格式。
HTML5 原生不支持 RTSP 协议，浏览器里直接用 <video></video> 标签无法播放 rtsp:// 地址——这不是配置问题，是协议层缺失。
为什么 HTML5 不能直接播 RTSP
RTSP 是控制协议（类似遥控器），本身不传输音视频数据；实际媒体流通常走 RTP/UDP，而现代浏览器出于安全和架构原因，禁止网页 JavaScript 直接收发 UDP 包，也不实现 RTSP 客户端逻辑。HTML5 <video></video> 只支持 HTTP(S) 范围内的协议，如 MP4、WebM、HLS（http:// 或 https:// 开头的 .m3u8）和 MSE 支持的格式。
可行方案只有转协议：RTSP → HLS 或 RTMP → WebRTC
必须在服务端把 RTSP 流转换成浏览器能懂的格式。常见路径有：
-
HLS 方案：用
ffmpeg或GStreamer拉取 RTSP，切片生成.m3u8+.ts，前端用原生<video src="xxx.m3u8"></video>或hls.js（兼容老浏览器） -
WebRTC 方案：用
Janus、Medooze或EasyRTC等 SFU/MCU 服务，将 RTSP 接入后转为 WebRTC，前端调用RTCPeerConnection播放——延迟低（~300ms），但部署复杂 -
RTMP 中转（已不推荐）：用
nginx-rtmp-module或SRS接 RTSP 再推 RTMP，前端靠flv.js播放 FLV over HTTP；但 RTMP 依赖 Flash 遗留方案，且flv.js不支持音频 AAC-LC 以外的编码，兼容性正在退化
别踩这些坑：插件/客户端方案的现实限制
所谓“HTML5 播 RTSP 插件”，实际都是骗人的营销话术。注意：
立即学习“前端免费学习笔记（深入）”；
- 浏览器已全面禁用 NPAPI/PPAPI 插件（Chrome 2015 年起，Firefox 2017 年起），
vlc-webplugin、quicktime-plugin全部失效 - Electron / Tauri 桌面应用可调用本地
vlc或ffplay，但这不是“HTML5 播放”，而是绕过浏览器沙箱的桌面能力 - 部分 SDK 声称“纯 Web 播 RTSP”，实则悄悄启用了 WebSocket 代理 + 后端转码，前端仍不是直连 RTSP
- 移动端 iOS/Android 的 WebView 更严格，连
hls.js都可能因MediaSource不可用而 fallback 失败
真正落地时，90% 的项目最终选 HLS + hls.js（兼顾兼容与维护成本），剩下 10% 对延迟敏感的场景才上 WebRTC。关键不是找“插件”，而是设计好服务端流转环节——ffmpeg -i rtsp://... -c:v libx264 -f hls 这一行命令背后，要考虑 GOP 对齐、时间戳修复、断流重拉和多路并发资源占用。
