HTML5 浏览器原生不支持 RTSP，无法直接播放；日志中不会出现 RTSP 请求，所谓“RTSP 日志”实为第三方转流服务（如 flv.js、hls.js 或 WebRTC）产生，调试需聚焦服务端与前端 SDK 日志。
HTML5 无法直接播放 RTSP，日志里根本不会出现 RTSP 请求
浏览器原生不支持 RTSP 协议， 标签传 rtsp:// 地址会直接失败，控制台通常只报 DOMException: The element has no supported sources 或静默无反应。所谓“HTML5 播放 RTSP 日志”，实际是前端调用的第三方 WebRTC/WS 转发服务（如 ffmpeg.wasm、flv.js + 后端转流、hls.js + 转 HLS）产生的日志，不是浏览器自身行为。
调试重点在转流服务端和前端 JS SDK 的日志输出
常见方案的日志抓取路径如下：
- 若用
flv.js播放ws://xxx/flv：打开浏览器开发者工具 → Console 标签页，确保勾选Verbose；flv.js默认开启enableWorker: false时，所有日志（如[FLV] Received metadata、[Transmuxer] Demux error）都在主页面 Console 输出 - 若用
hls.js播放http://xxx/xxx.m3u8：启用debug: true配置项，关键日志包括Hls.js: attachMedia、bufferStalledError、manifestLoadingStart - 若用自研 WebSocket 接收 H.264 Annex-B 帧并用
MediaSource拼接：需手动在onmessage和sourceBuffer.appendBuffer()前后加console.log()，例如记录帧长度、appendWindowStart值、sourceBuffer.updating状态
chrome://webrtc-internals 只对 WebRTC 有效，对纯 HTTP/WS 播放无用
该页面能查到 SDP 协商、ICE 连接、音视频统计等真实 WebRTC 流程日志，但前提是你的方案真正在用 RTCPeerConnection。如果只是把 RTSP 用 ffmpeg 转成 FLV 再走 WebSocket 推送，这里什么都不会显示——它压根没参与通信。
- 确认是否真走 WebRTC：检查 JS 是否创建了
new RTCPeerConnection()，是否有addTrack()或setRemoteDescription()调用 - 若用了
adapter.js，注意它可能屏蔽部分错误，建议临时移除再试 - WebRTC 日志中高频错误：
Failed to set remote offer sdp: Session description object has invalid type.（SDP 类型写错）、ICE connection state is failed（NAT/防火墙阻断）
服务端日志比前端更关键，尤其转流失败时
前端看到的往往是“黑屏”或“加载中”，真正原因常藏在服务端。比如用 ffmpeg 转 RTSP 到 FLV：
立即学习“前端免费学习笔记（深入）”；
- 启动命令必须加
-loglevel verbose，否则默认只输出 warning 级别 - 典型失败日志：
Could not connect to server（RTSP 地址不可达）、Invalid data found when processing input（编码格式不支持，如 H.265 未编译进 ffmpeg）、Connection timed out（超时参数未设，加-stimeout 5000000） - 若用 Node.js 的
child_process.spawn()启动 ffmpeg，务必监听stderr流，而不是只看exit事件
转流链路越长（RTSP → ffmpeg → WebSocket → flv.js），日志分散点就越多，漏看任意一环都可能卡在“不知道哪坏了”。最省事的验证方式：用 ffplay rtsp://xxx 先在本地确认源可用，再逐段查日志。
