HTML5原生不支持RTSP，需转码为WebRTC、HLS或MSE-FLV；低延迟选WebRTC，平衡选MSE+FLV，兼容优先选HLS；关键注意GOP、编码格式、音频编码及设备原始流质量。
HTML5 原生不支持 RTSP，必须转码
浏览器的 <video> 标签只认 MP4、WebM、FLV（通过 MSE）等格式，RTSP 协议本身不在支持列表里。直接把 rtsp:// 地址丢进 src 属性，只会静音失败——控制台通常报 DOMException: The element has no supported sources 或直接黑屏无日志。
常见转码路径：RTSP → WebRTC / HLS / MSE-FLV
实际部署中，有三条主流链路，选型取决于延迟要求和终端兼容性：
-
低延迟（<1s）→ WebRTC：用
Janus、Medooze或LiveKit接入 RTSP 流，转成RTCPeerConnection可播的VP8/VP9/H.264；需客户端写 JS 信令逻辑，iOS Safari 支持较稳，Android 部分低端机解码可能卡顿 -
平衡方案（2–5s）→ MSE + FLV：用
nginx-rtmp-module或SRS拉流并转封装为FLV，前端用flv.js解析；flv.js依赖MediaSourceAPI，IE11 不行，但 Chrome/Firefox/Edge 新版都 OK -
兼容优先（10s+）→ HLS：用
FFmpeg或GStreamer切片生成.m3u8，前端原生<video src="xxx.m3u8">；iOS 完全友好，但首屏慢、拖动卡顿明显，且FFmpeg实时切片对 CPU 压力大
别忽略编码参数和 GOP 设置
转码不是“能播就行”，关键参数直接影响首帧时间和卡顿率：
- 强制 I 帧间隔（GOP）设为
2s（如-g 60对应 30fps），否则 HLS/FLV 首屏要等下一个 I 帧，可能卡住 5–10 秒 - 避免使用 B 帧（加
-bf 0），部分 WebRTC 解码器或 flv.js 在 B 帧丢包时容易花屏或崩溃 - 分辨率建议 ≤ 1280×720，H.264 编码用
baseline或mainprofile，避开highprofile —— iOS Safari 对 high profile 的硬解支持不稳定 - 音频务必转成
AAC-LC（-acodec aac -profile:a aac_low），不要用 G.711 或 OPUS 直推，flv.js和大多数 MSE 方案都不认
自建 vs 托管服务：CPU 和连接数是硬门槛
如果你打算用 FFmpeg 或 SRS 自建，得盯紧两个数字：
立即学习“前端免费学习笔记（深入）”；
- 单路 1080p RTSP 转 FLV，现代 CPU（如 i5-10400）约吃 15–25% 负载；若并发 20 路，别指望一台 4 核机器扛住
-
SRS的 WebRTC 模式默认每路流建一个UDP端口，NAT 网关或云厂商安全组容易拦截；而nginx-rtmp的 HLS 模式虽省资源，但每个 .ts 文件都会触发一次磁盘写，SSD 寿命和 IO 要评估 - 托管服务（如阿里云视频直播、腾讯云 LVB）省事，但 RTSP 推流通常要先走
RTMP中转（设备不支持 RTMP 就得加边缘盒子），且按转发时长计费，小规模项目容易比自建贵
真正难的不是选哪个方案，而是设备端能否稳定输出符合 Web 播放要求的原始码流——很多 IPC 厂家默认开的是 H.265 + B-frame + 长 GOP，连转码服务器都救不回来。
