远程软件
6e83bda8b8
背景 协议 v2 与 vendor nvenc 补丁之后，KeyFrameReq 已成为**真正生效**的恢复主路径 （此前 NVENC 缺 FORCEIDR 标志，请求被静默忽略）。因此周期 IDR 的角色变了： 从「唯一恢复手段」降级为「兜底手段」，只用于防「请求连续丢失」这种极端情况。 既然是兜底，就没必要配得那么长。 问题：三处周期不一致，且都过长 - agent/src/capture.rs NVENC：gop_len = 240 帧 @60fps = 4 秒 - agent/src/capture.rs 软编： intra_period = 300 帧 @60fps = 5 秒 - agent-core/src/lib.rs Linux： intra_period = 300 帧 @30fps = **10 秒** 同一产品在三种编码后端上的恢复等待时间差 2.5 倍，且 Linux 端最差。 改动 - 新增 agent/src/capture.rs::INTRA_PERIOD_FRAMES = 60（Windows 两个编码器共用） - agent-core 的 EncoderSettings::default() 改为按 max_fps 推导（1 秒对应帧数）， 避免以后调帧率时周期又漂移 代价 IDR 是整帧内编码，实测一次约 95-120KB，而 P 帧约 3-10KB。1 秒一次 IDR 约 增加 0.8Mbps 开销，在 5Mbps 码率下可接受。 验证（dump_stream 观察 150 帧） [ 0] seq=0 IDR ← 首帧 [ 60] seq=60 IDR ← 间隔精确 60 帧 [120] seq=120 IDR @60fps 即每 1 秒一个自动 IDR，与 gop_len=60 配置一致。 |
||
|---|---|---|
| .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》。