This page is intended mainly for Southampton ECS users. If you are not working from within ECS, you will have to sort out for yourself:
Your local firewall requirements. Your firewall may restrict outgoing connections.
Your multicast arrangements. We use the Manchester or Argonne servers. You might have native multicast or might use another server.
Access Grid seems expensive and intimidating because it is usually set up in formal meeting rooms. You end up buying expensive projectors, cameras, microphones and echo cancellation kit. It doesn't have to be that way. You can just use a fast PC, a WebCam and a headset microphone. Here's how.
Most Access Grid sites use multicast technology to connect to
the other sites involved in a meeting. Unfortunately
although LeNSE, our regional
network, and the Campus firewall can support multicasts, our internal
routers do not; we have to use a server
at Manchester or, occasionally, one at Argonne. The notes here assume use of the
Manchester server george.ag.mcc.ac.uk (192.150.184.70) for both audio and video.
Almost everything works fine with the default settings of the
University and ECS firewalls. The only exception is incoming video. This
requires that incoming connections from george.ag.mcc.ac.uk be permitted to your
workstation on UDP ports 50002..50031. The University firewall already permits
this for all ECS IP addresses, so ECS users need only contact John Hallett (sysjjh@ecs.soton.ac.uk)
to have their individual workstations enabled. If you don't do this, everything
still works fine; you just don't see anybody else. They do see you.
You will need one or more fast PCs. For example, on a 267MHz AMD K6 with 384Mbytes of RAM, I can just run rat, the sound system, to two other sites. The incoming audio bandwidth grows rapidly with increasing numbers of sites. Trying to run vic, the video system, typically makes rat shut down. On the other hand, tkmoo presents almost no load to the system.
I also assume you are running on a Windows PC; alternative versions of the software run under Linux etc. I use Windows XP professional.
The Virtual Venues facility in the Access Grid software allows you, in principle, to have an integrated environment for entering Access Grid sessions. Unfortunately, it only works if you have multicast support, so it does not work at Southampton. You should completely ignore the Access Grid Toolkit->Venue->Start PIG and Access Grid Toolkit->Venue->Virtual Venues (which does work OK with tkmoo) Start menu items. You must run the tools separately; in this mode there are five completely independent parts to the Access Grid setup.
Two-way audio, using rat. This can use up a PC on its own.
Two-way video, using vic. You might choose to run two copies of vic on different PCs for incoming and outgoing video. Remember, the incoming video needs to have the firewall opened.
The operator MOO system. This provides IRC-style messaging between the operators. It presents very little system load and you should keep it running. You can also use it to ask about port numbers.
Distributed PowerPoint, for presentations. This just synchronises a power point presentation, normally served from a web page. It is a Java application and there are no firewall issues if you just want to be a client or master (presentation giver). Of course, if you want to serve either the slide transitions or the PowerPoint slides, you will need to make you peace with the firewalls, but the server role is normally taken by Manchester. This is, by all accounts, a pretty horrid system and very sensitive to the order of starting up the server, master and clients. It is being replaced by Remote PowerPoint.
VNC allows remote display of X and windows desktops. Again, servers will need to make arrangements to pass through the firewalls. The root site for the VNC system is http://www.realvnc.com.
In this short note I'll only deal with pieces 1 to 3. They are all built using tcl/tk to manage windows and menus. You can get 4 and 5 from http://www.accessgrid.org.
We start by installing the Access Grid 1.2 software from http://www-fp.mcs.anl.gov/fl/accessgrid/agpkgdownload.htm When prompted during the install process, you want to choose the PIG software.
To use this IRC-like "back channel" you need to register as an Access Grid user and get a username and password. You can set them up instantly by filling out the form at http://venues.accessgrid.org/AG/ag-register-form.html.
The distributed version of tkmoo.bat is broken, so go into C:\ag\agapps\bin
and replace tkmoo.bat with
c:
cd \ag\agapps\tkmoo
..\tcl\bin\wish82 tkmoo.tcl
You can then just double click on tkmoo.bat.
Select Connect->Access Grid Venues MUD, and log in with your
username and password. You can also edit the entry for this world in Connect->Worlds...
to include your username and password. The correct configuration is:
Host: venues.accessgrid.org
Port: 7777
User Name: YourUserName
Password: YourPassword
Connect to this world and type
enter
This puts you in the Access Grid Lobby.
@who
which lists all the current users. When you see one in a room that
interests you, just type
join Username
Actually, almost all your real conferences will be via
Manchester, so you can enter the appropriate room with
go to University of Manchester (CSAR)
Another popular place is
go to Full Sail Room
and so is
go to Meadow
" What is the audio port number?
and everybody in the room gets it.
In the Access Grid package you get rat and vic. To start them up, simply
open a command prompt, cd to C:\ag\agapps\bin and type
rat george.ag.mcc.ac.uk/50050
vic george.ag.mcc.ac.uk/50026
The port number for vic will be even, and between 50000 and 50030; the
number for rat will be at or just below 50050. You should have been told the
correct port numbers in an Email from the Manchester operators, otherwise you
can just guess. There is usually no security at all, so be careful what you say!
It is possible to run encrypted sessions, for which you will need a password
normally sent by Email; they probably won't tell it to you over an open moo
session.
Use a headset microphone to avoid echo problems; ordinary loudspeakers work fine for listening. The current version of rat seems to be unable to work with the microphone in my ClickSmart 510—but a headset mic is better anyway.
In vic, if you want to send video, you will need a web cam. Click on the "Menu" button and check the "Transmit" box. You will probably also want to lower the outgoing frame rate. My ClickSmart 510 works fine here. Almost everybody sends 352x288 (nomal) pictures using the h261 Encoder at Quality 8 or 10. If you do anything else, there is a good chance that some of the receiving vics will crash.
If all you want is a simple two-way interaction, just replace
george.ag.mcc.ac.uk with the name of the other machine with which you want to
have a meeting in both rat and vic. Of course, the firewall might
not like you accepting connections from somewhere outside.
User guides for vic and rat can be found at http://www-mice.cs.ucl.ac.uk/multimedia/software/documentation.
Usually, this is a bad idea. You will, for example, get better resolution and use up less network bandwidth if you send your PowerPoint presentation to the meeting organiser in advance. If, however, you must do it, here's how:
The X-windows (Linux/UNIX) versions of vic will send a continuous snapshot of part of the X display. The only reasonable vic setup for this data stream is to go into the menu, select 1fps rate, the x11 device, the h263+ encoder and normal size. You can pick an appropriate quality; though moving the control too far to the right might force vic to exit. In my experience all the other encoders are either very slow or render poor quality. In this configuration, vic continuously transmits the top left 352 (wide) by 288 (high) portion of the same X window on which its own dialogs display.
Notes:
In the Linux version of vic that I use, VIC v2.8ucl-1.1.3, large size does not work with the h263+ encoder. In the source for the encoder, it can be seen that 352x288 and 176x144 are the only layouts supported by h263+.
As an alternative to removing the window decorations as
described below, you can move the origin of the 352x288 patch by clicking to the
right of the X: and Y: in the X11 Grabber Controls,
entering a pixel offset (+ve from top left or -ve from bottom right) and typing
return.
Make sure the vic dialogs and other unwanted windows are
outside the transmitted region.
You probably want to avoid transmitting window decorations. If
you use the mwm window manager, you can insert the following line into your .Xdefaults
file:
Mwm*rdesktop.clientDecoration:-all
Here rdesktop is the name of the window that needs to be undecorated. You
can do this to all applications with:
Mwm*clientDecoration:-all
It
is also useful to insert the line
Mwm*clientAutoPlace:falsewhich causes most application windows to start up by default in the
top left corner of the screen. Remember that you will need to restart mwm
before these changes take effect.
Now all you have to do is start up your chosen application with geometry 352x288. Many X applications will let you use the option -geometry 352x288 , -g352x288 or -geometry 352x288+0+0 to start them up at the right size. This can be done for, for example, in Acrobat Reader (acroread), ghostscript (gs), xdvi and xv.
In general, I prefer to use a VNC X display for vic rather than a real screen. Of course, if the firewalls and your collaborators permit, you could use VNC itself to send better pictures at lower bandwidth...
What you probably really
want to do is send a PowerPoint or other Windows-based presentation. One of the
joys of this is that you can modify your presentation during the meeting,
and launch it on your partners without warning. To make this work, we need some
way of scaling a Windows screen onto 352x288 pixels of an X screen. For this you
need the rdesktop X windows client for
Remote Desktop (Windows Terminal Services). I use a modified version which can
be found
here. You want to
start it up on the Linux system with a command line something like
rdesktop -g 352x288 -k GB -l -N -u user machine
Here the -k GB option indicates a United Kingdom keyboard, user
is the username on the Windows system and machine the DNS name of the
Windows system.
Alternatively, look here if you simply want to resize your PowerPoint window on the PC. If you run an X server on the PC, you can point an X version of vic at it and gat painless screen capture,
The h263+ encoder seems to like sharp edges. I have built an experimental version of vic that averages a 704x576 region of the X-window, but the quality of rendered PowerPoint slides is worse than when imaged through 352x288 pixels, apparently because the edges are blurred. Similarly, within Windows, you will probably find it best to turn off Clear Type and Font Smoothing.
The vic sources from UCL will recompile under Linux after a few fairly obvious patches. The number of warning messages is, however, alarming.
If you want to try the
averaging patch, you need to modify vic/video/grabber-x11.cpp in
two places. The averaging is inserted into the grabber for a standard x86 24-bit
colour screen:
int
X11Grabber::X11Grab_TrueXBGR24()
{
int x, y;
uint8 *yp= (uint8 *)frame_ ;
uint8 *up= (uint8 *)yp + framesize_ ;
uint8 *vp= up + (framesize_ >> 2) ;
uint16 p0, p1 ;
uint32 d ;
#define CDy(d) (((d<<8)&0xf800)|((d>>5)&0x7e0)|((d>>19)&0x1f))
#define XGP(px,py) XGetPixel(ximage_->image,px,py)
#define XAV(m,px,py) ((((XGP(2*px,2*py)&m)+(XGP(2*px+1,2*py)&m)+(XGP(2*px,2*py+1)&m)+(XGP(2*px+1,2*py+1)&m))/4)&m)
#define XMEAN(px,py) (XAV(0xff0000,px,py)|XAV(0xff00,px,py)|XAV(0xff,px,py))
int factor=2;
for (y=0; y<height_; y++) {
for (x=0; x<width_; x+=2) {
p0 = CDy(XMEAN(x,y));
*yp++ = rgb2y_[ p0 ];
p1 = CDy(XMEAN(x+1,y));
*yp++ = rgb2y_[ p1 ];
/* average the two pixels... */
p0 = ( (p0 >> 1) & 0x7bef ) + ( (p1 >> 1) & 0x7bef ) ;
*up++ = rgb2u_[ p0 ];
}
y++;
for (x=0; x<width_; x+=2) {
p0 = CDy(XMEAN(x,y));
*yp++ = rgb2y_[ p0 ];
p1 = CDy(XMEAN(x+1,y));
*yp++ = rgb2y_[ p1 ];
/* average the two pixels... */
p0 = ( (p0 >> 1) & 0x7bef ) + ( (p1 >> 1) & 0x7bef ) ;
*vp++ = rgb2v_[ p0 ];
}
}
return 1;
}
and you also have to patch the call to
VidUtil_AllocXImage to double the image dimensions:
ximage_ = VidUtil_AllocXImage(dpy_, root_vis, root_depth_,
w*2, h*2, False);
Instead of averaging into a CIF image, you can use a larger 4CIF
image format directly. This is enabled in the GUI, but disabled in the h263+
code. The resultant image quality is very good and entirely adequate as a
replacement for distributed PowerPoint. You have to patch
vic/codec/encoder-h263v2.cpp at
H263plusEncoder::size to allow quad size images as a third size option
} else if (w == 2*CIF_WIDTH && h == 2*CIF_HEIGHT) {
state->pic->source_format = 4;
and you have to expand the bitstream buffer in vic/codec/encoder-h263v2.cpp
h263_bitstream = (char*)malloc(65536*4);
This new video format is received fine by the standard Linux vic. The windows version, however, crashes.
The vic code does not seem to be very stable. Most
of the crashes I have seen seem to be associated with freeing storage, for
example at vic/codec/encoder-h263v2.cpp:113 and at vic/codec/tmn-x/io.c:286.
In my experience, this sort of problem is usually caused by writing beyond the
allocated region of memory. Somebody needs to run it in bounds checking mode...
The Access Grid community uses absurdly high speech audio bit rates, consuming typically around 250k bit/s per site. This has two problems: first, it puts a lot of load on your PC and second, it puts a lot of load on the SUCS firewall. The National eScience centre opening generated so mush traffic to our single Access Grid room that SUCS thought they were suffering a DoS attack. It should be straightforward to persuade the participating sites to turn down their rat audio rates, if you ask them nicely.
The Access Grid community does not like to use silence suppression, as is slightly clips the start of a comment. The best way to fix this (see the paper by G3XJP in Radio Communication November 2002) is to delay the speech stream slightly. Of course, the really picky will want to delay the video a bit too. This is left as an exercise for the reader.
We currently depend on the Manchester multicast server. Each individual PC Access Grid user potentially generates as much traffic as the Escience Centre opening. Until we get better multicast technology, such as our own multicast bridge, please think about what you might be doing to the SUCS firewall by joining into a meeting from your office.
It has been claimed that rat under Windows can get into an error state that consumes lots of CPU.
The Open Mash team has been working on vic.
The current state of Multicast in the UK is described in http://www.ja.net/development/multicast/. There is a hall of shame here; apparently now only Southampton is unable to support native multicast.
vic and rat can be persuaded to cooperate so as to switch the active video picture based on who is speaking.
If you want to run your own local bridge, like the Manchester one, you need the QuickBridge software (local copy), and a sympathetic firewall. Under Linux, you can improve the responsiveness with a simple patch.
Perhaps somebody should look at a peer-to-peer variant of vic and rat. It would allow a large group of uses within a single site to be self-configuring. Perhaps http://www/peercast.org is the way to go?
VRVS uses a network of reflectors running permanent IP tunnels but uses the same vic and rat clients. They also support a number of gateway protocols to Access Grid and NetMeeting (H323 videoconferencing). There are also gateways to ISDN-based H320 (Polykom etc) videoconferencing..
Linux users can interwork with NetMeeting using Open H323.
you might just want to connect a computer-type headset to your ordinary phone, so you can chat away. The connector for the handset is commonly called an RJ-11 4P4 or 4/4, Rapid Electronics part 77-2396, and the cable end that plugs into most phones has the following pinout, looking at the end of the plug that plugs in, with the contacts on top.
4 Mic ground
2 Earphone signal
3 Earphone ground
1 Mic signal
The mic signal carries the usual +5V bias for the typical
electret mic.
So, 4 on the RJ-11 goes to the sleeve on the mic jack, 3 goes to the
sleeve on the earphone jack
2 goes to the tip and ring (1 and 2) on the earphone jack and
1 goes to the tip only (1) on the mic jack
| dan@ecs.soton.ac.uk |