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 配置一致。 |
||
|---|---|---|
| .. | ||
| lib.rs | ||