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

[alexander tian]

Hi, BugMaster

Thanks for your information. I see now. Let's look at the development for
the x264.

2007/11/27, BugMaster <BugMaster at narod.ru>:
>
> On Tue, 27 Nov 2007 14:28:13 +0800, alexander tian wrote:
> > 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
>
> Hi, Alexander.
> As Loren wrote this bug had been reported before and patchs for fixing
> were submited (for example,
> http://mailman.videolan.org/pipermail/x264-devel/2007-October/003634.html
> ).
>
> Hi, Loren.
> Does "experimental alternate threading scheme" meens thread-pool?
>
> _______________________________________________
> 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/20071129/0987b42f/attachment.htm