HTML5无法直接播放RTSP，因RTSP依赖RTP而video标签仅支持HTTP流；必须通过服务端转流（如WebRTC）实现低延迟，其中WebRTC是唯一能稳定达300–800ms的方案。
HTML5 本身不支持 RTSP 协议，所谓“HTML5 播放 RTSP”实际是靠服务端转流（如转成 WebRTC、HLS 或 MSE 兼容格式）再由浏览器渲染——延迟高，根本原因不在前端代码，而在转流链路和协议选型。
为什么直接用 video 标签播 RTSP 一定失败
RTSP 是控制协议，依赖 RTP 传输音视频帧，而浏览器 <video> 只能消费 HTTP-based 流（如 MP4 片段、fMP4、WebRTC 数据包）。试图用 src="rtsp://..." 会直接报错或静默失败，常见错误信息：DOMException: The element has no supported sources。
实操建议：
- 检查浏览器控制台，确认是否真在尝试加载 RTSP URL —— 这属于配置错误，不是优化问题
- 不要用任何“RTSP to HTML5”类的纯前端 JS 库（如
rtsp-relay浏览器版），它们不可行且误导性强 - 确认服务端是否已部署转流服务（如
ffmpeg+nginx-rtmp、Janus、Mediasoup或商用 SDK）
WebRTC 是目前唯一能稳定做到 500ms 内延迟的方案
HLS 延迟通常 10–30 秒，DASH 约 5–15 秒，MSE 接 fMP4 流也难低于 3 秒；只有 WebRTC 将端到端延迟压到 300–800ms 成为可能，前提是整条链路按实时逻辑设计。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 服务端必须将 RTSP 拉流后，用 WebRTC SFU（如
Medooze、LiveKit）或 MCU（如Janus）转发，不能只做 RTP→HTTP 封装 - 客户端用
RTCPeerConnection接收，而非<video>直接 src —— 示例关键片段：const pc = new RTCPeerConnection({ iceServers: [] });<br>pc.addTransceiver('video', { direction: 'recvonly' }); - 禁用
RTCPeerConnection的自动带宽调节（setParameters中关闭remb和twcc若不需要），减少反馈延迟 - RTSP 拉流端（如 ffmpeg）加参数降低缓冲：
-fflags nobuffer -flags low_delay -vcodec libx264 -preset ultrafast -tune zerolatency
转 HLS/DASH 时如何把延迟压到最低（妥协方案）
若因架构限制无法上 WebRTC，只能走 HTTP 流，则必须放弃标准 HLS 推荐配置，主动打破兼容性换延迟。
实操建议：
- HLS 切片设为
2s（-hls_time 2），并启用-hls_flags low_latency（ffmpeg 4.4+） - 播放器必须支持 LL-HLS（如
hls.js@v1.3+），且初始化时开启：const hls = new Hls({<br> lowLatencyMode: true,<br> backBufferLength: 1,<br> maxMaxBufferLength: 1<br>}); - 禁用服务端/CDN 缓存（
Cache-Control: no-cache），避免 Nginx 或 Cloudflare 拦截 .m3u8/.ts 文件 - 避免使用
EXT-X-PROGRAM-DATE-TIME，它会触发播放器等待“真实时间对齐”，徒增 1–2 秒
容易被忽略的网络与设备层瓶颈
即使协议和参数全调优，局域网内仍卡顿？大概率是下述环节出了问题。
实操建议：
- RTSP 源（如 IPC 摄像头）自身编码延迟：查其 Web 管理页，关闭 “Smart Codec”、“IVS”、“ROI” 等智能编码功能，强制 H.264 baseline profile
- 服务端 CPU 不足会导致 ffmpeg 转码丢帧，用
top观察转流进程 %CPU 是否持续 >90%，超载时加-threads 1强制单线程保稳定 - 客户端浏览器硬件加速未生效：Chrome 地址栏输入
chrome://gpu，确认Video Decode显示Hardware accelerated，否则降级为软件解码，延迟翻倍 - 不要在 WebSocket 或 HTTP 长连接里“推送”裸 H.264 Annex-B 帧——没有时间戳、无 GOP 边界、无 SEI，
MediaSource会解析失败或花屏
真正压低延迟，从来不是改一个参数或换一个播放器的事。从 IPC 输出、服务端转流策略、信令交互方式，到浏览器解码路径，每一环都得按“实时”重新校准。WebRTC 不是可选项，是当前唯一经验证的可行路径；其它方案都是拿延迟换兼容性，且底线就在 2–3 秒左右，再往下就失稳。
