17370845950

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 过小会导致频繁切码率卡顿；maxMaxBufferLen

  

  gth 设太高又可能拖慢首帧

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 逻辑也会紊乱

实际部署时，最耗时间的往往不是选哪个库，而是校准每一帧的时间戳、验证每个子流的 GOP 对齐、确认浏览器控制台里没有 HLS.js: [warn] fragLoadError 或 demuxerWorker: unknown video codec 这类错误。