首帧延迟需前后端协同测量：前端记录 play() 到 loadeddata 的时间差，后端记录 RTSP 连接建立至首个 RTP 包发出的时间戳；WebRTC 方案实测可压至 300–600ms。
怎么测 HTML5 播放 RTSP 的首帧延迟？
首帧延迟是 RTSP 播放最关键的性能指标，它直接决定“点击播放后多久看到画面”。浏览器本身不暴露 RTSP 首帧时间，必须靠前端打点 + 后端日志交叉验证。
- 前端在
videoElement.play()调用前记录Date.now()，监听loadeddata事件时再记一次，差值即为「浏览器感知首帧耗时」 - 但这个值常偏小——因为 MSE 或 WebRTC 可能已预加载部分数据。更准的做法是监听
timeupdate第一次触发且videoElement.currentTime > 0的时刻 - 后端中继服务（如
ws_rtsp或ffmpeg -i rtsp://... -f mp4 -）需开启日志，记录从 TCP 连接建立、RTSP OPTIONS/DESCRIBE/SETUP 到第一个 RTP 包发出的时间戳 - 注意：若使用 HLS 方案，首帧受
-hls_time影响极大，2s切片下理论首帧 ≥2s；而 WebRTC 方案实测可压到300–600ms（取决于 STUN/TURN 建连速度）
白屏时间 vs 首屏时间，哪个该监控？
对 RTSP 监控类场景，**白屏时间毫无意义**——用户看到黑屏或 loading 动画时，流可能早已在后台拉取。真正要盯的是「首屏时间」和「卡顿率」。
- 首屏时间 =
videoElement.readyState === 4且videoElement.videoWidth > 0的时刻（需轮询或监听resize） - 卡顿率建议按「每 10 秒内
timeupdate触发次数 webkitDecodedFrameCount 更稳定 - 别依赖
performance.getEntriesByType('navigation')——它只管页面加载，不管流是否就绪 - 真实弱网下，FFmpeg 转 HLS 时若未加
-re参数，会因读取过快导致切片堆积，首屏反而更慢
内存和 CPU 爆涨？大概率是 MSE 缓冲没控住
用 MSE 拼接 RTSP 流时，SourceBuffer.appendBuffer() 不释放旧数据，缓冲区会无限增长，尤其在高码率（如 4M H.264）+ 低帧率（如 5fps）组合下极易 OOM。
- 必须主动调用
sourceBuffer.remove(start, end)清理已播放段，推荐策略：保留最近bufferDuration: 30秒（见Streamedian.player配置） - Chrome 任务管理器里看
renderer进程内存 > 800MB 就该警觉；Firefox 可用about:memory查media-source占比 - 避免在
onmessage里直接appendBuffer大块数据——先用ArrayBuffer.slice()拆成 ≤2MB 的 chunk，否则触发主线程阻塞 - JS 解码方案（如
jsmpeg）CPU 占用高是常态，1920×1080@30fps在无 GPU 加速的笔记本上很容易飙到 90%+
网络波动下如何判断是流中断还是解码失败？
RTSP 播放器崩溃前往往静默——既不报错也不重连。得靠多层信号交叉验证，不能只信 video.onerror。
立即学习“前端免费学习笔记（深入）”；
-
video.networkState === 0（NETWORK_EMPTY）表示连接断开；=== 2（NETWORK_NO_SOURCE）才是资源无效 - WebSocket 中继方案中，监听
socket.onclose并检查event.code === 1006（异常关闭）比等video事件更早发现问题 - WebRTC 方案重点看
peerConnection.connectionState：从connecting → connected → disconnected是正常链路，若卡在connecting超过 5s，基本是 STUN 失败或 ICE 收集超时 - 所有方案都建议加心跳：比如每 3 秒向中继服务发个
{type:'ping'}，超时未回就主动player.destroy()+ 重试
