为何getFrameAtIndex提取视频帧速度远快于getFrameAtTime()？

两者的性能差异完全来自底层实现逻辑的不同，具体原因如下：

• getFrameAtIndex 是API 28新增的专用帧索引访问接口：
  底层预先维护了帧索引到视频文件物理位置的映射表，调用时不需要额外做时间戳到帧位置的转换计算，顺序提取全帧时会自动复用前一次的解码上下文，缓存已解码的中间结果，不需要每次调用都重置解码器状态、重复执行文件定位操作，因此性能很高。
• getFrameAtTime 是基于时间戳的通用访问接口：
  每次调用都需要先完成「输入时间戳 -> 对应帧位置」的映射查找，之后还要执行seek操作定位到目标帧附近的关键帧位置，再从关键帧开始逐帧解码到目标时间点的帧。每次调用都会重置解码器状态，无法复用前一次的解码缓存，大量的重复seek和解码操作直接导致了性能大幅下降。
  你当前代码中使用的MediaMetadataRetriever.OPTION_CLOSEST_SYNC参数只会返回时间点附近的关键帧，不仅提取不到所有普通帧，还会额外增加关键帧查找的开销，进一步拉长耗时。

低版本兼容优化建议 #

如果需要兼容API 28以下的系统，可以做如下调整提升速度：

1. 把OPTION_CLOSEST_SYNC替换为MediaMetadataRetriever.OPTION_CLOSEST，既能提取到非关键帧，也能减少关键帧查找的开销
2. 如果需要更高的提取效率，建议直接使用MediaCodec硬解码实现全帧提取，同等场景下耗时可以压缩到getFrameAtIndex的1/2甚至更低。

内容的提问来源于stack exchange，提问作者user7954210