HTML5原生不支持RTSP协议，更无码率自适应能力；可行方案是服务端将RTSP转为多码率HLS/DASH，由hls.js或dash.js实现ABR；WebRTC虽低延迟但无预设多码率切换机制。
HTML5 无法原生播放 RTSP，更谈不上码率自适应
这是最常被误解的前提——HTML5 的 标签根本不支持 rtsp:// 协议。浏览器不会发起 RTSP 握手，也不会解析 RTP 包，所以所谓“HTML5 自适应码率播放 RTSP”在标准层面就不存在。所有声称“纯前端实现”的方案，背后必然依赖转流服务（如 WebRTC 网关、FFmpeg 推流 + HLS/DASH 封装）或浏览器插件（已基本淘汰）。
真正可行的路径：RTSP → 转封装 → HLS/DASH → HTML5 播放器
要让 RTSP 流在 HTML5 页面中“看起来像”自适应码率，必须靠服务端把原始 RTSP 流实时转成多码率的 HLS（.m3u8 + .ts）或 DASH（.mpd + .m4s）。浏览器通过标准 加载这些协议，由播放器（如 hls.js 或 dash.js）自动选码率。
- 用
ffmpeg多路输出：一条命令同时生成 3–5 个不同分辨率/码率的 HLS 清单，例如-vf "scale=1280:720" -b:v 2000k、-vf "scale=640:360" -b:v 800k - 确保
HLS的#EXT-X-STREAM-INF主清单正确列出各子流，且BANDWIDTH值准确反映实际码率 -
hls.js默认启用 ABR（自适应码率），但需注意：maxBufferLength过小会导致频繁切码率卡顿；maxMaxBufferLength设太高又可能拖慢首帧
WebRTC 方案能低延迟，但不等于“自适应码率友好”
如果对延迟敏感（如安防监控），可走 RTSP → SRS/Janus/GStreamer → WebRTC 路径。但 WebRTC 的码率自适应是基于网络 QoS 动态调整的（通过 RTCP REMB 或 Transport-CC），和 HLS/DASH 的预设多码率完全不同。它没有“多档固定码率供切换”的概念，而是连续调节，因此：
- 不能靠手动指定“高清/标清”按钮切换，只能靠 SDK 提供的
getStats()观察availableOutgoingBitrate估算带宽 - 若强行用多个 WebRTC PeerConnection 分别推不同码率流，会极大增加服务端负载，且客户端无法无缝切换（有黑场）
- 主流 WebRTC 播放器（如
hls.js不适用；adapter.js+ 原生RTCPeerConnection）本身不提供 ABR UI 控制层
容易被忽略的坑：时间戳、GOP 对齐与跨域
即使转流配置看似正确，仍可能因底层细节导致自适应失效或卡顿：
立即学习“前端免费学习笔记（深入）”；
- 所有码率子流的
IDR 帧（关键帧）必须严格对齐，否则hls.js切换时会花屏或解码失败。用ffmpeg时加-g 50 -keyint_min 50强制 GOP 一致 -
HLS的EXT-X-MAP和EXT-X-I-FRAME-STREAM-INF若未正确生成，会影响快速启动和随机 Seek，间接干扰 ABR 决策 - 转流服务输出的
.m3u8必须带CORS头（Access-Control-Allow-Origin: *），否则hls.js无法加载分片 - 某些 IPC 厂商的 RTSP 流时间戳不规范（如
PTS跳变），需加-fflags +genpts或-vsync cfr修复，否则转出的 HLS 音画不同步，ABR 逻辑也会紊乱
HLS.js: [warn] fragLoadError 或 demuxerWorker: unknown video codec 这类错误。 
