Hello all,
we're having a performance (opening) in 10 days and have run into a little problem.
We are using gem to call up and play a base of movie clips (about 150 each at 512x256 cinepak) I did a test with 15 movie clips and came to an awful realization (under windows 2k):
after 4 hours of running everything looked find in the window, video still playing fast and nice. Then I looked at the system resources. PD was using 500MB RAM and 1.5GB Virtual Memory. After 5 hours PD died(quit).
So this thing is supposed to run for at least 5 hours, at best 3 days straight.
The way the patch works is that it sending a "open" message to a single pix_movie at a metro's whim. There are 15 such "open" messages called randomly. Is PD using so much memory because it keeps each clip in memory after the pix_movie has opened another one? Even when it loads the same clip twice it seems to be keeping multiple coppies in memory?
So the question is, what do I do about it? Whats the most efficient way to run many video clips on one primitive object (rectangle) Is there a way of loading all the clips into memory first and then calling each one out of memory when needed? Or is there a way of clearing the buffer everytime a new clip is loaded?
I'm trying now to get gem .87 test2 to work on linux, just to keep the thing from crashing... (I have 640MB RAM and 500MB swap space for linux)
any pointers would be appriciated... I'm now in the hunt for lmpeg3 can't find it with apt, any quick suggestions?
Thanks! Ben+ekran
Hi Ben
I have just done a live performance using similar ideas. i tested the patch solid for a couple of days, and the video didn't take up much ram at all, pix movie seems to play video back from disk (thats why other pix objects dont work with pix_movie data ...i think...;)
I reckon it may be the compressor that your using...try a software MJPEG compressor (worked for me).
Also, you could try opening up one huge movie with all your clips in it (like a wavetable) and then having messages for each section (start frame end frame etc). This way, you wont ever need to change the clip.
hope this is usefull
Goold luck
Mick G ----- Original Message ----- From: "Ben Bogart - FMPM/F1999" bbogart@acs.ryerson.ca To: "pd mailinglist" pd-list@iem.kug.ac.at Sent: Sunday, March 17, 2002 12:17 AM Subject: [PD] Many clips in Gem, best way to deal?
Hello all,
we're having a performance (opening) in 10 days and have run into a little problem.
We are using gem to call up and play a base of movie clips (about 150 each at 512x256 cinepak) I did a test with 15 movie clips and came to an awful realization (under windows 2k):
after 4 hours of running everything looked find in the window, video still playing fast and nice. Then I looked at the system resources. PD was using 500MB RAM and 1.5GB Virtual Memory. After 5 hours PD died(quit).
So this thing is supposed to run for at least 5 hours, at best 3 days straight.
The way the patch works is that it sending a "open" message to a single pix_movie at a metro's whim. There are 15 such "open" messages called randomly. Is PD using so much memory because it keeps each clip in memory after the pix_movie has opened another one? Even when it loads the same clip twice it seems to be keeping multiple coppies in memory?
So the question is, what do I do about it? Whats the most efficient way to run many video clips on one primitive object (rectangle) Is there a way of loading all the clips into memory first and then calling each one out of memory when needed? Or is there a way of clearing the buffer everytime a new clip is loaded?
I'm trying now to get gem .87 test2 to work on linux, just to keep the thing from crashing... (I have 640MB RAM and 500MB swap space for linux)
any pointers would be appriciated... I'm now in the hunt for lmpeg3 can't find it with apt, any quick suggestions?
Thanks! Ben+ekran
B. Bogart
Hi Mick,
Thanks for the quick reply.
I was hoping it might have been pd35 test 11 but 34 does the same thing, the memory just climbs, 1MB per min more or less.
I tried Indeo 5.2 this time, I only seem to have MJPEG for QT not AVI, where did you get your codec? I just tried one that plays fine in media player but gem will not load it.
I might have to do what you suggest and make a giant clip, will probably be 1.5GB though... ug!
Thanks. Ben
On Sun, 17 Mar 2002, mick grierson wrote:
Hi Ben
I have just done a live performance using similar ideas. i tested the patch solid for a couple of days, and the video didn't take up much ram at all, pix movie seems to play video back from disk (thats why other pix objects dont work with pix_movie data ...i think...;)
I reckon it may be the compressor that your using...try a software MJPEG compressor (worked for me).
Also, you could try opening up one huge movie with all your clips in it (like a wavetable) and then having messages for each section (start frame end frame etc). This way, you wont ever need to change the clip.
hope this is usefull
Goold luck
Mick G ----- Original Message ----- From: "Ben Bogart - FMPM/F1999" bbogart@acs.ryerson.ca To: "pd mailinglist" pd-list@iem.kug.ac.at Sent: Sunday, March 17, 2002 12:17 AM Subject: [PD] Many clips in Gem, best way to deal?
Hello all,
we're having a performance (opening) in 10 days and have run into a little problem.
We are using gem to call up and play a base of movie clips (about 150 each at 512x256 cinepak) I did a test with 15 movie clips and came to an awful realization (under windows 2k):
after 4 hours of running everything looked find in the window, video still playing fast and nice. Then I looked at the system resources. PD was using 500MB RAM and 1.5GB Virtual Memory. After 5 hours PD died(quit).
So this thing is supposed to run for at least 5 hours, at best 3 days straight.
The way the patch works is that it sending a "open" message to a single pix_movie at a metro's whim. There are 15 such "open" messages called randomly. Is PD using so much memory because it keeps each clip in memory after the pix_movie has opened another one? Even when it loads the same clip twice it seems to be keeping multiple coppies in memory?
So the question is, what do I do about it? Whats the most efficient way to run many video clips on one primitive object (rectangle) Is there a way of loading all the clips into memory first and then calling each one out of memory when needed? Or is there a way of clearing the buffer everytime a new clip is loaded?
I'm trying now to get gem .87 test2 to work on linux, just to keep the thing from crashing... (I have 640MB RAM and 500MB swap space for linux)
any pointers would be appriciated... I'm now in the hunt for lmpeg3 can't find it with apt, any quick suggestions?
Thanks! Ben+ekran
B. Bogart
mick grierson wrote:
Hi Ben
I have just done a live performance using similar ideas. i tested the patch solid for a couple of days, and the video didn't take up much ram at all, pix movie seems to play video back from disk (thats why other pix objects dont work with pix_movie data ...i think...;)
no that's false. pix_movie and pix_film are the very same objects, only pix_movie does load any images immediately into the texture-memory of the graphics card. that's why you cannot manipulate the pix-buffer (because they are save on the gfx-card and not in main-ram any more)
I reckon it may be the compressor that your using...try a software MJPEG compressor (worked for me).
i do not really now. i noticed similar behaviour under linux. so there is definitey a memory hole somewhere. but i did not notice it with all used libraries (i cannot remember right now which one did not leak: libmpeg1/libmpeg3/libquicktime4linux)
Also, you could try opening up one huge movie with all your clips in it (like a wavetable) and then having messages for each section (start frame end frame etc). This way, you wont ever need to change the clip.
might at least be a workaround
any pointers would be appriciated... I'm now in the hunt for lmpeg3 can't find it with apt, any quick suggestions?
i thought i had included a hint in the README.build (but obviously i have forgotten to do so) for debian systems, have a look at http://marillat.free.fr/ and follow the instructions to modify your sources.conf i think, the testing section is still very sparse, so you will either have to use the stable or the unstable version.
mfg.as.asr IOhannes
Thanks! Ben+ekran
B. Bogart
On Mon, 18 Mar 2002, IOhannes m zmoelnig wrote:
i do not really now. i noticed similar behaviour under linux. so there is definitey a memory hole somewhere. but i did not notice it with all used libraries (i cannot remember right now which one did not leak: libmpeg1/libmpeg3/libquicktime4linux)
it couldn't be those libraries, i'm actually using windows. ... this problem only seems to occur when the clips, even the same clips, are loaded many times, over and over. maybe the memory map doesn't get cleared and that's what fills up the RAM.
Also, you could try opening up one huge movie with all your clips in it (like a wavetable) and then having messages for each section (start frame end frame etc). This way, you wont ever need to change the clip.
might at least be a workaround
i just tried this and i seems to work... do you have any suggestions on a way to store all the clip in/out points?