FFmpeg视频播放的内存管理

在写这个播放器的时候，遇到了一些内存管理的问题，虽然棘手可是也让我对此有了比较完善的理解，并且不少相关资料并无跟随FFmpeg的更新，好比缓冲池AVBufferPool的使用。

使用ffmpeg版本是3.4

AVFrame和AVPacket的内存管理策略

对AVFrame:

• av_frame_alloc只是给AVFrame分配了内存，它内部的buf仍是空的，就至关于造了一个箱子，但箱子里是空的。
• av_frame_ref对src的buf增长一个引用，即便用同一个数据，只是这个数据引用计数+1.av_frame_unref把自身对buf的引用释放掉，数据的引用计数-1。
• av_frame_free内部仍是调用了unref,只是把传入的frame也置空。

发现还缺了一个buffer初始化的方法，初始化就在解码函数avcodec_send_packet和avcodec_receive_frame内部。

而后对于解码有个坑,对avcodec_receive_frame函数：

Note that the function will always call av_frame_unref(frame) before doing anything else.

若是你使用同一个frame，每次去接收解码后的数据，那么每次传进去就会把前面的数据释放掉，致使就只有一个frame是有用的。

若是你以为frame的alloc花费很大，想节省资源，而后又没注意到这个注释的话，极可能就会这么作。

对此有两种方案：

1. 继续只使用一个frame来接收，可是在传递给下一步(渲染、播放等)的时候，下一步的模块使用一个新的frame和av_frame_ref来接收，而不是直接的赋值。
2. 每次解码前构建一个新的AVFrame,把它传给avcodec_receive_frame，这样每次都是新的frame，互不干扰。可是在整个流程结束时，要释放这个frame.

方便来讲，是第二种方案好；但从模块化角度说，是第一种的更好，单解码这一步，要本身管理好本身的内存，即buffer的alloc和unref配套。这样内存的管理在当前的模块内部是完善的，若是出了问题，也只是其余模块出了问题。相比而言，第一种就是把内存的释放依赖在了其余模块的处理上。

AVPacket基本和AVFrame一致，只是获取packet的函数av_read_frame它并不会执行unref操做，而是直接把buf设为null。使用上面的两个方案之一也均可以规避这个问题。

无论怎样，直接的frame1=frame2这样的赋值是不可取的。固然要具体问题具体分析，时刻注意它内部是用引用计数的方式管理buf内的数据。

一点都没释放

最开始是播放中止后的内存几乎没有降低，解码后的AVFrame是用一个缓冲区来管理的，里面的frame是暂存没释放的，我觉得是这个缓冲区里有留存，而后给它添加了释放方法，结束后每一个frame都调用av_packet_free,而后奇怪的事出现了。

很明确每一个frame都调用了free或者unref，可是内存却没什么改变。哪怕释放不干净，至少要少一点吧。难道是av_packet_free不起做用？我试着把播放完的frame的free取消，但内存在播放的时候就飙涨了，说明这个是有用的。

而后缓冲区有个最大数量限制，调大这个数量，内存就上涨，调小就降低。这能够理解，由于这里面的frame都是存在的，因此确定会占内存。

结合上面一块儿就是：在结束播放后，缓冲区里的frame集体没有释放，一个都没有！

怎么查？看源码。

从av_frame_free看，这个里面起做用的仍是av_frame_unref，它的源码：

void av_buffer_unref(AVBufferRef **buf)
	{
	    if (!buf || !*buf)
	        return;
	
	    buffer_replace(buf, NULL);
	}
	
	 static void buffer_replace(AVBufferRef **dst, AVBufferRef **src)
	{
	    AVBuffer *b;
	
	    b = (*dst)->buffer;
	
	    if (src) {
	        **dst = **src;
	        av_freep(src);
	    } else
	        av_freep(dst);
	
	    if (atomic_fetch_add_explicit(&b->refcount, -1, memory_order_acq_rel) == 1) {
	        b->free(b->opaque, b->data);
	        av_freep(&b);
	    }
	}
复制代码

因此关键点就是atomic_fetch_add_explicit,这个函数有一个系列，就是进行原子性的加减乘除的，这个函数是先fetch再add,先查询再增长，因此返回的值是修改以前的。

