【问题标题】:Does stream seek order matter for ffmpeg av_seek_frame()?ffmpeg av_seek_frame() 的流搜索顺序是否重要?
【发布时间】:2019-05-28 03:36:06
【问题描述】:

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

我在寻找时遇到了一个问题,我已通过更改我的寻找顺序进行了补救,但我想确保我的修复实际上是一个修复,而不是一些巧合的破解。

我正在尝试寻找第一个数据包的音频和视频流。对于视频,第一个数据包的 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 调用的顺序是否真的很重要,或者我的代码中的其他地方是否存在恰好掩盖的错误?

【问题讨论】:

  • 另外,我使用的flagsAVSEEK_FLAG_BACKWARD

标签: c audio video ffmpeg decoding


【解决方案1】:

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

对于您的用例,您可以寻求解复用将为您提供所需的所有数据包的点,然后跳过那些为时过早的数据包。

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

【讨论】:

  • 澄清一下:是否应该始终按照流的索引顺序对流进行搜索调用,因为那是文件的流顺序?
  • 您应该只执行一次搜索调用。只需要搜索的流参数,因为对于某些媒体,流的时间戳可以有不同的分辨率。
  • 那么流索引真的只是为了获取时基乘以时间戳吗?在那种情况下,如果我试图正确地寻找文件的开头,我想找到具有最小 first_dts 的流,对吗?
  • 是的,需要流索引才能根据时基进行精确搜索。我会检查start_time 的最小值而不是first_dts。通常,您有一个更重要的流,并基于该流进行搜索。
猜你喜欢
  • 2010-10-05
  • 2011-03-03
  • 1970-01-01
  • 2020-09-15
  • 1970-01-01
  • 1970-01-01
  • 2014-08-10
  • 2018-06-01
  • 2011-10-30
相关资源
最近更新 更多