Re: [PD] A multiple problem with video playing
Matteo Sisti Sette wrote: tep wrote: I'm using a few computers to play some synced videos, but i can't get satisfying results using pix_movie. What is that is unsatisfying? Is the playback on each computer unsatisfying by itself (in which case I cannot be of help, whatever unsatisfying means), or is the syncronization between computers that is not perfect? In this second case, how much do you lose syncronization, i.e., how many frames of difference between any two computers do you accumulate per minute? If you just send a start signal to all computer and have them play the videos, and expect them to keep synchronized just by the exactness of their clock, I think it is impossible (with whatever software or codec) to maintain an acceptable synchro (meaning no much more than a couple of frames of difference) for more than a few minutes. I once had to do a synced playback of 3 videos and, if left to drift, they could stay apparently synchronized for as long as about 5 minutes. Indeed I was surprised by GEM's clock stability, I didn't expect so much (well actually i did, but I had been surprised a few months earlier with a similar application). To guarantee synchro within a given tolerance forever, I did a patch with one master and several (in my case 3) slaves where the master broadcast (via udp) its current time every N seconds (e.g. N=5) and each slave compared the received time with its own, and if the difference was greater than a threshold (e.g. 2 frames), it forced itself to skip or pause the needed amount of frames. It worked quite well. With a slightly more sofisticated patch you could correct the drift in a more gentle way than abruptly pausing or skipping a few frames. I used Windows (not sure whether xp or vista, I think xp) and DV-PAL codec. By the way, I never used pix_movie's auto mode: I turned it off and fed the right inlet with a counter incremented by bangs taken from the [gemhead]. But i dubt this makes any difference. I have synced several computers on a LAN successfully using a master, with a counter run by a [metro], sending frame numbers to the slaves via [netsend] and [netreceive], sending the frame number to each [pix_film] object. This way the master can also play audio which remains in sync, and pausing, scrubbing etc are all possible. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A multiple problem with video playing (was Re: Pd-list Digest, Vol 58, Issue 125)
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A multiple problem with video playing
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 zmoel...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A multiple problem with video playing
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 : 01235678012 as you can see, every fourth frame is dropped, which might look not so good. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A multiple problem with video playing
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 : 01235678012 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A multiple problem with video playing
PhotoJPEG is best for GEM I think, and the size should be fine too. Try [pix_film]? Best, Derek tep wrote: Hi I'm using a few computers to play some synced videos, but i can't get satisfying results using pix_movie. The computers are ibooks G4, maybe they're too weak ? The movies are 720x576, .mov, photo jpeg codec. Which codecs are the best, or lightest to use in pure data ? I don't need to manipulate the movies, just play some different ones at different moments, that's all. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 183: When is it for? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] A multiple problem with video playing
tep wrote: I'm using a few computers to play some synced videos, but i can't get satisfying results using pix_movie. What is that is unsatisfying? Is the playback on each computer unsatisfying by itself (in which case I cannot be of help, whatever unsatisfying means), or is the syncronization between computers that is not perfect? In this second case, how much do you lose syncronization, i.e., how many frames of difference between any two computers do you accumulate per minute? If you just send a start signal to all computer and have them play the videos, and expect them to keep synchronized just by the exactness of their clock, I think it is impossible (with whatever software or codec) to maintain an acceptable synchro (meaning no much more than a couple of frames of difference) for more than a few minutes. I once had to do a synced playback of 3 videos and, if left to drift, they could stay apparently synchronized for as long as about 5 minutes. Indeed I was surprised by GEM's clock stability, I didn't expect so much (well actually i did, but I had been surprised a few months earlier with a similar application). To guarantee synchro within a given tolerance forever, I did a patch with one master and several (in my case 3) slaves where the master broadcast (via udp) its current time every N seconds (e.g. N=5) and each slave compared the received time with its own, and if the difference was greater than a threshold (e.g. 2 frames), it forced itself to skip or pause the needed amount of frames. It worked quite well. With a slightly more sofisticated patch you could correct the drift in a more gentle way than abruptly pausing or skipping a few frames. I used Windows (not sure whether xp or vista, I think xp) and DV-PAL codec. By the way, I never used pix_movie's auto mode: I turned it off and fed the right inlet with a counter incremented by bangs taken from the [gemhead]. But i dubt this makes any difference. Not quite sure this helps... bye m. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
