HTML5浏览器原生不支持RTSP协议，需通过流媒体服务器将RTSP转为WebRTC等兼容格式，再用Canvas逐帧处理实现滤镜；WebRTC+captureStream()是实时滤镜最优解，但需注意延迟、同步及性能优化。
HTML5 无法直接播放 RTSP 流
浏览器原生不支持 rtsp:// 协议， 标签无法直接加载 RTSP 地址。所谓“HTML5 播放 RTSP 加滤镜”，本质是绕过协议限制：先将 RTSP 转成浏览器能解的格式（如 WebRTC、HLS、HTTP-FLV 或 MSE 支持的 fragmented MP4），再在 Canvas 或 WebGL 层做图像处理。
WebRTC 是目前最可行的实时滤镜方案
RTSP 流经流媒体服务器（如 nginx-rtmp、SRS、Janus 或 Mediasoup）转为 WebRTC（即 RTCPeerConnection）后，可通过 captureStream() 获取视频轨道，在 上逐帧绘制并应用滤镜：
- 用
videoElement.captureStream().getVideoTracks()[0]获取 MediaStreamTrack - 创建
+2d上下文，每帧调用ctx.drawImage(video, 0, 0) - 读取
ctx.getImageData()像素，修改 RGBA 值（如灰度、反色、亮度增强）后再ctx.putImageData() - 性能敏感：建议用
requestAnimationFrame控制帧率，避免全量像素遍历（可降采样或用filterCSS 属性快速模拟简单效果）
Canvas 滤镜常见坑：延迟与同步问题
直接 canvas 处理会引入额外延迟（尤其高分辨率+高帧率），且音画不同步风险上升：
- 不要在
video的timeupdate事件里绘图——它不保证帧对齐；改用requestAnimationFrame+ 检查video.readyState === 4 && !video.paused - 避免每帧都调用
getImageData()（内存分配开销大）；复用ImageData对象，或改用OffscreenCanvas（需 Chrome/Firefox 支持） - CSS
filter（如contrast(1.2) brightness(1.1)）作用于元素本身，零 JS 开销，但仅支持基础效果，且无法跨浏览器一致（Safari 对部分 filter 支持弱）
别碰 FFmpeg.wasm 做实时滤镜
虽然 ffmpeg.wasm 能做复杂图像处理，但它不适合 RTSP 实时流：
立即学习“前端免费学习笔记（深入）”；
- 单帧处理耗时常超 100ms（尤其 720p+），远高于 33ms（30fps）容忍阈值
- wasm 内存频繁分配/释放易触发 GC，造成卡顿
- 没有硬件加速，CPU 占用飙升，移动端基本不可用
真正需要高级滤镜（如美颜、边缘检测），应把处理逻辑下沉到流媒体服务器端（如用 GStreamer 插件或 SRS 的 filter 模块），前端只负责渲染。
