Loadram question

Jun 29, 2006 at 8:38pm

Loadram question

What is the correct usage of loadram message to jit.qt.movie? I have tried to browse through archives, but could not find clear answer nor example patch or such.

I trying to build a patch where I switch the movie constantly – via read “thisandthat.mov” command – and I was wondering whether I could increase the performance by loading them to ram. Some of the movies are basicly the same movie with wider resolution and I switch to same time point where the previous movie ended, but there are others also… So should I send the loadram message everytime I switch the movie? Can I load all of them to ram at the beginning? If so, how? I have many jit.qt.movie objects in use.

#26637
Jun 29, 2006 at 9:04pm

#79939
Jun 30, 2006 at 8:47pm

Thanks a lot for the reply! I am now using polymovie and it seems to work, but why just loadram first few frames? At the moment I just send loadram message – without arguments – after I read the movie from disk.. I quess this should load the entire movie to ram. The limit of ram won’t propably be an issue as have 4 gigabytes “to waste”. Allthough the movies are high quality, but low res, movies…But of course, if it is possible to make the app more slick by loading just few frames… But how to do it, though? The documentation does not say anything about “Loadram spesific frames”.

An example patch would be great.

#79940
Jul 3, 2006 at 10:11am

I’d be curious what you mean by the loading a few frames in as well. I thought the useage was to read a file, then upon confirmation of the read, send the loadram message. But there’s not much documentation except list mentions of loadram, preroll, or asyncread messages and how you’re properly supposed to use them to get better results. I’ve been avoiding all three since there seemed to be various problems with them and tenuous support of these functions. Getting smooth playback/initialization of movies with any kind of complex folder structure that allows parsing through lots of files is a common enough task, but one that has evaded my many efforts.

#79941
Jul 3, 2006 at 4:00pm

the html help file documentation for loadram:

loadram { [track-number (int)] } { [time-start (int)] [time-end (int)] }
Loads a specified movie or track into RAM. Without arguments, loadram
loads the entire movie. To specify an entire track, use a valid track
number as a single argument.
Two additional arguments may be used to specify start and end times
for the loadram operation. So, loadram followed by 2 arguments will
load a specified portion of an entire movie, while loadram followed
by 3 arguments will cause the jit.qt.movie to load a portion of a
single track into RAM.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Jul 3, 2006, at 6:12 AM, Leo Mayberry wrote:

>
> I’d be curious what you mean by the loading a few frames in as
> well. I thought the useage was to read a file, then upon
> confirmation of the read, send the loadram message. But there’s
> not much documentation except list mentions of loadram, preroll, or
> asyncread messages and how you’re properly supposed to use them to
> get better results. I’ve been avoiding all three since there
> seemed to be various problems with them and tenuous support of
> these functions. Getting smooth playback/initialization of movies
> with any kind of complex folder structure that allows parsing
> through lots of files is a common enough task, but one that has
> evaded my many efforts.

#79942
Jul 11, 2006 at 2:52am

ooor… you could use jit.matrixset and save your set of videos as jitter matrix format so that there is no QT decompression happening. much easier on the system.

#79943
Jul 11, 2006 at 3:15am

only if you have enough ram to store those uncompressed frames. ;)

v a d e //

http://www.vade.info
abstrakt.vade.info

On Jul 10, 2006, at 10:52 PM, Colin Wright wrote:

>
> ooor… you could use jit.matrixset and save your set of videos as
> jitter matrix format so that there is no QT decompression
> happening. much easier on the system.

#79944

You must be logged in to reply to this topic.