Hans-Christoph Steiner wrote:

My guess is because pix_buffer stores uncompressed frames, which are much bigger. But I could be wrong.

you could store the pixes in YUV-format, which will double the amount of images you can store in a given memory (the default is RGBA) (either send the [colorspace YUV( to the [pix_film] or use [pix_yuv] just before the [pix_buffer_write])

if you think that the bottleneck is the harddisk access, you could also try to read the film from a RAM-disk (if such a thing exists on w32)

fgmasdr IOhannes

Hmm, it seems that the "ram" message never made it into the pix_film/ movie help patches. Are there any details that should be added?

.hc

On Jun 23, 2008, at 6:35 PM, chris clepper wrote:

pix_buffer store the frames uncompressed which is many times larger
than DV. You may try the 'ram' message for pix_film/movie which
will load the compressed QT mov into RAM.

On Mon, Jun 23, 2008 at 11:18 AM, rainer _ jepoxy@hotmail.com wrote: Hi, just have rebuilt one of my patches to fetch single videoframes not
from harddisc but from RAM with the pix_buffer objects. It works
great, about 20 times faster - the problem is I can`t load more
than 960 frames of Quicktime DV PAL in RAM and the 2 GB of RAM are
full.... this is strange because the hole file of about 4 min. has
about 500 MB.

Any idea why?

GEM Vers. 0.90 on WinXP

thanks, Rainer

Connect to the next generation of MSN Messenger Get it now!

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie