wangyukun/remote
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
80 Commits 6 Branches 0 Tags 1.3 MiB
4379b01d41
Commit Graph

19 Commits

Author SHA1 Message Date
郑博文
b1ac32175c feat(agent): v5 光标采样接入帧头（GetCursorInfo + 折叠规则 + dump 观测列） 
采集端把远端光标位置填进每帧帧头，供主控端画标记（4b 解决看不见远端鼠标）。

- fold_cursor 纯函数承载全部折叠判定：隐藏(CURSOR_SHOWING 未置位)/
  越出采集画面 [0,w)x[0,h)（副屏负坐标区，Q5=A）/超 i16 范围（防截断成
  看似合法的错坐标）→ None；坐标语义单一来源在被控端
- sample_cursor 只负责 Win32 读数（cbSize 契约注释）与失败/越界留痕
  （会话期各只打一条日志，可见后果但不逐帧刷屏）
- 采样点在 emit! 宏（唯一发送入口）：新帧/静止 500ms 保活重发/强制 IDR
  三条路径天然全覆盖，帧头 cursor 与 ts_ms 同刻
- 前提：agent 的 per-monitor DPI 感知（3b/D2）保证 ptScreenPos 是物理像素
- agent crate 首批单测 4 例（界内含原点/隐藏/五类越界/i16 上界），
  mutation 反向验证（>= 改 > 后越界用例确实红）
- dump_stream 帧表加光标列，Windows 端实测（本机同回环）：
  界内 Some(1000,600) 精确、副屏 -960 折叠 None、None->Some(300,250) 恢复
  全部 PASS；期间发现有人操控真鼠标，探针已改静置门控+读回自校验设计
 2026-11-02 10:32:09 +08:00
郑博文
98b4f03cff feat(common): 协议 v5 帧头新增光标字段 cursor 
4b 光标覆盖层的协议地基：VideoFrameHeader 尾部追加 Option<(i16,i16)>，
携带本帧发送时刻的远端光标物理像素坐标（None=隐藏/离屏/未实现三态折叠）。
解决「看不见远端鼠标」——相对模式下用户不知道指针在哪、轻点会落在哪。

- 字段追加改变 bincode 线格式，PROTO_VERSION 4→5，v4 旧端由握手显式拒绝（既有机制）
- v4 守卫按 v3 先例降为下界锚点，最新一代用精确等号守卫
- 新增 3 测试：Option 往返（含 i16 边界与负值）、尾部追加不扰动既有字段、
  None 紧凑性（Some 比 None 恰多 4 字节，证明光标未被固定宽度白占）
- agent/agent-core/viewer-core 构造点补占位 cursor: None（真实采样下一步接入），
  保证本提交全 workspace 可编译
 2026-11-02 10:11:23 +08:00
郑博文
78ac9d9972 feat(agent): 相对鼠标注入（读光标+增量+clamp 绝对注入）+ 显式 DPI 感知 
注入实现刻意**不用** SendInput(MOUSEEVENTF_MOVE)：实测该路径的 dx 不是
像素而是 mickey，会被「指针加速」与「DPI 缩放」双重放大——本机 dx=1 走 0px、
dx=20 走 41px、dx=100 走 309px，且倍率随用户系统设置与机器变化，无法标定。
改为「GetCursorPos + 增量 + clamp + 绝对注入」，实测 1:1 精确（±1/2/3/5/17/100
四次重复全部等于请求值），撞边后回滑立即响应、不积步数债。

同时显式设 PER_MONITOR_AWARE_V2：实测本机 agent.exe 虽是 per-monitor，
但那是注册表 AppCompatFlags\\Layers 里一条**路径绑定**的 HIGHDPIAWARE 覆盖
造成的（同一 exe 复制到 %TEMP% 启动即变 UNAWARE），换机器/换构建路径即失效。
UNAWARE 时 GetCursorPos 返回逻辑坐标（1536x864）而采集是物理像素（1920x1080），
clamp 上界与增量尺度都会错。设置失败时区分「已被外部设定」与「真正降级」并分别报日志。
 2026-10-31 17:34:54 +08:00
郑博文
55cc8edbc1 fix(agent): 文本注入改为单次 SendInput 批量——按官方文档消除事件被打散的风险 
实读 Keyboard Input Overview 后修正两处凭记忆的实现：
1. 原文承诺「单次调用的事件不会被其他输入插入」，此前拆成 down 批 + up 批
   两次调用，两次之间可能夹进真实键鼠事件，代理对存在被拆开的风险。合并为
   一次提交（全部 down 紧接全部 up）。
2. KEYBDINPUT 文档「只能与 KEYEVENTF_KEYUP 组合」那句按推断写成结论；
   改为如实标注为推断，并写明真机失败时的退路（只发 UNICODE|KEYUP 单事件）。
 2026-10-30 11:41:54 +08:00
郑博文
5075888861 feat(agent): v3 文本注入用 KEYEVENTF_UNICODE，一次批量提交成对代理项 
Windows 侧按官方 KEYBDINPUT 语义实现：置 KEYEVENTF_UNICODE 时 wVk 必须为 0、
wScan 即要送出的字符，系统合成 VK_PACKET 经 TranslateMessage 产出 WM_CHAR。
down 批与 up 批分两次 SendInput，且让同一段文本的 code unit 在输入队列里相邻，
使代理对能被远端合成一个字符（最终由真机 emoji 验收定论）。

agent-core 的 InputInjector::text 用默认实现记日志而非静默忽略：Linux 后端
本轮不做文本注入（X11 需 keysym/XKB 映射，另立循环），但用户对着 Linux
被控端打字不能「什么都没发生还没痕迹」。Windows 端走自己的 handle()，
不经 agent-core，故超限截断日志在两侧同源补齐。
日志只打长度，不打用户输入内容。
 2026-10-30 11:29:25 +08:00
郑博文
5079d33b0a fix(agent): 显式 max_idle_timeout=10s——强杀主控端后 10 秒内可重连 
问题（实测复现）
串行 accept 下，主控端被强杀（force-stop，非正常 close）时 QUIC 连接
不会立即消亡：agent 还在向死连接发帧，新连接只能排队，要等 quinn 默认
idle 超时（约 30s）才能建立。表现为「杀掉 App 重开，一直连不上」。

修法
TransportConfig 显式设 max_idle_timeout=10s。正常会话每 500ms 一个 Ping
永不触发该超时，只回收死连接。10s = 20 个 Ping 周期，抗抖动余量足够。

验证（vivo S6 实测）
- 会话1 auth ok -> force-stop App -> 立即重连
- 10.2s 后 peer connected + auth ok（修复前 ~30s）
 2026-10-30 10:38:04 +08:00
郑博文
6a6f989595 fix(agent): 绝对坐标注入去掉 VIRTUALDESK——注入空间与采集空间对齐 
根因（实测确认）
capture 用 EnumOutputs(0) 只采**主屏**，AuthOk 报告的 width/height 也是主屏；
但 input 注入带 MOUSEEVENTF_VIRTUALDESK，归一化 0..=65535 被映射到**整个虚拟
桌面**。双显示器机器上虚拟桌面（主屏 2560x1440 + 副屏 1920x1080 在左）比主屏
宽得多，手机画面与指针位置系统性错位——点主屏任务栏，指针落到别处。
单显示器时两个空间重合，所以桌面 viewer 联调从未暴露。

修法
MOUSEEVENTF_ABSOLUTE 不带 VIRTUALDESK 时，0..=65535 恰好映射到主显示器，
与采集空间一致。协议注释「鼠标坐标为虚拟桌面归一化」的语义由「整个虚拟桌面」
修正为「被采集的输出」——桌面 viewer 是绝对定位透传，行为不变。

