Hi Conrad, you are surely right about the bandwidth issue, yet, for the tests we have been using only a 120x90 cam resolution with a DSL down/up of 6016/676 to the sever. Would this already be too much to expect an approximately lag-free operation?
Just to describe the setting a little more in detail: we had webcam 1 in front of screen 1, focussing on openmeetings camera windows on that screen, then on client 2 I was just looking at what webcam 1 was telling me about what was going on on screen 1. Then simply waved a piece of paper on the side of client 2 and webcam 2 and checked when openmeetings camera windows on client 2 would show me that someone on client 1 would see me waving a piece of paper. So we were simply checking a full round-trip time lag. The result was absolutely frustrating: it took more than *80* secs. for me to see that indeed on the screen of client 1 somebody (=me) was waving a piece of paper within the openmeetings camera window ... Is there a way to clarify in more quantitative terms what bandwidth with what camera window size with how many participants is actually required? Or would you suggest, that based on the preceding description we are missing some configuration details which might improve performance? Xaver ----- Original Message ----- > From: Conrad Beckert <conrad_videokonfer...@gmx.de> > To: openmeetings-user@incubator.apache.org > Cc: > Sent: Wednesday, January 18, 2012 11:05 AM > Subject: Re: voice/video time lag > > Hi Xaver, > > ... one can never underestimate the bandwidth needed. In a multiuser- > scenario > with n places it grows n*(n-1). But you mentioned having only two partners > and a > remote server (outside your LAN). If both sides are on the same LAN and the > server outside - you need twice the bandwidth ... > > The difference between Openmeetings and an UDP (SIP/XMPP) based system is - > that > the TCP protocoll ensures that all packets sent will reach at the remote side > - > no matter how long it takes them. The advantage is fewer dropouts but the > downside is the delay. > > Unfortunately the delay mounts over the time, so I suspect, there is more > than > that involved than packet jam. Bigbluebutton replaced Red5 by Freeswitch as > audio mixer. I haven't tried it thoughougly yet (as it lacks freatures I > want) but delay wasn't that much of an issue there. > > In your shoes, I would set the video settings more conservatively (smaller > video) and see what happens. I could help myself by putting Openmeetings on > an > outside server. Delay still is an issue but mitigated somehow. Try to get > VDSL > or Cable if available. I still have a DSL 16000 down/1024 up connection and > it > works reasonablely well but not perfectly. > > Unless I share screens the size of 1280x1024 I'm content. VDSL will help me > for my use cases. > > Conrad >
