[x264-devel] Re: Fwd: Huge memory leak in x264_encoder_open

[Ofer Shem Tov]

thanks for your response!

I am currently using x264 with one thread so I guess the fix solved
the memory leak for me but not for everybody else. What is the reason
to use more than one thread for real time encoding for 320x240 picture
size?

On 5/26/07, Alex Izvorski <aizvorski at gmail.com> wrote:
> Ofer,
>
> You're right about the memory leak, however it seems the patch you
> posted causes a crash if threads > 1.  Btw the leak is not fixed at
> 800k, it is simply number of threads*the size of a single frame, at
> large resolutions it can be pretty big ;)   Seems like h->fdec (same as
> h->threads[0]->fdec) can always be freed safely (and is not freed at
> present) but other threads' fdec are somehow different.  The frames all
> move through several queues, and also there are the frames in each
> thread which (as I understand it) share the actual plane arrays with
> frames in other threads.
>
> Yes the correct procedure to help fix problems is to post a patch to the
> mailing list.  Patches in diff -uNr format are preferred.  Please don't
> feel that you're being ignored if you don't get an immediate response to
> a patch (but yes do post it weekly or so as a reminder until you get a
> response).  People are busy, and this is a volunteer project, but they
> will get around to it when time permits.  This particular problem is not
> something that is immediately obvious to me, so I'll have to pass it
> along.
>
> Speaking of "known to be stable", check out tools/regression-test.pl and
> also make test.  It is a reasonable bet that x264 never has regressions
> that can be detected with make test, but breakage may occasionally be
> found with other combinations of options, or after changes which are
> *supposed to* produce a non-identical bitstream.  I think now that we
> have automated testing, every revision meets the same standard, except
> possibly right after major feature additions.  That said, I think people
> are open to ideas about a formal test/release process, if anyone was
> willing to volunteer to do most of the work.
>
> Regards,
> --Alex
>
> On Mon, 2007-05-21 at 15:48 +0300, Ofer Shem Tov wrote:
> > I got the x264 sources a few weeks ago from the trunk. When using it I
> > got a memory leak of around 800K between calling x264_encoder_open and
> > x264_encoder_close without doing anything between the calls.
> >
> > I looked at all the allocations and it seems that several large memory
> > blocks are allocated in x264_encoder_open by x264_frame_pop_unused
> > which calls x264_frame_new( h )
> >
> >     for( i = 0; i < h->param.i_threads; i++ )
> >     {
> >         ...
> >         h->thread[i]->fdec = x264_frame_pop_unused( h );
> >         ...
> >     }
> >
> > This frame memory was not deallocated in  x264_encoder_close so I
> > added one line to x264_encoder_close to free it and it solved the
> > leak:
> >
> >     for( i = h->param.i_threads - 1; i >= 0; i-- )
> >     {
> >         x264_macroblock_cache_end( h->thread[i] );
> >         x264_frame_delete(h->thread[i]->fdec); // ***** this line
> > solves the memory leak ****
> >         x264_free( h->thread[i]->out.p_bitstream )
> >         x264_free( h->thread[i] );
> >     }
> >
> > What is the process to get this sorted out by someone who is developing x264?
> >
> > Related question is how do I know when to update my x264 sources to a
> > newer version to something which is known to be stable? One idea is to
> > follow some other project that is tested and use what it is using or
> > just to take a snapshot when there is a week or so without any
> > commits....no idea really how to do it
> >
> > Ofer
> >
>
> --
> This is the x264-devel mailing-list
> To unsubscribe, go to: http://developers.videolan.org/lists.html
>
>

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html