Access Grid Advanced Video Status

This project aims to provide the best possible video for use in the Access Grid. The default H.261 codec was designed for (by today's standards) low bandwidth networks. While it does that quite well, its high compression and low resolution (320x240) don't allow it to be described as "high quality".

We don't necessarily aim to accommodate low bandwidth networks; we aim to provide the best video quality possible - limited only by our hardware budget, not network capability. Thus, native PAL and NTSC size streams are our base targets, higher sizes if possible.

DV standard specifies 720x576 @ 25fps; HDV is an interlaced 1440x1080 format which emulates true HDTV (1920x1080) by using non-square (4x3) pixels - 1440*4/3 = 1920. Both DV and HDV require 25Mb/s per stream.

Further, we aim for any solution to be fully integrated into the Access Grid environment, rather than something separate run alongside the AG environment. We also aim for platform neutrality, although initial development is based on the Linux platform.

Recommended System Characteristics for HDV/DV vic.

The following documentation and development-related links are available:

Technical documentation in HTML format (UML class diagrams and Doxygen-generated pages)

Latest source code in SVN repository for viewing with your web browser

To check-out the latest source code from the aforementioned SVN repository run the following command:

svn co https://svn.itee.uq.edu.au/repo/avcast/trunk/ag-media/

The instructions for running the enhanced vic on Ubuntu include a list of the additional packages (over and above a default installation) required for compiling.

Tips & Troubleshooting

HDV streams need 25Mb/s each. The DV streams from the Sony cameras use 30Mb/sec since it also contains an audio channel (not used here). H263 at PAL resolution varies depending on quality & fps settings; 3-5Mb/s is common, but 10Mb/s is possible i.e. network performance is likely to quickly become a limitation. Apart from network issues, Linux has various settings to enhance network performance.

A range of network characteristics available by pointing a java-enabled web browser to any of a number of NDT servers:

Argonne National Laboratory (Chicago, USA) http://miranda.cdt.anl.gov:7123/

University of Queensland Vislab (Brisbane, Australia) http://rrap.vislab.uq.edu.au:7123/

Rochester Institute of Technology (New York, USA) http://web100.rit.edu:7123/

These network characteristics pertain to TCP traffic (not UDP as used by vic & rat) but may still give some indication of particular problems.

ESTABLISH YOUR NETWORK CAPACITY. See if any of the participants in your collaboration session have the NDT (Network Diagnostics Tester) service running (e.g. try the NDT servers listed above). If so - give it a run on your web browser (must have java support enabled) and see the upload/download speeds together with "dropped/lost" packets statistics (by clicking on "More details" button).

BUFFER LIMITS IMPOSED BY KERNEL. Set your system's kernel socket limits to 17000000 (17 meg) by running the following commands from a shell:

sysctl -w net.core.rmem_default=65536
sysctl -w net.core.wmem_default=65536
sysctl -w net.core.rmem_max=17000000
sysctl -w net.core.wmem_max=17000000

NB: these settings will be lost when the machine next reboots, unless they are set in something like "/etc/sysctl.conf" (man sysctl for details on your system). In this case, the settings will apply to every application/process in the system (not just vic).

NB: adjustment of these buffer limits is already handled by the installer in some recent binary releases of aghdvic e.g. Slackware-12.1, Ubuntu 8.10

XSERVER/GRAPHICS-CARD SETTINGS. Make sure that your graphics card and its X server drivers:

support XVideo acceleration (if run from a shell, vic will report in that it is using Xvideo acceleration when receiving a given stream, e.g. “Using Xvideo accelerated rendering for Tcl/Tk window [xxxxx] on display [xxxxx]”);
do NOT have any automatic syncing to Vertical retrace of the monitor (a.k.a. VBLANK) in your system-wide configuration. For example if you are running the NVidia-based system, try the nvidia-settings command and (if it exists on your system) make sure that X Server's "Sync toVBlank" for XVideo is turned off in its configuration options. You may also be able to set this option via a script (e.g. which sets relevant environment variable if any).

CONFIGURE TRANSMITTING PORTION OF VIC - THE BANDWIDTH SLIDER (in transmission window).
Do not make it as large as possible (i.e. do not yank it all the way to the right). Instead, set it to be AS SMALL AS POSSIBLE, for example:

the maximum estimated bandwidth which is going to be used by currently transmitted video.
the maximum bandwidth for the slowest network link to function without dropping packets or

Also run "ulimit -a" and make sure that there are no limits on sockets and "niceness" of the processes.

MAKE RECEIVING VIC RUN IN MINIMAL MODE. For example:

with "-g" option (this disables the vic's “sync to VBLANK” mechanisms);
without "-W" option (do not use global time syncing);
with "-z" option (e.g. -z 3 with number (3) determined by how many virtual CPUs your system has with may be + 1) to utilise the multi-threaded decoding if possible ;

For info on these (and other new) options run vic without any command options.

DO SOME VALIDATION. For example, run nestat -su a number of times and see if the statistics for error/dropped packets increase.

Acknowlegdments
This work was part of the Collaboration Services Infrastructure (CSI) project of the Australian Partnership for Advanced Computing (APAC) grid program (2004-2006) and was funded jointly by APAC and the Queensland Cyber Infrastructure Foundation (QCIF). Its is currently supported by QCIF.

Contacts
Please report bugs, issues, comments to:

c dot willing (at) uq dot edu dot au