验证（vivo S6 -> 本机双屏，修复后）
- 手机拖微信标题栏：窗口跟随手指移动（drag-before/after 截图对比）
- App 状态栏 norm 坐标与视图坐标换算一致（view=(643,222) norm=(39017,23968)）
 2026-10-30 10:30:53 +08:00
郑博文
f119300a57 feat(agent): 串行多会话——会话结束不再退出进程 
问题（阶段 2 的硬阻塞）
accept() 只接一次，会话结束进程退出。阶段 1 一次验收看不出来，
但阶段 2 要反复测试输入，每测一次都要手动重启被控端。
（即公共阻碍清单里的 P5，此前判断为「只影响调试效率」，
 现在它阻塞迭代，提前做掉。）

改动
1. main：会话体抽成 serve_session()，外层 accept 循环。
   会话失败（含认证失败）只记日志不退出进程。
   明确不做并发多会话：DXGI Desktop Duplication 每个输出仅允许一个
   活动实例，第二个 DuplicateOutput 会让第一个收到 ACCESS_LOST。
2. 认证失败路径补 conn.closed() 等待（agent-core 已有同款修复，
   此处同源补齐 = 手册 §6.1 第 1 条）：否则客户端只看到 connection
   lost 而不是 AuthFail。
3. capture 循环加 tx.receiver_count()==0 守卫。
   只靠「send 失败退出」不够——桌面完全静止时那个分支根本不发送，
   线程会永远持有 duplication，下一个会话的 DuplicateOutput 直接失败
   （表现为新会话黑屏）。agent-core 同源修复。
4. 会话收尾：finish 流 + drop 接收端 + 等采集线程退出（2s 超时）后才
   返回，调用方才 accept 下一个连接。

验证（连续两个会话，中间不重启 agent）
  会话1：收到帧 40/40，结论 ✅
  agent 存活：✅
  会话2：收到帧 40/40，结论 ✅
  日志：session closed -> waiting for next connection -> peer connected
        -> auth ok；stderr 有 [capture] no receiver, stop 证明线程真退出
 2026-10-30 09:31:44 +08:00
郑博文
1837658c85 test(agent): dump_stream 增加 --save，可导出裸 H.264 码流供外部解码器验证 
目的
安卓主控方案的唯一高风险未知项是「agent 发出的码流能否被 MediaCodec 解码」。
要验证它，需要一份脱离 QUIC/自定义帧头的**裸 Annex-B 码流文件**，供手机端
或任何标准解码器直接读取。

改动
- 新增 --save <路径>：把各帧载荷按到达顺序拼接成 Annex-B 文件
- 存的是**载荷**而非完整帧：外部解码器只认标准 Annex-B，不认识本项目的
  长度前缀与 bincode 帧头，故不能存 encode_video_frame 的输出
- 保存时打印字节数与 IDR 数量，便于快速判断样本是否可用

不做的事
不引入独立的码流解析库，IDR 统计复用文件内已有的起始码扫描逻辑，
避免为一次性诊断工具增加依赖。

验证
cargo build --workspace 退出码 0；cargo test --workspace --exclude linux-agent 全绿。
实际使用：导出 90 帧、437823 字节、含 2 个 IDR，该文件已用于安卓 MediaCodec
兼容性验证（vivo S6 / Exynos 硬解，87/89 帧解出）。
 2026-10-29 16:13:58 +08:00
郑博文
6e83bda8b8 perf(agent): 关键帧周期从 4s/10s 统一到 1s，缩短丢帧后的兜底恢复窗口 
背景
协议 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 配置一致。
 2026-10-28 16:35:44 +08:00
郑博文
e778ff73cc test(agent): 新增 dump_stream 码流诊断工具 
用途：不依赖 viewer 的 Minifb 窗口，直接抓 agent 下发的码流并逐帧打印
NAL 结构与解码结果，用于定位解码恢复类问题。

