A simple guide to Access Grid at Southampton

A note for users outside Southampton

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:

  1. Your local firewall requirements. Your firewall may restrict outgoing connections.

  2. 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 ( 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.

  1. Two-way audio, using rat. This can use up a PC on its own.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

The operators' MOO

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
    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
This puts you in the Access Grid Lobby.

To join one of the rooms, type
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
Once you are in the right room, you can broadcast a message with a leading double-quote
    " What is the audio port number?
and everybody in the room gets it.

Video and Audio

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.

Sending a computer display as a video stream

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:

  1. 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.


  2. Make sure the vic dialogs and other unwanted windows are outside the transmitted region.

  3. 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:
    Here rdesktop is the name of the window that needs to be undecorated. You can do this to all applications with:
     It is also useful to insert the line
    which 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.

  4. 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.

Patching the vic sources

The vic sources from UCL will recompile under Linux after a few fairly obvious patches. The number of warning messages is, however, alarming.

Averaging so as to capture a larger 704x576 X-window patch

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 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 ];
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);

Enabling large 704x576 patch capture in the h263+ encoder

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.

Vic problems

 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...

A Short Rant

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.

Odds and Ends, and recent developments

  1. It has been claimed that rat under Windows can get into an error state that consumes lots of CPU.

  2. The Open Mash team has been working on vic.

  3. 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.

  4. vic and rat can be persuaded to cooperate so as to switch the active video picture based on who is speaking.

  5. 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.

  6. 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?

  7. 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..

  8. Linux users can interwork with NetMeeting using Open H323.

Finally, if all else fails

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