查找 MJPEG 视频的特定帧是否比查找 h.264 文件更快？
Is seeking to specific frames of an MJPEG video faster than doing the same for an h.264 file?
我正在录制视频，需要快速随机地寻找视频中的特定帧。
我可以用 MJPEG 或 h.264 压缩标准录制视频。
我知道 MJPEG 可以生成单独的 jpeg，并且生成的文件比 h.264 更大，而且 h.264 可以跨多个视频帧进行压缩。
Does this difference mean that I will get faster seek times when
seeking to a random location in the file using ffmpeg or gstreamer
programmatically?
Will the MJPEG allow the frame-seek operation to reduce the IO requirements when reading just 1 frame from a video file?
选择 MJPEG。
如果你正在寻找特定的（第 N 个）帧，在 H.264 的情况下你必须找到最接近你寻找的帧的 I 帧，然后 解码这个 I 帧和第 N 个帧之间的所有帧和如果第 N 帧是 B 帧 则更进一步，以恢复完整的第 N 帧。这需要几毫秒，但对您来说可能很重要。
MJPEG 文件更大但没有解码开销，因此除非您的磁盘非常非常非常慢，否则它是您的选择。
无论如何，ffmpeg 必须遍历所有视频数据包来计算它们，因此这是您的磁盘和处理器速度之间的权衡。
实际上，FFmpeg 2.1+ 也可以 非常快速地从 h.264 中提取帧。假设您按时间点指定所需的帧，则不需要 "go through all the video packets to count them"，如接受的答案中所述。我也不认为有一种方法可以请求 Nth 帧（除了将 N 乘以固定帧速率以确定所需的时间点） .
这是一个示例，使用免费动画短片的 h.264 版本，"Big Buck Bunny"。
让我们请求一个精确的帧，正好是视频中的 10 分钟：
$ ffmpeg -ss 00:10:00.000 -i /home/eric/Videos/bbb_sunflower_2160p_30fps_normal.mp4 -y -vframes 1 -s 3840x2160 /tmp/bbb-10:00.000.jpg
提取只用了大约 1.8 秒。
注意：如果你颠倒 -i 和 -ss 参数，你就是 "output seeking"（而不是 "input seeking" ).在这种情况下，“...the input will be decoded (and discarded) until it reaches the position given by -ss. This will be done very slowly, frame by frame.”
例如：
$ ffmpeg -i /home/eric/Videos/bbb_sunflower_2160p_30fps_normal.mp4 -ss 00:10:00 -y -vframes 1 -s 3840x2160 /tmp/bbb-10:00.000.jpg
提取大约需要 12 分 45 秒（请注意，电影本身 不到 11 分钟！）。所以在我的机器上，它是 运行 低于实时。
有关 "seeking" 使用 FFmpeg 的更多详细信息，请参见此处：https://trac.ffmpeg.org/wiki/Seeking
我正在录制视频，需要快速随机地寻找视频中的特定帧。
我可以用 MJPEG 或 h.264 压缩标准录制视频。
我知道 MJPEG 可以生成单独的 jpeg，并且生成的文件比 h.264 更大，而且 h.264 可以跨多个视频帧进行压缩。
Does this difference mean that I will get faster seek times when seeking to a random location in the file using ffmpeg or gstreamer programmatically?
Will the MJPEG allow the frame-seek operation to reduce the IO requirements when reading just 1 frame from a video file?
选择 MJPEG。
如果你正在寻找特定的（第 N 个）帧，在 H.264 的情况下你必须找到最接近你寻找的帧的 I 帧，然后 解码这个 I 帧和第 N 个帧之间的所有帧和如果第 N 帧是 B 帧 则更进一步，以恢复完整的第 N 帧。这需要几毫秒，但对您来说可能很重要。
MJPEG 文件更大但没有解码开销，因此除非您的磁盘非常非常非常慢，否则它是您的选择。
无论如何，ffmpeg 必须遍历所有视频数据包来计算它们，因此这是您的磁盘和处理器速度之间的权衡。
实际上，FFmpeg 2.1+ 也可以 非常快速地从 h.264 中提取帧。假设您按时间点指定所需的帧，则不需要 "go through all the video packets to count them"，如接受的答案中所述。我也不认为有一种方法可以请求 Nth 帧（除了将 N 乘以固定帧速率以确定所需的时间点） .
这是一个示例，使用免费动画短片的 h.264 版本，"Big Buck Bunny"。
让我们请求一个精确的帧，正好是视频中的 10 分钟：
$ ffmpeg -ss 00:10:00.000 -i /home/eric/Videos/bbb_sunflower_2160p_30fps_normal.mp4 -y -vframes 1 -s 3840x2160 /tmp/bbb-10:00.000.jpg
提取只用了大约 1.8 秒。
注意：如果你颠倒 -i 和 -ss 参数，你就是 "output seeking"（而不是 "input seeking" ).在这种情况下，“...the input will be decoded (and discarded) until it reaches the position given by -ss. This will be done very slowly, frame by frame.”
例如：
$ ffmpeg -i /home/eric/Videos/bbb_sunflower_2160p_30fps_normal.mp4 -ss 00:10:00 -y -vframes 1 -s 3840x2160 /tmp/bbb-10:00.000.jpg
提取大约需要 12 分 45 秒（请注意，电影本身 不到 11 分钟！）。所以在我的机器上，它是 运行 低于实时。
有关 "seeking" 使用 FFmpeg 的更多详细信息，请参见此处：https://trac.ffmpeg.org/wiki/Seeking