HTML5不支持RTSP协议，需服务端转协议为WebRTC或HLS；前者低延迟，后者部署简单。
HTML5 本身不支持 RTSP，必须转协议
浏览器原生 <video> 标签根本不认识 rtsp:// 地址，直接写 src="rtsp://..." 会静默失败，控制台可能只报 DOMException: The element has no supported sources。这不是路径或跨域问题，是协议层不兼容——RTSP 是实时信令协议，而 HTML5 视频只接受 HTTP-based 流（如 MP4、HLS、DASH）。所以“分片”不是在 HTML5 里做，而是在服务端把 RTSP 流转成浏览器能吃的格式。
主流方案：RTSP → WebRTC 或 RTSP → HLS（m3u8 + ts）
选哪条路，取决于延迟要求和部署复杂度：
- 要低延迟（WebRTC，需部署信令服务器（如
mediasoup、Janus或nginx-rtmp-module配webrtc插件），前端用RTCPeerConnection接收；但 WebRTC 对 NAT/防火墙敏感，且无法直接用<video>的src属性，必须手写连接逻辑 - 要简单兼容、可缓存、支持移动端：转 HLS，用
ffmpeg或GStreamer拉流并切片：ffmpeg -i "rtsp://192.168.1.100:554/stream" -c:v libx264 -c:a aac -f hls -hls_time 2 -hls_list_size 5 -hls_flags delete_segments out.m3u8
生成的out.m3u8就能直接喂给<video>（需配合hls.js） - 注意：HLS 默认有 10–30 秒累积延迟，
-hls_time 1可压到 3–5 秒，但太小会导致频繁 HTTP 请求和切片碎片化
用 hls.js 播放时，enableWorker 和 lowLatencyMode 得开
默认 hls.js 行为偏保守，对 RTSP 转来的 HLS 流容易卡顿或首帧慢。关键配置不能漏：
-
enableWorker: true—— 把解析逻辑移出主线程，避免卡 UI -
lowLatencyMode: true—— 让播放器更激进地加载新切片，减少缓冲区积压 -
backBufferLength: 15—— 控制最大缓存时长（单位秒），RTSP 转 HLS 场景下设太大会拖延迟，设太小易断流 - 别忘了加
video.setAttribute('playsinline', '');，尤其 iOS Safari 必须这个才能内联播放
FFmpeg 转 HLS 容易忽略的坑：时间戳重映射与 GOP 对齐
RTSP 源（尤其 IPC 摄像头）常出现 PTS 不连续、B 帧乱序、关键帧间隔（GOP）不固定，导致切片错位、花屏或播放卡死：
立即学习“前端免费学习笔记（深入）”；
- 加
-fflags +genpts强制生成单调递增 PTS - 加
-g 50（假设 25fps，即每 2 秒一个 I 帧）统一 GOP，确保每个.ts切片都以关键帧开头 - 加
-vsync cfr强制恒定帧率输出，避免因源流丢帧导致切片时长抖动 - 如果摄像头支持，优先在源头设置固定 GOP 和 CBR 编码，比 FFmpeg 后处理更稳
真正麻烦的从来不是“怎么分片”，而是让分出来的片，每一帧都能被浏览器视频解码器干净地接住——时间戳、关键帧、编码参数，三者缺一不可。
