HTML5原生不支持RTSP协议,必须通过服务端转流为HLS或WebRTC等浏览器兼容格式;断流重连需前后端协同,HLS依赖hls.js重试机制,WebRTC需处理信令保活、SDP更新与ICE重启。
HTML5 原生不支持 RTSP 协议,所以所谓“HTML5 播放 RTSP”本质上是靠服务端转协议(如转成 WebRTC、HLS 或 MSE 兼容的格式),再由前端加载。断流重连不是前端单方面能解决的问题,必须前后端协同设计。
无法播放 RTSPRTSP 是会话控制协议,依赖 TCP/UDP 传输 RTP 包,而浏览器 标签只支持 HTTP(S) 资源(如 MP4、WebM)或 MSE(Media Source Extensions)喂入的 fragmented MP4/WebM 流,不解析 RTSP 握手、SETUP、PLAY 等指令。
DOMException: The element has no supported sources 或静音黑屏无报错src="rtsp://..." 就能播 —— 实际上所有现代浏览器都会忽略该 URL 并静默失败主流方案只有两类,选型取决于延迟容忍度和部署能力:

.ts + .m3u8,前端用 + hls.js;重连靠 hls.js 的 retryDelay 和 maxMaxBufferLength 控制,但首屏慢(通常 >10s)、断流后恢复至少 2–3 个切片周期RTCPeerConnection 接收;重连需监听 iceConnectionState 变为 "disconnected" 或 "failed" 后触发 createOffer + setLocalDescription 再发信令WebRTC 延迟低(
hls.js 断流自动重连实操要点若选 HLS,hls.js 是目前最稳定的 MSE 封装库,但默认配置对弱网不友好,需手动调优:
enableStreaming: true、autoStartLoad: true
retryDelay: 1(单位秒),避免卡死在 ERROR 状态不恢复maxMaxBufferLength: 3(秒),防止断流后积压旧分片拖慢重连hls.on(Hls.Events.ERROR, (e, data) => { if (data.fatal) hls.destroy(); hls.loadSource(...); })
loadSource() 必须在 destroy() 后重新初始化实例,不能复用老实例调 loadSource()
示例片段:
const hls = new Hls({ retryDelay: 1, maxMaxBufferLength: 3 });
hls.loadSource('http://server/live/stream.m3u8');
hls.on(Hls.Events.ERROR, (e, data) => {
if (data.fatal && (data.type === 'networkError' || data.type === 'mediaError')) {
hls.destroy();
setTimeout(() => initHls(), 500);
}
});
WebRTC 表面是“点对点”,实际依赖服务端中继和信令,重连失败常因以下细节:
iceConnectionState 可能长期卡在 "checking";需监听 ws.onclose 并主动重连信令offer,服务端可能拒绝;每次重连必须调 createOffer({offerToReceiveVideo: true})
restartIce() 不够,需先 removeTrack() 再 addTrack() 触发新候选收集RTCPeerConnection 会冻结 ICE,唤醒后需手动 restartIce() 并检查 iceGatheringState
真正健壮的重连不是“断了再连”,而是提前探测连接质量(如统计 getStats() 中的 packetsLost、jitter),在恶化到断流前就主动重建连接。