This seems like a usage problem to me, if I'm reading your mail properly. Sending a bang to jit.qt.movie is the documented method for getting a frame to be shown in the interface. If you're relying on undocumented/unsupported/quirky quicktime stuff, like its playback of soundtracks with bangs, etc., you're going to run into the trouble.

For predictable behavior, "frame 10, bang" would be necessary here.

The bang message, by the way, causes QuickTime to task, which in turn causes it to figure out that the window moved.

jb

Ok. I had the impression that there is no need to bang jit.qt.movie when using the direct to window method.

Actually I intend to output 7 Pal movies (768*576) to seven screens attached to a G5 Quad with 4 (twin head) Graphic cards. It seems that I can only achieve a fluent representation of the clips when using direct to window with NO bangs. As soon as I start to bang the clips (frame n, bang) the clips start to stutter. Therefore I replay the clips with a very slow rate and send the frame numbers without bangs.

Any idea how I could fix this? Is there eventually a function like "direct to videoplane"? When I read the movie with 5040*576 Pixels and map it on a videoplane it is all too slow.

Thanks for any hints.

John.

As mentioned in previous threads, you cannot span a single window across different ~cards~ (this completely kills your frame rate) however you can successfully span across the 2 heads of a single card, so it seems you could try 3 windows (two planes each) at 1536x576, and the a 4th at 768x576, optionally, you could combine 6 movies into 3 at 1536x576 to reduce the number of videoplanes required.

another option is to use one large QXGA movie containing all the pal movies tiled, and zoom in on the content with hardware scalars. (but by then you might as well invest in synchronized dvd players or 7 minimacs etc.

good luck Dekron

-deKam