HTML5原生不支持RTSP及倍速控制，所谓“HTML5播放RTSP”实为转流服务或JS解码库兜底；RTSP转HLS可倍速但有延迟，WebRTC无法直接倍速，MSE+MP4封装理论可行但同步易崩。
HTML5 原生不支持 RTSP，更谈不上倍速控制
浏览器的 <video> 标签只支持 HTTP(S) 协议下的 MP4、WebM、Ogg 等格式，rtsp:// 地址直接扔进去会静默失败——连加载都做不到，倍速自然无从谈起。你看到的“HTML5 播放 RTSP”，背后一定是转流服务（如 FFmpeg + WebSocket / WebRTC）或 JS 解码库（如 wasm-ffmpeg、mp4box.js）在兜底。
常见转流方案中哪些能支持倍速
倍速是否可用，取决于最终送给 <video> 的是不是标准媒体流，以及播放器是否启用原生控制：
-
RTSP → HLS (m3u8)：可以倍速，但有 10–30 秒延迟，且 iOS Safari 对playbackRate支持较稳；Chrome 需确保 m3u8 的#EXT-X-PROGRAM-DATE-TIME或时间戳连续，否则倍速下音画易撕裂 -
RTSP → WebRTC (VP8/VP9/H.264)：不能直接用playbackRate，因为 WebRTC 流是实时推的，<video>的倍速仅影响渲染节奏，不改变解码帧率，结果是卡顿或跳帧；需在信令层或 SFU 中做帧率缩放（如用mediasoup的consumer.pause()+ 丢帧逻辑），复杂度高 -
RTSP → MSE + MP4 封装（如通过 ffmpeg.wasm）：理论上可倍速，但 wasm 实时转码压力大，playbackRate可设，但音视频同步极易崩，尤其在 1.5x 以上
playbackRate 设置后没反应？检查这几点
即使你已成功把 RTSP 转成可播放的 HTTP 流，playbackRate 也可能被静默忽略：
- 视频未进入
readyState >= HTMLMediaElement.HAVE_FUTURE_DATA就设置，会被丢弃；建议监听loadedmetadata或canplay后再赋值 - 使用了自研播放器（如 video.js、hls.js），它们可能屏蔽原生
playbackRate，改用内部调度；查文档确认是否暴露playbackRateAPI，例如 hls.js 需配合hls.config.liveSyncDurationCount = 3才能在直播场景下让倍速略有效 - 某些安卓 WebView（尤其旧版）对非 1.0 值强制归零，可用
console.log(video.playbackRate)验证实际值 - 流本身含 B-frame 或可变帧率（VFR），倍速时解码器可能拒绝跳帧，表现为画面冻结但音频继续——这时得靠服务端预处理为 CFR
真正可控的倍速方案只有服务端转流+客户端协同
如果业务真需要稳定倍速（比如安防回放、教学点播），别在前端硬扛。推荐路径：
立即学习“前端免费学习笔记（深入）”；
- 服务端用
ffmpeg -i rtsp://... -vf "setpts=PTS/1.5" -af "atempo=1.5"生成倍速后的 HLS 片段，前端只负责普通播放 - 若需动态切换倍速，服务端起多个转流进程（1x/1.5x/2x），前端按需切
src，避免运行时计算 - WebRTC 方案下，放弃
playbackRate，改由服务端按倍速频率推送关键帧（如 2x 就每 2 帧送 1 帧），客户端保持 1x 渲染，逻辑更稳
前端能做的只是“请求倍速”，真正干活的永远是服务端——这点容易被 demo 误导，一上生产就露馅。
