[MPlayer-dev-eng] CrystalHD & 1080p mkv memory leaks.

[wallak at free.fr]

I've found where the issue is. ff_combine_frame is called and increase
continuously is buffer size. On the example below the buffer size is over 700MB.

Theses functions and in the case of a mkv file seem to failed to find a h264
frame properly.

The issue may be related to the ffmpeg library only.

Best Regards,
Wallak.


Hardware watchpoint 14: *0x930ce0c0

Old value = 729152502
New value = 729185580
av_fast_realloc (ptr=0x64b9a008, size=0x930ce0c, min_size=729185580) at
libavcodec/utils.c:64
64          return ptr;
(gdb) bt
#0  av_fast_realloc (ptr=0x64b9a008, size=0x930ce0c, min_size=729185580) at
libavcodec/utils.c:64
#1  0x085b2711 in ff_combine_frame (pc=0x930ce00, next=-100, buf=0xbfffd300,
buf_size=0xbfffd304) at libavcodec/parser.c:243
#2  0x084bf17e in h264_parse (s=0x9043df0, avctx=0x90fd190, poutbuf=0xbfffd388,
poutbuf_size=0xbfffd384, buf=0x9718e10 "", buf_size=33078) at
libavcodec/h264_parser.c:263
#3  0x085b247c in av_parser_parse2 (s=0x9043df0, avctx=0x90fd190,
poutbuf=0xbfffd388, poutbuf_size=0xbfffd384, buf=0x9718e10 "", buf_size=33078,
pts=-9223372036854775808, dts=-9223372036854775808, pos=0) at
libavcodec/parser.c:149
#4  0x083ede62 in decode (avctx=0x90fd190, data=0x90fd080, data_size=0xbfffd51c,
avpkt=0xbfffd4c0) at libavcodec/crystalhd.c:842
#5  0x086379cf in avcodec_decode_video2 (avctx=0x90fd190, picture=0x90fd080,
got_picture_ptr=0xbfffd51c, avpkt=0xbfffd4c0) at libavcodec/utils.c:743
#6  0x081eb5b9 in decode (sh=0x90734a0, data=0x9718e10, len=33078, flags=0) at
libmpcodecs/vd_ffmpeg.c:854
#7  0x08120b0f in decode_video (sh_video=0x90734a0, start=0x9718e10 "",
in_size=33078, drop_frame=0, pts=638.42999999999995, full_frame=0x0) at
libmpcodecs/dec_video.c:392
#8  0x080ac7d5 in generate_video_frame (blit_frame=<value optimized out>) at
mplayer.c:1879
#9  update_video (blit_frame=<value optimized out>) at mplayer.c:2551
#10 0x080b112c in main (argc=7, argv=0xbffff7b4) at mplayer.c:3868



#1  0x085b2711 in ff_combine_frame (pc=0x930ce00, next=-100, buf=0xbfffd300,
buf_size=0xbfffd304) at libavcodec/parser.c:243
    /* copy into buffer end return */
    if(next == END_NOT_FOUND){
        void* new_buffer = av_fast_realloc(pc->buffer, &pc->buffer_size,
(*buf_size) + pc->index + FF_INPUT_BUFFER_PADDING_SIZE); 
//libavcodec/parser.c:243

        if(!new_buffer)
            return AVERROR(ENOMEM);
        pc->buffer = new_buffer;
        memcpy(&pc->buffer[pc->index], *buf, *buf_size);
        pc->index += *buf_size;
        return -1;
    }

Quoting Philip Langdale <philipl at overt.org>:

> On Thu, 02 Jun 2011 01:32:06 +0200
> wallak at free.fr wrote:
>
> >
> > I was trying with the software decoder, everything is fine. This
> > issue is CrystalHD specific.
> >
> > A line that trigger this state e.g.:
> > mplayer -fs -vc ffh264crystalhd -ao null sample-1080p.mkv
> >
> > I've done some experiments with valgrind, when mplayer closed this
> > memory seems to be freed and is no more visible. So this 1MB/s memory
> > increased is tracked somewhere in the code. Maybe the h264 raw video
> > stream ?
>
> Is the sample the exact same one you had in the ts container? If not,
> please verify where the video is the same.
>
> Honestly, I find your results surprising. The crystalhd code in mplayer
> and in libcrystalhd is container neutral, so if the same video is going
> in, the container shouldn't matter. On the other hand, the container
> code is decoder neutral, so if it's an mkv bug, I'd expect it to appear
> whether you use crystalhd or the software decoder.
>
> Have you tried comparing the native mkv demuxer with the libavformat
> one?
>
> --phil
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>