HTML5原生不支持RTSP协议，故标签无法播放RTSP流或生成缩略图；需通过服务端用ffmpeg截帧并返回图片，前端以加载，配合防缓存、定时更新及网络优化策略实现稳定低延迟缩略图。
HTML5 原生不支持 RTSP 协议，所以无法直接用 标签播放 RTSP 流，更不可能靠它自动生成缩略图。
为什么
RTSP 是实时流协议，依赖 RTP/UDP 传输，而 HTML5 的 只支持 HTTP(S)-based 流（如 MP4、WebM、HLS、DASH）。浏览器内核根本不解析 RTSP URL，访问 rtsp://... 会直接报错或静默失败。
- 常见错误现象：
DOMException: The element has no supported sources或控制台无日志但画面黑屏 - 即使加了
type="video/mp4"或伪造 MIME 类型也无效——协议层就不通 - 某些旧版 Electron 或定制 Chromium 内核可能硬编译了 FFmpeg 支持，但标准 Chrome/Firefox/Safari 均不支持
可行的缩略图生成路径：服务端截帧 + 前端加载图片
真正落地的做法是绕过浏览器限制，把“解码 RTSP + 抽帧”这件事交给后端或边缘服务，前端只负责请求一张 JPEG/PNG 图片。
- 常用工具链：
ffmpeg定时拉流并截图，例如：ffmpeg -i "rtsp://user:pass@192.168.1.100:554/stream" -vframes 1 -f image2 -y /tmp/thumb.jpg
- 建议加参数避免卡死：
-timeout 5000000 -rtsp_transport tcp（强制 TCP，防 UDP 丢包导致 ffmpeg 挂住） - 截图频率别太高（如 1–5 秒一次），否则对摄像头和服务器压力大；用文件时间戳或 Redis 缓存控制更新节奏
- 前端用
loading="lazy"和自然刷新逻辑（比如定时img.src = url + '?t=' + Date.now()）
前端“伪实时”缩略图的坑与技巧
用户想要的是“看起来像在动”的缩略图轮播，不是真视频。这时候细节决定体验是否卡顿或错乱。
立即学习“前端免费学习笔记（深入）”；
- 不要用
setInterval直接改src——可能触发浏览器缓存，显示旧图；务必拼随机查询参数或用cache: 'no-cache'配合fetch()+URL.createObjectURL() - 缩略图尺寸建议统一裁切（如 320×180），避免页面重排；可用
object-fit: cover保持比例 - 如果多个摄像头，别让所有缩略图共用一个定时器——应各自独立控制，防止某个流异常拖慢全部
- HTTP 响应头里加上
Cache-Control: no-store，防止代理或 PWA 缓存陈旧帧
真正难的不是“怎么画一张图”，而是让这张图在弱网、多设备、不同摄像头协议下都稳定、低延迟、不爆内存。缩略图服务最好和流媒体服务部署在同一局域网，RTSP 拉流走内网，避免跨公网带宽和 NAT 问题。
