HTML5不支持RTSP，需转为HLS或WebRTC；HLS由浏览器提供进度条但延迟高，WebRTC需自定义进度条，通过时间戳对齐与服务端seek实现，注意音视频同步和缓冲管理。
HTML5 本身不支持 RTSP 协议，别白费劲写 controls
浏览器原生 标签只认 HTTP(S) 流（如 MP4、HLS、DASH），rtsp:// 地址直接丢进去会静默失败，进度条根本不会出现——因为压根没加载成功。你看到的“没进度条”，其实是播放器连第一帧都没解出来。
必须用 WebRTC 或转流服务把 RTSP 转成浏览器能吃的格式
常见可行路径只有两条：
- 用
ffmpeg+nginx-rtmp-module或gstreamer把 RTSP 推成 HLS（.m3u8），再用播放——此时controls自带进度条，但 HLS 有固有延迟（通常 10–30 秒） - 用 WebRTC 方案（如
Janus、Medooze或自建 SFU）将 RTSP 转成application/webrtc，前端用RTCPeerConnection接收——这时没有原生进度条，得自己算
如果你硬要“自定义进度条”，说明你走的是 WebRTC 路线，因为 HLS 的进度条浏览器管了，不用你动手。
WebRTC 场景下怎么实现可拖动的进度条
WebRTC 是实时流，没有传统意义上的“总时长”和“当前时间点”，所以不能直接套用 video.currentTime。但你可以模拟：
立即学习“前端免费学习笔记（深入）”；
- 服务端在转发 RTSP 时，为每帧打上绝对时间戳（比如 UNIX 微秒），通过 DataChannel 或自定义信令发给前端
- 前端用
performance.now()对齐首帧渲染时间，结合帧时间戳推算“逻辑播放位置” - 进度条
的max设为预估总秒数（比如 60），value绑定到当前逻辑时间；拖动时触发 seek 请求，由服务端跳到对应 GOP 起始帧再重推 - 注意：真·精准拖动需要服务端支持随机访问（如基于 RTSP 的
PLAY ?start=参数），不是所有 RTSP 源都支持
示例片段（仅示意逻辑）：
别忽略音视频同步和缓冲区管理这个坑
自定义进度条最常崩在时间不准——画面卡住、音频飞走、拖动后花屏。原因通常是：
- 没做 PTS/DTS 校正，不同帧的时间戳来源混乱
- 前端渲染帧率 > 解码帧率，导致缓冲区堆积，
currentTime模拟值越来越偏 - 用
setTimeout做定时更新进度条，被 JS 主线程阻塞，误差累积 - 没监听
RTCPeerConnection.onconnectionstatechange，连接抖动时还在继续推进时间轴
真正可用的方案，往往得在服务端做时间锚点对齐，并让前端只响应服务端推送的“当前播放毫秒数”，而不是自己猜。
