[x264-devel] Delete the huge memory leak in x264.

[alexander tian]

hi, Loren

Thanks for your answer. I want to discuss with you about question "3".

The new "x264_frame_t" cause huge memory leak. My idea is to add two
parameters in the structure "x264_t". The one parameter "i_x264_new_frame"
is for counting the new frame number. The other parameter "*x264_new_frame[
]" is for the new frame pointer.

By using them we can create the frame structure at one position. In addtion,
we can count how many frames we have created. So we delete the created frame
completely at the end of encoding.

I test the method not only by single-thread but also by multi-thread. They
all run well. Anyone could reference by the attached file. It runs on
windows.

I must point out that my idea is not best. It has some redundant code in the
program. So anybody could reference from it and change it. Maybe somebody
have better idea to solve the problem.
I think it is only reference solution for the memory leak. Maybe the future
version will not have memory leak with full design.

2007/11/26, Loren Merritt <lorenm at u.washington.edu>:
>
> On Mon, 26 Nov 2007, alexander tian wrote:
>
> > I found huge memory leak in the x264. There are at least 3 positions
> which
> > has memory leak. Such as below:
> >
> > 1. The function "x264_mb_analyse_load_costs" in file "analyse.c". Here
> only
> > "malloc" the buffer for the parameter "*p_cost_mv[52]". But not free
> them in
> > the end. It should be freed at the function "x264_encoder_close".
>
> This is intentional. p_cost_mv is shared across all instances of x264. I
> would have made it static const instead of malloced, but then I'd have to
> write the big table literally in the source code. I could still make it
> static non-const, but that wouldn't free any memory, it would just
> appease your leak detector.
>
> > 2. The parameter "i_refs" in the function "x264_macroblock_cache_end"
> should
> > be computed like in the "x264_macroblock_cache_init". Otherwise it will
> > cause memory leak.
>
> Fixed, but no I don't have to duplicate the computation.
>
> > 3. Not all the new "x264_frame_t" are deleted at the end of encoding. So
> it
> > cause huge memory leak.
>
> This has been reported before. My reason for not accepting the patch was
> that it conflicts with my experimental alternate threading scheme.
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20071127/e40065f4/attachment.htm