|
From: jellybean stonerfish on 30 Jan 2008 21:58 On Tue, 29 Jan 2008 14:04:25 -0600, Moe Trin wrote: > t depends on your data recording programs. Off the top of my head, I'd > think of using a wrapper program around your recording applications such > that one application listens for a specific network packet, and on > receiving that delays a calibrated time then starts the recording. The > sending application could be the other recording application, and it > probably also needs a calibrated delay to compensate for it's own start > delays. > > Old guy I wonder if one wrapper could send a message to each of the recording program's wrappers. The message could contain a time to start recording. Each of the recording program's wrappers could calibrate itself. The same main wrapper could start of the feed also. stonerfish -- Way over my head.
From: jellybean stonerfish on 31 Jan 2008 09:57 On Wed, 30 Jan 2008 01:08:51 -0800, Giff wrote: > On 30 Gen, 03:58, jellybean stonerfish <stonerf...(a)geocities.com> > wrote: > >> >> I wonder if one wrapper could send a message to each of the recording >> program's wrappers. The message could contain a time to start recording. >> Each of the recording program's wrappers could calibrate itself. >> The same main wrapper could start of the feed also. >> > > Yes, that's basically the idea. I posted in order to look for > suggestions on how to implement it. Suppose you send time n to both recording programs and the feed program. Then use a calibration feed with a signal (clapping blocks). Start your feed at n+x, your audio recorder can be set to start at n+y and your video recorder set to start at n+z. If one of them starts too soon then make y or z a larger number. If one of them starts too late then make y or z a smaller number. If they both take too long to start, then increase x. stonerfish
|
Pages: 1 Prev: NetworkManager und wpa_supplicant overview Next: What is tcpdump's hook point? |