--- chris clepper cgclepper@gmail.com wrote:
On 2/16/07, Item State itemstatechanged@yahoo.de wrote:
it seems also that pix_film doesn't "fire" events
when
sending the same frame number repeatedly into the right inlet (like if i switch on the metro in
attached
patch, nothing happens).
What you describe is gloriously inefficient since the frame has been decoded, processed and sent to the GPU already.
i don't want to decode the frame again, i just want the processing chain to continue at say 20 fps to fade the currently halted movie image. if i stop the movie and then adjust the contrast, nothing is happening (only if a new movie frame is decoded). can i buffer the current movie frame somehow and then re-flush the buffer?
also i need to now the current time of the movie
(preferably quicktime time refering to the movie's timebase, or milliseconds, or otherwise frame
number
could do as well). like something equivalent to
the
[gettime( message with [jit.qt.movie]. i only see
a
static output for the films's dimension and an end-of-file bang...
Why do you need this?
i have hundreds of clips and .coll files with loop points specified in movie-time (quicktime time with timebase 600 usually). the movies have variable frame rates from 8 to 15, sometimes with frame rates changing within the movie so i would like to specify the current time using movie timebase not frame number. with low fps rates, the conversion of my time values into frame indices is very coarse, and all the audio part is already composed and fine synced ... the problem is if i switch to manual mode sending the frame indices to the right inlet, i will need the precise quicktime movie timing for every single frame, and it's not possible to get it (sometimes the actual fps is like 8.357883 etc. so i will need to analyse each of 300 movies ...)
is it possible to specify looppoints for the movies?
Yes, using the total number of frames in the movie sent to the middle outlet when the film loads. Use a counter object to set the start and stop frame of the loop between 0 and the total frames of the film.
i'll do a test tomorrow. if i use a metro, will it automatically compensate for runtime jitter, i.e. will it stay stable over time (i know metro is horrors in max).
also what i don't understand: if the rendering is not triggered independant of the film but only if a new film frame is decoded, what happens if i have four movies with different frame rates? this sounds as if i get very inefficient rendering since probably four times as much rendering events will be fired than would actually be needed to compose one image of all four movies glued together.
ciao, -sciss-
Send instant messages to your online friends http://au.messenger.yahoo.com