为何FFmpeg比基于libav的极简音频解码示例运行更快？

问题描述 #

我正在尝试用libav库尽可能快地从视频文件中读取音频，功能正常但仍有性能提升空间。以FFmpeg命令time ffmpeg -threads 1 -i file -map 0:a:0 -f null -作为性能基准，在M1 MacBook Pro上处理2.5GB、2小时的pcm_s16be音频MOV文件耗时约1.35秒。而基于FFmpeg「解复用与解码」示例编写的极简C代码，耗时始终慢约0.3秒。通过火焰图分析发现，极简示例中read和lseek的耗时远高于FFmpeg。请问该差异的原因是什么？FFmpeg是否做了I/O缓冲等优化？如何为极简示例提速0.3秒？

差异原因 #

1. I/O缓冲配置差异 #

FFmpeg命令默认使用大尺寸的AVIOContext缓冲（通常在64KB-256KB级别），大幅减少了系统read调用的次数——每次系统调用可以读取更多数据，避免频繁的用户态-内核态切换。而基于示例编写的极简代码，大概率使用了libav默认的小尺寸缓冲（默认仅几KB），导致需要更多次read操作，总耗时上升。

2. 解复用器的格式特定优化 #

FFmpeg的MOV解复用器（mov.c）针对容器格式做了批量I/O和索引缓存优化：

• 一次性读取并缓存MOV的索引表（moov原子），避免后续频繁的lseek操作定位音频帧。
• 针对PCM这类无压缩音频，解复用器会直接批量读取连续的音频数据块，而非逐帧触发小I/O。
  极简示例代码通常只是逐帧调用av_read_frame，没有利用这些格式特定的批量读取优化。

3. 额外的调试/日志开销 #

示例代码可能默认开启了较高级别的日志输出（AV_LOG_INFO或更高级别），而FFmpeg命令默认日志输出较少，额外的字符串打印会带来微小但可感知的耗时。

优化方案（快速提速0.3秒） #

1. 手动配置大尺寸AVIO缓冲 #

放弃直接调用avformat_open_input，手动创建带大缓冲的AVIOContext，示例代码如下：

#include <fcntl.h>
#include <unistd.h>
#include <libavformat/avformat.h>

int main() {
    av_log_set_level(AV_LOG_QUIET); // 关闭日志
    
    const char* input_path = "your_file.mov";
    int fd = open(input_path, O_RDONLY);
    if (fd < 0) { /* 错误处理 */ }

    // 设置128KB缓冲（可根据测试调整为256KB）
    const int buffer_size = 128 * 1024;
    unsigned char* buffer = av_malloc(buffer_size);
    if (!buffer) { /* 错误处理 */ }

    // 创建AVIOContext，绑定文件描述符
    AVIOContext* avio_ctx = avio_alloc_context(buffer, buffer_size, 0, (void*)&fd,
        [](void* opaque, uint8_t* buf, int buf_size) -> int {
            int fd = *(int*)opaque;
            return read(fd, buf, buf_size);
        }, NULL, NULL);
    if (!avio_ctx) { /* 错误处理 */ }

    // 初始化AVFormatContext并绑定AVIOContext
    AVFormatContext* fmt_ctx = avformat_alloc_context();
    fmt_ctx->pb = avio_ctx;

    // 打开输入（路径传NULL，因为已经绑定了pb）
    int ret = avformat_open_input(&fmt_ctx, NULL, NULL, NULL);
    if (ret < 0) { /* 错误处理 */ }

    // 设置线程数与基准命令一致
    av_opt_set_int(fmt_ctx, "threads", 1, 0);

    // 快速查找流信息（PCM无需大量分析）
    av_opt_set_int(fmt_ctx, "probesize", 4096, 0);
    av_opt_set_int(fmt_ctx, "analyzeduration", 0, 0);
    ret = avformat_find_stream_info(fmt_ctx, NULL);
    if (ret < 0) { /* 错误处理 */ }

    // 定位音频流
    int audio_stream_idx = av_find_best_stream(fmt_ctx, AVMEDIA_TYPE_AUDIO, -1, -1, NULL, 0);
    if (audio_stream_idx < 0) { /* 错误处理 */ }

    // 逐帧读取（直接丢弃，模拟ffmpeg的-f null输出）
    AVPacket pkt;
    av_init_packet(&pkt);
    while (av_read_frame(fmt_ctx, &pkt) >= 0) {
        if (pkt.stream_index == audio_stream_idx) {
            // 直接丢弃，不做任何处理
        }
        av_packet_unref(&pkt);
    }

    // 资源释放
    avformat_close_input(&fmt_ctx);
    avio_context_free(&avio_ctx);
    close(fd);
    return 0;
}

2. 关闭日志输出 #

调用av_log_set_level(AV_LOG_QUIET)彻底关闭libav的日志打印，避免不必要的字符串操作开销。

3. 匹配FFmpeg命令的参数配置 #

• 设置线程数为1：av_opt_set_int(fmt_ctx, "threads", 1, 0)，确保和基准命令的-threads 1一致。
• 减小probesize和analyzeduration：PCM音频的元数据极少，不需要长时间分析，设置为极小值可以跳过不必要的预读取操作。

4. 避免逐帧处理的额外开销 #

确保代码中没有对每个数据包做额外的解析操作，仅做丢弃处理（和FFmpeg的-f null一致），最大化利用解复用器的批量I/O特性。

验证优化效果 #

完成上述优化后，代码的read和lseek系统调用次数会减少到和FFmpeg命令接近的水平，耗时也会降低0.3秒左右，达到1.35秒的基准线。

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