HTML5不支持RTSP协议和原生录屏；可行方案仅有服务端转存（如FFmpeg拉流录MP4/HLS）或客户端MediaRecorder录制WebRTC流；hls.js等无法直接录制，且需注意权限、跨域、内存溢出等问题。
HTML5 本身不支持 RTSP，更无法直接录屏
浏览器原生 标签只支持 MP4、WebM、Ogg 等 HTTP 流媒体格式，rtsp:// 协议不在支持范围内。所谓“HTML5 播放 RTSP”，实际是靠第三方库（如 ffmpeg.wasm、hls.js 配合转流服务）把 RTSP 转成 HLS 或 WebRTC，再喂给浏览器。录屏不是播放的附属功能，必须额外设计采集与编码逻辑。
真正可行的录制路径只有两种：服务端转存 or 客户端 MediaRecorder
如果你看到某个“HTML5 RTSP 录制”方案声称纯前端完成，大概率是混淆了概念——它只是触发了服务端录制指令，或把 WebRTC 接收到的视频帧用 MediaRecorder 录制成 webm（但前提是 RTSP 已被转为 WebRTC 流）。
-
服务端录制：RTSP 流由
FFmpeg或GStreamer拉取，直接保存为mp4或切片为HLS，前端只负责发控制命令（如/api/record/start?stream=cam1） -
客户端录制：需确保播放使用的是
MediaStream（例如通过WebRTC接收），然后调用new MediaRecorder(stream)；若用hls.js播放，它输出的是元素，MediaRecorder无法直接捕获画面（会录黑屏或报错InvalidStateError） - 注意：
MediaRecorder录制 WebRTC 流时，音频轨道若未正确附加（如 mute 或无权限），会导致生成文件无声
回放依赖录制格式，不是 HTML5 自带能力
录下来的文件能不能播，取决于格式和编码：
- 服务端录成
mp4（H.264 + AAC）：可直接用播放 - 服务端录成
flv或原始h264帧：浏览器不支持，必须转封装或用flv.js解析 - 客户端用
MediaRecorder录的webm：兼容性好，但部分旧版 Safari 不支持 VP8/VP9，建议强制指定mimeType: "video/webm;codecs=vp8" - 时间戳对齐问题：RTSP 流若无 NTP 同步，服务端录制的文件可能缺少准确 PTS，导致回放时音画不同步
容易被忽略的坑：权限、跨域、时长与资源泄漏
即使技术链路跑通，线上仍常卡在这些细节：
立即学习“前端免费学习笔记（深入）”；
- Chrome 对
MediaRecorder的video轨道要求严格：若MediaStream来自非安全上下文（http://）、或未用户手势触发（如自动播放），会静默失败 - WebRTC 接收端若用
RTCPeerConnection，必须正确处理track事件并调用stream.addTrack()，否则MediaRecorder构造时拿不到有效轨道 - 长时间录制（>30 分钟）易触发
MediaRecorder的 blob 内存溢出，应启用ondataavailable分段导出，而非等stop()后一次性获取 - 服务端 FFmpeg 进程未优雅退出，或录制文件未及时 flush，会导致回放时末尾几秒丢失
真正能稳定跑通的方案，几乎都绕不开服务端参与——要么转协议，要么管录制。纯前端“点一下就录 RTSP”的宣传，基本是简化了背后的复杂度。
