[GEM-dev] pix_film and "ram" message on OSX
ben at ekran.org
Tue May 30 20:22:50 CEST 2006
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
I guess [pix_multifilm] will remain a dream for now...
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 at 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
>> 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
>> 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
> 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 at iem.at
More information about the GEM-dev