HTML5无法直接播放RTSP流，因浏览器已废除NPAPI/PPAPI插件（含VLC插件）；可行方案是服务端将RTSP转为HLS或WebRTC等浏览器兼容格式。
HTML5 本身不支持 RTSP 协议，直接用 标签无法播放 RTSP 流，装 VLC 也帮不上忙 —— 因为浏览器插件时代已终结，现代 Chrome/Firefox/Edge 均不支持任何第三方 NPAPI/PPAPI 插件（包括 VLC Web Plugin）。
为什么装 VLC 对 HTML5 播放 RTSP 没用
VLC 曾提供浏览器插件（npvlc.dll 或 libvlcplugin.so），但自 2015 年起，Chrome 废除 NPAPI，Firefox 在 52 版后彻底移除支持，Edge 从未支持。现在即使本地装了 VLC， 或 引用 VLC 控件的方式会静默失败或报 Plugin not supported 错误。
- 浏览器控制台常见错误：
Failed to load plugin: npvlc或net::ERR_BLOCKED_BY_CLIENT（被广告拦截器或浏览器策略阻止） - VLC 自带的“Web Interface”是独立 HTTP 服务，不是嵌入式播放器，不能直接被
拉流 - 所谓“VLC + HTML5”方案，实际是绕过浏览器限制，靠服务端转协议
可行路径：服务端将 RTSP 转成 HLS 或 MSE 兼容格式
真正落地的做法是引入中转服务，把摄像头的 RTSP 地址（如 rtsp://192.168.1.100:554/stream）转成浏览器能原生解析的格式。关键不在前端装什么，而在后端跑什么：
-
HLS 方案：用
ffmpeg拉流并切片，生成.m3u8+.ts，前端用—— 兼容性好，但延迟通常 10–30 秒 -
MSE（Media Source Extensions）方案：用
ffmpeg或GStreamer将 RTSP 解复用为 H.264/AAC Annex-B 流，再通过 WebSocket 或 HTTP chunked 传给前端，用MediaSource+SourceBuffer动态喂帧 —— 延迟可压到 1–3 秒，但需自行处理时间戳、IDR 帧对齐、解码器初始化 - 现成服务推荐：
nginx-rtmp-module（HLS）、Janus Gateway（WebRTC）、Livego（HLS + RTMP）、Mediamtx（原 rtsp-simple-server，支持 RTSP → WebRTC 直播）
如果坚持“零服务端”，唯一勉强可行的客户端方案是 WebRTC
某些 IPC 厂商（如海康、大华）的新固件支持 RTSP over WebRTC，或提供私有 SDK 将 RTSP 封装成 offer/answer 信令；也有开源项目如 rtsp-relay + webrtc-streamer，它在服务端拉 RTSP，再以 WebRTC 方式推给浏览器 —— 仍需部署服务端，只是不用自己写转码逻辑。
立即学习“前端免费学习笔记（深入）”；
- 前端只需一个
和几行RTCPeerConnection代码，但依赖服务端的信令交换和媒体转发 - 不依赖 VLC，也不依赖 Flash / 插件，纯标准 Web API
- 注意：WebRTC 对 NAT 穿透敏感，内网直连容易，跨公网需 STUN/TURN 配置
真正卡住的从来不是“怎么装 VLC”，而是 RTSP 的传输层（基于 TCP/UDP）和浏览器媒体栈的解耦设计。绕不开服务端转换，就只能接受无法播放的事实 —— 这不是配置问题，是协议鸿沟。
