远程软件
192513dd2a
问题 H.264 的 P 帧依赖前一帧的参考图像。主控端的积压跳帧逻辑（读出但不解码） 会切断参考链，此后所有 P 帧都解不出来，且不会自行恢复——必须收到 IDR。 旧实现跳帧后只是 continue，后续 P 帧仍被送进 decoder，导致： - 每帧解码失败一次 → stderr 刷屏「decode failed」 - 每次失败都触发一次 KeyFrameReq → 请求风暴 - 解码器反复在错误状态里挣扎 实测（修复前，10 秒会话）：decode failed 刷屏数十条。 修复 引入 awaiting_idr 状态，语义是「参考链已断，等 IDR 重新同步」： - 跳帧时置位，并请求关键帧 - 置位期间跳过所有 P 帧（这是正确性要求，不是优化） - 收到 hdr.keyframe=true 的帧才清位并恢复解码 - 解码出错时也置位 - 初始值为 true：入会时已发 KeyFrameReq，拿到第一个 IDR 前不该硬解 该实现依赖协议 v2 新增的 hdr.keyframe 字段（从实际码流 NAL 类型判定）， 因此必须在协议改动之后合入。 HUD 新增 STATE 行显示 OK / RECOVER。RECOVER 期间画面冻结是**预期行为**， 没有这个指示用户会误以为软件卡死。 验证（同机 agent+viewer，25 秒） - decode failed：0 次（修复前刷屏） - stderr 总行数：3（仅首帧日志 + 2 条积压提示） - 窗口稳定无假死 已知局限（下一步） 本修复解决的是「跳帧后不再做无用功」，但跳帧本身仍会造成画面冻结直到 IDR 到达。NVENC 的 gop_len=240、@60fps 即 4 秒才有一个自动 IDR，恢复窗口 偏长。缩短 GOP 或降低跳帧触发频率是后续优化项。 |
||
|---|---|---|
| .cargo | ||
| agent | ||
| agent-core | ||
| common | ||
| linux-agent | ||
| scripts | ||
| tools | ||
| vendor/nvenc | ||
| viewer | ||
| .gitattributes | ||
| .gitignore | ||
| B侧设计文档.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Git协作规范.md | ||
| README.md | ||
| 借鉴映射与落地规范.md | ||
| 多平台架构设计.md | ||
| 打洞与信令设计.md | ||
| 打洞验证记录.md | ||
| 构建运行手册.md | ||
mvp-remote
自研远程桌面控制软件（办公场景），技术路线参考网易 UU 远程逆向分析结论。
架构
| Crate | 角色 | 说明 |
|---|---|---|
common |
协议库 | 控制消息 / 视频帧线格式，三端共享契约 |
agent |
被控端 | DXGI 屏幕采集 + openh264(H.264) 编码 + QUIC 服务 + SendInput 键鼠注入 |
viewer |
主控端 | QUIC 客户端 + openh264 解码 + minifb 渲染 + 键鼠采集 + 延迟 HUD |
构建
cargo build --release
产物：target/release/agent.exe（被控端）、viewer.exe（主控端），需附带 3 个 mingw 运行库 DLL（libstdc++-6 / libgcc_s_seh-1 / libwinpthread-1）。
运行
# 被控机
agent.exe --port 47800 --code 123456
# 主控机
viewer.exe --addr <被控机IP> --port 47800 --code 123456
详见《构建运行手册.md》、《Git协作规范.md》与《打洞与信令设计.md》。