Question

我正在使用ffmpeg 3.0版本提供的muxing.c示例来创建VS 2013的MP4文件（H.264和AAC）。

样本工作正常，默认宽度＆amp;视频的高度，但是当我将宽度更改为1920并将高度更改为1080时，样本将占用近400MB的空间。整个程序中60-70％的CPU使用率（使用任务管理器和发布模式）。我也使用过多线程。

我在调用write_frame()后尝试释放编码数据包，但没有成功。只有在调用avcodec_close()后才会释放内存。

有人可以告诉我我做错了吗？

我正在为使用VS 2013测试的代码添加链接（https://drive.google.com/open?id=0B75_-V7se7tmWUhyM0ItS0kzUVk）。

屏幕截图链接https://drive.google.com/open?id=0B75_-V7se7tmVm4tUjFtSnNNSHc

样本中的STREAM_DURATION值设置为120秒（甚至600秒测试），我更改了默认高度＆amp; add_stream功能中的 AVCodecContext 的宽度值，视频类型为1080＆amp;分别是1920年。通过整个程序，它需要355 MB，而根本没有变化。我认为，一旦使用avcodec_encode_video2编码帧并将其写入文件，就应该释放内存。

如果我错了，请纠正我。

Answer 1

您无法删除已渲染的帧，您仍需要它用于下一帧。压缩对于H.264编解码器和其他许多工具的工作原理如下：检查各个帧之间的变化，并用一些代码说明用以下代码替换所有不变的内容：同上（是的，它＆＃ 39;比那复杂得多）。

但ffmpeg版本3.0.2的内存使用量相当适中：

使用288x352和10s流（默认值）运行：

==9162== HEAP SUMMARY:
==9162==     in use at exit: 40 bytes in 1 blocks
==9162==   total heap usage: 19,970 allocs, 19,969 frees, 4,036,822 bytes allocated
==9162== 
==9162== 40 bytes in 1 blocks are still reachable in loss record 1 of 1
==9162==    at 0x4C2D110: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9162==    by 0x4C2D227: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9162==    by 0xDB7B49: av_malloc (mem.c:97)
==9162==    by 0x97EE51: default_lockmgr_cb (utils.c:77)
==9162==    by 0x9854F6: ff_lock_avcodec (utils.c:3320)
==9162==    by 0x985733: avcodec_open2 (utils.c:1197)
==9162==    by 0x4674F8: open_video (muxing.c:392)
==9162==    by 0x4674F8: main (muxing.c:595)
==9162== 
==9162== LEAK SUMMARY:
==9162==    definitely lost: 0 bytes in 0 blocks
==9162==    indirectly lost: 0 bytes in 0 blocks
==9162==      possibly lost: 0 bytes in 0 blocks
==9162==    still reachable: 40 bytes in 1 blocks
==9162==         suppressed: 0 bytes in 0 blocks
==9162== 
==9162== For counts of detected and suppressed errors, rerun with: -v
==9162== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

（哦，看看Ma＆＃39;，内存泄漏！）

全高清（1920x1080，超过20倍！）

==9402== HEAP SUMMARY:
==9402==     in use at exit: 40 bytes in 1 blocks
==9402==   total heap usage: 19,970 allocs, 19,969 frees, 25,695,760 bytes allocated

这些是相同数量的分配，但是对于25mb的内存 - 21mb更多，对于20倍以上的格式似乎更合适。

将持续时间延长至120秒：

==9459== HEAP SUMMARY:
==9459==     in use at exit: 40 bytes in 1 blocks
==9459==   total heap usage: 236,157 allocs, 236,156 frees, 84,057,359 bytes allocated

最后600s：

==9821== HEAP SUMMARY:
==9821==     in use at exit: 40 bytes in 1 blocks
==9821==   total heap usage: 1,179,521 allocs, 1,179,520 frees, 340,106,248 bytes allocated

对我来说似乎很合理。

这可能是ffmpeg的确切版本而不是Windows的问题，因为较旧的快照（从4月份开始）显示了与您的版本相同的大量内存使用。

ChangeLog有点稀疏，我只找到了条目

avformat / cache：修复树条目的memleak

在3.0.1中，因此您需要搜索GIT以获取更多信息。

高记忆力复用音频和视频时ffmpeg C示例中的cpu使用情况

1 个答案: