ffmpeg av_seek_frame() 的流搜索顺序重要吗？

Question

我正在尝试使用 ffmpeg av_seek_frame方法为 mp4 寻找音频和视频流。

我在寻求通过更改搜索顺序进行补救时遇到了一个问题，但我想确保我的修复实际上是一个修复，而不是一些偶然的 hack 有效。

我正在尝试寻找第一个数据包的音频和视频流。 对于视频，第一个数据包的 pts 为 0。对于音频，第一个数据包的 pts 为 -1024。 视频流的索引为 0，音频流的索引为 1。这都已在媒体文件上使用 ffprobe 查看数据包和流进行了验证。

以下代码不起作用，它将音频和视频流寻找到 pts 为 0 的数据包：

for (int i = format_context->nb_streams - 1; i >= 0; --i) {
    AVStream* stream = format_context->streams[i];
    av_seek_frame(format_context, i, stream->first_dts, flags);
}

但这正确地将视频流搜索到 pts 0，将音频流搜索到 pts -1024：

for (int i = 0; i < format_context->nb_streams; ++i) {
    AVStream* stream = format_context->streams[i];
    av_seek_frame(format_context, i, stream->first_dts, flags);
}

请注意，在第一个示例中，在视频之前搜索音频，而在第二个示例中，在音频之前搜索视频。

av_seek_frame 调用的顺序是否真的很重要，还是我的代码中的其他地方有一个错误恰好掩盖了这个错误？

Answer 1

寻求影响所有流。 寻道请求由分路器处理。 它将移动到文件或多路复用流中的某个点。 随后的解复用将从那时起为您提供数据包。 不支持在 dexmed 流中单独查找。

对于您的用例，您可以寻求一个点，即分路器将为您提供所需的所有数据包，然后跳过那些为时过早的数据包。

所以是的，上面示例代码中的顺序很重要。 但这仅仅是因为音频和视频数据包恰好存储在您的 mp4 文件中的方式。