时间戳不是通用帧号
视频播放器显示的时间以秒为单位。设置媒体元素的当前时间会要求浏览器寻找时间轴中的该点。然后，浏览器解码足够的数据以在请求时间附近呈现可用帧。 HTMLMediaElement currentTime 文档 定义了定位接口，但它不保证每个编解码器和容器都有稳定的源帧索引。
对于恒定 30 FPS 媒体，一帧标称持续时间约为 1 / 30 秒，即 0.0333 秒。这使得 1/30 秒的轻推变得直观。对于 24、25、29.97、60 或可变帧速率媒体，相同的微调只是一个很小的时间步长。它可能会移动多个呈现帧，落在同一显示帧上，或暴露时间戳间距与平均值不同的帧。
因此，VideoToImg 将其控制描述为 1/30 秒的微调，而不是承诺为每个来源提供一个原始帧。这种区别对于可重复的质量保证、科学观察、法律证据和动画计时很重要。
为什么关键帧会影响搜索
大多数用于分发的视频都会随着时间的推移进行压缩。关键帧包含独立的图片，而后面的帧间帧通常描述相对于早期解码图像的变化。为了在 37.4 秒处显示帧，解码器可能需要定位较早的关键帧并向前解码，直到达到设定的呈现时间。
稀疏关键帧会使随机定位速度变慢，尤其是在长文件或高分辨率文件中。它们还可能暴露正常向前播放隐藏的浏览器或文件索引问题。 MDN 视频编解码器指南 解释了帧间压缩和周期性关键帧如何影响播放和压缩伪影恢复。
定位延迟并不能证明该工具上传了文件。本地文件仍由当前标签页中的浏览器媒体 API 进行解码。解码时间取决于源文件结构、设备、编解码器实现以及与有用随机访问点的距离。
使用可重复的精确框架工作流程
- 大致定位场景。 在操作附近拖曳或输入时间戳，然后等待预览更新。
- 检查两个方向。 通过几个小的时间步长来前后推动。比较主体位置、焦点、动作模糊、字幕和界面状态。
- 记录媒体时间。 将显示的时间戳与导出的图片一起保留或保留在您的审查笔记中。仅文件名称可能无法保留足够的上下文。
- 首先按源视频宽度导出。 仅当最终使用的显示尺寸已知时才缩小尺寸。稍后调整大小无法恢复丢失的细节。
- 选择像素周围的输出。 PNG 避免了额外的有损静态图像步骤； JPG 对于摄影场景来说比较紧凑； WebP 对于现代网络交付非常有用。
- 独立验证关键证据。 浏览器屏幕截图工具适合视觉选择，不能取代报告准确帧身份和呈现时间戳的取证解码器。
恒定和可变帧速率需要不同的语言
恒定帧速率视频的目标是均匀间隔的帧，尽管 29.97 等常见速率仍然需要精确合理的计时。可变帧率视频允许改变演示持续时间。屏幕录制、会议工具和电话可能会使用可变的计时来适应内容或截取条件。
因此，将时间戳除以公布的平均 FPS 可以产生方便的估计值，而不是权威的帧数。两个画面的持续时间可能不同，重复或丢失的呈现可能会影响时间和顺序位置之间的关系。
当工作流程需要诸如「编码流的第 1,248 帧」之类的语句时，请使用公开数据报和帧时间戳的工具检查文件。当任务是「保存41.2秒左右最清晰的图像」时，浏览器视觉选择通常是更直接的方法。
诊断错误、黑色或陈旧的帧
当请求的时间超出最后一个可解码讯框时，即使容器报告的持续时间稍长，也可能会在文档末尾附近出现黑色图像。提前移动一点，然后再试一次。查找后的陈旧图像可能表示解码尚未完成；等待预览状态而不是在转换期间捕获。
如果只有一个文件失败，请怀疑其编解码器、索引、时间戳或损坏的媒体数据。如果每个文件在一个浏览器中都失败，请测试当前的浏览器版本和一个已知良好的小型 H.264 MP4 或 WebM 文件。如果直接 URL 失败而下载的本地副本有效，则跨域权限或远程响应可能是边界。
编解码器和容器指南 提供了更完整的诊断串行。向 hello@videotoimg.com 报告可重现的问题，而无需发送私人媒体。
了解图像导出可以改变什么，不能改变什么
浏览器呈现框架后，工具会将解码后的图像绘制到画布上，并要求浏览器对图像 Blob 进行编码。 canvas toBlob 文档 描述了此静态图像编码步骤。更改 PNG、JPG 或 WebP 会影响新图像文件，而不是已解码的源图像细节。
PNG 无法反转运动模糊、焦点错误、色度子采样、低比特率或先前的视频压缩。 JPG 质量仅控制额外的 JPEG 编码权衡。较小的最大宽度会减少像素尺寸和内存或文件重量，但应根据预期显示来选择它，而不是将其视为质量升级。