hi,
sorry i have some more questions regarding pix_film. i understand i have to use pix_film if i need to process the pixel matrix before going into openGL texture renderer.
i don't understand the way the rendering is triggered in GEM. in jitter i do a bang down the rendering tree, in GEM i specify a framerate with gemwin or i bang gemwin manually. however, the rendering chain seems to be interrupted if the pix_film object is stopped (when i send [auto 0( ). i want to halt the movie and fade it out to gray, but as soon as i stop the movie, the successive GEM objects like pix_contrast in the attached patch don't get triggered any more.
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).
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...
is it possible to specify looppoints for the movies?
thanks again, -sciss-
Send instant messages to your online friends http://au.messenger.yahoo.com
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.
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?
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.
On 2/16/07, 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.
And I forgot to add: try pix_buf and see if it does what you want.
ah yes, mutually switching between pix_film auto 0/1 and pix_buf bangs works fine! thanks!
also found the combo of pix_crop and pix_scanline useful in getting almost the same fadeout effect i had before in jitter. very nice...
good night, -sciss-
--- chris clepper cgclepper@gmail.com wrote:
On 2/16/07, 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.
And I forgot to add: try pix_buf and see if it does what you want.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Send instant messages to your online friends http://au.messenger.yahoo.com
On 2/16/07, Item State itemstatechanged@yahoo.de wrote:
ah yes, mutually switching between pix_film auto 0/1 and pix_buf bangs works fine! thanks!
also found the combo of pix_crop and pix_scanline useful in getting almost the same fadeout effect i had before in jitter. very nice...
Fair warning: I never really finished the scanline object.
--- 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
On 2/16/07, Item State itemstatechanged@yahoo.de wrote:
can i buffer the current movie frame somehow and then re-flush the buffer?
try pix_buf or the pix_buffer objects...
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.
Nato user? They did things like you want to do a lot better than c74 does.
Reasons GEM doesn't allow for QT 'ticks':
- Quicktime is only one of many API used for playback of media
- QT ticks are not easy to reconcile with the global GEM render timing
You may set the rate of a QT film using the 'rate' message and 'rate 1' will follow an internal change in fps inside a QT 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).
The metro is not so hot in Pd either. Good luck.
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.
On the contrary, the internal handling of Quicktime in GEM is extremely efficient. There is lots of code that issues a new frame only when one is needed. The way to have this work for you is to set pix_movie/film to 'auto 1' and use the 'rate' message to control playback speed.
On 2/17/07, Frank Barknecht fbar@footils.org wrote:
Hallo, chris clepper hat gesagt: // chris clepper wrote:
The metro is not so hot in Pd either. Good luck.
[metro] in Pd is hot enough to play in sync with a phasor~, see attached patch.
Media handling APIs have internal clocks and it is best to use those for the most efficient playback. It is basically impossible to sync Pd or Max to one of these APIs without some tricks (GEM) or having the API drive the app (Max/Jitter).
Also, you patch has no real load and under load Pd's scheduler begins to have lots of problems. If your media API is taking 20-30ms to return decoded frames then a metro is of little use.
Hallo, chris clepper hat gesagt: // chris clepper wrote:
On 2/17/07, Frank Barknecht fbar@footils.org wrote:
Hallo, chris clepper hat gesagt: // chris clepper wrote:
The metro is not so hot in Pd either. Good luck.
[metro] in Pd is hot enough to play in sync with a phasor~, see attached patch.
Media handling APIs have internal clocks and it is best to use those for the most efficient playback. It is basically impossible to sync Pd or Max to one of these APIs without some tricks (GEM) or having the API drive the app (Max/Jitter).
Syncing Pd's clock to other clocks of course is a difficult issue. I actually was more trying to illustrate how hot Pd's [metro] is compared to Max's [metro], which AFAIK has a lowest period of 20 msec, while Pd can go as low as 1 msec and actually could go even lower if you remove the limit in the source code (or build a metro-clone with [delay]). Even with periods that small Pd's [metro] stays tight compared to audio objects. But yes, that still doesn't make it a good choice when playing or recording video.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 2007-02-16 at 18:58 -0600, chris clepper wrote:
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).The metro is not so hot in Pd either. Good luck.
here we go again. we already had a discussion here about that topic without a satisfying conclusion (at least for me). what exactly do you mean by 'not so hot'? is it inaccurate when using it to draw something on the screen? if so, why?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On 2/17/07, Roman Haefeli reduzierer@yahoo.de wrote:
The metro is not so hot in Pd either. Good luck.
here we go again. we already had a discussion here about that topic without a satisfying conclusion (at least for me). what exactly do you mean by 'not so hot'? is it inaccurate when using it to draw something on the screen? if so, why?
Pd's logical time ignores real world 'wall time' and it also queues events. That is fine if you only deal with time inside of Pd, assume that time is perfect and want every event to fire no matter how wrong the time is, but it causes trouble with any media reliant on 'wall time'. Using a metro to drive pix_film will cause the media to drift from reference over time since events are not dropped if they do not arrive on time. The correct handling would drop the event if it did not occur in the proper window and move on thus keeping proper relation to actual time.
The original pix_record used Pd's logical time and made recordings with completely wrong timing. After adding internal timers pix_record would properly drop frames and adhere to a wall clock. The windows version still has some problems with timing and will make some Keystone Cops footage if he load is extremely high.
On 2/17/07, chris clepper cgclepper@gmail.com wrote:
properly drop frames and adhere to a wall clock. The windows version still has some problems with timing and will make some Keystone Cops footage if he load is extremely high.
I'm from the Keystone State and this offends me.
-Chuckk
Chuckk Hubbard wrote:
On 2/17/07, chris clepper cgclepper@gmail.com wrote:
properly drop frames and adhere to a wall clock. The windows version still has some problems with timing and will make some Keystone Cops footage if he load is extremely high.
I'm from the Keystone State and this offends me.
That California? http://en.wikipedia.org/wiki/Keystone_Studios I think Chris was referring to the unnaturally high playback rate of early films when played on modern equipment.
Martin
On 2/18/07, Martin Peach martin.peach@sympatico.ca wrote:
Chuckk Hubbard wrote:
On 2/17/07, chris clepper cgclepper@gmail.com wrote:
properly drop frames and adhere to a wall clock. The windows version still has some problems with timing and will make some Keystone Cops footage if he load is extremely high.
I'm from the Keystone State and this offends me.
That California? http://en.wikipedia.org/wiki/Keystone_Studios I think Chris was referring to the unnaturally high playback rate of early films when played on modern equipment.
http://en.wikipedia.org/w/index.php?title=Keystone_State I know, I was having a petulant frenzy. I was petulant, and I was having a frenzy.
-Chuckk
On Sat, 2007-02-17 at 12:58 -0600, chris clepper wrote:
On 2/17/07, Roman Haefeli reduzierer@yahoo.de wrote:
> The metro is not so hot in Pd either. Good luck. here we go again. we already had a discussion here about that topic without a satisfying conclusion (at least for me). what exactly do you mean by 'not so hot'? is it inaccurate when using it to draw something on the screen? if so, why?Pd's logical time ignores real world 'wall time' and it also queues events. That is fine if you only deal with time inside of Pd, assume that time is perfect and want every event to fire no matter how wrong the time is, but it causes trouble with any media reliant on 'wall time'. Using a metro to drive pix_film will cause the media to drift from reference over time since events are not dropped if they do not arrive on time. The correct handling would drop the event if it did not occur in the proper window and move on thus keeping proper relation to actual time.
ok. but everything you say has nothing to do specifically with [metro], but with the design of pd. [metro] itself is working ok and as expected (like many example patches of frank show).
The original pix_record used Pd's logical time and made recordings with completely wrong timing. After adding internal timers pix_record would properly drop frames and adhere to a wall clock. The windows version still has some problems with timing and will make some Keystone Cops footage if he load is extremely high.
hm. i can see why someone would rather pd/gem have to drop one or the another frame, if cpu-load is too high, when playing a movie-file, instead of playing each frame in order, while losing timing. but why would someone want [pix_record] to drop frames, while recording? i see it as a big advantage of pd, that in a case, where a patch is too heavy in cpu-load, you still could record an audio-file using [writesf~], which might take a longer time than realtime, but you'll have for sure a click-free audio-file as a result. why would someone want to have a different behaviour for video?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 2/17/07, Roman Haefeli reduzierer@yahoo.de wrote:
hm. i can see why someone would rather pd/gem have to drop one or the another frame, if cpu-load is too high, when playing a movie-file, instead of playing each frame in order, while losing timing. but why would someone want [pix_record] to drop frames, while recording?
The answer is to keep in sync with time in the real world. An example would be if I make a ten second recording but the CPU is only able to grab and compress 240 frames. On playback setting each frame to a 33 ms duration would result in a movie eight seconds long which would playback faster than the events happened in real time. Setting average frame duration to around 42ms will play the 240 frames back over ten seconds. The resulting playback might have gaps but it will show the action in the same amount of time it originally occured.
just a small advice : forget everything you learn with jitter. Gem is really diferent.
cyrille
Item State a écrit :
hi,
sorry i have some more questions regarding pix_film. i understand i have to use pix_film if i need to process the pixel matrix before going into openGL texture renderer.
i don't understand the way the rendering is triggered in GEM. in jitter i do a bang down the rendering tree, in GEM i specify a framerate with gemwin or i bang gemwin manually. however, the rendering chain seems to be interrupted if the pix_film object is stopped (when i send [auto 0( ). i want to halt the movie and fade it out to gray, but as soon as i stop the movie, the successive GEM objects like pix_contrast in the attached patch don't get triggered any more.
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).
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...
is it possible to specify looppoints for the movies?
thanks again, -sciss-
Send instant messages to your online friends http://au.messenger.yahoo.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
chris clepper -
Chuckk Hubbard -
cyrille henry -
Frank Barknecht -
Item State -
Martin Peach -
Roman Haefeli