FAQ

  1. What is Ultra-Videoconferencing?
  2. How do I install Ultra-Videoconferencing?
  3. How do I run Ultra-Videoconferencing?
  4. What operating systems support Ultra-Videoconferencing?
  5. What are the CPU requirements for Ultra-Videoconferencing?
  6. Can I have multiple clients connected to one server?
  7. How much network bandwidth is needed for the various modes supported by Ultra-Videoconferencing?
  8. Is Ultra-Videoconferencing RTP-compliant?
  9. What video modes are supported by Ultra-Videoconferencing?
  10. Why can't my client connect to the server?
  11. Why do I see frequent reports of bad frames or missing fragments when receiving video, even though I believe I have plenty of network capacity?
  12. Why do I see a "Unexpected error when calling select!" message or a series of "Writing : Broken pipe" diagnostics?
  13. Why do my attempts to transmit video result in a strange (non-) image?
  14. Why can't I resize the video output window?
  15. What audio modes and interfaces are supported by Ultra-Videoconferencing?
  16. What should I do if I'm seeing an error "Unsupported sample frequency 44100; card suggests -f 44101"?
  17. Why do I receive apparent error messages from the software when trying to transmit DV and see the images often freezing or apparently corrupted?
  18. How do I achieve minimum latency for interactive applications?
  19. We are running a public demo and wish to acknowledge your contribution to the project. Where can we find a logo for the McGill Ultra-Videoconferencing system?


  1. What is Ultra-Videoconferencing?
    Ultra-Videoconferencing is a flexible, low-latency IP transport system for audio, video, and vibrosensory data. We have used this system for a range of demanding applications including live concert streaming (1999), remote mixing (2000), collaborative performance (2001), distance masters classes over SDI (2002), and remote video interpreting of sign language using three simultaneous DV streams (2003). Our software supports high-resolution multichannel audio and video from either frame grabbers using v4l or v4l2 interfaces (e.g., Bt878 chipset), digital video (DV) cameras, DCAM (raw, uncompressed video) 1394 devices, and standard or high-definition Serial Digital Interface (SDI). Video can also be passed through a JPEG codec to reduce bandwidth and the video display window may be resized up to full screen.

  2. How do I install Ultra-Videoconferencing?
    Unpack the tarball with tar -xzf uv-<version>.tar.gz. The Ultra-videoconferencing system is invoked through the uv launch script, which in turn, calls the binary, bronto, so named in honour of the network traffic type it produces: traffic with a very long, heavy tail!

  3. How do I run Ultra-Videoconferencing?
    Typical usage is explained in the README file accompanying the distribution. uv -h provides general help and uv -H gives flag-by-flag details.

  4. What operating systems support Ultra-Videoconferencing?
    Ultra-Videoconferencing currently runs only under Linux systems. Release versions have been tested under Ubuntu and Fedora Core distributions, for which instructions are provided on the download page to select the appropriate version based on your installation. Your mileage with other Linuces may vary.

  5. What are the CPU requirements for Ultra-Videoconferencing?
    The CPU requirements depend entirely on what modes of transport and coding are involved. Ultra-Videoconferencing requires fairly minimal CPU power for audio-only transport, but requires PIII-1GHz or better for DV or JPEG decoding.

  6. Can I have multiple clients connected to one server?
    Yes, you can have multiple clients connected to a single uv server (bandwidth dependent). We even have rudimentary support for multicast, although this is not exposed through the uv interface at present.

  7. How much network bandwidth is needed for the various modes supported by Ultra-Videoconferencing?
    PCM audio with default sampling (44.1 kHz, 16 bit) requires approximately 706 kbps per channel. DV camera output (audio and video) consumes approximately 25 Mbps; JPEG-encoded full-frame video is similar. Uncompressed analog or dc1394 video at full-frame requires anywhere from 148-270 Mbps depending on colorspace employed; this may be reduced to as low as 37 Mbps by selecting quarter-frame size with -w 320 -h 240. Note also the importance of increasing your IP buffer on the receiving machine, as described below.

  8. Is Ultra-Videoconferencing RTP-compliant?
    No. Ultra-Videoconferencing is not RTP-compliant, nor do we have any immediate plans to make it so. The software uses its own transport mechanism that was developed specifically for our needs, some of which are incompatible with RTP.

  9. What video modes are supported by Ultra-Videoconferencing?
    Ultra-Videoconferencing supports video input from either frame grabbers using v4l or v4l2 interfaces (e.g. Bt878 chipset), digital video (DV) cameras, IIDC (raw, uncompressed video) 1394 devices, and standard or high-definition Serial Digital Interface (SDI).

  10. Why can't my client connect to the server?
    Connection failures are most often due to firewall rules or port restrictions on the network(s) you may be using. Ultra-Videoconferencing uses UDP ports 8000-8010 and the helper uv script uses TCP port 8000 on the server to accept incoming requests from clients. If in doubt, check with your network administrator.

  11. Why do I see frequent reports of bad frames or missing fragments when receiving video, even though I believe I have plenty of network capacity?
    The default IP buffers provided by the system are generally far too small to support the demands of video reception, even for compressed video such as DV. In order to correct this, you should (as root) increase the buffer temporarily with sysctl -w net.core.rmem_max=500000 or permanently, by adding the following line to /etc/sysctl.conf:
    net.core.rmem_max=500000

    Note that the latter goes into effect only after a reboot.

  12. Why do I see a "Unexpected error when calling select!" message or a series of "Writing : Broken pipe" diagnostics?
    The first one mystifies us (the developers) but the second often relates to mismatches in data rate to audio hardware, for example, from a mis-specification of the audio sampling format in a DV transmission.

  13. Why do my attempts to transmit video result in a strange (non-) image?
    The Ultra-Videoconferencing software defaults to the first valid video channel as reported by the frame grabber to the operating system. Some cards seem to report a valid channel for configurations that produce invalid video; in this case, you may wish to experiment with the -C flag (./uv -v -C <#> with <#> ranging between 0 and 4.

  14. Why can't I resize the video output window?
    Ultra-Videoconferencing makes use of the video scaling capability of your graphics card to handle resizing, so if the "maximize" button isn't available on the video window, this is most often remedied by installation of the appropriate custom graphics driver associated with your particular video card. Unless the correct driver is installed, you'll likely see the diagnostic message "Xv: not present" appear each time you invoke the client.

  15. What audio modes and devices are supported by Ultra-Videoconferencing?
    Ultra-Videoconferencing supports audio using either the Open Sound System (OSS) or Advanced Linux Sound Architecture (ALSA) interface. If your audio device is supported by OSS or ALSA drivers, it will likely work with Ultra-Videoconferencing.

  16. What should I do if I'm seeing an error "Unsupported sample frequency 44100; card suggests -f 44101"?
    Low-cost consumer sound cards and built-in motherboard audio are often tempermental with respect to the audio frequencies they claim to support. In such a case, you can instruct Ultra-Videoconferencing to use a different sampling frequency with the -f flag, as in ./uv -a -f 44.101.

  17. Why do I receive apparent error messages from the software when trying to transmit DV and see the images often freezing or apparently corrupted?
    If you're seeing complaints on the server side as well as on the client, then the problem source is at the video input rather than the network interface. Our experience is that the firewire drivers themselves are far from perfect under Linux (although they have been improving). We suggest you ensure that the computer being used is relatively current (e.g. P4-2GHz or better) and not experiencing any transient load due to other processes, in particular as related to interrupt requests.

  18. How do I achieve minimum latency for interactive applications?
    Many factors dictate end-to-end latency in audio and video transport. These include characteristics of the audio and video devices, the audio and video interface buffers, CPU scheduling, PC bus and network bandwidth, and network path delay. While most of these factors are beyond the control of typical users, general tips are to avoid video codecs (i.e., DV or JPEG encoding) as these may add anywhere from 10-60 ms of latency and similarly, avoid low-cost sound cards, as these typically employ fairly large buffers, thus increasing audio latency. Note that apart from DV, which bundles together audio and video, Ultra-Videoconferencing makes no effort to synchronize the two streams. Users wishing to adjust synchronization manually may do so using the -l parameter.

    We have measured end-to-end video latency at approximately 75 ms for analog video, 100 ms for DV, and 120 ms for JPEG. Audio latency can be lower than 20 ms when using professional sound cards, as these allow for minimal buffering.

  19. We are running a public demo and wish to acknowledge your contribution to the project. Where can we find a logo for the McGill Ultra-Videoconferencing system?
    Our logo can be downloaded in either gif or eps format.

Last updated 2 May 2010