Hi, BugMaster<br><br>Thanks for your information. I see now. Let's look at the development for the x264.<br><br><div><span class="gmail_quote">2007/11/27, BugMaster <<a href="mailto:BugMaster@narod.ru">BugMaster@narod.ru
</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Tue, 27 Nov 2007 14:28:13 +0800, alexander tian wrote:<br>> hi, Loren<br>
> Thanks for your answer. I want to discuss with you about question "3".<br>> The new "x264_frame_t" cause huge memory leak. My idea is to add<br>> two parameters in the structure "x264_t". The one parameter
<br>> "i_x264_new_frame" is for counting the new frame number. The other<br>> parameter "*x264_new_frame[ ]" is for the new frame pointer.<br>> By using them we can create the frame structure at one position. In
<br>> addtion, we can count how many frames we have created. So we delete<br>> the created frame completely at the end of encoding.<br>> I test the method not only by single-thread but also by<br>> multi-thread. They all run well. Anyone could reference by the
<br>> attached file. It runs on windows.<br>> I must point out that my idea is not best. It has some redundant<br>> code in the program. So anybody could reference from it and change<br>> it. Maybe somebody have better idea to solve the problem.
<br>> I think it is only reference solution for the memory leak. Maybe<br>> the future version will not have memory leak with full design.<br><br>> 2007/11/26, Loren Merritt <<a href="mailto:lorenm@u.washington.edu">
lorenm@u.washington.edu</a>>:<br>> On Mon, 26 Nov 2007, alexander tian wrote:<br><br>>> I found huge memory leak in the x264. There are at least 3 positions which<br>>> has memory leak. Such as below:<br>
>><br>>> 1. The function "x264_mb_analyse_load_costs" in file " analyse.c". Here only<br>>> "malloc" the buffer for the parameter "*p_cost_mv[52]". But not free them in
<br>>> the end. It should be freed at the function "x264_encoder_close".<br><br>> This is intentional. p_cost_mv is shared across all instances of x264. I<br>> would have made it static const instead of malloced, but then I'd have to
<br>> write the big table literally in the source code. I could still make it<br>> static non-const, but that wouldn't free any memory, it would just<br>> appease your leak detector.<br><br>>> 2. The parameter "i_refs" in the function "x264_macroblock_cache_end" should
<br>>> be computed like in the "x264_macroblock_cache_init". Otherwise it will<br>>> cause memory leak.<br><br>> Fixed, but no I don't have to duplicate the computation.<br><br>>> 3. Not all the new "x264_frame_t" are deleted at the end of encoding. So it
<br>>> cause huge memory leak.<br><br>> This has been reported before. My reason for not accepting the patch was<br>> that it conflicts with my experimental alternate threading scheme.<br><br>> --Loren Merritt
<br>> _______________________________________________<br>> x264-devel mailing list<br>> <a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>> <a href="http://mailman.videolan.org/listinfo/x264-devel">
http://mailman.videolan.org/listinfo/x264-devel</a><br><br>Hi, Alexander.<br>As Loren wrote this bug had been reported before and patchs for fixing<br>were submited (for example,<br><a href="http://mailman.videolan.org/pipermail/x264-devel/2007-October/003634.html">
http://mailman.videolan.org/pipermail/x264-devel/2007-October/003634.html</a>).<br><br>Hi, Loren.<br>Does "experimental alternate threading scheme" meens thread-pool?<br><br>_______________________________________________
<br>x264-devel mailing list<br><a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br><a href="http://mailman.videolan.org/listinfo/x264-devel">http://mailman.videolan.org/listinfo/x264-devel</a><br></blockquote>
</div><br>