2 movies – 4 cores – Best way to use them

Sep 19, 2007 at 11:23am

2 movies – 4 cores – Best way to use them

Hello,

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.

So,
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 !

yann

#33736
Sep 19, 2007 at 12:52pm

sounds like a very reasonable method :)

On Sep 19, 2007, at 7:23 AM, yrp wrote:

#112776
Sep 19, 2007 at 6:44pm

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.

$.02

#112777
Sep 20, 2007 at 9:45am

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.
>
> $.02

#112778
Sep 20, 2007 at 11:17pm

thanks for the comments and advice, I’ll tell you about the stuff.

yann

#112779

You must be logged in to reply to this topic.