HTML5无法原生播放RTSP，所有方案均依赖中间服务转封装/转码；WebRTC替代HLS或MSE可显著降内存；需优化FFmpeg参数、前端资源释放及启用硬件加速。
HTML5 无法原生播放 RTSP，所谓“高内存”其实是转封装/转码服务的锅
浏览器根本不支持 rtsp:// 协议，所有号称“HTML5 播放 RTSP”的方案，背后都依赖一个中间服务（如 FFmpeg + WebSocket / WebRTC / HLS 转发）。真正吃内存的是这个服务进程，不是前端页面。排查时别在 chrome://memory-redirect/ 里盯着 JS 堆栈看——先确认你用的是哪种中转架构。
用 WebRTC 替代 HLS 或 MSE + WebSocket 方案能显著降内存
HLS（.m3u8 + .ts）和基于 WebSocket 推送 Annex-B 帧再用 MediaSource 拼接的方式，都会持续缓存多段视频数据，尤其在低延迟要求下会强制缩短切片时长、增大并发 buffer，导致服务端内存飙升（常见于 Node.js + fluent-ffmpeg 或 Python + opencv 场景）。WebRTC 则走 P2P 或 SFU 架构，帧级按需传输，无服务端解码+重封装开销。
- 服务端改用
mediasoup或janus-gateway接入 RTSP 源，开启forceVP8或h264Profile: 'baseline'降低编码压力 - 前端用
RTCPeerConnection+addTrack直接消费，避免MediaSource的 chunk 缓存累积 - 禁用自动 keyframe 请求（
pc.getSenders()[0].replaceTrack(null)后不重置 track），防止服务端重复生成 I 帧
FFmpeg 转推参数不设对，内存泄漏比播放还严重
很多自建服务用 ffmpeg -i rtsp://... -f hls 简单起流，但默认行为会无限缓存 ts 切片、堆积 GOP、开启不必要的滤镜，导致 RSS 持续上涨。关键不是“减参数”，而是关掉隐式内存大户：
- 加
-preset ultrafast -tune zerolatency：跳过耗内存的码率分析与运动估计 - 强制 GOP 固定：
-g 30 -keyint_min 30，避免 FFmpeg 自适应 keyframe 导致缓冲区不可控增长 - 删掉
-vf滤镜链（哪怕只是scale），除非真需要；用硬件加速时优先选-c:v h264_nvenc而非libx264 - 限制输出队列：
-fflags +flush_packets -max_muxing_queue_size 1024，防 ts/mpegts 封装器内部 buffer 溢出
前端 video 标签本身也会悄悄吃内存
即使后端很轻量，前端若反复创建/销毁 video 元素、未清理 MediaSource 对象或 WebRTC RTCPeerConnection，GC 不及时就会积累。Chrome 对 MediaSource 的回收尤其迟钝。
立即学习“前端免费学习笔记（深入）”；
- 复用
video元素，不要每次播放都document.createElement('video') - 停止播放时显式调用：
mediaSource.endOfStream()→URL.revokeObjectURL(video.src)→mediaSource.close() - WebRTC 场景下，
pc.close()后手动置空：pc = null，并确保没有未取消的setInterval在轮询 stats - 用
chrome://gpu确认是否启用了Hardware-accelerated video decode，没启用时软解会把内存压给 JS Heap
