HTML5不支持RTSP，需转为HLS/WebRTC/MSE-FLV；弱网首选WebRTC（抗抖动、自动降帧、重传），但需定制信令与SDP；HLS/FLV方案须严控分片、缓冲及CDN边缘部署。
HTML5 本身不支持 RTSP，别硬扛协议转换
浏览器原生 标签根本不认识 rtsp:// 地址，所有“HTML5 播 RTSP”的方案本质都是：先把 RTSP 流转成浏览器能播的格式（如 HLS、WebRTC、MSE-HTTP-FLV）。网络差时卡顿、花屏、断连，问题不在 HTML5，而在中间转流环节和传输协议选型。
常见错误是直接用 ffmpeg 拉 RTSP 再推 HLS，结果 m3u8 切片延迟高、弱网下索引文件加载失败、404 频发——这不是优化问题，是架构错配。
弱网首选 WebRTC，但得绕过信令和 SDP 手动控制
WebRTC 天然抗抖动、自动降帧率/分辨率、NACK/PLI 重传机制对丢包友好，比 HLS/FLV 更适合弱网。但难点在：RTSP 源需接入 WebRTC 信令服务（如 mediasoup、janus），且必须定制 SDP 生成逻辑，否则默认配置会因带宽预估不准导致卡死。
-
offer中显式禁用 BFCP、RTCP-MUX，减少协商失败概率 - 强制
maxplaybackrate=30和maxaveragebitrate=800000（单位 bps），避免自适应带宽探测拖慢首帧 - 服务端用
gstreamer或ffmpeg -f rtsp -vcodec copy -acodec copy拉流后，用webrtcbin推出，别走 RTP over UDP 直推——NAT 穿透失败率太高
若必须用 MSE（如 FLV/HLS），重点压住分片与缓冲策略
MSE 方案在弱网下极易因 HTTP 请求超时或分片缺失中断播放。关键不是调 video.buffered，而是控制服务端输出节奏和客户端加载逻辑：
立即学习“前端免费学习笔记（深入）”；
- HLS：用
EXT-X-TARGETDURATION=2（别用 4 或 6），并确保EXT-X-MEDIA-SEQUENCE连续；禁用EXT-X-DISCONTINUITY，弱网下切片不完整极易触发播放器 panic - FLV over HTTP：服务端返回
Content-Range+206 Partial Content，前端用fetch分段拉取，自己拼Uint8Array塞进SourceBuffer；避免用现成播放器（如 flv.js 默认 3s 缓冲，弱网下等不到就报Uncaught (in promise) DOMException: The play() request was interrupted） - 客户端加
video.play().catch(e => { if (e.name === 'AbortError') setTimeout(() => video.play(), 500); })，防首帧加载失败直接挂死
CDN 和边缘节点不是可选项，是弱网下的生存线
RTSP 源通常在内网或远端摄像头，直连转流服务器再传到浏览器，链路长、跳数多、TCP 重传放大延迟。实测显示：同一城市内，经边缘节点（如阿里云 EDS、腾讯云 ECDN）中转后，95% 分位首帧耗时 从 4.2s 降到 1.1s，卡顿率下降 67%。
注意两个细节：edge node 必须支持 WebSocket 或 QUIC 回源（避免 TCP HOL blocking），且转流服务要部署在离 CDN 边缘最近的可用区——跨 AZ 延迟增加 8–15ms，对 WebRTC 是致命的。
真正难的不是选哪种方案，是看清 RTSP 到浏览器之间到底隔着几层协议转换、多少个网络跃点。每个环节的 buffer、timeout、重试逻辑，都可能在弱网下被放大成不可恢复的播放中断。
