html5播放rtsp怎么转码_html5将rtsp转hls或webrtc【步骤】

HTML5不支持RTSP协议，必须通过服务端转流为HLS或WebRTC等浏览器兼容格式；HLS延迟高（10–30秒）但兼容性好，WebRTC延迟低但部署复杂。

HTML5 本身不支持 RTSP，必须靠服务端转流

浏览器原生 标签根本不认识 rtsp:// 协议，这不是前端能“加个库”绕过去的限制，而是协议层彻底不兼容。RTSP 是控制协议（带 SETUP/PLAY），而 HTML5 只接受基于 HTTP 的流（如 HLS、MPEG-DASH）或 WebRTC 的信令+数据通道。所以所有“HTML5 播放 RTSP”的方案，本质都是：先用服务端把 RTSP 流转成浏览器能吃的格式，再让前端加载。

选 HLS 还是 WebRTC？看延迟和兼容性需求

HLS 延迟高（通常 10–30 秒），但兼容性极好（Safari、Chrome、Android WebView 全支持），部署简单；WebRTC 延迟低（RTCPeerConnection 的 H.264 支持不稳定，Android 旧版 WebView 也不一定支持。

• 监控大屏、非实时回看 → 优先选 HLS，用 ffmpeg + nginx-http-flv-module 或 gstreamer 推 HLS
• 对讲、远程操控、需要音视频同步交互 → 必须上 WebRTC，推荐用 Janus Gateway 或 Mediasoup 接入 RTSP 源
• 别信“纯前端 JS 解码 RTSP”的方案——rtsp-relay、hls.js 加 ffmpeg.wasm 都扛不住持续视频帧，CPU 爆表且卡顿严重

用 FFmpeg 转 RTSP 到 HLS 的最小可行命令

这是最轻量、调试最快的起步方式，适合测试和小规模部署：

ffmpeg -i "rtsp://admin:password@192.168.1.100:554/stream1" \
  -c:v libx264 -c:a aac \
  -f hls \
  -hls_time 2 \
  -hls_list_size 3 \
  -hls_flags delete_segments \
  /var/www/html/live/stream.m3u8

注意几个关键点：

立即学习“前端免费学习笔记（深入）”；

• -hls_time 2：每个 ts 片段 2 秒，太小会增加 HTTP 请求压力，太大延迟更高
• 输出路径必须是 Web 服务器可读的静态目录（如 Nginx

  

  的 root），前端用
• 如果 RTSP 源有鉴权，确保 URL 中的用户名密码正确，否则 ffmpeg 日志会卡在 Authentication failed
• 某些 IPC 摄像头只支持 TCP 回传 RTSP，需加 -rtsp_transport tcp 参数

WebRTC 方案里最容易被忽略的三件事

用 Janus 或 Mediasoup 接 RTSP 后，前端看似只是调 new RTCPeerConnection()，但实际卡点都在服务端和网络配置上：

• RTSP 源必须是 H.264 baseline 或 main profile —— 很多海康/大华默认用 high profile，WebRTC 解码器不认，会黑屏无报错
• Janus 的 videoroom 插件默认不拉流 RTSP，要启用 rtsp 插件并配 rtsp_url 和 rtsp_user/rtsp_pwd
• 内网部署时，ice_servers 如果只写 stun:stun.l.google.com:19302，公网用户可能无法连通，必须配好自己的 TURN 服务，或至少 fallback 到 iceTransportPolicy: "relay"

真正跑通前，先用 ffplay rtsp://... 和 curl http://your-hls-domain/live/stream.m3u8 确认源和转流都活，再动 WebRTC。一步跨太多，问题根本分不清是推流断了、信令没通，还是 SDP 交换失败。