能力
- 打印每帧的 seq / keyframe / 字节数 / NAL 类型（SPS PPS IDR P）
- --skip-at N：模拟主控端「积压跳帧」——读出但不解码，用于验证跳帧是否
  切断参考链（实测确认：跳掉一帧后所有 P 帧持续解码失败，直到收到 IDR）
- 交叉校验帧头 keyframe 标志与码流实际 NAL 类型是否一致
- 末尾补发 KeyFrameReq 并观察 IDR 是否真的回来

用法
  cargo run --release -p agent --bin dump_stream -- --port 47800 --code 123456
  cargo run --release -p agent --bin dump_stream -- --port 47800 --code 123456 --skip-at 1

注意：KeyFrameReq 必须写在流 2（isend）——agent 的读循环只监听流 2，
写到流 1 会被静默忽略（本工具第一版踩过，误判「修复无效」）。

这个工具是发现 nvenc FORCEIDR 缺陷的直接手段，保留以备回归排查。
 2026-10-28 16:05:41 +08:00
郑博文
9e50bc6237 feat(common): 协议 v2——版本号 + 帧头 seq/keyframe + 长度下界校验 
为接入安卓主控做准备，先把三端共享契约改到能承载多客户端。改动集中在
common/src/lib.rs，三端适配在同一提交内完成以保证可编译。

协议版本（PROTO_VERSION=2）
- ControlMsg::Auth/AuthOk 增加 proto_version 字段；认证顺序改为「先版本后验证码」：
  版本不一致时字段布局可能不同，验证码的解析结果不可信
- 任一端版本不符即 AuthFail 并明确报错，把「连上了但行为诡异」变成「连不上且提示升级」

视频帧头（VideoFrameHeader）
- 新增 seq: u64（每次实际发送递增，含静止桌面重发）与 keyframe: bool
- keyframe 由新增的 common::h264_contains_idr() 从实际 Annex-B 码流判定，
  不依赖编码器 API 推断——NVENC 与 openh264 规则不同，实际输出才是唯一可信来源
- 该字段是 MediaCodec 判断解码器重置时机的必要条件，避免客户端自己写 NAL 扫描

不可信输入防护
- read_video_frame 补齐长度下界：total 必须 >= 4，hlen 必须落在 [1, total-4]
- 旧实现只校验上界，构造 total<4 的帧会让接收端在 buf[0..4] 处 panic（进程级DoS）
- 测试从 0 增至 11 个，覆盖序列化往返与 6 类越界/损坏输入

顺带修复（与上述契约直接相关）
- 新增 common::split_video_frame()：静止桌面重发时复用载荷但重建帧头，
  否则 seq/ts_ms 会停在上次发送时刻，破坏 seq 单调递增契约
- agent-core 与 agent 两端的静止重发路径均改用该函数

验证：cargo test -p common → 20 passed（9 signaling + 11 新增）
 2026-10-28 16:05:41 +08:00
dev-team
04c02d9ced fix: 启动黑屏 - 静止桌面响应KeyFrameReq + 首帧强制IDR + 入会主动请求关键帧 2026-10-23 13:12:27 +08:00
dev-team
168f600fe1 perf(agent): E2E 排队修复——发送窗口 512KB→64KB + 拥塞反馈自动跳帧 
- 实测数据：FPS 61 / RTT 7ms / E2E 618ms → 延迟全在发送侧排队：
  512KB 窗口 ÷ WiFi 实际 ~3Mbps 吞吐 ≈ 1.3s 排队上限，latest-wins 管不到已进 QUIC 的字节
- send_window 64KB：排队硬上限 ~170ms@3Mbps；突发吞吐 64KB/7ms≈72Mbps 不受限；
  连接级窗口，流 2 输入数据量极小不受影响
