跨设备摄像头串流 让你在一台设备的浏览器里实时看到另一台设备的摄像头画面：一端打开页面生成二维码 → 另一端扫码并授权摄像头 → 画面直接通过 WebRTC P2P 推送过去。接收端和推流端可以是手机或电脑任意组合（手机↔PC、PC↔PC、手机↔手机都行），整个过程不需要安装任何 App，浏览器原生 API 一把梭。
┌──────────────┐ ①扫码 ┌──────────────┐
│ 接收端浏览器 │ ◀──────────│ 推流端浏览器 │
│ (PC 或手机) │ │ (手机或 PC) │
└──────────────┘ └──────────────┘
▲ ▲
│ ②交换会话信息（SDP/ICE） │
│ 仅元数据，不含画面 │
│ │
└──── PeerJS 公开 broker ───┘
③ WebRTC P2P 直连
接收端 ◀═══════════════════════ 推流端
视频流，不经服务器| 项目 | 是否经过第三方 |
|---|---|
| 视频画面 | ❌ 不经过 |
| 音频（本工具未启用） | — |
| 会话协商元数据（SDP / ICE） | ✅ PeerJS 公开 broker |
| 公网地址探测 | ✅ Google STUN |
如果对会话协商也敏感，可以自部署 PeerJS server（开源 peer 包），但本静态网页无法直接配置，需要自行 fork 修改。
不会。视频流通过 WebRTC P2P 直连从手机直接传到 PC 浏览器，中间不经过我们或任何第三方服务器。仅在"建立连接"阶段会通过 PeerJS 公开 broker 交换会话信息（SDP / ICE），交换的内容是连接元数据，不包含画面。
本工具未配置 TURN 中继，仅依赖 STUN 做 NAT 穿透。两端处于不同运营商、对称型 NAT、或办公网严格防火墙时，P2P 可能失败，表现为长时间"协商中…"。推荐让两端连接同一 WiFi，直连成功率最高、延迟最低。若你愿意自部署 coturn 或接 Cloudflare Realtime TURN，把 ICE_SERVERS 加一条即可。
不能。本工具只在浏览器内显示画面，做不到让操作系统把它识别为摄像头设备。要做到这一点必须装系统级虚拟摄像头驱动（比如 DroidCam、Iriun 提供的 PC 客户端），这是浏览器沙箱无法触及的。但 OBS 可以通过"窗口捕获"或"浏览器源"读取本页面的画面，再通过 OBS 虚拟摄像头喂给会议软件，能间接实现类似效果。
这不是 iOS Safari 的特殊行为——所有现代浏览器（Chrome / Edge / Firefox / Safari）的 getUserMedia 都要求 secure context，只有 HTTPS、localhost 或 127.0.0.1 才放行；HTTP + 局域网 IP 一律被拒，且 navigator.mediaDevices 会被设为 undefined。本站部署在 HTTPS 上，扫码访问正常使用不会遇到这个问题。仅在本地 pnpm dev + 手机访问 LAN IP 时会出现，解决办法是用 ngrok / cloudflared 把开发服务器套一层 HTTPS。
不会。连接成功后会出现"切换前后摄像头"按钮，内部使用 WebRTC 的 RTCRtpSender.replaceTrack() 替换视频轨，会话不重建，体感是画面短暂卡一帧后切换到另一个镜头。
同一 WiFi 下端到端延迟通常在 100-300 ms 之间，比常规视频会议低（不经过中间服务器）。隔多层路由器或走 ICE relay 候选时可能升到 500 ms+。推流端可选 480p / 720p / 1080p / 4K 四档画质，码率会自适应，弱网下浏览器自动降帧降清晰度。