HTML5原生不支持RTSP，flv.js仅能播放HTTP-FLV流；需经流媒体服务器（如SRS、nginx-http-flv-module）将RTSP转为H.264/AAC编码的FLV格式，并禁用B帧、设置正确MIME类型及flv.js参数方可稳定播放。
HTML5 原生不支持 RTSP，flv.js 也不支持直接播 RTSP 流——必须先将 RTSP 转成 FLV 格式（通常是通过 HTTP-FLV 协议推送），再由 flv.js 播放。这不是“HTML5 播 RTSP”，而是“前端播转封装后的 FLV 流”。
为什么不能直接用 flv.js 接 RTSP 地址
flv.js 只能消费符合 FLV 封装规范、并通过 HTTP 长连接（或 WebSocket）逐段传输的流数据，它不解析 RTSP 协议，也不处理 RTP 包。RTSP 是控制协议，实际音视频载荷在 RTP 中，且通常带时间戳、序列号、NALU 分包等，flv.js 完全无法识别。
- 常见错误现象：
NetStream.Play.StreamNotFound或控制台报Uncaught (in promise) Error: Unsupported video codec - 即使强行把
rtsp://xxx塞进flvPlayer.play()，也会立刻失败，因为底层 fetch/XHR 根本发不出 RTSP 请求 - 浏览器本身禁止 RTSP 协议的跨域请求，连握手都过不去
可行链路：RTSP → 推流服务 → HTTP-FLV → flv.js
核心是中间加一层流媒体服务器做协议转换和封装。主流选择有 nginx-http-flv-module、SRS、EasyDarwin（需插件）或 FFmpeg + node-media-server 组合。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 典型流程：
ffmpeg -i rtsp://192.168.1.100:554/stream -c:v copy -c:a aac -f flv http://127.0.0.1:8080/live/test.flv - 更稳定做法：用 SRS 接入 RTSP（配置
ingest），再开启 HTTP-FLV 输出，前端访问http://srs-ip:8080/live/test.flv - 注意 FLV 的关键要求：视频编码需为 H.264（AVC），音频为 AAC；H.265（HEVC）不被
flv.js支持 - 务必关闭 B-frame（
-vsync cfr -x264opts no-b-adapt=1:bframes=0），否则flv.js解码易卡顿或花屏
前端播放时容易忽略的细节
flv.js 对 HTTP-FLV 流的格式、延迟、错误恢复非常敏感，很多“播不出”问题其实出在服务端输出或初始化参数上。
立即学习“前端免费学习笔记（深入）”；
- 必须设置
enableWorker: true和enableStashBuffer: false（低延迟场景），否则首帧等待过长 - 若服务端未返回正确的
Content-Type: video/x-flv，部分浏览器会拒绝解析，建议 Nginx/SRS 显式配置 MIME 类型 - 不要依赖自动重连：需监听
player.on('error', ...)并手动调用player.unload(); player.load(); player.play(); - 移动端 iOS Safari 不支持 HTTP-FLV（无 MSE 支持），必须 fallback 到 HLS（需服务端同时输出
.m3u8）
真正难的不是写几行 flv.js 初始化代码，而是确保 RTSP 源稳定、转封装无丢帧、HTTP-FLV 流头合法、时间戳连续、B-frame 被禁用——任何一个环节断掉，前端就黑屏或报错。调试时优先抓包看 HTTP 响应体是否以 FLV\001\001 开头，再查 flv.js 日志里的 onMediaInfo 是否触发。