- 拥塞反馈跳帧：send write 耗时 >20ms(单帧预算 1.2 倍) → 置位标志 → 采集线程
  跳过当前帧（NVENC 少输入一帧，参考链连续无花屏），注入率自适应匹配网络吞吐；
  capture 日志新增 skipped 计数
- viewer 标题版本 v0.7-LowLatency
- 回环实测：NVENC 4ms/帧、skipped 0（回环无拥塞符合预期）、零错误
 2026-10-23 12:48:16 +08:00
dev-team
9c72aecc3b fix(viewer): 帧管线 latest-wins 单槽（修 NVENC 60fps 下积压假死/HUD 停刷）+ GOP 周期自愈 
- viewer: 无界 mpsc → Mutex 单槽 latest-wins。根因：NVENC 60fps 到达率 > 渲染
  吞吐(~55fps)，无界队列无限积压 → 延迟线性增长 + 渲染 drain 阻塞消息泵 →
  窗口假死、HUD 停刷（软编 20fps 时代掩盖，NVENC 后暴露）
- viewer: 解码帧尺寸与窗口解耦（blit 逐行拷贝，防 NVENC 对齐尺寸不匹配）；
  首帧打印解码尺寸诊断
- agent: NVENC gop_len 0xffffffff→240（60fps 下 4s 周期 IDR 自愈恢复点，
  配合 KeyFrameReq 即时恢复，消除长时间冻结锯齿）
- 回环实测：NVENC 4ms/帧满速、解码 1920x1080 匹配、14s 零错误
 2026-10-23 10:31:30 +08:00
dev-team
ddbb53d41a feat(agent): NVENC 硬编接入（GPU 零拷贝 ARGB 直通，软编自动兜底） 
- 编码器自动选择：NVENC（H264 High/CBR 5Mbps/UltraLowLatency/无B帧/按需IDR）→ openh264 兜底
- Duplication 增加 GPU 中间纹理（B8G8R8A8 DEFAULT），NVENC register_resource_dx11 直读，颜色转换完全省略
- KeyFrameReq → encode_picture(picture_type=IDR)，静止 500ms 重编码 P 帧
- windows 0.58→0.62（nvenc crate 依赖 0.62，运行时 dlopen nvEncodeAPI64.dll 零 SDK 依赖）
- 实测（GTX 1650 Ti 回环）：encode 41ms→4ms/帧（10x），convert 0ms，viewer 解码正常
 2026-10-23 10:18:29 +08:00
dev-team
e7472fa12f perf(agent): 60fps上限/零拷贝转换/多线程编码/发送缓冲512KB + encbench基准 
- capture: min_frame 33→16ms，RC 60fps；with_mapped 映射窗口内直接 BGRA→YUV（行距连续零拷贝）
- capture: num_threads(4) + 每120帧输出 convert/encode 耗时（实测：convert 2ms，encode 41ms/帧真实工况）
- agent: send_window 2MB→512KB，E2E 排队天花板 ~0.15s（修复 E2E 633ms 红）
- encbench: 1080p 编码基准（合成 5ms/帧，真实工况 41ms/帧 → 软编 1080p 上限 ~24fps，60fps 需 NVENC）
- tools/bench.md
 2026-10-23 10:02:41 +08:00
dev-team
7dbb04da17 feat(hud): B1 基线指标——抖动/帧间隔p95/丢包率/解码失败计数 + 测试脚本 
- common: Pong 扩展 lost/sent（agent 发送方向 QUIC 计数，经交叉评审项）
- agent: Pong 附带 conn.stats().path 丢包统计
- viewer: Stats 加 GapRing(64)/jitter EMA/dec_fail；HUD 新增 JIT/P95/LOSS/DECFAIL 四行，% 字形
- tools/bench.md: 三场景基线测试脚本
 2026-10-23 09:47:09 +08:00
dev-team
61e8a75cdd init: MVP remote desktop (agent/viewer/common) with H.264 pipeline 2026-10-23 09:17:55 +08:00