ok,
got my first "official" patch (a midi controlled video scratch&break player) bug hunting ready :)
(this was discussed here before, but the workaround doesnt work for this)
my first BIG bug that i found is the memory usage of pix_movie & pix_film. i made 2 test with my d1.2ghz/256mb geforce2mx/64mb win2k...
but after closing pd+gem all memory was freed !
does any1 know how to fix this ???
i was also thinking to use a third-party memory cleaner to have as a workaround for not needing to restart pd+gem...
cheers -andre ps. if some1 is interested on the patch, i can post it here when the bug hunt is over... (gotta clean it 2 a little)
I'm still using .86 but I did find the same behavior with pix_movie under windows. everytime you switch the movie via "open" it seems to gobble up more memory. my guess is that the table that maps the frames to memory locations is taking up the space? I've resotred to stringing all my video into long big avis and jumping around in them. Works very well, last one was 1.8GB.
anyone else have any ideas as to why the memory keeps increasing when you reload the same movie (or different movies) into a pix_movie?
Thanks Ben
On Mon, 15 Apr 2002, Andre Schmidt wrote:
ok,
got my first "official" patch (a midi controlled video scratch&break = player) bug hunting ready :)
(this was discussed here before, but the workaround doesnt work for = this)
my first BIG bug that i found is the memory usage of pix_movie & = pix_film. i made 2 test with my d1.2ghz/256mb geforce2mx/64mb win2k...
- loading the same video many times (and fast) with pix_movie filled my =
memory to full in 2mins
- the same with pix_film was not so bad, but i think in 1hour the memory =
would be also full
but after closing pd+gem all memory was freed !
does any1 know how to fix this ???
i was also thinking to use a third-party memory cleaner to have as a = workaround for not needing to restart pd+gem...
cheers -andre ps. if some1 is interested on the patch, i can post it here when the bug = hunt is over... (gotta clean it 2 a little)
Ben Bogart - FMPM/F1999 wrote:
I'm still using .86 but I did find the same behavior with pix_movie under windows. everytime you switch the movie via "open" it seems to gobble up more memory. my guess is that the table that maps the frames to memory locations is taking up the space? I've resotred to stringing all my video into long big avis and jumping around in them. Works very well, last one was 1.8GB.
anyone else have any ideas as to why the memory keeps increasing when you reload the same movie (or different movies) into a pix_movie?
oops ! i have found a really bad memory-leak in my sources ! it is fixed now (but not yet online) - wait 24h....
anyhow: there is still a (small) memory-leak (the one thyt appears with [pix_film]). this is windows only and i do think (or: hope) that it is really a windows-bug. the used memory increases for 400k (or 40k?) each time, an AVI is opened.
does anyone know another application that opens A LOT (1000s) of avi's ?
mfg.cdas.dr IOhannes
Thanks Ben
On Mon, 15 Apr 2002, Andre Schmidt wrote:
Hi Johannes,
I did 70 avifile-opens per second for a few minutes with Framestein; had no effect on available memory.
Juha
----- Original Message ----- From: "IOhannes m zmoelnig" zmoelnig@iem.kug.ac.at
anyhow: there is still a (small) memory-leak (the one thyt appears with [pix_film]). this is windows only and i do think (or: hope) that it is really a windows-bug. the used memory increases for 400k (or 40k?) each time, an AVI is opened.
does anyone know another application that opens A LOT (1000s) of avi's ?