HTML5原生不支持RTSP协议,video标签无法直接播放rtsp://地址;需服务端转为HLS或MSE兼容格式,前端用hls.js等库加载后controls才生效。

HTML5 原生不支持 RTSP 协议, 标签无法直接播放 rtsp:// 地址,所谓“加控制条”或“添加控件”是建立在能播放的前提上的——而这个前提本身就不成立。
为什么 不能播 RTSP
RTSP 是一个基于 TCP/UDP 的会话控制协议,不传输音视频帧数据本身;它需要配合 RTP/RTCP 才能完成媒体流传输。而 HTML5 只支持解码 MP4、WebM、Ogg 等封装格式,且仅通过 HTTP(S) 加载(如 src="http://.../video.mp4")。浏览器内核根本没实现 RTSP 客户端栈。
常见错误现象:DOMException: The element has no supported sources 或静音黑屏无报错。
- RTSP 流必须先被转成 HLS(
.m3u8)或 MSE 兼容的格式(如 fragmented MP4 +MediaSource) - 转流一般由服务端完成(如用
ffmpeg、gstreamer、EasyDarwin、Node-Media-Server) - 前端只负责播放转换后的 HTTP 资源,此时控制条才起作用
用 FFmpeg 转 RTSP 为 HLS 的最小可行命令
这是最常落地的方案:服务端拉流、切片、生成 .m3u8,前端用 + hls.js 播放。
立即学习“前端免费学习笔记(深入)”;
示例命令(需安装 ffmpeg):
ffmpeg -i "rtsp://192.168.1.100:554/stream" \ -c:v libx264 -c:a aac \ -f hls \ -hls_time 2 \ -hls_list_size 5 \ -hls_flags delete_segments \ /var/www/html/live/stream.m3u8
关键点:
-
-hls_time越小延迟越低,但太小(如0.5)会显著增加 HTTP 请求数和服务器压力 - 生成的
stream.m3u8必须可通过 HTTP 访问(如https://yourdomain.com/live/stream.m3u8) - 前端需引入
hls.js,因为 Safari 以外的浏览器原生不支持 HLS
前端播放 HLS 并启用原生控制条
只要资源可访问、格式合法, 的 controls 属性就能正常工作——但前提是用 hls.js 加载,而不是直接赋值 src。
正确写法:
注意:
- 不要写
—— 这样hls.js不会接管,直接失败 -
controls属性对 HLS 有效,但拖动进度条依赖服务端是否支持 HTTP Range 请求(HLS 切片需可随机访问) - 移动端 iOS Safari 可直接播
.m3u8,但 Android 原生 WebView 多数不支持,仍需hls.js
替代方案:WebRTC(低延迟场景)
如果 RTSP 源延迟要求严苛(
- 需信令服务器(WebSocket)+ SFU(如
mediasoup、janus-gateway) - RTSP 流需由服务端用
gstreamer或ffmpeg推送到 WebRTC 服务器 - 前端用
RTCPeerConnection接收,显示,控制条要自己实现(原生controls不支持 WebRTC 流的播放/暂停语义) - 没有服务端配合,纯前端无法把 RTSP 转成 WebRTC
真正卡住的地方从来不是“怎么加控制条”,而是“谁来把 RTSP 变成浏览器能啃的东西”——这个环节漏掉,后面所有 DOM 操作都是空转。