atomic_fetch_add_explicit(&b->refcount, -1, memory_order_acq_rel) == 1整句代码就是：若是当前引用计数为1，就释放数据，由于加-1，因此条件等价于引用计数为0。

AVFrame和AVPacket的重量级数据都存在它们的buf里，data和extend_data都是从数据里引用过来的，buf是AVBufferRef类型，表示一个对于AVBuffer的引用，多一个引用，AVBuffer的引用计数就+1，少一个就-1，没有引用就释放，AVBuffer是数据的真身。对于AVFrame和AVPacket的内存管理就是依赖av_xxx_ref和av_xxx_unref这一套函数。

而后就是看一下b->free(b->opaque, b->data);这个具体调用了什么函数。在AVBuffer的文档里有个void av_buffer_default_free(void *opaque, uint8_t *data);，说是默认的释放函数，在释放AVBuffer时调用这个函数。这个函数就是调用了av_free,而av_free就是调用了free,也就是单纯的释放内存罢了。

若是b->free(b->opaque, b->data);真的是调用了这个默认的释放函数，那么内存必定会降低的。这里有个帮助很大但不知道原理的东西，就是Synbolic断点能够自动定位到源码，并且能够查看调用栈数据，相关知识只能查到这个。这样就能够在运行的时候直接看到b->free是什么东西了,它是pool_release_buffer!!!

static void pool_release_buffer(void *opaque, uint8_t *data)
{
   BufferPoolEntry *buf = opaque;
   AVBufferPool *pool = buf->pool;
   ...
   if (atomic_fetch_add_explicit(&pool->refcount, -1, memory_order_acq_rel) == 1)
       buffer_pool_free(pool);

复制代码

这里面根本没有释放data的地方，一样是引用计数操做，而后到buffer_pool_free。

/*
* This function gets called when the pool has been uninited and
* all the buffers returned to it.
*/
static void buffer_pool_free(AVBufferPool *pool)
{
   while (pool->pool) {
       BufferPoolEntry *buf = pool->pool;
       pool->pool = buf->next;

       buf->free(buf->opaque, buf->data);
       av_freep(&buf);
   }
   ff_mutex_destroy(&pool->mutex);

   if (pool->pool_free)
       pool->pool_free(pool->opaque);

   av_freep(&pool);
}
复制代码

结合这个函数、pool这个名字还有上面那两行注释，以及个人测试能够得出：

• pool是一个缓冲池，管理者众多的内存缓冲区（AVBuffer）
• 从池里生成的buffer，在释放的时候，是再回到池里，而且池的引用计数-1。也就是这是一个循环使用的缓冲池，使用引用计数来标记内部的缓冲区。
• 池构建(av_buffer_pool_init)的时候,引用计数为初始值1，调用av_buffer_pool_uninit标记为可销毁，引用计数减1，这二者恰好匹配。
• 内部每生成一个buffer，引用计数+1,回收一个buffer,引用计数-1。这二者也是匹配的。
• 结合上两点，只要合理操做，内存就能够获得释放。而没有释放，至少有一个没作到。
• 循环缓冲池的做用是为了不频繁的、大量的内存分配和释放，特别是视频帧数据，一帧就上百k。同时也解释了为何内存一点都没有释放，使用了池，要么所有释放，要么一点都不释放。

从内部再回到外部，先检查是否有frame没有释放。这时确实是有的，就在：

retval = avcodec_receive_frame(decoder->codecCtx, frame);
            
if (retval != 0) {
    TFCheckRetval("avcodec receive frame");
    av_frame_free(&frame);//漏掉了这里
    continue;
 }
复制代码

在解码失败后，就直接continue了。在乎识里，好像这里的frame是无用的，没数据的，因此就直接忽略了，接下一个。就死在了这里。

在把这种的frame都释放时候，仍是有问题，就剩下av_buffer_pool_uninit这个了。这个函数的调用里用户使用的外层很远，最终查到是从avcodec_close这里进入的。在逻辑也是合理的，解码结束了，才须要把分配的内存销毁。可是不要直接调用avcodec_close,而是使用avcodec_free_context，把codec相关的其余东西一并释放了。

到这，终于内存释放了。重点在于认识到有个pool的存在，这个在网上资料并很少。