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
原创粉丝点击