[x264-devel] Memory management

[BugMaster]

On Tue, 22 May 2012 16:40:21 +0200, Dieter Verslype wrote:
> Hello developer-list,

Hi.

> I have an application that frequently sets up and tears down x264
> encoders, and think there is an unclarity in the memory management of the
> encoder. I posted this same question to the doom10 forum, where they
> redirected me to this mailing list
> (http://doom10.org/index.php?topic=2258.0).

As you didn't provide any real test case (you code at doom10 can't
count as such because it missing important parts) I had to write one
myself (attached). And after long run I haven't seen any significant
memory leaks. So if you have memory leaks than most probably they are
in your code not in libx264.

> My question is the following:

> what happens with the nal units after cleaning up the encoder. I think now
> the nals of the previous frame are erased on every x264_encoder_encode
> call, but what happens with the last nals. Are they cleaned on a
> x264_encoder_close.

nals are allocated (x264_encoder_open) and freed (x264_encoder_close)
by libx264 itself. With every x264_encoder_encode buffered used for
them are overwritten (allocated/freed only sometimes when old was too
small) with new data that is why you should copy data before calling
next x264_encoder_encode.

> And what about pic_out. At first I alloc'ed it with x264_picture_alloc,
> but my app crashed on x264_picture_clean before closing the encoder. Now I
> don't even alloc it myself (and in fact I do not know why it is used).

You shouldn't allocate its planes but you should provide pointer on
structure so x264_encoder_encode can fill it as result. It is used to
get encoded frame type/dts/hdr timings and other info.

> I don't know what happens exactly, but my application's memory augments
> linearly with the number of encoders started and stopped.

Something is buggy in your code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: application/octet-stream
Size: 3575 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20120522/d163eea4/attachment.obj>