Rust封装库中回调函数调用次数不一致问题排查

1. 验证ExactSizeIterator的实际迭代量 #

虽然两个迭代器都实现了ExactSizeIterator，但实际运行时的元素数可能和len()返回值不符：

• 打印两个迭代器的len()值，确认是否均为1800；
• 手动遍历计数，对比迭代器实际产出的元素数量：

  let ref_iter_count = reference_frames.count();
  let dist_iter_count = distorted_frames.count();
  println!("参考帧数量: {}, 失真帧数量: {}", ref_iter_count, dist_iter_count);
  

2. 排查zip的实际执行逻辑 #

Rust的Iterator::zip会以较短的迭代器为准，但需注意：

• 检查是否有迭代器在zip前被隐式修改（比如调用了skip/take方法，或内部包含filter逻辑）；
• 确认迭代过程中是否有某一方提前终止（比如某帧解码触发了迭代器的None返回）。

3. 核对Decode回调的触发时机 #

确认Exhibit A中是否真的每帧都触发了回调：

• 检查解码逻辑的条件分支，是否存在解码失败时跳过Decode回调的情况；
• 在回调内部添加计数日志，直接统计实际触发次数，和迭代器遍历次数做对比。

4. 检查GetScore回调的触发范围 #

既然GetScore仅对Ok值触发，但次数更多，需排查：

• 统计收集到的Vec<Result<usize,VmafError>>长度：如果长度是1800，说明Decode少触发2次；如果长度是1798，说明GetScore多触发2次；
• 确认是否有其他逻辑（比如重试、额外帧处理）在外部调用了GetScore回调；
• 检查Exhibit C的循环逻辑，是否存在重复遍历或索引越界导致的额外调用。

5. 排查VMAF库的帧计数逻辑 #

如果上述检查都无问题，可能是底层库的逻辑差异：

• 确认输入视频的实际帧数量，是否存在空帧、重复帧或编码端的帧计数偏差；
• 检查VMAF计算时是否会对某些帧重复计算分数，或解码阶段跳过了部分无效帧。

内容的提问来源于stack exchange，提问作者Brandon Piña