HTML5原生不支持RTSP，卡顿主因是转流环节；HLS切片过大会延迟高，WebRTC可低至300ms但需信令服务器；前端未配preload、autoplay/muted或缺hls.js均致卡顿；局域网推荐FFmpeg推RTMP+nginx-rtmp+WebRTC方案。
HTML5 本身不支持 RTSP，卡顿是必然结果
浏览器原生 标签只支持 MP4、WebM、Ogg 等 HTTP 流（如 HLS、DASH），rtsp:// 协议无法直接加载。所谓“HTML5 播放 RTSP”实际是靠中间服务转协议，卡顿根源往往不在前端代码，而在转流环节。
常见转流方案中影响卡顿的关键参数
主流做法是用 FFmpeg 或 GStreamer 将 RTSP 转成 HLS（.m3u8）或 WebRTC（offer/answer）。不同方案延迟与卡顿表现差异极大：
- HLS 默认切片 10s，
-hls_time 2可压到 2s，但太小会增加 HTTP 请求压力和首屏耗时 - WebRTC 延迟可压到 300ms 内，但需部署信令服务器 + STUN/TURN，且 FFmpeg 推流端必须加
-vf "setpts=PTS-STARTPTS"对齐音画 - Nginx + nginx-rtmp-module 转 HLS 时，若未配置
hls_fragment 2s和hls_playlist_length 6s，播放器会频繁等待新切片，表现为间歇性卡顿
前端
即使后端转流正常，前端配置不当也会加剧卡顿：
- 没加
preload="none"：浏览器可能预加载大量 HLS 切片，拖慢首帧，尤其弱网下更明显 - 没设
autoplay+muted：Chrome 70+ 会阻止有声音的自动播放，导致play()被挂起，画面冻结 - 用
src直接赋值 HLS 地址但未引入hls.js：Safari 可能勉强播，Chrome 完全黑屏，错误信息是DOMException: The element has no supported sources -
hls.js实例未监听hls.on(Hls.Events.ERROR, ...)：网络抖动时静默失败，看起来就是“卡住不动”，实际是加载中断未重试
真正在浏览器里“不卡”的最低成本路径
如果设备 RTSP 码率稳定在 2Mbps 以下、局域网部署，推荐这条链路：
立即学习“前端免费学习笔记（深入）”；
- 用
ffmpeg -i rtsp://... -c:v libx264 -preset ultrafast -tune zerolatency -b:v 1500k -f flv rtmp://127.0.0.1/live/stream推到本地 Nginx-RTMP - Nginx 配置
application live { allow publish 127.0.0.1; allow play all; }并开启exec_push启动 WebRTC 转发（如用webrtc-streamer） - 前端用
webrtc-streamer提供的index.html页面，它内置了自动重连和 JitterBuffer 控制，比纯 HLS 更抗丢包
跨公网或高并发场景，WebRTC 的 SDP 交换和 ICE 连接建立失败率会上升，这时候卡顿就不是前端能调出来的了——得查 STUN 是否可达、TURN 是否启用、UDP 端口是否被运营商封锁。
