<html><body><br>Please unsubscribe me for now I am not using this list for now.<br><br>Thanks<br>Best,<br>
-Harsha Viswanath PhD<br>
WOWSilica!<br>
email: <a href="mailto:harsha@wowsilica.com">harsha@wowsilica.com</a><br>
Ph: 408 772 7621<br>
Fax: 484 782 0384<br>
<br>
- Serving the Bay Area's technical needs for the last 15 years<br><br>
<blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px;">
-------- Original Message --------<br>
Subject: Re: [x264-devel] Delete the huge memory leak in x264.<br>
From: BugMaster <BugMaster@narod.ru><br>
Date: Tue, November 27, 2007 4:14 am<br>
To: Mailing list for x264 developers <x264-devel@videolan.org><br>
<br>
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="http://email.secureserver.net/pcompose.php#Compose" onclick="Popup.composeWindow('pcompose.php?sendto=lorenm%40u.washington.edu'); return false;">lorenm<b></b>@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="http://email.secureserver.net/pcompose.php#Compose" onclick="Popup.composeWindow('pcompose.php?sendto=x264-devel%40videolan.org'); return false;">x264-devel<b></b>@videolan.org</a><br>
> <a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">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" target="_blank">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="http://email.secureserver.net/pcompose.php#Compose" onclick="Popup.composeWindow('pcompose.php?sendto=x264-devel%40videolan.org'); return false;">x264-devel<b></b>@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></body></html>