A couple questions:
First: I assume that reading images from [pix_buffer] is less CPU intensive than decoding a video file with [pix_film]. Is that true?
Second (and assuming the first statement is true): is there a way to dump a whole video into [pix_buffer] without doing it frame-by-frame?
Thanks + best, derek
On 7/23/07, Derek Holzer derek@umatic.nl wrote:
A couple questions:
First: I assume that reading images from [pix_buffer] is less CPU intensive than decoding a video file with [pix_film]. Is that true?
Yes. Reading and writing a pix_buffer is at most a memory copy operation.
Second (and assuming the first statement is true): is there a way to
dump a whole video into [pix_buffer] without doing it frame-by-frame?
On OSX you can load a compressed video file into RAM using the 'ram' message. This will use less memory than pix_buffer but still use CPU for decoding the video.
Hi Chris,
chris clepper wrote:
Yes. Reading and writing a pix_buffer is at most a memory copy operation.
Great! That's what I thought.
On OSX you can load a compressed video file into RAM using the 'ram' message. This will use less memory than pix_buffer but still use CPU for decoding the video.
That's the problem... we're long on memory and short on CPU with the patch I'm working on. I hoped I could use [pix_buffer] to get some of that CPU back at the expense of a lot of RAM...
Besides, I couldn't preload *all* my clips with the 'ram' message anyways. Only the one I'm currently playing. My patch has 48 clips which will be addressed by three different players, so a way of storing all the vids ahead of time is required to avoid lagtime starting the video when it's requested.
thx+best, d.
On 7/23/07, Derek Holzer derek@umatic.nl wrote:
That's the problem... we're long on memory and short on CPU with the patch I'm working on. I hoped I could use [pix_buffer] to get some of that CPU back at the expense of a lot of RAM...
Besides, I couldn't preload *all* my clips with the 'ram' message anyways. Only the one I'm currently playing. My patch has 48 clips which will be addressed by three different players, so a way of storing all the vids ahead of time is required to avoid lagtime starting the video when it's requested.
Can you fit all 48 clips uncompressed into RAM? A 1 second clip at 640x480 30fps in YCbCr is about 18.5MB (double that for RGBA) which would allow 3 and a half minutes of video to fit in 32bit address space.
Try creating a RAM disk and copy the uncompressed clips into that. RAM disks might even allow for greater than 32 bit sizes.
Hi Chris,
thanks again for helping me get this "codec issue" sorted out, and for taking it into consideration for the CVS GEM.
chris clepper wrote:
Can you fit all 48 clips uncompressed into RAM? A 1 second clip at 640x480 30fps in YCbCr is about 18.5MB (double that for RGBA) which would allow 3 and a half minutes of video to fit in 32bit address space.
I didn't even think about addressing! I just assumed that if I had all my clips in buffers, then they would be more quickly accessible. Thanks for pointing that out. Guess I'll need to read a bit more about how buffers are accessed. Suggestions? Use the Source?
Try creating a RAM disk and copy the uncompressed clips into that. RAM disks might even allow for greater than 32 bit sizes.
For shorter clips, loading direct from the HD is pleasantly faster than I expected. But when the clips get bigger, I might look into a RAMdisk. I found quite a few tutorials on making a RAM disk on OSX via Google, using everything from command line to Freeware.
One more question: if I use the "ram" message to [pix_film], does it stay in RAM when I load another one? My guess is no, of course. I suppose if I really needed speed I could make 48 [pix_film] instances, each with the clip loaded to RAM. But of course, using a RAM disk might be more efficient at that point anyways!
best, d.
-
chris clepper -
Derek Holzer