[PD] A "multiple problem" with video playing

[tep]

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 at 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
>



-- 
http://www.myspace.com/nicotep
www.bedroomresearch.com/TEP
http://nicotep.free.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100128/b45f1c2a/attachment.htm>