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