Hi Chris,
Thanks for the answer. I guess I'm stuck with playing back about 16 movies at once then... at least per machine.
I recall using an array of pix_multiimage objects, and I think it did not reload the same images over and over again but somehow managed to access the same pixes in memory rather than reallocating...
Indeed HDV and RAM formats are big, but I'm happy with my photo-jpeg QTs. Also I'm working with a 1024x768 gemwin, so I've been dividing the resolution by the number of clips. Also since we can now get 8GB of RAM in these things I think its still faster that most arrays (with only 2-3 disks anyhow).
I guess [pix_multifilm] will remain a dream for now...
Thanks, .b.
PS: did you pass on my profiler data to Apple so that (maybe) the next version of QT will be useful for playing many clips simultaneously.
On Tue, May 30, 2006 12:26 pm, chris clepper said:
On 5/30/06, B. Bogart ben@ekran.org wrote:
Hey all, So I'm trying to seek 1 or 2 movie files, at different frames on 36
different objects. I was hoping I could put the 1 or 2 movie files into RAM, and then have all 36 pix_film seek from RAM.
Seems if I send "RAM" to all the pix_film objects GEM tries to load
them
all into RAM, even though they are the same file.
If I send ram to the first pix_film object the rest of the pix_film
objects still seek from disk, not from the RAM copy.
Of course, those are all separate objects with their own set of memory
-
otherwise it would be an unusable mess.
Could pix_film check to see if another pix_film has already loaded the
file into ram, and if it has map the frames to the same memory
location,
if it has not then load the file into RAM?
No, it would have to be some sort of new object that held a global pool
of
Quicktime movie objects. I'm not sure how feasible it is either.
With many clips you just need an array of fast disks (potencially) but I
though RAM would be a great solution since I'm seeking the same file in
many different locations at the same time.
With the usual professional formats (DV, HD, etc) the RAM limit on a process would be reached quite quickly. _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev