HTML5 iOS播放RTSP实现要点

HTML5在iOS上根本无法原生播放RTSP流，这不是简单的兼容性问题，而是协议层面的硬性缺失——RTSP依赖RTP/UDP传输，而iOS Safari只支持基于HTTP的媒体格式（如HLS），且严格限制底层音视频操作；目前真正可行的方案仅有三种：服务端用FFmpeg或GStreamer实时转封装为低延迟HLS、通过Janus等WebRTC网关将RTSP转为iOS 16.4+支持的H.264 over WebRTC流，或彻底放弃网页方案、采用AVFoundation/FFmpeg开发原生iOS App以实现安防级低延迟播放——任何试图纯前端JS解析RTSP的尝试都注定失败。

HTML5 原生不支持 RTSP，iOS 上更不可能直接用 播 RTSP 流。这不是兼容性问题，而是协议层根本缺失——RTSP 是控制协议，依赖 RTP/UDP 传输，而 HTML5 只认 HLS、DASH、MP4 等基于 HTTP 的媒体格式。

为什么 iOS + RTSP 特别难搞

iOS 的限制比安卓更硬：

• WebRTC 在 Safari 中长期不支持接收裸 RTP 包（iOS 16.4+ 才开始有限支持 RTCPeerConnection 接收，但需服务端转成 VP8/VP9/H.264 over WebRTC，且不兼容传统 RTSP 设备）
• Safari 禁止 XMLHttpRequest 或 fetch 读取二进制流后手动解包（无法像桌面 Chrome 那样靠 MediaSource Extensions + 解码器 JS 库拼凑播放）
• 没有 getUserMedia 以外的底层音视频帧注入接口，Canvas 渲染 H.264 帧在 iOS Safari 上性能极差甚至崩溃

可行路径只有两条：服务端转封装 or 客户端绕过浏览器

真正落地的方案只有这些，别试“纯前端 JS 解 RTSP”：

• 服务端转 HLS：用 ffmpeg 或 GStreamer 拉取 rtsp://xxx，实时转成 HLS（.m3u8 + .ts 分片），再由 iOS 加载。注意：ffmpeg 要加 -hls_time 2 -hls_list_size 3 控制延迟，否则首屏 >10s
• WebRTC 网关中转：用 Janus、Medooze 或 Wowza 接入 RTSP 源，暴露为 WebRTC 端点；前端调用 RTCPeerConnection 连接（iOS 16.4+ Safari 支持）。关键点：offer/answer 必须协商 H.264，禁用 VP8（iOS 不支持 VP8 解码）
• 放弃 Web，改用原生 App：iOS App 可用 AVFoundation 直接播 RTSP（通过 AVPlayerItem + 自定义 AVURLAsset 协议处理），或集成 FFmpeg + VideoToolbox 硬解。这是唯一能接近安防级低延迟（

常见错误和坑点

很多人卡在看似“能连上”的假象里：

• 用 curl rtsp://... 能收到响应 ≠ 浏览器能播——那只是 TCP 握手成功，不代表媒体流可被 HTML5 消费
• 误以为 hls.js 能播 RTSP：它只处理 HLS，你得先有 .m3u8，不是把 rtsp:// 地址丢给它
• 在 iOS 上测试 WebRTC 方案时忽略证书：Safari 强制要求 https:// + 有效 TLS 证书，localhost 或自签名证书会静默失败
• 用 ffmpeg -i rtsp://x -c copy -f hls ... 直推 HLS，但源流是 H.265 —— iOS Safari 不支持 HEVC over HLS，必须加 -c:v libx264 转码

真正在 iOS 上跑通 RTSP 播放，核心不在前端写多少 JS，而在服务端是否稳定输出 Safari 认的格式，以及是否接受 2~5 秒的合理延迟。想压到 1 秒以内？别碰浏览器，原生走起。

到这里，我们也就讲完了《HTML5 iOS播放RTSP实现要点》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！