[PD] pix_film more questions

chris clepper cgclepper at gmail.com
Sat Feb 17 01:58:27 CET 2007


On 2/16/07, Item State <itemstatechanged at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070216/bed223fb/attachment.htm>


More information about the Pd-list mailing list