HTML5原生不支持RTSP协议，因此无法直接用标签播放或截图RTSP流；必须通过服务端转协议（如WebRTC）或WebAssembly等方案实现。
HTML5 原生不支持 RTSP 协议，所以直接用 标签播放 RTSP 流并截图是不可能的。所有声称“HTML5 播放 RTSP 并截图”的方案，背后都依赖服务端转协议（如转成 WebRTC、HLS 或 MSE 兼容的格式），或使用 WebAssembly/插件桥接。纯前端 JS 无法解码 RTSP。
为什么
RTSP 是控制协议，不传输音视频数据本身；实际媒体流走的是 RTP/UDP，浏览器既不实现 RTSP 客户端，也不支持裸 RTP 解包和解码。调用 canvas.getContext('2d').drawImage(video, ...) 前，video 元素必须已成功加载并解码帧——而 RTSP 流根本进不了这个 pipeline。
- 常见错误现象：
VIDEO_ERROR: MEDIA_ERR_SRC_NOT_SUPPORTED或静音黑屏，但控制台无报错 - 即使某些 SDK（如 WebRTC-based）能“模拟播放”，其
video元素本质是 Canvas 绘制或 WebAssembly 渲染，drawImage可能捕获到空帧或上一帧残留 - 浏览器对
MediaStream的截图限制：若流来自非本地摄像头（如经 WebSocket 推送的 H.264 Annex B 帧），它不暴露为合法MediaStream，captureStream()会返回空或抛错
可行路径：服务端转 WebRTC 后截图
目前最稳定、低延迟、支持截图的方案是：用服务端（如 ffmpeg + janus-gateway 或 mediasoup）将 RTSP 转为 WebRTC 流，前端用 RTCPeerConnection 接收，并把远端视频轨道绑定到 元素——此时它才是标准可操作的媒体元素。
- 关键前提：服务端必须完成 SDP 协商，并确保视频编码为浏览器支持的格式（如 VP8、H.264 baseline）
- 截图实操步骤：
- 等
video.readyState === 4且video.videoWidth > 0 - 创建
，尺寸设为video.videoWidth × video.videoHeight - 调用
ctx.drawImage(video, 0, 0)—— 此时能拿到真实帧 - 用
canvas.toDataURL('image/jpeg', 0.9)或canvas.toBlob()保存
- 等
- 注意兼容性：
toBlob()在 Safari 旧版需 polyfill；截图时机建议加requestAnimationFrame避免取到未渲染帧
替代方案：用 FFmpeg.js 在前端硬解（仅限小流、低帧率）
如果服务端不可控，可尝试在浏览器中用 ffmpeg.wasm 直接拉 RTSP（需服务端开启 HTTP-FLV 或 HLS 代理，因为 FFmpeg.js 不支持原生 RTSP over UDP）。但这属于“曲线救国”，性能差、启动慢、内存占用高，仅适合调试或单帧抓取。
立即学习“前端免费学习笔记（深入）”；
- 典型流程：RTSP → Nginx-rtmp 或 SRS 推出 HLS → 前端用
ffmpeg.wasm下载 ts 片段 → 解封装 + 解码 → 写入 canvas - 关键限制：
ffmpeg.wasm无法实时拉流，只能处理已下载的片段；截图本质是“解码某一帧”，不是“从播放器截当前画面” - 容易踩的坑：HLS 的
m3u8必须含#EXT-X-MAP（init segment），否则 FFmpeg.js 解不出关键帧；截图前必须等ffmpeg.FFmpeg.run()完成并触发onProgress到指定 PTS
真正可靠的截图，永远取决于“视频是否进入了浏览器的标准媒体管线”。绕过协议转换强行截图，要么得到黑图，要么截到上古缓存帧。WebRTC 路径虽需额外部署，但它是目前唯一兼顾实时性、兼容性和截图准确性的正解。
