HTML5无法直接播放RTSP流，必须经后端转为HLS或WebRTC等浏览器支持格式；花屏主因是转封装关键帧丢失、PTS/DTS错乱、HLS切片不规范或编码不兼容。
HTML5 本身不支持直接播放 RTSP 流，所谓“花屏”根本不是解码或渲染问题，而是整个链路没走通——你看到的压根不是真正的 RTSP 解码画面，而是转封装/转协议过程出错导致的帧损坏或同步失败。
为什么 HTML5 页面放 RTSP 一定会花屏或黑屏
浏览器（Chrome/Firefox/Safari）的 标签只支持 MP4、WebM、Ogg 等基于 HTTP 的媒体格式，不识别 rtsp:// 协议。所谓“播放 RTSP”，实际依赖后端服务（如 FFmpeg + WebSocket + WebRTC 或 HLS 转发）把 RTSP 流转成浏览器能吃的格式。花屏通常意味着：
- 转封装时关键帧（IDR）丢失或 PTS/DTS 错乱 → 导致解码器无法重建图像
- HLS 切片（
.ts）生成不规范，#EXT-X-DISCONTINUITY缺失 → 播放器误判帧序列 - WebRTC 中
RTCP feedback未启用或丢包重传（NACK/PLI）配置错误 → 关键帧请求失败 - 编码参数不兼容：RTSP 源用 H.265（HEVC），但浏览器不支持（仅 Safari 有限支持），强行推送导致解析崩溃
用 FFmpeg 转 HLS 时避免花屏的关键参数
如果你用 ffmpeg 把 RTSP 转成 HLS（.m3u8 + .ts），默认参数极易花屏。必须显式控制 GOP、关键帧对齐和时间基：
- 强制 I 帧间隔与 HLS 切片对齐：
-g 50 -keyint_min 50（假设帧率 25fps，即每 2 秒一个关键帧） - 禁用 B 帧（B-frame 会导致 DTS/PTS 混乱）：
-bf 0 - 固定时间基并压制音视频同步漂移：
-vsync cfr -copyts -avoid_negative_ts make_zero - 指定编码器为兼容性最好的 H.264 baseline profile：
-c:v libx264 -profile:v baseline -level 3.0 - 务必加
-hls_flags +independent_segments+discont_start，否则切片间无断点标记，容易卡在旧 GOP
典型命令片段：
ffmpeg -i rtsp://192.168.1.100:554/stream -c:v libx264 -profile:v baseline -level 3.0 -g 50 -keyint_min 50 -bf 0 -vsync cfr -c:a aac -b:a 64k -hls_time 2 -hls_list_size 5 -hls_flags +independent_segments+discont_start stream.m3u8
立即学习“前端免费学习笔记（深入）”；
WebRTC 方案中花屏的快速定位点
若走 WebRTC（比如用 mediasoup、Janus 或自建 SFU），花屏大概率是 SDP 协商或 RTP 包处理异常：
- 检查 SDP 中
fmtp行是否包含完整 H.264 级别信息，例如：a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f—— 缺少profile-level-id会导致 Chrome 解码器拒绝初始化 - 确认 STUN/TURN 配置正确，NAT 后设备无法收发 RTCP PLI 请求 → 关键帧无法按需重发 → 长时间花屏后才恢复
- 服务端未正确处理
RTCP NACK反馈，或丢包率 >5% 时未触发 FIR（Full Intra Request）→ 解码器持续使用错误参考帧 -
前端
RTCPeerConnection创建时未设置offerToReceiveVideo: true，或addTransceiver未指定direction: "recvonly"→ 视频轨道静默但无报错
真正能跑通的最小可行路径
不要试图让浏览器直连 RTSP。验证是否真通，只看三件事：
- 用
ffplay rtsp://...能否本地稳定播放（排除摄像头流本身问题） -
curl
http://your-server/stream.m3u8能否拿到可读的 m3u8 文件，且其中.tsURL 能逐个 curl 下来（排除 HTTP 服务或路径权限问题） - 打开 Chrome DevTools → Network 标签，过滤
media，观察是否持续加载.ts文件、有无 404/416 错误、响应体是否为二进制 TS 数据（而非 HTML 错误页）
只要其中一环断了，后续所有“花屏修复”都是空谈。很多团队卡在第一步：以为 FFmpeg 进程起来了就算转起来了，其实日志里早写了 Unable to parse option value "baseline" —— 参数拼错，却一直往播放器里塞损坏的 ts。
