Thanks Iohannes
So, i can conclude that the slaves local frame clocks are taken from the "local" gemhead objects, as explained in Matteo's answer ? Is it more reliable/light than using a metro on each computer (which would allow me to change the playback speed) ???
Also, for the codecs, no, i don't have raid system. And it's mostly laptops with slow drives. But i'm not sure to have some spare cpu to treat a compressed video codec.
2010/1/28 IOhannes m zmoelnig zmoelnig@iem.at
changed the subject back to the original mail...
Marco Donnarumma wrote:
Yep, I can confirm the same. I worked with three macs connected via LAN
and
a simple sync via a master works very well.
this will usually give you quite a lot of jitter, since the "now" in Pd drifts in the audio-buffer (network jitter is probably neglectable in a LAN, but of course you also have that), which most likely will lead to not so smooth playback. of course it depends on the material you want to play back.
the solution we came up with, was to have a master frame clock and local frame clocks on the slaves. the slaves would adjust their framerates in order to keep up with the master, if the lag between the master clock and the slave clocks was low (some frames). if the lag was too big, the slaves would "jump" to the target value.
this worked well with several "full size" (cannot remember the actual resolution) videos played back in sync with live and taped music over 90 minutes or so.
Also, maybe someone could disagree, but in my experience not-compressed movies (even full DV) are lighter for the machine.
uncompressed video is lighter for the CPU, but more load for the harddisk. the "best" codec always depends on your system (e.g. do you have a fast RAID-system?)
fgmasdr IOhannes
tep wrote:
Thanks Iohannes
So, i can conclude that the slaves local frame clocks are taken from the "local" gemhead objects, as explained in Matteo's answer ? Is it more reliable/light than using a metro on each computer (which would allow me to change the playback speed) ???
well changing the playback speed with the [metro] might be unsatisfactory, because you will have all sorts of weird re-sampling artefacts.
gemhead: + + + + + + + + + + + metro : 0 1 2 3 4 5 6 7 8 9 0 1 2 frame : 0 1 2 3 5 6 7 8 0 1 2
as you can see, every fourth frame is dropped, which might look not so good.
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
tep wrote:
Thanks Iohannes
So, i can conclude that the slaves local frame clocks are taken from the "local" gemhead objects, as explained in Matteo's answer ? Is it more reliable/light than using a metro on each computer (which would allow me to change the playback speed) ???
well changing the playback speed with the [metro] might be unsatisfactory, because you will have all sorts of weird re-sampling artefacts.
gemhead: + + + + + + + + + + + metro : 0 1 2 3 4 5 6 7 8 9 0 1 2 frame : 0 1 2 3 5 6 7 8 0 1 2
as you can see, every fourth frame is dropped, which might look not so good.
The method I have used reliably and with smooth playback is a single [metro] on the master machine, which sends the actual frame numbers to all the other machines. I think the Gemwindows had quite high framerates, linked to the refresh rates of the projectors.
All the [pix_film] objects have auto off, and are sent the frame number explicitly so there is no playback speed at all - each frame is called for independently. This allowed much more flexibility with seeking and playback speeds, and has worked with 5 old G4 mac-minis showing a very wide screen movie where it was vital that they showed exactly the same frame (there was some very fast dance movement running across several screens and the movies looped indefinitely).
Use the master to play any audio so that the metro stays in sync with the soundtrack.
Simon
-
IOhannes m zmoelnig -
Simon Wise -
tep