Prev: seems arp problem with bonding 802.3ad on centos 5
Next: NetworkManager und wpa_supplicant overview
From: Moe Trin on 29 Jan 2008 15:04
On Tue, 29 Jan 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <479efe48$1(a)news1-rz-ap.ethz.ch>, Giff wrote:

>I need to run two different recording systems each residing in a
>separate machine: one acquires audio while the other records video.
>Obviously, I want the two resulting streams to be as synchronized as
>possible, i.e., they should start recording at the same time.

"at the same time" is interesting. If you were to look at the
motion picture case, the sound track[s] are recorded on the same
piece of film, but are displaced a set distance because the device
that reads the sound will not fit into the same place as the shutter
mechanism, and that at the instant of displaying the image, the film
is (more or less) stationary in front of the projection light, while
the film is moving at 24 frame/second past the audio detector. This
separation is _about_ 26.5 (optical) or 28 (magnetic) frames ahead
of the picture. The person loading the film onto older projectors
might "miss" the 26.5 or 28 frame point by one frame either way, and
few people watching the movie would notice the error (i.e. 1/24 of a
second mismatch).

>How good do you think it would be to do this over the ethernet network?

Depends on how busy the network and both computers are - PROBABLY not
a problem, but hard to say without details.

>Also, could you suggest a way to program a script that would launch
>the recording on the second machine at the same time as the one on the
>first machine? Any pointer on where to start studying in order to
>achieve this?

It 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
From: Ignoramus1782 on 29 Jan 2008 21:57
> On Tue, 29 Jan 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <479efe48$1(a)news1-rz-ap.ethz.ch>, Giff wrote:
>
>>I need to run two different recording systems each residing in a
>>separate machine: one acquires audio while the other records video.
>>Obviously, I want the two resulting streams to be as synchronized as
>>possible, i.e., they should start recording at the same time.

You do not need to synchronize them, all you need is record an event
that would be clearly seen on video and on sound. Such as clapping
hands. There used to be a special clapping thing in video, two wood
pieces on a hinge that would clap.

i
From: Giff on 31 Jan 2008 04:04
On 29 Gen, 21:04, ibupro...(a)painkiller.example.tld (Moe Trin) wrote:

> >How good do you think it would be to do this over the ethernet network?
>
> Depends on how busy the network and both computers are - PROBABLY not
> a problem, but hard to say without details.

Well the computers will only be recording, which is actually a bit
heavy for the one recording video. The network will not be busy, as I
could actually use a crossed ethernet cable and connect the two pc's
directly.

>
> >Also, could you suggest a way to program a script that would launch
> >the recording on the second machine at the same time as the one on the
> >first machine? Any pointer on where to start studying in order to
> >achieve this?
>
> It depends on your data recording programs.

Well the video recording system is made by a colleague of mine so we
have complete control over it, that means I could check how long it
takes from when I trigger it until it writes the first frame (it is
not really video, it's more frame by frame).
I still do not know what to use for the sound recording. It should not
be anything too fancy, just able to record speech and keep it
understandable, we are in a controlled environment (no noise etc.).
For the reasoning below, I should need to know the delay it takes from
the trigger to the actual recording starts... Do you have any
suggestions on what to use?

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.

So, let me see if I have understood you. If T1 and T2 represent the
time needed by the two applications to actually start recording (I
should then measure these values), and T1>T2, I let machine 2 send
the packet to machine 1 and wait T1-T2 before issuing the start
recording command. This does not count the network delay, but I
measure that too (approximately) and add it to T1-T2.
Am I completely wrong?

Thanks

From: Giff on 31 Jan 2008 04:05
On 30 Gen, 03:57, Ignoramus1782 <ignoramus1...(a)NOSPAM.1782.invalid>
wrote:

> You do not need to synchronize them, all you need is record an event
> that would be clearly seen on video and on sound. Such as clapping
> hands. There used to be a special clapping thing in video, two wood
> pieces on a hinge that would clap.
>

Yes, that would be the last resort solution. The problem is that I am
going to record many short clips and then I will have to manually
synchronize them, one by one...

From: Giff on 31 Jan 2008 04:08
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.
 | 
Pages: 1
Prev: seems arp problem with bonding 802.3ad on centos 5
Next: NetworkManager und wpa_supplicant overview