ffmpeg笔记，av_read_frame()阻塞在哪

最新推荐文章于 2026-05-13 06:22:12 发布

原创最新推荐文章于 2026-05-13 06:22:12 发布 · 8.3k 阅读

10 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

ffmpeg笔记专栏收录该内容

2 篇文章

订阅专栏

本文探讨了FFmpeg中av_read_frame()函数的阻塞问题，并深入分析了其内部调用过程。从ff_read_packet()到read_from_url()直至最终在retry_transfer_wrapper()中发生阻塞的原因被详细解释。此外，还讨论了通过设置AVIO_FLAG_NONBLOCK标志来避免阻塞的方法及潜在的问题。

笔记一下。av_read_frame()阻塞在哪

av_read_frame() -> read_frame_internal() -> ff_read_packet() -> s->iformat->read_packet() -> /*不同demux最后都要到read url*/ -> read_from_url() -> ffurl_read() -> retry_transfer_wrapper() (这里有堵塞)

如果作为输入参数的URLContext的flag写上AVIO_FLAG_NONBLOCK，就不会在这里block住了，会直接返回EAGAIN。
然而后面还有坑，在aviobuf.c里的fill_buffer()，虽然之前返回的是EAGAIN，但是这里有个逻辑：

    if (len <= 0) {
        /* do not modify buffer if EOF reached so that a seek back can
           be done without rereading data */
        s->eof_reached = 1;
        if (len < 0)
            s->error = len;
    }

直接给置上eof了，然后外面开始flush demux了。

所以如果使用AVIO_FLAG_NONBLOCK，需要增加逻辑进行判断。
比如在retry_transfer_wrapper()里区分ret是0（真的eof）还是EAGAIN，在fill_buffer()这块区分是eof还是EAGAIN。