<html>
<font size=3>We had this or a similar problem at NCSA at one time.&nbsp;
There was a lag in rat that grew larger the longer rat ran.&nbsp; Every
time&nbsp; we re-started rat the sync problem would get better, but then
as rat ran the delay would come back and keep getting larger.&nbsp; We
never could find and solve the exact problem, but as we upgraded cards
and drivers, the problem went away.<br>
<br>
<br>
At 06:01 AM 6/27/01 -0400, Will, Rodger (R.) wrote:<br>
<blockquote type=cite class=cite cite>I am very new to this technology,
but I assumed that with vic and rat being independent programs, that sync
would be a challenge.<br>
<br>
One of our nodes employs an automatic camera/microphone system that
switches vic's input to the active speaker's camera and microphone. I
would assume that this effect would be akin to high-motion. <br>
<br>
I will watch the stats today, and pass along the information.<br>
<br>
I agree that someone urgently needs to solve this problem in
software.<br>
<br>
-----Original Message-----<br>
From: Markus Buchhorn
[<a href="mailto:Markus.Buchhorn@anu.edu.au" eudora="autourl">mailto:Markus.Buchhorn@anu.edu.au</a>]<br>
Sent: Tuesday, June 26, 2001 11:22 PM<br>
To: ag-tech@mcs.anl.gov<br>
Subject: Re: [AG-TECH] Audio and Video Syncronization<br>
<br>
<br>
At 08:21 PM 26/06/2001 -0500, Marty Hoag wrote:<br>
&gt;However, I'm not sure how much<br>
&gt;effect [ntp] will have on the actual audio/video
syncronization.&nbsp; I've had a<br>
&gt;feeling that rat or vic can drift, especially if there is packet loss
or other<br>
&gt;weirdness but others would know more about why that is.&nbsp; I'd
also check things<br>
&gt;like the rat settings to make sure everyone is at 16khz audio and
look at the<br>
&gt;playout and decode stats for remote sites<br>
<br>
<br>
I'd always understood/assumed (I may be wrong) that the sync problem was
<br>
due to the apps being totally independent and sizing their own playout
<br>
buffers (or delays) independently. Hence if jitter and/or loss get larger
<br>
for one stream over another (packet size issues?) the playout buffer is
<br>
&quot;stretched&quot; (or delay increased) and sync goes out the window.
I think rat <br>
and vic try to keep this to a reasonably constant level, and drop the
<br>
playout delay whenever they can - but they are doing it
independently.<br>
<br>
Audio can catch up during silence, video during &quot;static&quot;
periods - so it <br>
can also be a function of the content<br>
<br>
So Marty's suggestion to watch the playout delay stats is spot on. You
need <br>
to watch both audio and video and how they relate to each other.<br>
<br>
&quot;Professional&quot;/commercial software does audio and video in the
same app, or <br>
tighly linked apps, and I'd understood it to be (partly) for that
reason.<br>
<br>
Has anybody looked at MBUS hooks for vic and rat? Synch is one of the
areas <br>
that it is meant to address.<br>
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-06.txt<br>
<br>
Perhaps one dirty option for now is to force vic/rat to drop late packets
<br>
in preference to variable buffers - set the playout delay to a
constant...<br>
<br>
Just my two bits worth. However, I can't stress enough how important it
is <br>
to ultimately get this right - we have to put up with enough crap from
the <br>
ISDN VC guys without giving them more ammunition :-) (not that ISDN is
<br>
always fully synched either...). There's no reason why we couldn't get
the <br>
synch perfect. Bundled MPEG streams would be another way we could do it,
<br>
with a little effort...<br>
<br>
Cheers,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Markus<br>
<br>
P.S. Lip synch can be lost at the *source* if the audio and video
encoders <br>
aren't time synched to each other (and ditto the decoders at the
receiving <br>
end). So it is worth doing ntp or similar. Tying it to a specific ntp
<br>
server on the Net I don't believe is necessary though, a local ntp server
<br>
should suffice.<br>
<br>
P.P.S. I'm not sure why Rodger leaving the room should make it better
<br>
(presuming it is not a personal reflection :-) ). If the encoding and
<br>
decoding is on the same machine it may be that it reduces the pressure on
<br>
the CPU on the encoding side or NIC on the machine. If they are on <br>
different machines it may be reflecting network problems somewhere
upstream <br>
(sending less/smaller packets if the video is static and the audio is
<br>
quiet). You could try watching a one-way stream, with nothing sent in the
<br>
other direction and see how it behaves, and then turn on your
transmission.<br>
<br>
Markus Buchhorn, Faculty of Engineering and
IT,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Ph: +61 2
61258810<br>
email: markus.buchhorn@anu.edu.au, mail: CSIT Bldg #108&nbsp; |Fax: +61 2
61259805<br>
Australian National University, Canberra 0200, Australia |Mobile: 0417
281429</font></blockquote></html>