ofxTextureRecorder - memory build up

@arturo

I got your addon working with OF 0.10 on OS X 10.10.5

I modified it to save an array of ofTextures. Eventually i will capture a bunch of camera frames in an array and if i like the captured content i want to save it to disk.

But it seems the memory usage goes up when reading from an array to your addon’s recorder.
If i comment out this line there is no memory build up. (but obviously no saving)

recorder.save(frames[i]);

I saw similar behaviour when using the older ofxImageSequenceRecorder addon.

Do you have any advice on what i am doing wrong?

here is my modified example:

the addon has a memory limit that you are setting at 9Gb how much memory is it consuming?

also if you have the pixels already then this addon is not very useful since it’s thought to download the pixels from a texture as fast as possible but if you already have the pixels it’s always going to be faster.

dont try to download the pixels yourself from the fbo’s texture and instead pass the fbo’s texture to the recorder directly, it’ll download it much faster than using readToPixels

currently my modified code builds up to bout 500 mb for a 60 frames.
but if i comment out the above mentioned line it stays at 90 mb.
your original code that right away saves the fbo texture also only consumes 90 mb.

i know that should not pass the fbo to pix and then again to a texture, as i am doing in my modified code.
this is just done to allow my to pure the fbo frames in to an array. just so i can test to read that array and pass it to your recorder.
and i think in passing each array frame to your recorder i get a build up.

would you know why i get the build up?
i hope this makes sense.

as i said that’s normal, the addon uses seveeral threads to download from the gpu, encode and save which can be slow depending on the format you are saving to for example. even if the recorder manages to record in realtime internally it might be using as many threads as your machine has cores to encode (or in your case 12 as you are explicitly setting the value) with several buffers to communicate between threads which depending on the resolution will easily add up to 500mb.

in this line:

 settings.maxMemoryUsage = 9000000000;

you are telling the addon to use up to around 8Gb so if it doesn’t go beyond that it’s working as expected. if you want it to use less than 500Mb just adjust that number but then it might be slower since it might not be able to use as many threads for encoding

first of all, thanks for taking the time to respond.

i made a little video that shows how using this code has a memory build up to 441 MB during saving and how it never goes back down to the MB it used before saving.

 frames[counter] = tex;
 recorder.save(frames[counter]);

but when using this next code, memory only builds up to 130MB.

 frames[counter] = tex;
 //recorder.save(frames[counter]);
 recorder.save(fbo.getTexture());

you can also see how i set maxMemoryUsage = 9000

thanks again for your time.

yes that’s normal, the addon creates a pool of pixels so it doesn’t need to constantly allocate and free memory which is really slow so when you use it for the first time it starts allocating memory until it allocates as much as it needs for every thread or passes the maximum permitted.

there’s a minimum of memory needed depending on the number of threads so even if you set it to something really low like 9Kb every thread will allocate at least 1 buffer for the raw pixels and 1 for the compressed image.

if you leave the program running for a while you’ll see that it’ll never go beyond that, there’s no memory leaks.

1 Like