HTML5原生不支持RTSP，需服务端转协议（如WebRTC/HLS）；弹幕仅WebRTC+时间戳同步+DOM渲染可行，误差容忍±300ms，其他方案均为demo级妥协。
HTML5 本身不支持 RTSP，所以不存在“HTML5 播放 RTSP”的原生能力
浏览器的 <video> 标签只支持 HTTP(S) 协议下的 MP4、WebM、Ogg 等格式，rtsp:// 地址会直接报错或静默失败。所谓“HTML5 播放 RTSP”，实际是靠服务端转协议（如转成 WebRTC、HLS 或 MSE 支持的 fragmented MP4），前端再用对应方式加载。弹幕叠加必须基于这个前提才可讨论。
WebRTC 方案下叠加弹幕最可行，但需自研渲染逻辑
RTSP 流经服务端（如 ffmpeg + webrtc-streamer、mediasoup、LiveKit）转为 WebRTC 后，前端用 RTCPeerConnection 接收音视频轨道，但 WebRTC 不提供时间戳对齐的媒体帧回调。因此弹幕不能靠“绑定视频帧”实现，只能走时间轴同步：
- 服务端推送弹幕时，附带 NTP 时间戳或相对起播时间（如
{text: "hello", time: 12.345}） - 前端用
video.currentTime做主时钟，结合requestAnimationFrame定期比对并渲染/隐藏弹幕 - 避免直接监听
timeupdate事件——它触发不均匀，且在 seek 后可能丢失关键帧 - 弹幕 DOM 元素需用
position: absolute叠在<video>上层，z-index 要高于 video 的 controls（如有）
HLS 方案下弹幕时间精度差，仅适合低频场景
若 RTSP 被转为 HLS（m3u8 + ts），则无法利用 TS 分片内精确 PTS；播放器（如 hls.js）暴露的 hls.media.currentTime 有 100–500ms 滞后，且 seek 后 currentTime 可能跳变。此时弹幕易出现：
- 批量涌出（多个弹幕在同一秒内触发）
- 漏播（seek 跳过某段时间，弹幕未重载）
- 建议只用于评论式低频弹幕（如每 5 秒最多 1 条），并强制加 debounce
- 不要依赖
hls.on(Hls.Events.FRAG_PARSING_METADATA)—— RTSP 转 HLS 通常不注入 ID3 或 EMSG 元数据
务必绕开「用 canvas 绘制视频帧+弹幕」这种方案
有人尝试用 canvas.getContext('2d').drawImage(video, ...) 每帧捕获再叠字，这在 RTSP 场景下几乎不可行：
立即学习“前端免费学习笔记（深入）”；
- WebRTC 的
video元素无法被 drawImage 正常读取（跨域策略、MediaStream 渲染限制） - HLS 下频繁 drawImage 触发大量 GPU 上传，iOS Safari 直接卡死
- 弹幕位置计算需匹配原始分辨率，而
video.videoWidth/videoHeight在流启动初期常为 0 - 没有硬件加速路径，1080p@30fps 下 CPU 占用飙升
真正能落地的只有 WebRTC + 时间戳对齐 + DOM 渲染这一条路，其他都是 demo 级妥协。时间轴同步的误差容忍要按 ±300ms 设计，别追求毫秒级精准——RTSP 到 WebRTC 的端到端延迟本身就在 800ms 以上。
