ffmpeg 编码 apng 解决内存泄露问题
来源:互联网 发布:淘宝土产店 编辑:程序博客网 时间:2024/06/02 00:12
ffmpeg 编码 apng 解决内存泄露问题
1.通过之前写的文章可以很容易进行apng的编码,但是通过使用memcheck内存检测,发现编码多张png图片造成了严重的内存泄露问题
chenglong@chenglong-virtual-machine:~/work/ffmpeg$ valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./main==9514== Memcheck, a memory error detector==9514== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.==9514== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info==9514== Command: ./main==9514== 26-11:19:57 linux device26-11:19:57 [video_decode_example]picture->linesize[0]=1920, c->width=480,c->height=480,c->format= 2826-11:19:57 encode one frame ok!!!!!!!!!!26-11:19:57 [video_decode_example]picture->linesize[0]=1920, c->width=480,c->height=480,c->format= 2826-11:19:57 encode one frame ok!!!!!!!!!!26-11:19:57 encode time = 0.009516==9514== ==9514== HEAP SUMMARY:==9514== in use at exit: 1,041,120 bytes in 4 blocks==9514== total heap usage: 412 allocs, 408 frees, 14,864,840 bytes allocated==9514== ==9514== 128 bytes in 1 blocks are still reachable in loss record 1 of 4==9514== at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==9514== by 0x8982828: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)==9514== by 0x8991B84: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)==9514== by 0x8980DB5: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)==9514== by 0x400F2C5: call_init.part.0 (dl-init.c:85)==9514== by 0x400F39E: _dl_init (dl-init.c:52)==9514== by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so)==9514== ==9514== 16,384 bytes in 1 blocks are definitely lost in loss record 2 of 4==9514== at 0x4C29BE8: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==9514== by 0x4C29C97: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==9514== by 0x6B5208C: av_malloc (in /usr/local/lib/libavutil-54.so)==9514== by 0x5A1A0E1: ??? (in /usr/local/lib/libavcodec-56.so)==9514== by 0x5AF2CE6: avcodec_encode_video2 (in /usr/local/lib/libavcodec-56.so)==9514== by 0x4425B0: encode_png(Encode_PNG_Key*, char*, int, int, int) (decode.cpp:1114)==9514== by 0x40CC28: test_encode_png(int, char**) (main.cpp:426)==9514== by 0x40CDD8: main (main.cpp:484)==9514== ==9514== 72,704 bytes in 1 blocks are still reachable in loss record 3 of 4==9514== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==9514== by 0x83D09DF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22)==9514== by 0x400F2C5: call_init.part.0 (dl-init.c:85)==9514== by 0x400F39E: _dl_init (dl-init.c:52)==9514== by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so)==9514== ==9514== 951,904 bytes in 1 blocks are possibly lost in loss record 4 of 4==9514== at 0x4C29BE8: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==9514== by 0x4C29C97: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==9514== by 0x6B5208C: av_malloc (in /usr/local/lib/libavutil-54.so)==9514== by 0x5A1A124: ??? (in /usr/local/lib/libavcodec-56.so)==9514== by 0x5AF2CE6: avcodec_encode_video2 (in /usr/local/lib/libavcodec-56.so)==9514== by 0x4425B0: encode_png(Encode_PNG_Key*, char*, int, int, int) (decode.cpp:1114)==9514== by 0x40CC28: test_encode_png(int, char**) (main.cpp:426)==9514== by 0x40CDD8: main (main.cpp:484)==9514== ==9514== LEAK SUMMARY:==9514== definitely lost: 16,384 bytes in 1 blocks==9514== indirectly lost: 0 bytes in 0 blocks==9514== possibly lost: 951,904 bytes in 1 blocks==9514== still reachable: 72,832 bytes in 2 blocks==9514== suppressed: 0 bytes in 0 blocks==9514==
通过记录可以看到大概是再调用
avcodec_encode_video2这个接口造成的,内存释放
后来查阅ffmpeg的源码找到了apng编码器
再源码目录下 libavcodec下的 pngenc.c这个文件
找到编码初始化的时候
static int encode_apng(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *pict, int *got_packet){ PNGEncContext *s = avctx->priv_data; int ret; int enc_row_size; size_t max_packet_size; APNGFctlChunk fctl_chunk; if (pict && avctx->codec_id == AV_CODEC_ID_APNG && s->color_type == PNG_COLOR_TYPE_PALETTE) { uint32_t checksum = ~av_crc(av_crc_get_table(AV_CRC_32_IEEE_LE), ~0U, pict->data[1], 256 * sizeof(uint32_t)); if (avctx->frame_number == 0) { s->palette_checksum = checksum; } else if (checksum != s->palette_checksum) { av_log(avctx, AV_LOG_ERROR, "Input contains more than one unique palette. APNG does not support multiple palettes.\n"); return -1; } } enc_row_size = deflateBound(&s->zstream, (avctx->width * s->bits_per_pixel + 7) >> 3); max_packet_size = AV_INPUT_BUFFER_MIN_SIZE + // headers avctx->height * ( enc_row_size + (4 + 12) * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // fdAT * ceil(enc_row_size / IOBUF_SIZE) ); if (max_packet_size > INT_MAX) return AVERROR(ENOMEM); if (avctx->frame_number == 0) { s->bytestream = avctx->extradata = av_malloc(FF_MIN_BUFFER_SIZE); if (!avctx->extradata) return AVERROR(ENOMEM); ret = encode_headers(avctx, pict); if (ret < 0) return ret; avctx->extradata_size = s->bytestream - avctx->extradata; s->last_frame_packet = av_malloc(max_packet_size); if (!s->last_frame_packet) return AVERROR(ENOMEM); } else if (s->last_frame) { ret = ff_alloc_packet2(avctx, pkt, max_packet_size, 0); if (ret < 0) return ret; memcpy(pkt->data, s->last_frame_packet, s->last_frame_packet_size); pkt->size = s->last_frame_packet_size; pkt->pts = pkt->dts = s->last_frame->pts; } if (pict) { s->bytestream_start = s->bytestream = s->last_frame_packet; s->bytestream_end = s->bytestream + max_packet_size; // We're encoding the frame first, so we have to do a bit of shuffling around // to have the image data write to the correct place in the buffer fctl_chunk.sequence_number = s->sequence_number; ++s->sequence_number; s->bytestream += 26 + 12; ret = apng_encode_frame(avctx, pict, &fctl_chunk, &s->last_frame_fctl); if (ret < 0) return ret; fctl_chunk.delay_num = 0; // delay filled in during muxing fctl_chunk.delay_den = 0; } else { s->last_frame_fctl.dispose_op = APNG_DISPOSE_OP_NONE; } if (s->last_frame) { uint8_t* last_fctl_chunk_start = pkt->data; uint8_t buf[26]; AV_WB32(buf + 0, s->last_frame_fctl.sequence_number); AV_WB32(buf + 4, s->last_frame_fctl.width); AV_WB32(buf + 8, s->last_frame_fctl.height); AV_WB32(buf + 12, s->last_frame_fctl.x_offset); AV_WB32(buf + 16, s->last_frame_fctl.y_offset); AV_WB16(buf + 20, s->last_frame_fctl.delay_num); AV_WB16(buf + 22, s->last_frame_fctl.delay_den); buf[24] = s->last_frame_fctl.dispose_op; buf[25] = s->last_frame_fctl.blend_op; png_write_chunk(&last_fctl_chunk_start, MKTAG('f', 'c', 'T', 'L'), buf, 26); *got_packet = 1; } if (pict) { if (!s->last_frame) { s->last_frame = av_frame_alloc(); if (!s->last_frame) return AVERROR(ENOMEM); } else if (s->last_frame_fctl.dispose_op != APNG_DISPOSE_OP_PREVIOUS) { if (!s->prev_frame) { s->prev_frame = av_frame_alloc(); if (!s->prev_frame) return AVERROR(ENOMEM); s->prev_frame->format = pict->format; s->prev_frame->width = pict->width; s->prev_frame->height = pict->height; if ((ret = av_frame_get_buffer(s->prev_frame, 32)) < 0) return ret; } // Do disposal, but not blending memcpy(s->prev_frame->data[0], s->last_frame->data[0], s->last_frame->linesize[0] * s->last_frame->height); if (s->last_frame_fctl.dispose_op == APNG_DISPOSE_OP_BACKGROUND) { uint32_t y; uint8_t bpp = (s->bits_per_pixel + 7) >> 3; for (y = s->last_frame_fctl.y_offset; y < s->last_frame_fctl.y_offset + s->last_frame_fctl.height; ++y) { size_t row_start = s->last_frame->linesize[0] * y + bpp * s->last_frame_fctl.x_offset; memset(s->prev_frame->data[0] + row_start, 0, bpp * s->last_frame_fctl.width); } } } av_frame_unref(s->last_frame); ret = av_frame_ref(s->last_frame, (AVFrame*)pict); if (ret < 0) return ret; s->last_frame_fctl = fctl_chunk; s->last_frame_packet_size = s->bytestream - s->bytestream_start; } else { av_frame_free(&s->last_frame); } return 0;}上边备注的时候红色的部分是分配内存的,
avctx->extradata = av_malloc(FF_MIN_BUFFER_SIZE);这个很容易通过外部的api进行释放,这个是
AVCodecContext内部的成员
s->last_frame_packet = av_malloc(max_packet_size);
然后查找s的定义PNGEncContext *s = avctx->priv_data;可以发现这个是AVCodecContext 里的成员变量priv_data
通过对结构体的指针移位也很容易释放这个资源
另外还有一种方法就是该ffmpeg源码重新打包,这样更放一些。
== LEAK SUMMARY:==9996== definitely lost: 0 bytes in 0 blocks==9996== indirectly lost: 0 bytes in 0 blocks==9996== possibly lost: 951,904 bytes in 1 blocks==9996== still reachable: 72,832 bytes in 2 blocks==9996== suppressed: 0 bytes in 0 blocks==9996== Reachable blocks (those to which a pointer was found) are not shown.==9996== To see them, rerun with: --leak-check=full --show-reachable=yes
阅读全文
0 0
- ffmpeg 编码 apng 解决内存泄露问题
- ffmpeg 编码 png apng图片
- 怎么解决内存泄露问题?
- 用Instruments解决内存泄露问题
- 解决ie6内存泄露的问题
- 解决Java内存泄露问题方案
- spark内存泄露的问题及解决
- 解决Office2007使用内存泄露问题
- 用Instruments解决内存泄露问题
- cvLoadImage内存泄露问题的解决
- 如何解决浏览器内存泄露问题?
- android中解决内存泄露问题
- 解决webview内存泄露的问题
- 解决webview内存泄露的问题
- basic_string内存泄露问题之分析解决
- ffmpeg 手动添加 sps pps(处理内存泄露问题)
- ffmpeg 解码 png apng 图片
- 内存泄露或内存碎片问题的解决
- mysql的水平拆分和垂直拆分
- Spring MVC POJO入参过程分析
- mysql语句 一个表统计每天产生的不同类型数据 根据类型字段 统计每天有多少
- linux 查看系统信息的一些命令及查看已安装软件包的命令
- HashMap、LinkedHashMap元素遍历机制探讨
- ffmpeg 编码 apng 解决内存泄露问题
- Ubuntu16成功安装QQ2012国际版(wine1.6.2)
- 深入理解计算机1.2 --HolleWord的程序运行到底经历了什么?
- bindService后,onServiceConnected方法没有执行
- Netty API 中文翻译(4.1.11.Final) —— 缘由
- 时间控件:my97DatePicker选择年、季度、月、周、日
- ROS教程1--创建节点
- PI与RFC连接测验
- mybatis打印出sql语句