HTML5不支持RTSP及RTSPS，需通过WebRTC（如mediasoup）转协议并用SRTP加密传输，或MSE+HTTPS分片推送；RTSPS和WebSocket手动封装均不可行，安全关键在信令与媒体面分离、密钥动态协商、凭据不落盘。
HTML5 本身不支持 RTSP，更不支持 RTSP 加密传输
直接在 标签里写 src="rtsp://..." 是无效的——所有主流浏览器（Chrome、Firefox、Safari、Edge）均未实现 RTSP 协议栈。所谓“HTML5 播放 RTSP”本质是绕过浏览器原生能力，靠中间服务转协议。加密不是加个 HTTPS 就行，RTSP 本身没有 TLS 原生封装（rtsps:// 极少被客户端支持，且需服务端完整 TLS 握手 + 证书管理），实际落地必须拆解为“传输加密”和“流内容保护”两层。
用 WebRTC 中转是最可行的加密路径
把 RTSP 流喂给 WebRTC 信令服务器（如 mediasoup、Janus 或 LiveKit），由其拉流、解码、再以 SRTP 封装推给前端 RTCPeerConnection。SRTP 默认启用 AES-128 加密，密钥通过 DTLS-SRTP 在信令阶段协商，全程不暴露明文音视频帧。
-
mediasoup需配置enableSrtp: true，并确保 worker 启动时加载 OpenSSL 支持 - 前端
RTCPeerConnection不用手动处理密钥，但必须禁用不安全选项：iceTransportPolicy: "all"+bundlePolicy: "max-bundle" - 避免把 RTSP URL 直接暴露在前端 JS 里；鉴权应放在信令层（例如 WebSocket 连接前校验 JWT）
用 MSE + 转码服务（如 FFmpeg + Node.js）也能加密，但链路更长
用 ffmpeg 拉 rtsp:// 流，实时转成 fragmented MP4（-f mp4 -movflags +frag_keyframe+empty_moov），再通过 HTTPS 接口分片推送，前端用 MediaSource + fetch() 拼接。此时加密靠 HTTPS 传输层保护，但要注意：
- FFmpeg 拉流过程本身不加密——RTSP 用户名密码若明文写在命令里（如
rtsp://user:pass@ip/），会被进程列表泄露；应改用-rtsp_transport tcp+ 环境变量传凭据 - 分片接口必须带鉴权（如
Authorization: Bearer xxx），否则 HTTPS 仅防窃听，不防未授权访问 - 延迟比 WebRTC 高（通常 2–5 秒），不适合实时交互场景
别碰 rtsps:// 和自研 WebSocket 封装
rtsps:// 虽然 RFC 定义了，但 Chrome 早在 2017 年就移除了实验性支持；Firefox 从未实现；Safari 无任何计划。而用 WebSocket 手动转发 RTP 包，等于重造 WebRTC 轮子：你得自己处理 NTP 时间戳对齐、丢包重传（NACK）、Jitter Buffer、SSRC 冲突，还无法利用浏览器内置的 SRTP 加密。实际项目中，99% 的“WebSocket RTSP 播放器”最终都因音画不同步或卡顿放弃。
立即学习“前端免费学习笔记（深入）”；
真正要安全，重点不在协议名带不带 “s”，而在控制面（信令）和媒体面（SRTP/HTTPS）是否分离、密钥是否动态协商、凭据是否不落盘——这些细节比选什么协议更容易被忽略。
