[x264-devel] Unsuscribe
Florian Bugiel
mail at bugie.de
Tue Nov 27 15:56:49 CET 2007
Maybe you should take a look at this site:
http://mailman.videolan.org/listinfo/x264-devel
and not write to the whole list!
Am Di, 27.11.2007, 15:49, schrieb harsha at wowsilica.com:
> <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 at wowsilica.com">harsha at 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 at narod.ru><br>
> Date: Tue, November 27, 2007 4:14 am<br>
> To: Mailing list for x264 developers <x264-devel at 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>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
More information about the x264-devel
mailing list