2 movies – 4 cores – Best way to use them
I’m working on a movie player for a show (like a lot of people here), and I’m looking for the best way to get the smoothest possible playback (like everybody here …), considering some posts, I’ve got some ideas, but I’m asking for some advice…
There’s no complex image processing, I just need to play back simultaneously 2 movies (768 x 576 pixels, 25 fps) from 2 playlists and display them in 2 jit.window (to 2 videoprojectors).
The computer will be a Mac Pro with 2 x 3.0GHz Dual-Core Intel Xeon, 2 GB of RAM and 2 x Nvidia Geforce 7300 GT.
in order to make the best use of the 4 cores, I’m thinking of implementing 4 patches running in 4 instances of Max Runtime which will intercommunicate with udpsend/udpreceive :
– one instance/patch would be dedicated to the (light) graphical interface (transport commands, basic monitoring, playlist in a jit.cellblock)
– another instance/patch would be the software core (ui logic, management and transmission of the commands…)
– 2 instances/patches would be the movie players themselves, each of the two is based on the Poly~ForMovies.pat example (jit.qt.movie in poly~) and a jit.window (jit.qt.movie are in directwindow mode).
My first question to the experts is : am I on the right way or am I totaly wrong ??
then, I’m asking if there’s a benefit to use a unique clock (metro) placed in the "software core" instance and transmitted to the players instances with netsend or if it would be better to put one metro in each of the two players instances.
any advice is welcome, many thanks !
sounds like a very reasonable method :)
On Sep 19, 2007, at 7:23 AM, yrp wrote:
yeah, you seem to have the basic idea down.
really it’s a matter of testing and comparing results at this point.
one suggestion to keep everything in sync (if that’s an issues) is to have one of the ‘light’ cores use the cpu system time, as your main global timer, and send time messages to each player at your framerate, rather than have each player run at it’s own timing.
but then again, that might not be the best solution, so test it out.
if someone tests this, i’d love to see the results
On Sep 19, 2007, at 7:44 PM, Robert Ramirez wrote:
> yeah, you seem to have the basic idea down.
> really it’s a matter of testing and comparing results at this point.
> one suggestion to keep everything in sync (if that’s an issues) is
> to have one of the ‘light’ cores use the cpu system time, as your
> main global timer, and send time messages to each player at your
> framerate, rather than have each player run at it’s own timing.
> but then again, that might not be the best solution, so test it out.
thanks for the comments and advice, I’ll tell you about the stuff.
Forums > Jitter