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 或降低跳帧触发频率是后续优化项。 |
||
|---|---|---|
| .. | ||
| keymap.rs | ||
| main.rs | ||