<p class="MsoNormal"><span lang="EN-US">hi, Loren</span></p><p class="MsoNormal"><span lang="EN-US">Thanks for your answer. I want to discuss
with you about question "3".<br></span></p>







<p class="MsoNormal"><span lang="EN-US">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.</span></p><p class="MsoNormal"><span lang="EN-US">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. <br></span></p>



<p class="MsoNormal"><span lang="EN-US">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. <br></span></p>



<p class="MsoNormal"><span lang="EN-US">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. <br></span></p>

<span style="font-size: 10.5pt; font-family: &quot;Times New Roman&quot;;" lang="EN-US">I think it is only reference
solution for the memory leak. Maybe the future version will not have memory
leak with full design.</span><br><br><div><span class="gmail_quote">2007/11/26, Loren Merritt &lt;<a href="mailto:lorenm@u.washington.edu">lorenm@u.washington.edu</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 26 Nov 2007, alexander tian wrote:<br><br>&gt; I found huge memory leak in the x264. There are at least 3 positions which<br>&gt; has memory leak. Such as below:<br>&gt;<br>&gt; 1. The function &quot;x264_mb_analyse_load_costs&quot; in file &quot;
analyse.c&quot;. Here only<br>&gt; &quot;malloc&quot; the buffer for the parameter &quot;*p_cost_mv[52]&quot;. But not free them in<br>&gt; the end. It should be freed at the function &quot;x264_encoder_close&quot;.<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&#39;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&#39;t free any memory, it would just<br>appease your leak detector.<br><br>&gt; 2. The parameter &quot;i_refs&quot; in the function &quot;x264_macroblock_cache_end&quot; should<br>&gt; be computed like in the &quot;x264_macroblock_cache_init&quot;. Otherwise it will
<br>&gt; cause memory leak.<br><br>Fixed, but no I don&#39;t have to duplicate the computation.<br><br>&gt; 3. Not all the new &quot;x264_frame_t&quot; are deleted at the end of encoding. So it<br>&gt; 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></blockquote>
</div><br>